What are the worst programming habits?
-
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 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 – ∞)
-
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
ctrl-c/ctrl-v
I'd rather be phishing!
-
In order of how I have them listed below: 0) Use of VB. 1) Use of Convert and/or ToString rather than casting and/or Parsing. 2) Over-use of Reflection. Not caching and reusing information retrieved via Reflection. 3) Over-reliance on tools, especially third-party tools. 4) Monolithic classes, lack of modularity, non-single-responsibility. 5) Singletons. X| 6) Convoluted concatenation -- a String.Format will be clearer. 6.1) Concatenated SQL statements, when a parameterized statement is better on so many levels. 7) Not leveraging interfaces. 8) Not allowing polymorphism for no apparent reason. 9) Swallowing Exceptions. 10) Posting snippets of code that use uncommon, custon, or third-party classes and expecting everyone to know what they are.
You'll never get very far if all you do is follow instructions.
6.1 - I had to work on code today of a developer that left us last year. He used concatenated SQL statements... :| This is where something like Entity Framework comes in handy - let it handle your sql inserts / updates. There was also a whole lot of other bad coding habits. I blame the university where he studied though, seems like they didn't teach him good coding standards.
-
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 am currently working on something that has massive presence of #1, 2 and 4. Other than that I totally hate if someone mixes up naming conventions. I have my favorites but I am OK with any convention. Just stick to single bloody way. Other than that, for some reason, heavily parameterized methods and constructors to bother me. I also totally hate logic and calculations in constructors (unless that is really needed).
My CP workspace: Incredibly trivial and probably useless code samples[^]
-
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
Not sealing classes by default/crazy overuse of inheritance Just because something needs something else doesn't mean it is a base class of that other thing, I think in a modern programming language you rarely actually need to use inheritance Also, Code that does nothing, but hasn't been taken out of the project, eugh I rarely comment my code unless I am doing something weird, I assume the next developer will be at least as smart as me, if not much much smarter (likely) I might use o as a variable name if I'm maybe inside a for loop inside another for loop (using i for the outer one), everybody should know what for(var i = 0; i < blah; i++) means, anything more descriptive is a waste of keystrokes Everything else I agree with
-
If you need comments to explain what the code does, then the code is too complex. Formatting is a matter of taste, and there's a keyboard shortcut to automatically reformat in the VS-IDE. My worst programming habits;
- Removing the access modifier "private" from code, as it is redundant. Not a bad habit in my book, but apparently in everyone else's.
- Hitting F5 too regularly. Kills productivity if it takes 15 minutes to build.
- Reading CodeProject while building a solution. I cannot stare at the build-screen, especially since it does not provide adequate feedback on what it is doing. If it appears to be waiting for a long time then chances are that it gets killed using the task-manager.
- Coffee. With two suger, and two cups an hour, that adds to 32 lumps of suger.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Eddy Vluggen wrote:
Removing the access modifier "private" from code
There should be no default access modifiers; the developer's intent should be clearly specified. I don't want to have to guess, and you don't want me to keep asking you. Specify it, and decrease the hit to your own productivity caused by your juniors.
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
Misspelled identifiers. Inconsistent naming for related items. C++ header files that group things by their access method (
public:,protected:,private:) rather than putting related items together. Hungarian notation should die in a fire.Software Zen:
delete this; -
Not sealing classes by default/crazy overuse of inheritance Just because something needs something else doesn't mean it is a base class of that other thing, I think in a modern programming language you rarely actually need to use inheritance Also, Code that does nothing, but hasn't been taken out of the project, eugh I rarely comment my code unless I am doing something weird, I assume the next developer will be at least as smart as me, if not much much smarter (likely) I might use o as a variable name if I'm maybe inside a for loop inside another for loop (using i for the outer one), everybody should know what for(var i = 0; i < blah; i++) means, anything more descriptive is a waste of keystrokes Everything else I agree with
Use of
varis justifiable? In my useless opinion, var is useless in .Net framework World.My CP workspace: Incredibly trivial and probably useless code samples[^]
-
If you need comments to explain what the code does, then the code is too complex. Formatting is a matter of taste, and there's a keyboard shortcut to automatically reformat in the VS-IDE. My worst programming habits;
- Removing the access modifier "private" from code, as it is redundant. Not a bad habit in my book, but apparently in everyone else's.
- Hitting F5 too regularly. Kills productivity if it takes 15 minutes to build.
- Reading CodeProject while building a solution. I cannot stare at the build-screen, especially since it does not provide adequate feedback on what it is doing. If it appears to be waiting for a long time then chances are that it gets killed using the task-manager.
- Coffee. With two suger, and two cups an hour, that adds to 32 lumps of suger.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
I gotta call foul on removing the private access specifier. In C# the default is private while in VB it's Public. I absolutely hate that and really dont want to have to remember what the defaults ars supposed to be when scanning over code for problems.
A guide to posting questions on CodeProject
How to debug small programs
Dave Kreskowiak -
Not sealing classes by default/crazy overuse of inheritance Just because something needs something else doesn't mean it is a base class of that other thing, I think in a modern programming language you rarely actually need to use inheritance Also, Code that does nothing, but hasn't been taken out of the project, eugh I rarely comment my code unless I am doing something weird, I assume the next developer will be at least as smart as me, if not much much smarter (likely) I might use o as a variable name if I'm maybe inside a for loop inside another for loop (using i for the outer one), everybody should know what for(var i = 0; i < blah; i++) means, anything more descriptive is a waste of keystrokes Everything else I agree with
-
Misspelled identifiers. Inconsistent naming for related items. C++ header files that group things by their access method (
public:,protected:,private:) rather than putting related items together. Hungarian notation should die in a fire.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.
-
Use of
varis justifiable? In my useless opinion, var is useless in .Net framework World.My CP workspace: Incredibly trivial and probably useless code samples[^]
I disagree, in a situation like:
CryptographicUnexpectedOperationException exception = new CryptographicUnexpectedOperationException();
I find this more readable:
var exception = new CryptographicUnexpectedOperationException();
Typing CryptographicUnexpectedOperationException twice in such a short space I think is a bit redundant
-
Eddy Vluggen wrote:
Removing the access modifier "private" from code
There should be no default access modifiers; the developer's intent should be clearly specified. I don't want to have to guess, and you don't want me to keep asking you. Specify it, and decrease the hit to your own productivity caused by your juniors.
You'll never get very far if all you do is follow instructions.
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[^]
-
I disagree, in a situation like:
CryptographicUnexpectedOperationException exception = new CryptographicUnexpectedOperationException();
I find this more readable:
var exception = new CryptographicUnexpectedOperationException();
Typing CryptographicUnexpectedOperationException twice in such a short space I think is a bit redundant
Intellisense does help. For reading, indentation is something I would prefer. It is opinion. I think MS wants to divide and rule. When did Britishers took over MS? *Last 2 sentences are supposed to be humor.
My CP workspace: Incredibly trivial and probably useless code samples[^]
-
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[^]
-
Use of
varis justifiable? In my useless opinion, var is useless in .Net framework World.My CP workspace: Incredibly trivial and probably useless code samples[^]
varis handy in two places: 1) When using Linq and returning "An IEnumerable of something, gawddammit, but I have no idea what the compiler is going to call it" 2) To identify people whose code you can't trust because they have no idea or no interest in what type a variable should be. It may save five keystrokes to usevarinstead ofIEnumerable<Customer>but it doesn't help understanding when you have to read the code later.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 – ∞)
-
Intellisense does help. For reading, indentation is something I would prefer. It is opinion. I think MS wants to divide and rule. When did Britishers took over MS? *Last 2 sentences are supposed to be humor.
My CP workspace: Incredibly trivial and probably useless code samples[^]
d@nish wrote:
When did Britishers took over MS?
We didn't. If we had, the
Colorclass would be spelled properly!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 – ∞)
-
varis handy in two places: 1) When using Linq and returning "An IEnumerable of something, gawddammit, but I have no idea what the compiler is going to call it" 2) To identify people whose code you can't trust because they have no idea or no interest in what type a variable should be. It may save five keystrokes to usevarinstead ofIEnumerable<Customer>but it doesn't help understanding when you have to read the code later.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 – ∞)
