Over time we all evolve as a coder, the code we write today is hopefully better then the code we wrote yesterday. In turn, the code we write tomorrow should be better then the 'great code' we wrote today. If this is not the case then we are not learning and evolving as professionals.
I have put together some coding no-no's that I remember encountering over time.
Multiple return paths in a method:
How often have we written a method where there are mulitple logic statements that would affect the value that is returned. When all possible have one variable that acts as the return value holder and set that value in your logic and return it at the end of your method. I know that there are exceptions to this, but as a general rule I feel this is the best way to go.
When we declare a parameter for a method we should make sure that the parameter name is not the exact (casing, spelling, etc) same as some local instance varable. I know the compiler will know the correct scope, but it is not fun for the developer to have to debug.
Finding objects based on Display Values:
When we have a list of objects in a collection, array, etc we should always be looking for them via some sort of key. The key value can be anything as long as it is unique. We should never lookup values based on some string values such as a name, or display value. This will lead to poor results as well as very poor code to maintain and extend.
Reuse of local variables with differnet meanings:
When we declare a local value name it so that the intent can be clear defined, but also only used it for its intent. Don't create a variable that is resued in the method for different intents.
I know there are more examples of coding No-No's these are just a few I could remember seeing in the past.
05-18-2007 7:10 AM