What are the worst programming habits?

[Plamen Dragiyski]

Since I use javascript I'm guilty about 2), but here it is: 6) use of lambda functions inside lambda functions (even inside lambda functions). 7) inline conditions, functions and constructing objects:

var i, o;
for(i = 0; (function() { ... })(); ++i) {
o = new (objlist[i])();
}

Although I never allowed 3). If a tool cannot properly autoformat my code, according to my standards, then that tool is thrown away.

[Stefan_Lang]

That's got nothing to do with self-commenting code, it's just that the comments are pointless - which is yet another bad programming habit:

n+1. comments that state the obvious

In your example, comments could still be useful if they pointed out e. g. what is expected of the user object to be considered valid, what is expected of the user to fix the problem, or if the user not being valid may be an indication of an internal error, because the user object is expected to be in a valid state upon calling this function.

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

[Stefan_Lang]

Could have been worse, like

const int FiveHundred= 450;

;P

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

[Stefan_Lang]

Forogar wrote:

Which one to delete when refactoring?

Both. :cool:

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

[Stefan_Lang]

Jacquers wrote:

university [...] didn't teach him good coding standards

Coding standards? At university? :omg:

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

[R Erasmus]

Checking code into source control that doesn't compile.

"Program testing can be used to show the presence of bugs, but never to show their absence." << please vote!! >>

[R Erasmus]

Neglecting the design phase: - reverse engineering the design requirements because the design was neglected.

"Program testing can be used to show the presence of bugs, but never to show their absence." << please vote!! >>

[Martin Hart Turner]

0. ;) 3) This can be a project killer, good observation. 4) There is no excuse nowadays, there are plenty of tools available to help with refactoring. 5) :mad: 6.1) Unforgivable! Good observations!

[Peter Adam]

2. Short variable names. But usually using my own conventions: Array processing: i for rows, j for columns, v for current value; read/written from/to file: d for data, c for counting, etc. Why? Because I try to keep 80 columns of code. C# constants are superfluous (MessageBoxDefaultButton.Button1 FTW!), no way to keep the 80 columns, so I use more descriptive variable names there.

[Stefan Bogdan]

Never ending methods.

[Herbie Mountjoy]

Re-using code blocks in different applications without checking that the pre-existing comments are relevant in the latest incarnation. I keep finding examples of this in my archive. Stupid boy...

I may not last forever but the mess I leave behind certainly will.

[greldak]

Nish Sivakumar wrote:

Sometimes, it is though.

not really - the comments that are there are irrelevant but the ones that are needed are missing. The user is valid so why does it need updating?

[Member 9063556]

1. Leaving Edits in the code (Edits are messages that often pop up in developmental purposes for our in-house testing) 2) Bad tabbing. Don't blame me, really. I use a different tabbing structure due to the program we use doesn't automatically tab things well.

if (Broken) then fix.this else !fix.this end-if

[Rosenne]

Wrong or obsolete comments.

[Mel Padden]

I've seen the best and worst of stuff, but I've grown so used to it I just edit it out. There are modern tools to autoformat code in any case, I think the only things I would seriously have a problem with on that list are 4 and 5. Worst coding pet peeve? Code that isn't written defensively, with a mind to robustness, or that is not fully tested.

I too dabbled in pacifism once.

[SortaCore]

Some code I write includes the "sneaky minus".

someFunc(300, 250 * abc, -(500-otherVar * (3+abc), 592.3f);
// ^

I generally document that, unless the logic shouldn't ever need changing.

[SortaCore]

pfld_ is a pointer to a fixed long double and it ranks under other variables in testing. Hence, the underscore notation.

[SortaCore]

class uhoh
{
bool yay;
uhoh(bool yay)
{
this.yay = yay;
}
}

... is usually the only time I want to use "this". Unless there was another "uhoh" being involved in an uhoh function. Which is probably not good practice.

[Lost User]

I'm not into saving keystrokes; but it does convey the same information using less symbols. For your comparison:

// Delphi style;
procedure Test()
begin
end

// C#
void Test()
{
}

Would you like to imply that we use "{" and "}" merely to save keystrokes? You cannot deny that C# is a bit more readable than COBOL. Still, feel free to state the obvious if you feel like you have to :) It's a non-discussion. Try

11 + 2 = 13
Eleven plus two is thirteen

Would we prefer the first version, just to save keystrokes? And which of the two explains the fastest what is going on?

Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]

[Lost User]

PIEBALDconsult wrote:

the class is private? :confused: How does that work?

Create a new console-application. Look at the access modifier for "Program" and it's entrypoint. Both are private. Surprised? :)

Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]