Seven deadly sins of application development
Here is a list off the top of my head
1 - Ugly code!
Why do some people set local variables to null when they have finished with them? This is .NET! The garbage collector will collect "unreferenced" objects when it is ready, an object is unreferenced if you no longer use the variable that holds the reference to it!
Why do people name variables so poorly? Firstly I *hate* Hungarian notation. C# is a strongly typed language so I cannot multiply a boolean by a string, so why do people use variable names like "bIsMale" and "iAge"?
2 - Catching all exceptions
An exception is something you expect to happen, but shouldn't happen if all goes well. If such an exception occurs you might know how to solve the problem and enable your application to continue, but if the exception type was unexpected how can you possibly know the cause of the error or what state your application is now in? Therefore I hate code like this
try
{
DoSomething();
}
catch
{
}
3 - Accessing camelCase members
I really dislike it when people use camelCase names for private members with no property accessor. Sure, at the moment you don't need to execute any code whenever that member is read/written, but in future you might! If you name your private members with PascalCase instead then it becomes very easy to implement a property by changing it to camelCase instead, and then every reference to that member will automatically access your property instead.
4 - No testing
If something is so simple that it cannot possibly fail, it will fail! If you can't see why something could possibly fail it is because you haven't tested it, once you have tested it you will see all sorts of ways to make your code fail that you had not previously thought of.
5 - Implementing anticipated features
I hate being asked to write features that "might be needed in the future". Inevitably they are rarely needed and merely take away time from the development of features that are.
6 - Being told how to do something rather than what is needed
Managers who used to be programmers are the worst for this one! They see a requirement and the only way they can think of describing it is in a technical way. 1) Do this, 2) Do that, 3) Check this. From this description you have to reverse engineer what they are trying to achieve in order to come up with the original requirement. It's a bit like Chinese whisper, and you never end up with the original requirement. Worse still, you don't know why the customer requires the feature.
7 - Unreasonable deadlines
It is surprising how quickly an unmissable deadline is rescheduled when it is missed, this is usually a sign of a deadline that has been concocted for no apparent reason other than to make your manager look good. Unreasonable deadlines just stress your developers, and humans don't work so well under stress.
Have time off work, you will be more productive than if you work lots of hours. Don't let the consequences of failure drive your coding, write the best possible solution given a reasonable amount of time to develop it. I hate the "just get it out of the door" types, but perfectionists must also note that an undelivered application is far from perfection!
1 - Ugly code!
Why do some people set local variables to null when they have finished with them? This is .NET! The garbage collector will collect "unreferenced" objects when it is ready, an object is unreferenced if you no longer use the variable that holds the reference to it!
Why do people name variables so poorly? Firstly I *hate* Hungarian notation. C# is a strongly typed language so I cannot multiply a boolean by a string, so why do people use variable names like "bIsMale" and "iAge"?
2 - Catching all exceptions
An exception is something you expect to happen, but shouldn't happen if all goes well. If such an exception occurs you might know how to solve the problem and enable your application to continue, but if the exception type was unexpected how can you possibly know the cause of the error or what state your application is now in? Therefore I hate code like this
try
{
DoSomething();
}
catch
{
}
3 - Accessing camelCase members
I really dislike it when people use camelCase names for private members with no property accessor. Sure, at the moment you don't need to execute any code whenever that member is read/written, but in future you might! If you name your private members with PascalCase instead then it becomes very easy to implement a property by changing it to camelCase instead, and then every reference to that member will automatically access your property instead.
4 - No testing
If something is so simple that it cannot possibly fail, it will fail! If you can't see why something could possibly fail it is because you haven't tested it, once you have tested it you will see all sorts of ways to make your code fail that you had not previously thought of.
5 - Implementing anticipated features
I hate being asked to write features that "might be needed in the future". Inevitably they are rarely needed and merely take away time from the development of features that are.
6 - Being told how to do something rather than what is needed
Managers who used to be programmers are the worst for this one! They see a requirement and the only way they can think of describing it is in a technical way. 1) Do this, 2) Do that, 3) Check this. From this description you have to reverse engineer what they are trying to achieve in order to come up with the original requirement. It's a bit like Chinese whisper, and you never end up with the original requirement. Worse still, you don't know why the customer requires the feature.
7 - Unreasonable deadlines
It is surprising how quickly an unmissable deadline is rescheduled when it is missed, this is usually a sign of a deadline that has been concocted for no apparent reason other than to make your manager look good. Unreasonable deadlines just stress your developers, and humans don't work so well under stress.
Have time off work, you will be more productive than if you work lots of hours. Don't let the consequences of failure drive your coding, write the best possible solution given a reasonable amount of time to develop it. I hate the "just get it out of the door" types, but perfectionists must also note that an undelivered application is far from perfection!
Comments