|
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!! >>
|
|
|
|
|
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!! >>
|
|
|
|
|
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.
|
|
|
|
|
|
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
|
|
|
|
|
Wrong or obsolete comments.
|
|
|
|
|
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.
|
|
|
|
|
Allow me to submit something a bit off-axis: a habit of thought.
In more than one place where I've worked, I've encountered persons so confident in their skills that they didn't bother to test "trivial changes." Such "trivial changes" caused major crashes in important products, more often than I (or they) would care to remember. Inasmuch as for many years it's been a large part of my responsibilities to train young software engineers, it's been the very first thing I've pounded on: there is no such thing as a change too small to test.
Some took the advice to heart, but not all -- and when the bills came due, the incredulity of the sinner at issue was often thick enough to slice: "But all I did was...!"
We're fallible, each and every one of us, from the dunces to the geniuses, and from the brand-new graduates to the fifty-year veterans. But an engineer's ego can be resistant to that homily...until he's experienced the consequences on his own hide.
My "favorite" case of excessive confidence involves a young turk -- let's call him Andy, as that was his name -- who was assigned a component in a large monolithic application intended to run on a VAX under VMS. Andy was excessively fond of assembly language, and was eager to write his piece in VAX assembler. I counseled him against it -- the rest of the application was written in C -- but couldn't dissuade him. To shorten the story a bit, some weeks later Andy presented me with his component, which I added to the build without comment. The resulting application ran for approximately twenty seconds before it crashed -- and it didn't just bring down the app; it crashed VMS with a "bug check" error.
The problem was, of course, in Andy's module. I pointed it out to him at once. The subsequent exchange ran roughly as follows:
FWP: Did you test it?
Andy: Well...
FWP: This instruction [I pointed it out] is out of sequence. You have to allocate and enable mapping registers before it will be valid.
Andy: Well...
FWP: I expected you to test this before you brought it to the link.
Andy: But it assembled without errors, so I figured it was right!
Words fail me, friends.
(This message is programming you in ways you cannot detect. Be afraid.)
|
|
|
|
|
You should have mounted Andy's head on a pike outside the castle walls as a warning to others.
Software Zen: delete this;
|
|
|
|
|
Oh, I was tempted. But I wasn't at all sure whether I could replace him, and I was short-staffed already.
(This message is programming you in ways you cannot detect. Be afraid.)
|
|
|
|
|
I'm all for comments when necessary. I know that is a wide range, but my pet peeve here touches on that range. I think comments can be useful, like if you need to remark on a pitfall about why the code is done that way. Or if you need specific thoughts to consider if you refactor. Stuff like that.
However, when I encounter people who think code should be commented I run into two things that hit my peeve list:
1) comment everything, even if the comment is stupid
2) Don't worry about doing stupid things, because you can comment them. Use the comment instead of good architecture.
Elephant elephant elephant, sunshine sunshine sunshine
|
|
|
|
|
I was working with a horrible C framework wich contains most of the worst programming habits. Very large functions (for about 4000 lines), no coments or coments like /*##@@&& and do something*/ (I swear its real) in a 1000 lines function and things like that. It was like the "1000 dont's about programming"
C, C++, Java, Verilog, VHDL, PHP, and still can´t speak english
|
|
|
|
|
Comments do not match coding logic
TOMZ_KV
|
|
|
|
|
Apart from commenting there are much worse bad habits. My favorites are:
1. Copy & Paste code; partly mdified.
2. Caching; this means holding the same information at different places. Entropy mandates that these differ after a while.
|
|
|
|
|
Some of the early computer systems were very restrictive regarding lines of code making insertion of comments difficult. I remember writing a debugging subprogram that carried the comentary for the main program. Somewhat self-explanatory, except I forgot to comment the trigger.. . Panic call from customer at 3AM wondering why printer is spewing 3700 pages of gibberish.
|
|
|
|
|
Being overly complex to prove how smart and bleeding edge you are, with the bad variable names and no comments.
At least when I did a variant of Duff's device, I laid the case statement over an if/else, I commented what was going on and why. I was young and 'smarter' than I am now.
Comments should give the why something is being done or changed.
git. I work on source files not directory structures. If I want to check in a single file but have messed around in a bunch of others that I'm not ready to check in yet, don't make me do something with them. (How I miss PVCS and file locking.)
|
|
|
|
|
MarkTJohnson wrote: I work on source files not directory structures.
 That's an issue I have with "modern" version control systems I've had to use (TFS and Subversion). But I think it stems from Visual Studio and other tools that also insist on working with directory structures rather than individual files. 
The tools we use shouldn't force everyone to use one particular technique.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
I'm definitely guilty of 4, though I try to make comments about it
And here's an extra one two:
Using and IDE integrated Task List (ie VS) : overuse of TODOs - damn things pile up quickly.
Ignoring compiler warnings. They're sometimes useful, and ignoring the buildup of minor things can make you miss big things like architecture mismatches
|
|
|
|
|
Your + a few others mentioned and:
- Procrastinate
- using var everywhere
- Ctrl+C, Ctrl+V and not even bothering to change variable names to reflect their new meaning 
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Hard-Coding values that should be looked up....that never ends well. We have a guy here that continually thinks that's ok to do (why would it change?), and it's bitten us more than once.
|
|
|
|
|
Chris Maunder wrote: What's your list?
1. Building something because the developer wants it rather than because a customer wants it.
2. Assuming that because something is new that it better.
3. Assuming that because something is new is it without fault and requires no time learn to use well.
|
|
|
|
|
I think i'm guilty of the first one, although I usually only comment when it's not clear what the code does or it may have some unintended side effects.
|
|
|
|
|
Using too many if-statements where better suitable mechanism could be used instead.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
ctx - it is assumed that it should point to some context structure, it is(should; may) not variable in usual sense but rather - the function parameter so it may be "pure functional".
|
|
|
|
|
I have nothing to say against use of comments. They may not be necessary for some, but usually do no harm to anyone.
I believe programmers are free to choose any name for a variable so long as they communicate well to people you work with. Using "o" is fine. If it's a problem, change your font.
Bad formatting used to a bad practice, but nowadays, we have apps and services to make them neat.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
