Paradigm Envy

I read a lot in the past few years about Continuous Deployment, and I finally realized what about it seemed odd - I've spent most of my career working on systems that were not web-based, but installed individually at customer sites.  So all those wonderful ideas about rolling out new code on the fly just don't apply to me.

And I really envy those developers who can use it - you avoid all the hassles - customers who never upgrade; customers who want fixes in the new releases backported to their current release; customers who want you to fix the problem, but not change any code, since they have to test for 6 months before deploying code.

Maybe someday I'll get the chance to work on a system that CD will be applicable

---

Naming Names

In What's In A Name? I addressed a common problem - the naming of functions.  I suggested that predicate functions be named so that reading the code aloud is comprehensible.

Today, I realized that there is a corollary that applies to a common type of function, the setter.

Often you have a setter function that has a small set of values, typically a binary flag.  There are two common schemes for getting/setting the flag - set(flag,. value) + getFlag(), and setFlag() , clearFlag().

From a code comprehension standpoint, the latter is better.  You can read the code and no matter what the value is, know if the flag is set or clear.  No more having to search back in the code when you see:
setFlag(someVar);
to see if someVar is True or False.  You know immediately at that point how the flag is set.

Now, you will probably need a getter still, since you will likely need to printout the value, at least, but the cognitive easing of this will be good for you, your successors, and your code.

---