12 January 2012

Code validation advocacy

It was said many times that static code validation sucks, validation warnings are false and senseless.

Well, it is a common mood despite numerous words to support code validation. So just my 2 cents.

What code validation tools do

So what is the code validation about - starting from most simple topics. Some are not covered - such as API analysis.

  1. Copy-paste

    Detects chunks of duplicated code. It is bad, obviously.

  2. Formatting

    Checks if the source code follow certain formatting rules.
    Well, these rules may differ from Sun, Microsoft or Google ones. That doesn't matter. The only things that matters is that the rules must be the same. For the whole project. For all projects around. Soon you will get used to them. And the project code will be like a book printed with a good font but not a hand-written notes on a napkin.
    And we don't write in Brainfuck, right?

  3. Bad words

    Checks for certain typical words in comments - such as TODO, FIXME, DEBUG, etc.
    Imagine - you are a Big Company and your contractor sent you a piece of code. In the middle of the code:

    /* TODO: implement it according to the spec */

    What will you say? "WTF, what did they send?!"
    Put TODOs to your code in development. But clean them out prior to submission to a repository. Not just delete the comment but solve its cause. Leave the code in a stable state. If there is a problem - create a task in an issue tracker.
    Finally we are coders. Our product - those text files that we submit to the repository. Those lines of text brings us our money. They must shine.

  4. Documentation

    Checks that all relevant code items have inline documentation.
    Sure good inline documentation is the must. Lack of proper inline docs leads to misuse, time waste and re-invention the wheel. And don't bother to choose what should be documented and what should not. You are not a prophet and cannot predict how and when this code will be used. So just document everything.
    Checks for legal stuff - such as license headers. Remember - nowadays is the era of lawyers. So don't feed the trolls.

  5. Anti-patterns

    Looks for coding patterns that are either bad practice or directly dangerous.
    Most developers can argue that in this specific case it won't cause problems. Nobody can predict all execution flows. Nobody can imagine all possible uses in the future. All these anti-patterns may cause problems. So take for granted that if they can cause problems they will - according to the Murphy law.

How do code validation tools affect developers work?

  • Difficulties?

    Everyone has habits. Everyone has own taste for formatting. OK, IDE will do it for you.
    Everyone has own code tricks. That is good sometimes - for sole coding. For team work it is not acceptable. We are speaking the code to our colleagues and need to understand and to be understood.
    It takes precious time. But bugs takes more. Bugs by you, by users of your code. Maintenance takes even more.

  • Profit!

    It really helps to avoid some bugs.
    It makes more transparent and easier to understand for teammates - so developers can switch faster and accustom better with a new code. They will use the existing functionality better and make less bugs.
    It makes code look more clear and professional. That means - more valuable. That means higher customer satisfaction.
    The more professional is code look, the less tension it will cause with the customer-side reviewers - they are seldom benevolent.

What should we do?

Just follow the code validation rules. Always. But switch brain on and do not invent constructions to just shut the validation rule up.

It is not difficult, is it?