Code craft: March 2008 Archives
Here's a little article about the "file header tax", lines of boilerplate at the top of files that serve no purpose. Copyright notices, disclaimers, maybe even some revision history, it's all just clutter, and clutter is technical debt.
Take a look at the next file you edit. Is there anything at the top of it that is not functional code? Ask yourself if it really needs to be there. If in doubt, throw it out.
Jared Parsons writes about how Part of being a good programmer is learning not to trust yourself. It's filled with basic but all-too-often-forgotten wisdom about defensive programming. Key bits: "Turn assumptions into compiler errors," "The best way to avoid making bad assumptions is to actively question them at all times," and "1 test is worth 1000 expert opinions."
I also chuckled to see a sidebar disclaimer that said "All code posted to this site is covered under the Microsoft Permissive Lice." I'd heard of parasitic licensing before, but never like this!
Dropping vowels to shorten names is a terrible practice. Quick, someone give me an idea what $hdnchgdsp means, an Actual Variable from some Bad Code I'm working on today.
It's not just variables names, either. Filenames often need to be shortened, but dropping vowels is not the way to do it. You're left with unpronounceable names that are annoying to type.
The key to effective abbreviation is not removal of letters from the middle of the words, but from the end. Sometimes, it doesn't make sense to shorten a word at all, like "post". If you have a file that is supposed to "post audit transactions", call it "post-aud-trans" or "post-aud-trx", not "pst_adt_trns".