What are the worst programming habits?
-
I do #2, when I specifically have to work with an
objectComments are my major bugbear: I enforce XML comments on all public methods (and add them to non-public ones) and have "warnings as errors" on, so I have to comment my methods as a bare minimum. The rest of the time, I reserve comments for where they are needed. 6) I hate comments that explain exactly what the code is telling you it is doing! I can read the code, dammit - I don't need you to putif (customer.IsAnIdiot)
{
// If the customer is an idiot then we need to handle it.- Out of date comments. This gets my goat. Comments are there to help, when the code is complicated and more explanation is needed. So if you change the damn code, change the damn comments! Or you will hear the sound of a soft cough behind you, and it'll be me, with the ClueBat... 8) Variables names that don't reflect the use and / or purpose. Leaving control names at the VS default for example... ClueBat time!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
But if you are only scanning the code you can focus on the green lines instead of running an in-memory compiler :)
-
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 wrote:
unless the logic shouldn't ever need changing
That's a rather roundabout way of saying 'always' ;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)
-
SortaCore wrote:
unless the logic shouldn't ever need changing
That's a rather roundabout way of saying 'always' ;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)
-
I was thinking about the things that bug me and came up with a short list
- No comments. I know - let's have a religious war etc, but I find no comments dangerous.
- using o as a variable name. In fact using anything that's not sensible.
ctx,dr_rfp_ptr,i2 - Bad formatting. It's like walking into a house and being unable to sit down because of empty pizza boxes on the couch
- Mystery side-effects in code.
- Magic numbers
I'm guilty of 2 of these on occasion. What's your list?
cheers Chris Maunder
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.)
-
I was thinking about the things that bug me and came up with a short list
- No comments. I know - let's have a religious war etc, but I find no comments dangerous.
- using o as a variable name. In fact using anything that's not sensible.
ctx,dr_rfp_ptr,i2 - Bad formatting. It's like walking into a house and being unable to sit down because of empty pizza boxes on the couch
- Mystery side-effects in code.
- Magic numbers
I'm guilty of 2 of these on occasion. What's your list?
cheers Chris Maunder
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
-
7. Having two different methods that do exactly the same thing but with the arguments in a different order. I have come across this at at least three different places I have worked. Which one to delete when refactoring?
- I would love to change the world, but they won’t give me the source code.
I've encountered a similar, but annoying variant of this. There were a whole bunch of functions in my old employer's code base which did nothing but call an almost identically named function, such as:
someFunc(int a, string b)
{
return some_Func(a, b);
}In some cases, this went on for a step or two further, with some_Func calling some__Func (I HATE double underscores in code), which then again finally called the 'real' function someOtherFunc. I suppose it was the result of a messed up attempt at refactoring. It was hugely annoying when debugging.
-
I was thinking about the things that bug me and came up with a short list
- No comments. I know - let's have a religious war etc, but I find no comments dangerous.
- using o as a variable name. In fact using anything that's not sensible.
ctx,dr_rfp_ptr,i2 - Bad formatting. It's like walking into a house and being unable to sit down because of empty pizza boxes on the couch
- Mystery side-effects in code.
- Magic numbers
I'm guilty of 2 of these on occasion. What's your list?
cheers Chris Maunder
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
-
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
Charl wrote:
2. Refusing to commit code until it is "perfect"
There's another side to this. Excessive check ins. You don't need to check in every single change every time you make the change - wait until you have a logical break and then check it in. I've seen people check in every 5 minutes, just checking in things like colour or border thickness changes. It wouldn't be so bad if the next checkin wasn't for the next colour.
-
Since I don't do this for a living anymore, my opinion probably doesn't count for much. But back when I did do it, the cost of maintaining code far exceeded the cost of developing it, and I considered a lack of meaningful comments grounds for termination. I still do. Others in my list would include leaving commented-out code in production source, and embedding numeric constants in code for use in calculations. I don't know if that last one is common anymore, but it used to drive me nuts, and I found it in a lot of code.
Will Rogers never met me.
>back when I did do it, the cost of maintaining code far exceeded the >cost of developing it, and I considered a lack of meaningful comments >grounds for termination. I still do. +1 A friend of mine teaches programming for high-school students - and docks a student's grade if the programs aren't reasonably commented. Back in the early 1960s while in college I made some changes to a copy of Spacewar, and still have the source listings...but I have no idea today what those changes were. I hadn't learned about commenting (and in general neither had the other programmers who worked on the code). Now, as the senior engineer in my department at my POE I use those uncommented listings as examples of poor programming practice. (There are few things so horribly bad that they can't be used as a bad example.)
-
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 thirteenWould 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[^]
I like to be explicit in my code. There is no doubt in my intent. I just find it a bit strange that "private" is the only exception to access modifiers where you have to be explicit about everything but only because it's default. I'm just saying that the access modifier shouldn't have a default forcing you to be explicit in your intent and (granted hopefully) think about what you're doing. I am happy to say, as the other replier pointed out, that I'm not one of those that needs to be "saved from himself" because VB made everything Public by default and that's what generates tons and tons of bad "public everything" code. I don't believe that the problem is with VB. I believe the problem is with the education and the lax standards of what should be taught in school. I've has more than few degreed grads that couldn't tell me the difference between public and private. I've also heard most of those same grads say they've never written an API, to which I call BULLSHIT since every application contains it's own API, usually for the sole consumer being the application itself. I think the entire "private as default" or whatever modifier is default is a Band-Aid on a bigger problem. EDIT: And just for the record, I'm going to admit to being a hypocrite. I also rely on private being the default in my own code but, just because I do it, that in no way means I think it's a good idea.
A guide to posting questions on CodeProject
How to debug small programs
Dave Kreskowiak -
"this" was introduced for a reason and should be used.
We can’t stop here, this is bat country - Hunter S Thompson RIP
Better auto complete systems don't need this. as a crutch to figure out what they should be offering as suggestions. It may have been useful a decade ago but belongs on the rubbish heap today.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
harold aptroot wrote:
- Unreachable code. Often mistaken for "defensive programming". Code that provably can't run is provably useless.
Dunno about that one - I once inserted a check that I was 100% sure couldn't possibly fail, so I inserted a message saying this shouldn't be happening, and to please contact me. Thank god, it was a beta tester eventually seeing said message, not an actual user in production code - it turned out I was wrong on my 100% assumption... :-O
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)
To CYA in the future wrap that in a debug only block and let the app die more messily otherwise.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
mark merrens wrote:
People that tell you their code is 'self-commenting'.
Sometimes, it is though.
// check if user is valid
if(IsUserValid(user))
{
// update the user
UpdateUser(user);
}
else
{
// show a messagebox with an error
MessageBox(error);
}In that snippet, the comments are sorta annoying.
Regards, Nish
Latest article: Using the Microsoft Azure Storage Client Library for C++ Blog: voidnish.wordpress.com
// check if user is valid
if(IsUserValid(user))
{
// update the user
UpdateUser(user);
}
else
{
// show a messagebox with an error
MessageBox(error);
}Worthless comments, agreed...but doesn't mean comments aren't expected. I'd much rather have a comment at the beginning of the code segment saying what this chunk of work means, rather than what each step does...for example:
// better validate user before we get too far into the process...
</twocentsworth>
I used to call it "Super Happy No-Pants Wonder Day"! It turns out that the police just call it "Tuesday". Go figure...
-
I was thinking about the things that bug me and came up with a short list
- No comments. I know - let's have a religious war etc, but I find no comments dangerous.
- using o as a variable name. In fact using anything that's not sensible.
ctx,dr_rfp_ptr,i2 - Bad formatting. It's like walking into a house and being unable to sit down because of empty pizza boxes on the couch
- Mystery side-effects in code.
- Magic numbers
I'm guilty of 2 of these on occasion. What's your list?
cheers Chris Maunder
-
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; -
Gary Wheeler wrote:
Hungarian notation should die in a fire
That's too good for it. However, have you read this: Making Wrong Code Look Wrong by Joel Spolsky[^]
You'll never get very far if all you do is follow instructions.
Thank you, that's a very interesting article - I never new the Hunagrian notation was meant to be like that. And I actually like it: It could be an easy way to improve the legibility of old legacy code by means of a simple Rename, and it could be done incrementally, at our own pace, without need to set aside extra time for refactoring. :)
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)
-
// check if user is valid
if(IsUserValid(user))
{
// update the user
UpdateUser(user);
}
else
{
// show a messagebox with an error
MessageBox(error);
}Worthless comments, agreed...but doesn't mean comments aren't expected. I'd much rather have a comment at the beginning of the code segment saying what this chunk of work means, rather than what each step does...for example:
// better validate user before we get too far into the process...
</twocentsworth>
I used to call it "Super Happy No-Pants Wonder Day"! It turns out that the police just call it "Tuesday". Go figure...
This is how I try to comment. If the code section is complex I'll put comments that refer to the overall comment just to help the reader track where in the logic we're running. For instance /* * There are several constraints that need to verified. * * Constraint 1: * Constratin 2: * *** */ In the code I'll put a comment to provide a quick reference to each constraint right before I start checking that constrain.
-
I was thinking about the things that bug me and came up with a short list
- No comments. I know - let's have a religious war etc, but I find no comments dangerous.
- using o as a variable name. In fact using anything that's not sensible.
ctx,dr_rfp_ptr,i2 - Bad formatting. It's like walking into a house and being unable to sit down because of empty pizza boxes on the couch
- Mystery side-effects in code.
- Magic numbers
I'm guilty of 2 of these on occasion. What's your list?
cheers Chris Maunder
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.
-
I was thinking about the things that bug me and came up with a short list
- No comments. I know - let's have a religious war etc, but I find no comments dangerous.
- using o as a variable name. In fact using anything that's not sensible.
ctx,dr_rfp_ptr,i2 - Bad formatting. It's like walking into a house and being unable to sit down because of empty pizza boxes on the couch
- Mystery side-effects in code.
- Magic numbers
I'm guilty of 2 of these on occasion. What's your list?
cheers Chris Maunder
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.
-
PIEBALDconsult wrote:
the developer's intent should be clearly specified.
It IS clearly specified if it is omitted. It is not some arcane trick, it is not something that causes side-effects, and it improves readability. It is as usefull as typing "begin" and "end" instead of the default scope-blocks. It might take some getting used to, but it conveys the same amount of information using less symbols. That's kinda essential, and the reason why we are not programming in COBOL.
PIEBALDconsult wrote:
I don't want to have to guess
If you have to guess at the default access modifier in C#, you should not be writing in C#.
PIEBALDconsult wrote:
and decrease the hit to your own productivity caused by your juniors.
Should I prefix each class with a complete namespace? Otherwise they'd be guessing at which class it will take :D You explain a junior ONCE that everything that does not have a modifier is private. If they come asking, even once, then make them prefix everything. Using "this" and "that", using namespaces, using "global::". Throw in some hungarian systems, so they won't have to guess the type :suss:
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Eddy Vluggen wrote:
You explain a junior ONCE that everything that does not have a modifier is private.
No. It isn't. The default for types is "internal" , but the default for class or struct members is private. :-\ So basically omitting the access modifier applies a different meaning to different elements. For that reason I prefer code with explicitly stated modifier.
