![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rCognitive complexity and numeric constraints
Programmers try to fight complexity with rules.
"Lines should be N characters or less". "Not more than M member functions in a class". "Maximum K statements per function". "Maximum L classes on a diagram"...
Such rules sound reasonable. They are parts of established standards. Their correctness was defended in numerous discussions with many facts and theories. Unfortunately they have a common flaw: Cognitive complexity is a synergetic problem. Most rules are dilettantish attempts to tune a complex system by considering only one parameter.
There are unavoidable technical constraints. If a compiler created at the beginning of the computer age did not understand words longer than 8 characters, programmers were forced to use short abbreviations for names of functions and variables. The number 8 was absolute.
Modern tools allow more flexibility but many numeric constraints with such ancient roots remain untouched and migrate form one coding standard into another.
Today rules usually state that they apply artificially selected numbers to simply set some borders between acceptable and bad.
If we follow this logic, we must say that reducing these numbers makes everything better.
A function with 20 statements is better than a function with 30 statements. A diagram with 5 classes is better than a diagram with 7 classes. A code line 40 characters long is better than a line exceeding 50 characters...
It is mysterious but usually nobody tries to consider the best variant: all functions must contain 1 line of code, all diagrams must contain 2 classes and to shorten all source code lines all names of all variables and functions must be truncated to minimal lengths.
Anyone can see that the complexity will be drastically reduced. But I doubt somebody will proclaim that these extreme numbers are good.
These samples show that the "local complexity" is reduced on the price of a nonlinear grow of the "structural complexity". Short functions produce long lists of function names. Simple diagrams hide tangles of invisible connections. Short abbreviations create enormous cryptic vocabularies.
Any numeric constraint not only cuts out some part of complexity but simultaneously prohibits optimization for other aspects. Extreme cases make this barriers obvious.
Most programmers are trained not to find optimal solutions for complex problems but to solve simple exercises from books they had read to study their favorite programming languages. They simply do not see the grow of complexity above the source code level.
They fanatically follow rules and by all objections try to prove artificial numbers by creating crazy theories in the unfamiliar domain of human psychology.
