lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Tue, Jun 6, 2017 at 4:15 PM, Ross Berteig <> wrote:
> On 6/6/2017 2:58 PM, Russell Haley wrote:
>> On Tue, Jun 6, 2017 at 2:27 PM, Hisham <> wrote:
>>> And here's another Style Guide added to the list, taking input from
>>> the ones posted in this thread, and adjusting them to the style guide
>>> as used in the LuaRocks codebase. Enjoy!
>>> -- Hisham
>> Rationale: No one works on VT100 terminals anymore. If line lengths
>> are a proxy for code complexity, we should address code complexity
>> instead of using line breaks to fit mind-bending statements over
>> multiple lines.
> I've had my head stuffed in a book design task (using LuaLaTeX) recently.
> There really is good rational from book design for shorter line lengths
> based on studies of readability of running text. Printers (the people who
> handle lead type and spill ink on things) have known this intuitively about
> as long as moveable type has existed. The rule of thumb is that lines of
> print should be perhaps 45 to 75 characters long to avoid tracking to the
> wrong line as one reads. Mitigating that in code, you have the varying
> indentation, but generally keeping the ink to 66 characters more or less is
> likely easier on the reader.

A rule I can see being useful on pages with blocks of uniform text.
However, my code is rarely uniform. I like my logic on one line if I
can sometimes. But there is no accounting for some taste. I also
prefer counting from 1.


> In an 80 column screen, a block of 66 characters leaves up to 14 spaces for
> indentation. At 4 spaces per indent, you get three levels, at three per you
> get four levels. I'm inclined to argue that if you needed five levels you
> might have a problem that could benefit from some refactoring. In the deeply
> nested loop cases where you can't refactor that away, the loop body is
> likely expressible in less than 66 character lines if you choose local
> variable names judiciously.
> Of course, code is usually set in fixed-pitch fonts, which actually makes
> tracking on long lines even more difficult.
> Adding to that is the observation that at 10 chars/inch, an 80 column screen
> fits within the printable borders of a letter-sized page (both US letter and
> metric A4). Scatter in a few ASCII FF characters in front of significant
> breaks in program flow, and listings become almost pleasant to read.... (ok,
> I guess I'm old.)
> --
> Ross Berteig                     
> Cheshire Engineering Corp. 
> +1 626 303 1602