[Servatis]

if(CheckTrue() == false)
{
    return true;
}
else
{
    return false;
}

I have found several of these in the code that I have to change. I gave them the name "flipflop booleans".
One button press I found, runs through 5 of these, I think I now see the reason why this guy doesn't work here anymore. It's making me dizzy just looking at it.

This post has been edited by Servatis: 27 May 2011 - 02:42 AM

[JackOfAllTrades]

Well that's enterprisey.

[Curtis Rutland]

It's amazing the length some people will go to duplicate the ! operator.

[eclipsed4utoo]

I was making a change to an application today. We encrypt the settings file when saving and decrypt when loading it to read. The application seems to be having a problem reading and saving, so I looked at the method for encrypting....and I saw this....



This is in production code that's been running for 3 years. Not "worst", but I guess my former colleagues liked that movie.

[Momerath]

for(int i = 1; i <= 1; i++)

Found multiple times in the same file. I have no idea what they were trying to do.

[DrAcid]

Momerath, on 02 June 2011 - 01:57 PM, said:

for(int i = 1; i <= 1; i++)

Found multiple times in the same file. I have no idea what they were trying to do.

Oh my God
Why on Earth would do they do this?

Laughed hard. Choked in the end...

[Shane Hudson]

Momerath, on 02 June 2011 - 09:57 PM, said:

for(int i = 1; i <= 1; i++)

Found multiple times in the same file. I have no idea what they were trying to do.

I think this code causes the universe to implode on itself!

To be honest, I think I am probably lucky enough not to be able to add to this thread!

[JackOfAllTrades]

Wonder if the JIT would just optimize that out? It's effectively declaring a scope block or simulating a do { } while (false); loop.

[Momerath]

eclipsed4utoo, on 02 June 2011 - 09:19 AM, said:

I guess my former colleagues liked that movie.

Not enough to get the quote right And it was a book long before it was a movie (or a radio show, or a computer game, etc.)

[darkrain714]

Sergio Tapia, on 03 December 2010 - 12:05 PM, said:

Luckily I haven't had my mind scarred so bad yet, but I saw this gem in production code the other day:

if(1 == getReturnResponse())
{
}

They're what I like to call, yoda conditionals. "If blue is sky", "if broken is car". We really scolded the guy who wrote it!

I've actually seen this suggested before somewhere. It's terrible to read, but it will drop a syntax error if you forget one of the '=' instead of making you find your unintentional assignment.

[CodeGrappler]

darkrain714, on 21 June 2011 - 08:57 PM, said:

Sergio Tapia, on 03 December 2010 - 12:05 PM, said:

Luckily I haven't had my mind scarred so bad yet, but I saw this gem in production code the other day:

if(1 == getReturnResponse())
{
}

They're what I like to call, yoda conditionals. "If blue is sky", "if broken is car". We really scolded the guy who wrote it!

I've actually seen this suggested before somewhere. It's terrible to read, but it will drop a syntax error if you forget one of the '=' instead of making you find your unintentional assignment.

It's actually fairly common to do that in languages that let you do it. I.E C++ where if(i = 1) would evaluate to true. While if(1 = i) would throw a syntax error. A lot of people recommend it. I however recommend that you write it the "normal" way and just don't make mistakes

[darkrain714]

CodeGrappler, on 21 June 2011 - 09:01 PM, said:

darkrain714, on 21 June 2011 - 08:57 PM, said:

../

It's actually fairly common to do that in languages that let you do it. I.E C++ where if(i = 1) would evaluate to true. While if(1 = i) would throw a syntax error. A lot of people recommend it. I however recommend that you write it the "normal" way and just don't make mistakes

Yeah, I've never had a taste to write it that way, was just pointing out the reasoning. As to the never making mistakes part, I'll look into that one

[guardianlamppost]

I've been assigned a project and could not for the life of me understand what the purpose of these two lines were.

foreach(object obj in list)
    valueInit.Value=obj;

I continued to the class for the valueInit object and found this..

public List<object> ValueList {get;set;}
public object Value { set{ ValueList.Add(value); } }

The previous developers are no longer with the company, which leaves me to maintain this.
And it does not look better in the rest of the solution.

[Curtis Rutland]

Wow, abusing properties sucks.

A lot of people don't realize that properties are just methods with special syntax. But the people that do need to realize that just because you can do things that you can do from methods, doesn't mean that you should do them.

"Obvious behavior" should be a goal to strive for. Assigning to a property to add to an internal collection is terribly non-obvious.

[Skydiver]

Unfortunately, it takes a few rounds of being a victim of "cute" or "overly smart" code, that we as developers learn not to inflict the same pain on others and start applying the principle of "least surprise".

I admit to writing highly optimized "smart" code early in my software development career. At that time, I didn't think much of it because I assumed that people would invest the same amount of time I did in doing the initial analysis and design. As I started inheriting ownership of larger and larger code bases, then I realized that no sane person could do that and still have enough time to keep the big picture in their head when diving into a new code base.