What are the worst programming habits?
-
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.
-
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
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.)
-
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 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
-
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
Your + a few others mentioned and: - Procrastinate - using
vareverywhere - Ctrl+C, Ctrl+V and not even bothering to change variable names to reflect their new meaning :mad: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
-
Reminded me of a story I heard about a dev who had written guidance software for tank aiming - the idea being the operator could identify a target and the software would move the barrel to track the object and fire when aimed. The story goes that the first time it was tried out on a real tank, the tank fired almost immediately - in entirely the wrong direction. Turned out that the software was full of literal values, and had been fudged during testing so the devs didn't have to wait while a virtual barrel turned laboriously around - and they'd missed a value when they took out the changes in the real McCoy! Not sure I believe it (as surely there'd need to be some feedback from the tank) but nice image of lots of brass and boffins ducking for cover!
PooperPig - Coming Soon
Ah, the Helen Keller code! I did that once on a conveyor I was programming. Didn't want to make labels for the boxes and so I substituted the label read for a list read. My intent was to load the entire conveyor with boxes and then have all the diverters (it was a two sided sorter) fire at once to make a fireworks display.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
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
-
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.)
-
That isn't self-commenting code, it's badly commented code. Those comments are worthless - but that's not to say that some comments wouldn't be helpful
PooperPig - Coming Soon
Agreed. I felt that the comment for UpdateUser(); Should have indicated what information was being updated in which direction... // Grab DB Information and load into object or // update DB with current user information Because I have NO IDEA which direction that update is operating, although I guess I could look :-) But those comments in his example are USELESS comments, which are worse than no comments, because they give you false security.
-
// 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...
There is a saying that goes something like "you can tell how smart someone is by how much they agree with you". Kudos to every one of these bad coding habit comments! I can tell every one of you has not only developed, but MAINTAINED real life code!!! I would like to make one more statement in favor of good comments. In the classical book by Fred Brooks (The Mythical Man Month), he stated "always throw the first version away". When I am about to code something non-trivial, I almost always write the comments first, as I consider that my "first version". I figure that if I cannot describe in words what I need to do, then I probably can't describe it in code either.
-
Can you explain the reason? :) There is no good argumentation. "This" is used for the nut-cases who don't want to prefix with an underscore, and it is one of the most abused keywords, littering code without adding ANY value whatsoever.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Eddy Vluggen wrote:
prefix with an underscore
X| Yuck, filth, "littering code without adding ANY value whatsoever". X|
You'll never get very far if all you do is follow instructions.
-
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 KreskowiakDave Kreskowiak wrote:
like to be explicit in my code. There is no doubt in my intent
Hear! Hear!
Dave Kreskowiak wrote:
"private as default" or whatever modifier is default is a Band-Aid
Testify, brother!
You'll never get very far if all you do is follow instructions.
-
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.
:thumbsup: 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. :sigh: 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 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
Any single method that requires me to scroll (either way) on a 1920x1280 monitor.
-
// 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...
Normally happens if you write the comments before you write the code. It is just forgetting to remove the obvious comments after the code has been written.
-
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.
Spoon Of Doom wrote:
nothing but call an almost identically named function
I've seen that too. It was in just plain C, in some code that represented a layered architecture -- so it was similar to:
BL_GetDate() { return DAL_GetDate() ; }An OOP version might be:F() { base.F() ; }:sigh:You'll never get very far if all you do is follow instructions.
-
Then please show me the way parametrizing a table name, or field names in a query. Of course, you can keep hacking[^].
Or specifying a value for
TOP. But only as necessary.You'll never get very far if all you do is follow instructions.