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.

It’s my site! Check out the About page for more about me, or follow me on Twitter at @jlangr.

Leave a Reply

*

captcha *

Atom