What are the worst programming habits?

pkfox

"this" was introduced for a reason and should be used.

We can’t stop here, this is bat country - Hunter S Thompson RIP

Roger Wright

I don't have any trouble believing that story, as I've been part of worse. Back in the days when the Phalanx gun system was being developed by my company, at a demonstration session they fired it up in front of a bunch on Navy brass (unloaded, but still noisy as hell), it deployed from its clamshell mount, spun around and locked on the first available target - the bridge of the ship where all the brass stood watching. I suspect a lot of dress whites needed cleaning that afternoon, and I dearly wish I could have been there to see it. Happily, I was still in school when I started working at General Dynamics, and my Control Systems instructor was a part timer whose day job was chief engineer for Phalanx at General Dynamics. He was there, and told us all about it. Then he assigned us a 10 question take home, open book exam that contained all the field measurements, design equations for the control loop, and target classification algorithms, and required us to solve the problem and properly assign constraints and design compensation circuits to stabilize the control system. Apparently we managed to solve the problem for him, as the error never happened again, and I passed the class. That was the single, most difficult test I ever took, as it was all using real world data - not theoretical nonsense that textbooks present - and each question depended upon the answer to the one before it being correct - exactly how the real world works for an engineer. If you get step two wrong, in the real universe, everything that follows will also be wrong, though you might not notice that until step 28, years and million$ later. :-O

Will Rogers never met me.

Charl

Team work often brings out the best (and the worst) in people. My peeves are about devs who indulge in: 1. Sending an email to the dev in the next cubicle instead of simply having a chat 2. Refusing to commit code until it is "perfect" 3. Making working code not work in the name of "refactoring" 4. Spending a week perfecting the latest LINQ statement and being unable to debug or optimise the thing 5. Deciding mid-project to change data access 6. Bitching about FXCop 7. Logging? What logging? 8. Hubris 9. Read the spec - real devs don't read specs! My two fav's are: Inline braces and swallowing exceptions

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

;) 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

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.