Re: To <=80 char code line length or not (focus)

[shmem]

While the 80 char limit may have its origin in widely accepted typesetting conventions for books with flowing text, combining book size, font size, line length and line number, those containing poetry leave the most part of their pages blank.

Reading flowing text, long lines make it difficult to return to the start of the following line after reaching the current line ending, which makes me memorize the current lines starting block of 1-2 lines before and after the current one, which is is annoying and hinders my flowing comprehension of what I am reading, and the limit of chars per line at which that orientation support begins to occur seems to be dependant on other factors like line margin, font, topic and so on, and - of course - also on the amount of information expressed and the numbers of sentences and sub-sentences being involved in that expression. Qed.

But code is neither flowing text nor poetry. Readability of code follows a whole bunch of different or additional factors.

An important one is proper variable naming. I think the most important one is focus - horizontally, vertically or block-wise. A simple transforming subroutine with a good name consisting of a single statement, sporting map, grep, sort, referencing and de-referencing with proper variable names and sensible spacing can easily be longer than 80 chars, whilst being just a macro which could be inlined. It depends of your own reading/writing habits and that of your team and/or audience whether you break that up into multiple lines.

Most of the bible prints I have seen are typeset with a very small font and 3-4 columns per page, so as to narrow the focus to just the holy sentence at hand, which purportedly helps to induce the "alpha wave" mode of the brain and protects from seeing the bigger picture. Nice trick.

So - as always, it depends, and TIMTOWTDI. I could, for instance, format my code left aligned, and the comments right aligned, and read either top down without distraction. Or just center the core of a subroutine after conditionals resolving, and before wantarray resolution. Or else.

Maybe we'll get editors some day which permit zooming in and out of projects for proper focus, as we already can do with online maps. We could then zoom into bugs until they fill the whole screen.

The 80 columns restriction is a thing of the past, and while the convention lives on for hysterical raisins, software or coding standards which enforce that restrictions for no other reasons than "well, it's been like that and therefore we continue doing it like that" is just annoying. Take the results from the ldapsearch(1) utility from openLDAP which splits lines after 78 chars, forcing reassembly of lines for further processing. There's absolutely no reason to do such a thing except for the holy cow "backward compatibility", and it forces you to filter the output with e.g. perl -p00 -e 's/\n //g' which is silly.

I'm formatting with "proper" indentation and in a way which looks fitting to me (except in python); for those yelling at me after the fact I have perltidy.