Re: [TUHS] The Elements Of Style: UNIX As Literature

Larry McVoy writes: We're getting into religion again here, and I've never found that to be a sound basis for policy. I'm going to quote liberally here from a screed that I wrote (but have not published) when trying to understand parts of the linux kernel. I've always been willing to spend buckets of money on the monitors because to me that's an area where bigger and higher resolution is always better. I've been using 132 column terminal windows since sometime in the 90s when I got myself a monster 24" Trinitron monitor from Sun. I seem to recall that it listed for $3,300, thanks to the unnamed person who got me the employee discount :-) I tried going to 160 columns but that was too wide for the monitors that people I worked with had. I hated Shakespeare in high school. One of the big reasons was that I felt that he made up a word whenever he didn't have a good one available. The flipping back and forth to the list of definitions completely interrupted the cadence of reading. The insistence on short line lengths in coding standards and the contortions that people go through to meet them has the same effect for me. I've coined the phrase "mental locality of reference" to describe this; at least I think that I'm the first one to use it. Short lines and modern coding styles ask the human brain to contort itself in ways that we are loath to ask hardware to do. As near as I can tell, the belief that people do best with line lengths between 50 and 75 characters long is the result of people repeating "wisdom" that they heard from someone else that orginates from what I consider to be a misreading of Emil Ruder's book "Typographie: A Manual of Design". While Ruder does make this statement about line length, it's in the context of normal typography. It does not even remotely consider computer code where long lines are long mainly due to leading whitespace. To the best of my knowledge nobody has studied this - does the line length when counting begin at the first column or the first non-whitespace character? While readers might "lose focus" part of the way through long lines, that has to be balanced against the loss of focus that comes from 'mental carriage-returns" when text is too narrow and broken across several lines. Again, not studied as far as I know. The linux coding standard makes the unsubstantiated claim that having more than three levels of indent is a problem. And it's really hard to understand, because on one hand, it says that you "should fix your program", and then says that "nesting functions too deep" is a problem. Sounds like a catch-22 to me; how are you going to minimize indent if you can't nest functions? I'm guessing that someone typed this without reading what they wrote and really meant "statements", not "functions". We're back to the mental locality-of-reference thing that was mentioned earlier. I'd much rather have a few more levels of indent and longer lines than have to go chasing gratuitous function calls. Think about every diversion from the stuff in front of you as a cache miss. When I look at the linux kernel code, I see incredibly bad contortions made in attempts to meet the coding style. I also observed that the code only loosely follows its coding style. How are people limiting their code to three indent levels? By including dozens of header files that contain static inline functions. Gak! I feel that style rules should be observed in some sort of priority order, and mental locality of reference, which isn't in anybody's rules but mine, is at the top of the list. I could go on, but hopefully I've made my point. Jon