Death by 1000 Programming Sins
I've been guilty of 76 - I've been a fan of domain specific languages since the early days of lex/yacc...
77. Blinded by the latest trends - everything from clouds to virtualization to Web 2.0
78. Tempted into spec'ing out an overpowered server because I need all those cores and memory slots.
79. Enamored with Scala because it makes me so much more productive than C++ - a nice GUI client in only 1/4 of the time... ...and then discovering that I can do even more with less using AJAX...
80. Suckered into buying piles of cheap RAM, so you can replace the p0rn stash with a p0rn cache.
77. Blinded by the latest trends - everything from clouds to virtualization to Web 2.0
78. Tempted into spec'ing out an overpowered server because I need all those cores and memory slots.
79. Enamored with Scala because it makes me so much more productive than C++ - a nice GUI client in only 1/4 of the time... ...and then discovering that I can do even more with less using AJAX...
80. Suckered into buying piles of cheap RAM, so you can replace the p0rn stash with a p0rn cache.
| 68. Emulating polymorphism with switch cases |
Huh? What's wrong with that? Switch cases are one of valid ways of doing polymorphism. They have some downsides virtual dispatch doesn't have, but virtual dispatch also has some downsides the switch doesn't have. Just know your tools.
So 68. should be rather:
68. Chosing wrong tool to implement polymorphic behaviour (and the tools can be: virtual dispatch, switch/if, templates)
Last edited on
closed account (z05DSL3A)
81 Not using change management to keep the WIBNIs in check.
82 Using software configuration management (SCM) but not (fully) testing it regularly.
82 Using software configuration management (SCM) but not (fully) testing it regularly.
@xander If there come to be many more of us it could indeed get confusing. We might need some kind of inquisition to make sure no-one uses the name unjustifiably.
I've been guilty of that one with C++ for quite some time. A while ago I looked up some other languages, but I strongly disliked some of Ruby's syntax in my opinion only ;) and I am still meaning to learn Python...
Thanks for rephrasing this :P
@rapidcoder Can you do polymorphism with C++ templates? I read polymorphism is supposed to happen at runtime. Okay, forget that. There is of course compile time polymorphism as well...
| 74. Strictly and solely using one language and one paradigm as a solution to all your applications, no matter what purpose of the software will be. |
I've been guilty of that one with C++ for quite some time. A while ago I looked up some other languages, but I strongly disliked some of Ruby's syntax in my opinion only ;) and I am still meaning to learn Python...
| 80. Suckered into buying piles of cheap RAM, so you can replace the p0rn stash with a p0rn cache. |
Thanks for rephrasing this :P
Last edited on
83. Keeping compiled binaries in SCM
84. Not using any coding-style convention
85. Using coding-style convention you like instead of the coding convention that is used by other team members.
86. Forgetting a ";" after a class definition in one of the header files.
87. Using lowercase names for preprocessor macros.
88. Comparing floats with == or !=
88.999999999 Using floats where integers suffice, and forgetting about round-off errors.
89. Using floats for storing money.
91. Expecting floating point arithmetic to yield the same results on different platforms.
92. Not using Unicode for your strings.
93. Using gets to deal with user input.
84. Not using any coding-style convention
85. Using coding-style convention you like instead of the coding convention that is used by other team members.
86. Forgetting a ";" after a class definition in one of the header files.
87. Using lowercase names for preprocessor macros.
88. Comparing floats with == or !=
88.999999999 Using floats where integers suffice, and forgetting about round-off errors.
89. Using floats for storing money.
91. Expecting floating point arithmetic to yield the same results on different platforms.
92. Not using Unicode for your strings.
93. Using gets to deal with user input.
Last edited on
94. Attempting large (read: large) mathematical computations without the use of a proper arbitrary-precision number class.
95. Using poorly-documented libraries without sufficient code-reading skill.
96. Poorly documenting/commenting your own libraries.
97. Obfuscating your code before you've finished programming.
-Albatross
95. Using poorly-documented libraries without sufficient code-reading skill.
96. Poorly documenting/commenting your own libraries.
97. Obfuscating your code before you've finished programming.
-Albatross
Last edited on
98. Putting of work that should take less than 30 min. to do.
I do that BTW.
Perhaps #96 should be "Making poorly documented and commented library code(then expecting others to use it).
I do that BTW.
Perhaps #96 should be "Making poorly documented and commented library code(then expecting others to use it).
Last edited on
| then expecting others to use it |
Still, you might forget what it does/how to use it yourself if you leave it for a while.
99) assert(functionWithImportantSideEffects());
followed by an afternoon complaining about how rubbish the Windows implementation of boost::interprocess is, because the same code worked fine on Mac OS.
followed by an afternoon complaining about how rubbish the Windows implementation of boost::interprocess is, because the same code worked fine on Mac OS.
Father forgive me for I have sinned ...
I am systematically guilty of:
1,6,7(actually I never used the abstract keyword outside of exercises),10,15,18,19
One from me:
100. Carry your laptop for a corridor's length holding it for the space bar. Notice that there is a } missing when it is not (it is simply some 50 000 empty spaces away), and add consequently add an extra } . Have to diff code versions to find out your error.
I am systematically guilty of:
1,6,7(actually I never used the abstract keyword outside of exercises),10,15,18,19
One from me:
100. Carry your laptop for a corridor's length holding it for the space bar. Notice that there is a } missing when it is not (it is simply some 50 000 empty spaces away), and add consequently add an extra } . Have to diff code versions to find out your error.
Last edited on
@tition Since when was an empty statement an error? I even turned my warning level to max and almost died with shock when I got 600 warnings about unused inline functions...
EDIT:What's the abstract keyword?
@tition, Albatross Lol @ Catholicism analogy ;)
EDIT:
101. Making an inline duplicate copy of your code in the form of perpetual, ridiculously verbose comments which say nothing more than the code itself.
102. Having non self explanatory code which necessitates the use of such comments.
EDIT:What's the abstract keyword?
@tition, Albatross Lol @ Catholicism analogy ;)
EDIT:
101. Making an inline duplicate copy of your code in the form of perpetual, ridiculously verbose comments which say nothing more than the code itself.
102. Having non self explanatory code which necessitates the use of such comments.
Last edited on
| EDIT:What's the abstract keyword? |
http://msdn.microsoft.com/en-us/library/b0z6b513(v=vs.80).aspx
103. Leaving too many unnecesary comments in code.
105. Using too many compiler specific features (#pragmas, keywords)
106. Throwing exceptions where return values can be used instead.
107. Using exception specifications
108. Not checking user's input.
I think that's C++/CLI only.
EDIT:
109. Using return values when performance is not an issue and exceptions would provide a significantly neater solution. (:p)
EDIT:
109. Using return values when performance is not an issue and exceptions would provide a significantly neater solution. (:p)
Last edited on
The problem with exceptions is not performance (well, it is sometimes, but hear me out), the problem is that all too often they're used in lieu of return values for perfectly ordinary circumstances.
Suppose you're looking for a row in a database. An improper use of exceptions is to signal that the row wasn't found. A proper use is to signal that the table doesn't exist, or that you're getting back garbage from the server. Stuff that shouldn't happen unless something has gone terribly wrong.
Suppose you're looking for a row in a database. An improper use of exceptions is to signal that the row wasn't found. A proper use is to signal that the table doesn't exist, or that you're getting back garbage from the server. Stuff that shouldn't happen unless something has gone terribly wrong.
I often use a combination therein. In my .NET applications I use a library I wrote filled with some base classes to be use as generic exceptions. Or if they are not specific enough I inherit from them and make use of the child classes.
Anyways, back to my point; What I will do is throw the appropriate exception from my method and when it is caught I return a member variable of the thrown exception class whose value is assigned based on the failing method. Not really the best way of doing things, but it's what I'm comfortable with.
Anyways, back to my point; What I will do is throw the appropriate exception from my method and when it is caught I return a member variable of the thrown exception class whose value is assigned based on the failing method. Not really the best way of doing things, but it's what I'm comfortable with.
@ helios:
part of me disagrees.
I agree in that your example situation might be excessive for an exception.
On the other hand, it might be completely appropriate, depending on how complex the database operation is.
Say for example you're doing a lookup where you need to look up 5 different fields for information, then find a row on another table that matches all 5 lookups. If any of the first lookups fail (row not found), the entire operation would need to fail.
In this situation, throwing an exception would be great because then you can write your code assuming everything is working, without having to have
I think the appropriate behavior in this case would be to have an error return by default, but have an optional setting so you can configure it to throw an exception.
part of me disagrees.
I agree in that your example situation might be excessive for an exception.
On the other hand, it might be completely appropriate, depending on how complex the database operation is.
Say for example you're doing a lookup where you need to look up 5 different fields for information, then find a row on another table that matches all 5 lookups. If any of the first lookups fail (row not found), the entire operation would need to fail.
In this situation, throwing an exception would be great because then you can write your code assuming everything is working, without having to have
if(failed) checks a million times after every operation. That's the whole point of exceptions.I think the appropriate behavior in this case would be to have an error return by default, but have an optional setting so you can configure it to throw an exception.