Page 1 of 1
12 common programming mistakes to avoid
Posted: Fri Nov 16, 2007 12:01 pm
by sunilbhatia79
Posted: Sat Nov 17, 2007 4:31 am
by onion2k
That's a pretty good list.
Posted: Sat Nov 17, 2007 7:55 am
by Kieran Huggins
indeed it is.
Refactoring and unit testing often need to be sold to the client as a strength of your design methodology. Everyone always wants it now for cheap, but only because they don't understand the implications of what they're buying. It's our job as developers to help educate the client in this field. I won't waste time with the wrong clients anymore, there are enough good ones out there if you're patient.
Analogies are often helpful in this regard.
Posted: Sat Nov 17, 2007 8:35 am
by RobertGonzalez
That is a pretty decent list.
Posted: Sat Nov 17, 2007 11:48 am
by Christopher
It is a good, but odd list. I can't tell if it is just a list of good ideas, but in being a little hasty, missing a bunch of others. Or is it a little out of date? It certainly misses the impact that Agile has had on programming -- testing, refactoring, peer review, CVS, etc. would be on a primary list, with things like indenting and comments on a secondary one.
I guess it is a good list of common mistakes.
Posted: Sat Nov 17, 2007 12:00 pm
by superdezign
Those don't exactly seem like "common" mistakes to me, but moreso mistakes that come from inexperience.
Posted: Mon Nov 19, 2007 8:32 am
by shiznatix
I agree with those but I must say that I don't do things like unit testing. I am also really bad at commenting code but I have been trying to go back through a lot of my code at my current job and put in nice comments. I just don't see how unit testing is that amazingly important, just seams like it catches small errors that should be caught when testing your code in the first place.
Posted: Mon Nov 19, 2007 10:18 am
by Maugrim_The_Reaper
I just don't see how unit testing is that amazingly important, just seams like it catches small errors that should be caught when testing your code in the first place.
The problem is one of consistency. I want to be assured my code does Use Cases #1 to #1000 without manually checking every single one for errors. So an automated testing suite is a huge time saver (and less prone to dodgy manual testing and setup). In my experience you catch a lot more than small errors - you catch some pretty bone crushing ones early enough to fix them silently before anyone else notices

. At the end of the day, if you're not continuously testing code you can't say confidently everything works as you expect unless you manually check every one. Been there, eats up too much time and effort (as well as being dead boring) and never liked sitting on my hands waiting for the inevitable bug reports to be filed.
The other side, is using preemptive test/spec (TDD or BDD) writing to describe examples of how each small piece of unique behaviour should work from my preferred theoretical public API, so I know what's what before I even start implementing it, and in such a way anyone else reading these examples can pick it all up easily afterwards and have a safety net to catch their mistakes. Probably one of my three main reasons for being so fascinated with BDD these days - BDD specs tend towards being more readable than xUnit tests.