Archive for September, 2008

Don’t Copy If You Can’t Paste

Sep 24

Posted by Alex Rosiu in Uncategorized | No Comments

Copy/Paste

Xerox-boy

Matt used to be an appreciated developer at his previous job, but now he succeeded to join a much bigger software company, one which he and all his friends had always admired. His new colleagues started to trust him also, so he was assigned with creating one new plugin for their application. They were even so nice to show him other plugins’ source code, and explain him how they worked by means of code samples. In one week’s time, he got it all woriking well, but when his code was reviewed, this came out:

/*
* class CGuiSettingsPlugin
* Manages settings for the Graphical User Interface
*/
class CCommunicationSettingsPlugin
{
…
}

He is now known as “Xerox-boy”.

As a developer, you are often faced with the situation of creating software components very similar to others, in terms of structure and behaviour. In those times, the easiest approach is to simply copy entire functions, classes, or even source code files and do some changes here-and-there. This habbit, however, has several darker sides which usually strike back sooner or later, one way or another.

Why Copy and Paste?

Because it’s easy. Why rethink an architecture, why bother to try and convince the managers that the (proper) changes would take more time, why even bother when you can just copy that class, change its name and slightly modify one single member function? It has already worked for you so many times before, so it’s pretty much supposed to work this time too… after all, you are just duplicating something that’s already working.

Because others also did it before you. You are faced with adding a new branch to a decisional “switch”, that already contains 30 other alternative cases. You’re not supposed to change the whole logic right now, are you?

Wrong

Nobody said it was gonna be easy, and after all, it’s not always necessarily supposed to be. There are times in products’ lifecycles when architectures need to be revised, and code needs to be refactored. Postponing those times for too long may force you to eventually do the right thing exactly when you have no time for that.

You may not want to start thinking everything all-over by youself, and it also wouldn’t be advisable, but the least you could do would be to raise the problem, and make people aware of it. There will be for sure many who will understand the need of allocating time and resources for finding the right solutions.

Title picture © Mafoto | Dreamstime.com

Tags: Attention, Detail

0 error(s), 0 warning(s)

Sep 5

Posted by Alex Rosiu in Coding | 6 Comments

Smoking Kills

The boy is smoking and leaving smoke rings into the air.
The girl gets irritated with the smoke and says to her lover: “Can’t you see the warning written on the cigarettes packet, smoking is injurious to health!”
The boy replies back: “Darling, I am a programmer. We don’t worry about warnings, we only worry about errors.”

Many developers tend to give little attention to writing code that generates no warnings at compile time, thinking that since there are no errors, it’s all good.

However, if the compiler issues a warning, there is a good chance that there really is a not-so-obvious problem hidden in the code. If you dig deeper, you might find issues like 32-bit pointers used on 64-bit architectures, comparisons between signed and unsigned variables, and others alike.
What is more, these real problems will be obscured by the tens of “not important” warnings, and you will most probably miss them.

“Unimportant” warnings

If you come to think about it, why do you get these “unimportant” warnings?
Usually it’s because you forget about a declared variable which you no longer use, leave function parameters unhandled, and so on. Problem is – why live with them? In fact, they only scream to you “Clean the code!!!”. Why wouldn’t you delete a parameter that you’re not using, or why would you keep an unused variable?

#pragma warning(disable …)

You may be tempted to easily prevent the warnings to annoy you by simply disabling them. Well, this “ostrich” approach is one of the worst practices that you might do as a developer.
There is one exception though, specifically when you are using 3rd party modules which are poorly coded and thus generate warnings at compile time. In that case, you really have no fault, there is nothing you can do about them, and it might be a good idea to disable them. Good news is, that you can disable the warnings only for the included header file, by wrapping it with a #pragma warning(push) / #pragma warning(pop) construction:

#pragma warning(push) // disable warnings for this header only

#pragma warning(disable:4213)
#include “header_with_warnings.h”

#pragma warning(pop)

The Bottom Line

Do not treat compiler warnings superficially. Use your compiler at its highest warning level and, if there are warnings that appear when you compile your code, understand them and eliminate them by fixing the code, rather than by disabling them.