Coding Techniques That You Absolutely Abhor

[jsmith]

All professional programmers have certain things they absolutely abhor when it comes to C++ programming, and of course half the engineers in the company do it.
Which ones do you hate the most?

To start it off, here's four of mine in one example:

bool SomeFunction() {
    bool result;
    result = false;
    if( SomeOtherFunction() == false )
       result = false;
    else
       result = true;
    return result;
}

1. Doing in 10 lines of code what could have been done in 1. 'Nuff said.

2. Declaring an uninitialized variable on one line, then initializing it on the very next line.

3. "Some booleans aren't true or false enough to be assigned to other booleans." Why not result = SomeOtherFunction()???

4. Not returning when there's nothing else to do. (The "one return per function" rule).

Two more of mine:

5. Not using an initializer list in the constructor. Instead, assign each element in the body of the constructor.

6. Not even bothering to write a constructor for a value class; instead just have the calling code willy-nilly initialize data members whereever/whenever it feels like it, so that when you need to go add new elements to the class, you have to manually find every instantiation of it to ensure the new element gets initialized in all cases.

[Mythios]

All of those things shit me :)

[g0dwyn]

7. Coding when you have a hangover.

8. Using way too many iterative loops when a well-placed recursive call would've done the same thing.

9. Using a recursive function with 5+ parameters when a well-placed iterative loop would've done handily on its own.

10. Hungarian Notation. It's just a lot of extra clutter, and it doesn't actually help all that much either.

[seymore15074]

11. What bothers me most is copy and paste. Not that it can be done, but that some professionals do it without thinking. There's nothing like going down though some code and finding bugs that are in a lot of other classes, as well--I mean character for character. If you copy anything, go through every line and understand it.

12. Another poor practice that seems all to common is not being familiar with base classes. I often find redefinition of variables and a lot of code that could be replaced by calling a default implementation in a base class. Always know your base classes.

13. Hard-coded comparison values that are already in a library or header file somewhere. Use what is already in place.

[helios]

14. Explicit comparisons to zero.

15. NULL.

16. Classes where 75% of the methods are interfaces that do nothing more than set or get members.

[Mythios]

Oh god i was working with a game a few months back where all of the classes were just like your number 16 helios - was horrible.

[helios]

I decided that every time I see something like that, I'm going to

#define private public
#define protected public 

[jsmith]

Yeah, just yesterday I fixed a bug in a line of code and then copy/pasted it to two other places that needed a similar fix. Without thinking, of course, and as it turns out I replaced one bug with four... (because the lines weren't quite identical, and I forgot to "fix" them after pasting).

Yep, 14, 15, 16 are like nails on a chalkboard to me too :)

[firedraco]

16. Classes where 75% of the methods are interfaces that do nothing more than set or get members.

>.> <.< ^^;

[g0dwyn]

14. Explicit comparisons to zero.

seconded.

[g0dwyn]

17. Iterators. I can never get them to work, and yet they're incredibly important for just about anything. Damn you, iterator gods!

[firedraco]

17. Iterators. I can never get them to work, and yet they're incredibly important for just about anything. Damn you, iterator gods!

They aren't really that complex...instead of:

vector<string> stuff;
for(int i = 0; i < stuff.size(); ++i)

use
for(vector<string>::iterator i = stuff.begin(); i != stuff.end(); ++i)

[helios]

It's a problem, though, when you have to use something like this:

for (std::map<wchar_t *,NONS_Variable *,wstrCmpCI>::iterator i=this->variables.begin();i!=this->variables.end();i++){
    //...
}

I like to torture future maintainers (including myself), by using as few typedefs as possible.

[jsmith]

Iterators are very useful for generic programming, but IMHO only if you use typedefs.

Just this weekend I had to fix a bug where things were being output in "random" order and I wanted to sort them. All I had to do was change a single typedef from vector<Foo> to set<Foo> and add operator< for Foo and the code compiled and ran the first time. Without the typedef I would have had to search and replace all occurrences of the type vector<Foo> with set<Foo>.

But the "this->" syntax is only really required inside template functions where you specifically do not want to make a function call point a customization point.

[helios]

I like to keep the this->. I've already seen what it's like to see a function call or a variable and not knowing if it's in global scope or a method.

[scythe]

A class mate told me about a programmer working for the company at which he's currently doing an internship.
In a class, there were two methods named:

start(); and start_();

He thought that was a bit weird, so he asked the programmer.
Programmer says:
"Oh, the start_(); is a stop method. I was thinking "start" with a boolean inverter, but since you can't draw lines above the name, I just made a line at the end instead."


I thought that was a bit funny. =)

[firedraco]

Yeah, I like using this-> as well. It makes it more clear (at least to me) and easily understandable.

"Oh, the start_(); is a stop method. I was thinking "start" with a boolean inverter, but since you can't draw lines above the name, I just made a line at the end instead."

Lolz, my response: How about "stop()"!!!