Rule Of 7

Rule of 7

All details are chopped up into layers.

No node in a layer has more than 7±2 items in it.

Most programming languages encourage breaking this rule, i.e. they encourage writing functions that have more than 7±2 lines of code in them, they encourage writing program modules that have more than 7±2 functions in them, they encourage the use of more than 7±2 types, etc, etc.

Early BASIC Programs

Early BASIC programs were easy to understand.

I would say that this is because no program had more than 7±2 lines in it.

Early BASIC programs did not have problems with global variables. Early BASIC programs did have global variables, but, this did not cause problems. I argue that globals weren’t a problem because the full scope of all variables - parameters, locals, globals - were visible in the same eye-full. Programmers could see all variables in one window (screen) and reason about them.

Globals became a problem when BASIC programs began breaking the Rule of 7. Globals were off-screen and programmers could no longer see them all at the same time.

The programming language community opted to allow for breaking the Rule of 7 and, thereby, inadvertently created the “global variable problem”. Instead of fixing the root cause of the problem, the community invented epicycles to contain the deleterious effects of elided global variables.

The epicycles induced programmers to engage in acts of self-flagellation. Programmers are required to distort their code to fit into the epicycles. For example, programmers still must - manually - deal with concepts such as scope and whole languages were mutilated to allow for “efficient” handling of scope.

Note that the chimera of “efficiency” tends to be solved by breaking the Rule of 7, causing exponential explosions in complexity in languages that have global-variable-limiting-epicycles already built into them. At best, “efficiency” is an ill-defined concept that is typically applied only to end-user applications, at the expense of time wasted by developers. This is a different kind of “efficiency”, which is mostly ignored.

How Do You Write Code That Obeys The Rule of 7?

Layering.

You don’t need to delete details, you simply find a way to elide details, so that a reader can come to a gradual understanding of the code. After all, you need all of the details to make the solution work. You don’t need to see all of the details at once in one big gulp, though.

Traditional OO breaks understandability and the Rule of 7 (inheritance means that you can’t look at a specific layer and know what is going to happen (without examining all children and overrides)).

StateChart HSMs (Hierarchical State Machines) use something that looks like inheritance, yet obeys the Rule of 7. I call this parental authority. We’ve all seen this technique in, say, graphic windowing systems. The outer-most layer gets first dibs on any incoming message. If the outer-most layer wants to punt the work, it sends the message on down to its children (and the children can further punt, recursively). If the outer-most layers wants to do the work, the children don’t even get to see the message. I.E. no child can override the operation of a parent. Furthermore, in HSMs, if an outer layer decides to “change state”, it causes all of its children to exit (finalize) their current state in a deepest-first manner. Again, a child gets no say in the matter, it simply responds to commands from up-on-high (its parent). Again, this means that a reader can understand the code and predict “what will happen” without needing to dig into the details. The reader can dig into the details only if the reader wishes to know more about the details. The details are elided and the reader can glean an understanding of the code in a gradual manner.

I drew a picture of this kind of protocol in https://publish.obsidian.md/programmingsimplicity/2022-08-09-Structured+Message+Passing.