Dishonest Programming

20 Jan 2008

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.