Archive for category Coding

0 error(s), 0 warning(s)


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.

Title picture © Les Cunliffe | Dreamstime.com

  • Facebook
  • Twitter
  • Google Buzz
  • MySpace
  • Yahoo Messenger
  • Google Gmail
  • Yahoo Bookmarks
  • Yahoo Buzz
  • AIM
  • AOL Mail
  • Blogger Post
  • Delicious
  • Digg
  • Google Bookmarks
  • LinkedIn
  • Orkut
  • StumbleUpon
  • Technorati Favorites
  • Windows Live Favorites
  • Share/Bookmark

Tags:

“My Code Has no Bugs”

Bugs

Even though it is practically impossible to write bug-free source code, some people really think they do.

It was the case of one of my former colleagues from a company for which I have worked for a couple of years. He was really thinking that he was extremely skilled (and he was… but not as much as he thought), which unfortunately for him, has led him to adopt a quite arrogant and distant attitude towards everybody. And I mean everybody, as you are about to discover later on.

Durig a tremendously difficult installation for an important customer – a pretty big hypermarket which had just opened – the service team has discovered a blocker bug within the system: transactions weren’t properly saved to the application’s database. After spending a considerable amount of time in order to properly reproduce and describe the problem, it came out that there was a problem in one of this guy’s modules. So they called the company’s HQ and described him the problem.

Well, this is where arrogance and ignorance came in. He totally denied that the problem existed, even though the service people were looking straight at it. There was no bug. They’ve uselessly struggled to convince him, but the problem was so big that they had to escaladate the issue. As ridiculous at it may sound, it was the CEO himself who tried to convince him to look after the problem. Even then, he kept denying that there was a bug, and only when the boss became really “persuasive”, he took a look at the source files.

It appeared that his code did have bugs.

So when you’re thinking your code is perfect… better think you didn’t test it properly.

Title picture © Alexandr Anastasin | Dreamstime.com

  • Facebook
  • Twitter
  • Google Buzz
  • MySpace
  • Yahoo Messenger
  • Google Gmail
  • Yahoo Bookmarks
  • Yahoo Buzz
  • AIM
  • AOL Mail
  • Blogger Post
  • Delicious
  • Digg
  • Google Bookmarks
  • LinkedIn
  • Orkut
  • StumbleUpon
  • Technorati Favorites
  • Windows Live Favorites
  • Share/Bookmark

Tags: