Monday, October 8, 2007

Make it part of the system

GTD is a lot about "getting things out of your head into a trusted system". Keith Ray and splogs discuss a property of some programming languages that helps you to do just that.

Their topic is const-correctness, a major issue in C++ (which happens to be the language I am mainly working with). Adding const to a variable or method just says: "This variable won't change" or "This method doesn't change the object, on which it is called".

As a colleague once correctly observed, adding const in most cases doesn't change the program that is being compiled. But what he failed to realize is, that you put some knowledge you have when you write the program into the source code. This allows you to forget about it. The interesting thing happens when you revisit the code (either to debug or to change it): with const in it you instantly know something important about the variable/method. Without const you have to try to either remember something or rebuild the knowledge. Not knowing something is const means you have to carry more stuff around with you.

As splogs said:
"When a software developer is debugging a program (as s/he often is), just knowing that one "thing" will not change after creation decreases the scope of required knowledge for that session by one."
So the source code is a trusted system (the compiler actually tells you, if something contradicts the const-ness) to put your knowledge into.

Designing programming languages and teaching good programming is a lot about reducing the amount of knowledge the programmer needs to achieve one task. Examples are
  • reducing the scope of entities
  • achieving high cohesiveness and low coupling
  • striving for orthogonality
  • grouping of code and corresponding data (the core of OO)
Getting const-ipated is one way for software-developers to get stuff out of their brains into a trusted system, so they can focus easier on the task-at-hand.

Additional tricks include leaving a breaking task as a reminder what you were doing at, when you have to stop working on something before finishing it. If you don't happen to have Unittest, you might introduce a syntax error, but this doesn't tell you what you were trying to achieve.

3 comments:

Unknown said...

Wonderful! I couldn't agree more.

Now, we just need to make an executable specification so we don't have to have anything in our head...

--Sean

Gerriet said...

Hi Sean,

thanks for your nice comment that happens to be the first one on my blog. I hope you will be stepping by in the future.

I came across your article via Keith Ray and thought it was a perfect fit for my agenda.

Gerriet

PS: Oh yeah, executable specification ... I will invent that immediately after the perpetuum mobile ...

Anonymous said...

Good for people to know.