10 really lousy commandments for Java Developers

Facebook

Twitter

Linkedin

Aleksey Shevchenko have on developer.com published 10 commandments for Java Developers, and they are of such lousy quality that I just have to respond (this vaguely resembles a xkcd cartoon :-). His commandments are:

1. Add comments to your code
2. Do not complicate things
3. Keep in Mind – "Less is more" is not always better
4. No hard coding please
5. Do not invent your own frameworks
6. Say no to Print lines and String Concatenations
7. Pay attention to the GUI
8. Always Prepare Document Requirements
9. Unit-test. Unit-test. Unit-test
10. Remember – quality, not quantity

Lets have a meta discussion about programming guidelines. In my not so humble opinion, they must fulfil at least these requirements:

• Programming guidelines must be relevant. None of the commandments above have anything to do with Java. What was he thinking?
• Programming guidelines must be helpful. Take "No hard coding please" as an example. How the hell is that helpful?
• Programming guidelines must stand on their own in one or two sentences. As an example, "Remember – quality, not qualtity" is just sloppy wabbly gibberish. It does not help me at all in my day-to-day programming.
• If you feel like writing commandments, better make damned sure they are important. First, is the issue you are adressing severe? If so, is it common? It has to be both severe and common to grant status as commandment. Is "No hard coding please" among the 10 most important programming problems we’re wrestling with in Java-land? No. It is at most annoying, and can easily be refactored.

After frothing at the mouth like this, lets go into details:

1. Add comments to your code.

   My reaction is that this is just the wrong way to go. Instead extract methods with names describing what is going on. If you’ve added a comment, such as "Calculate interest rate according to RFC 666", extract the relevant code into a function named calculateInterestRateAccordingToRfc666(). Much better!

2. Do not complicate things

   I feel like using the cane to punish such useless meaningless drivel.

3. Keep in Mind – "Less is more" is not always better

   Have a look at the original examples and ask yourself, what is the correct thing to do? My suggestion is, again, to extract a function, and use constants.

4. No hard coding please

   To be helpful he should have written "Literals should only be used in the definition of constants and enumerations".

5. Do not invent your own frameworks

   Yes yes yes, but what has this to do with Java?

6. Say no to Print lines and String Concatenations

   Is this important? Is it common? If so, you really have a serious problem.

7. Pay attention to the GUI

   Well, what can I say? Aleksey have realized that "The GUI is an essential part of a successful application". What can I say? It seems… profound!

8. Always Prepare Document Requirements

   In the description he elaborates thus: "Every business requirement must be documented." This guy seriously needs to be hit by the 26 ton agile bus.

9. Unit-test. Unit-test. Unit-test

   TDD, TDD, or BDD, BDD. Much more important than unit tests.

10. Remember – quality, not quantity

    Has he stumbled upon something important here? No, I will, as always, prefer quantity over quality every day of the week. Code is an asset, as well all know. The more the merrier!
    

As a warning to anyone with a severe case of Moses complex out there, think again before you start whacking away with chisel on stone.