Search This Blog

Wednesday 23 February 2022

Coding With Rules of Thumb

I create code quite a bit and have fallen into a process of using 'Rules of Thumb'  or 'Meta Patterns ' when doing this. These rules aren't hard and fast and cover all aspects of working with code. I thought I'd document them, so other people can have a look and maybe use them. I also get a list of my rules, and a list of things can help spot missing and duplicated items.

These rules are similar to software patterns but are usually at a much higher level than the code (The Software Hammer) or at a very low level (Chinese Questions).

This page is the index of rules and will be updated as I get round to documenting the rules, and in some case recognising that I use a rule.


The Software Hammer

Chinese Questions

Code the Specification




Chinese Questions

It's always a good idea to have descriptive labels when coding, it is extra information that is useful for code comprehension. So:

turn_the_light_on

is a nicely description label, and 

light_on

is a shorter way to name a procedure that turns a light on. If you have code that does something then you quite often have code that checks that the something has been done. This is code that asks a question and the obvious way to name such a function is as:

light_on?

this isn't valid in at least C. The simple way to solve this problem is to drop the question mark:

light_on

and infer the question from the context. That's the same name as the function's partner procedure, though, and that doesn't work. You end up with something like:

is_light_on

Which is fine but a bit cumbersome (well I think so). It turns out that the Chinese language comes to the rescue here, as Chinese indicates a question using the suffix 'ma'. I'm not an expert in Chinese and don't have to be as the key point is that I can write that suffix in plain text. So, we can create a label that asks a question:

light_on_ma

The pair of labels for code that does something and the code that checks that same something is now very consistently named and this rule is easy to apply. It's also probably confusing to anyone who reads the code, unfortunately, so should be explained somewhere obvious.