The Compulsive Coder, Episode 8: You Might Not Like This

Things I think I like to do in code that others might find off-putting or even stupid. Convince me that I’m wrong. Please. Comments and castigations welcome.

Annoyed “Annoyed,” courtesy Feliciano Guimarães. License.
  • Ignore access modifiers for fields in tests. We’re always taught to make things private when possible. For Java, I simply omit the private keyword–it’s one less piece of clutter, and these are tests, which should have no clients.
  • Start my test class names with A or An. Examples: AnExpirationCalculator, APantry, AnItem. This means that I have a naming convention for tests that is vetted by sheer readability. For example: APantry.listsItemsExpiringToday(). I’m actually ambivalent and even inconsistent about this; if enough people beat me up, I might change, but I kind of like it the more I do it.
  • Eschew safety braces. Why type if (x) { doSomething(); } when if (x) doSomething(); will suffice? “But what if you forget to add the braces when needed (ed: and you don’t remember to format the code)?” Has yet to be a problem, particularly since I’m doing TDD.
  • Put single-statement if‘s (and for other similar control flow statements) on a single line. In fact, single-line if‘s make the use of safety braces look even stupider, as the previous bullet demonstrates.
  • import packagename.*; … because I figure one could always hover or automatically get the imports to show explicitly if needed. Lately though I’m feeling a bit repentant and showing explicit imports… for pedantic reasons?
  • Largely ignore code coverage and other static-code-analysis-tool-generated metrics. My sh*t does stink sometimes, but I know when it does and when it doesn’t.
  • Use Java. Well, most of the shops I interact with still use it. It is our LCD language.

Maybe I need to pair more frequently again.

10 Reasons Code Duplication Increases Cost

Eliminating duplication is rule #2 of Beck’s Simple Design.

Duplicates “Duplicates,” courtesy Pelle Sten. License.

Here’s a starter list of the costs that duplication creates:

  • increased effort to change all occurrences in the system. Think about 5 lines of logic duplicated 30 times throughout your codebase, and now they need to all be changed.
  • effort to find all occurrences that need to change. This is often compounded by small changes (e.g. renaming) made over time to the duplicated code.
  • risk of not finding all occurrences in the system. Imagine you need to change the 5 lines of logic; you locate 29 occurrences but miss the 30th. You’ve now shipped a defect.
  • risk of making an incorrect change in one of those places. 30x increases chances of screwing up by 30 times… or more. Tedium induces sleepiness.
  • increased effort to understand variances. Is that small change to one of the occurrences intentional or accidental?
  • increased effort to test each duplicate occurrence in its context. And more time to maintain all these additional tests.
  • increase in impact of a defect in the duplicated logic. “Not only is module A failing, but so are modules B through Z and AA through DD.”
  • increased effort to understand the codebase overall. More code, more time, less fun.
  • minimized potential to re-use code. Often the 5 duplicated lines are smack-dab in the middle of other methods, minimizing your potential for some form of algorithmic substitution.
  • self-perpetuation. A codebase and culture that doesn’t promote code sharing just makes it that much harder to do anything about it.

No doubt some of you can add additional costs associated with duplicate code in a system. Please do (in the comments).

Atom