Adam Jordens@littlesquare:~/

There was an interesting post (by David Brady) included in the most recent dzone.com email that discussed the notion of Dishonest Programming.

The last sentence does a decent job of summarizing the author’s thoughts:

Any time you feel yourself being clever, ask yourself a key question: are you being deceptively simple, or simply deceptive?

In my mind it boils down to a matter of transparency. As a developer we should be striving towards writing transparent code. It’s easier to test, easier to maintain, and most importantly we’ll be setting a good example for others to follow.

1. Ensure that implementation artifacts (interfaces, classes, methods and variables) are named for what they actually do. Simple enough.
2. Ensure side-effects are known and documented. Pay attention to state and how it’s being maintained and manipulated. Prefer a stateless business tier and avoid undocumented data caches. The latter are trivially introduced and a pain to eliminate.
3. Immutability is good. Final classes, final methods and final variables. Pay attention to the mutability of return types as well.

Keep It Simple … and save the complexity for the kitchen.

As a developer, it’s amazing the difference in motivation you have when you’re working in a coherent and well-structure code base. It’s a difficult stage to get to (and maintain) but it must always remain a goal.

Adhering to a few simple rules will not only make you a better developer but will also improve the overall efficiency of your team.