What are the worst programming habits?
-
Well, he tried, as you say. I used to program automated test equipment for missile guidance systems, and each test station had to be initiated with a local gravity vector for its physical location. Some programmers simply hard-coded a three-valued constant into the code; DATA 0.00340120, 0.00002101, 32.16254301, or some such. Moving the machine to a new location meant recoding gravity at that point, but nothing in the code told what numbers were gravity. That's just one example, and there were many much worse.
Will Rogers never met me.
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
-
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 – ∞)
OriginalGriff wrote:
Leaving control names at the VS default
I do that sometimes, mostly with container controls I don't reference in the code. I often get weird build errors if I set the 'Create a variable' option (or whatever that option is called, no VS instance open right now to check) to false, so I don't usually do that. I have no idea why, and it only happens with certain types of controls (e.g. Panel, Table Layout Panel, etc.) VS is weird sometimes.
What do you get when you cross a joke with a rhetorical question?
-
Pete O'Hanlon wrote:
Secondly, learn how to use the power of LINQ, that
Wherestatement is redundant so the statement can becomemyList.SingleOrDefault(p => p.Id == aUniqueId);However, using Where(predicate).function rather than Function(predicate) is significantly faster. Incidentally a straight forward While loop is more efficient than either. So if efficiency is a concern (and we're not just talking close here, there's a big enough difference that it counts!) you need to be careful!
var found = collectionClass.FirstOrDefault(i => i.Field == searchValue);
or
2.
var found = collectionClass.Where(i => i.Field == searchValue).FirstOrDefault();or
3.
foreach(item in collectionClass)
{
if (item.Field = searchValue)
{
found = item;
break;
}
}The results for 100,000 collection with 100,000 searches? 1. 'normal' 78.5 1. parallel 32.2 2. 'normal' 51.2 2. parallel 31.9 3. 29.9
PooperPig - Coming Soon
How about the SingleOrDefault on the same machine?
Wrong is evil and must be defeated. - Jeff Ello[^]
-
Well, he tried, as you say. I used to program automated test equipment for missile guidance systems, and each test station had to be initiated with a local gravity vector for its physical location. Some programmers simply hard-coded a three-valued constant into the code; DATA 0.00340120, 0.00002101, 32.16254301, or some such. Moving the machine to a new location meant recoding gravity at that point, but nothing in the code told what numbers were gravity. That's just one example, and there were many much worse.
Will Rogers never met me.
-
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[^]
-
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
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.
-
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
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
-
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
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.
-
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
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 obviousIn 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)
-
Roger Wright wrote:
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.
Oh, it's still common! I found some code a while ago that the dev had obviously thought he'd done the right thing...
const int FiveHundred= 500;
Sure, re-factoring is easier (although it was only used in one place anyway) but not the most meaningfull names! (it was for a 1/2 second time out time)
PooperPig - Coming Soon
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)
-
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.
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)
-
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.
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)
-
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 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
-
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.
- ;) 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!
-
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
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.
-
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
Never ending methods.
-
- Wrong comments. Comments that pretend to explain the code, but the code and the explanation don't match. - Rambling comments. At least they're not wrong, but the useful part is hiding. - Unreachable code. Often mistaken for "defensive programming". Code that provably can't run is provably useless.
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.
-
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
-
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
- 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
