|
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. 
Will Rogers never met me.
|
|
|
|
|
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.
|
|
|
|
|
That's a worry considering what those systems did 
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
Could have been worse, like
const int FiveHundred= 450;
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)
|
|
|
|
|
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'
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)
|
|
|
|
|
Yeah, when coordinates are no longer used in printing, the logic will need changing. 
|
|
|
|
|
>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.)
|
|
|
|
|
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.
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'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() ; } 
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
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. 
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.
modified 24-Jun-14 14:44pm.
|
|
|
|
|
PIEBALDconsult wrote: 5) Singletons.
I reckon valid use cases for singletons. Facade patterns, for example, especially in C++ code.
PIEBALDconsult wrote: 1) Use of Convert and/or ToString rather than casting and/or Parsing.
I lost you there, can you please clarify?
The console is a black place
|
|
|
|
|
PIEBALDconsult wrote: 6.1) Concatenated SQL statements
Revoke the programming license of anyone who does this.
|
|
|
|
|
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.
|
|
|
|
|
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? 
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)
|
|
|
|
|
0)
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) 
6.1) Unforgivable!
Good observations!
|
|
|
|
|
I like this list.. more to add:
1. Making all member variables public (usually in the context of unit testing.. but also to increase coupling because the original OO design wasn't decomposed correctly)
2. Making all member methods public
3. lack of use of auto_ptr and other more modern mechanisms for properly handling pointer lifetime management.
4. lack of understanding of exceptions, especially their side effects on locking and memory management. (years of my life has been spent on fixing these types of issues..)
5. misunderstanding by value semantics when passing instances of classes across method interfaces.
6. passing container instances by value (eek!).
Note these are ALL things I've directly observed/fixed.
|
|
|
|
|
Quote: 9) Swallowing Exceptions
My number 1 pet hate. Should be in capitals.
//BUT THAT IS SOMETHING ELSE THAT'S ANNOYING IN COMMENTS
Plz 4giv me shtng
|
|
|
|
|
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 
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.
|
|
|
|
|
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
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
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
