Billy Tobon's blog about software and other vanalities

Last week’s Java meetup in NYC brought to great speakers, first Timothy Fagan, talking about Java best practices and later Mark Pollack from Spring source gave us an overview about what’s new on Spring 3.0

The talk about Java best practices wasn’t something new, but it was a nice reminder about the basics things you as a developer should have in mind when write software; here we have some rants:

Who’s your real audience:

• The compiler: well, if the compiler throws errors and warnings, obviously it doesn’t understand what you are trying to code. Sometimes your IDE will help you to make your code more “compiler friendly”, but this is the most important audience you need to talk to… if not, your software would never see the light.
• You: I agree with this point, lot of many times I’ve returned after some months to an old code and I cannot believe I wrote it.
• The fellow maintenance developer: Most of the time, you are not the developer that would maintain the software and probably you won’t be able for the maintenance developer, therefore, don’t make a fellow developer to hate you in the distance.

Indeed, the first steps to write friendly code are:

Use naming standards and be logical: Java have conventions about how to write classes, variables and methods; spend some time reading the documentation , also some companies have their own specific standards and write names that reflect the intention of the code. Like:

int clientSize=10

instead of

int i=10

And please don’t be evil, I’ve saw code like this before (no kidding):

boolean _true=false;

Use the language helpers: Simple, start using generics, annotations,auto-boxing and new methods/classes from your java version. Sadly, the companies upgrade the Java versions, but don’t upgrade the Java code itself, my humble advice try to refactor some classes to start learning the new tricks. You can be totally sure your code will be faster also.

Comment your code: Big discussion here, basically we have to points of view, comment as much as necessary to let the others know your intentions, or don’t write comments but make your code already understandable using good naming conventions, short methods, patterns, unit testing, annotations and assertions*.

*(assertions would make your comments executable, and you can turn them on/off depending the environments BUT remember to be careful with this property on production instances, you never want to show them to the final user).

Thats all for today, I have to take the train now (The N line is getting crowd lately). I hope this points would make you think about your code wisely. As I said before, there is nothing new here, but it’s a nice reminder.

next post, the new features in spring 3.0

{ 0 comments }