Re: Is 80-column source code formatting still standard ?

André Pang <[email protected]> writes:
> On 25/06/2008, at 3:34 PM, Mary Gardiner wrote:
>
>> One point in favour of approx 80 character lines in both code and
>> writing is that apparently there is some suggestion that it's much
>> more natural to read text of that width than it is to read really long
>> lines.
>
> I entirely agree that shorter lines of text make for easier reading,
> but I'm not convinced that argument applies to code.  If you have a
> big expression, you don't have too many choices.  

You will find that this opinion is, in essence, the heart of the
disagreement that most people have with your thesis.  I certainly do.

> You can split the expression up into its own dedicated functions,
> which may lower readability by forcing you to navigate around the file
> to figure out what's going on.  

I absolutely agree with this: it certainly /may/ lower readability.

However, /may/ is not a very strong supporting position for your
argument.  It renders your point essentially meaningless:

I could, for example, substitute various things for "split ... dedicated
functions" and have a valid, and equally poorly supported claim:

  You can write your code in <any language>, which may ...
  You can write your code {with,without} extensive commends, which may ...
  You can write your code in {functional,OO,procedural} style, which may ...

Do you see the problem here?  Your argument is, in essence, that we
should fear that splitting into functions is concerning because bad
things might, possibly, happen.

You even supply an example of why, which is nice: we might have to
navigate around to understand the expression.  I can't argue that: it
might happen, or it might not -- who knows?


The same is true of all my examples: you /might/ have to learn
<any language> to be able to understand the code, or you /might/ need
the comments -- or be distracted by them. 

You /might/ not understand a functional style program, or you /might/
need facilities that OO design offers your code.


If you want to make that claim you should probably rephrase it until you
can remove the wishy-washy "may" part of the claim -- until it is
something, like your other arguments, that you can defend as likely.


> You can use shorter variable names, but that almost always lowers code
> readability.  

I don't really agree here: if you can't express the purpose of your
variable or function in one or two short, clear English[1] words then
you are probably modelling the problem domain incorrectly.

I think, personally, that the best way to understand that is to study
written expression in English or other human languages: you will find
that, as a rule, the more complex your qualified terms are the harder it
is for the reader to comprehend.

While computer languages are much more restricted than human language
they serve the same purpose, more or less: to communicate to people.

(Oh, and they coincidentally make the computer do something, but mostly
 they exist so we poor humans can comprehend the program -- otherwise,
 trivially, toggling the front panel switches would be just as good.)


So, I would argue that while you can choose bad variable names or
abbreviations in an effort to reduce code size, you generally shouldn't
need to /if/ you are communicating effectively.

I discount arguments, here, about how likely hood you are to work with
bad developers who, in their foolishness, cannot choose good, clear
variable names: no matter how idiot proof you make your system they can
/always/ find a bigger, better idiot. ;)


> You can assign sub-expressions to intermediate variables, but then you
> have the burden of naming the variables for the sub-expressions, plus
> you probably also want to mark that intermediate variable as immutable
> (const) otherwise it's one more possible stateful variable to keep
> track up when trying to understand how a function works.

I agree wholeheartedly with you here; you are absolutely correct.

> I don't think it'll be hard to find cases where a 160-character line
> is a lot more maintainable than trying to split it into 3 or 4 lines
> of 50 columns each.

I, personally, do, simply because I don't know of any editors out there
which are particularly intelligent about word-wrapping wide columns.

You can break the expression into four lines by hand in a much more
sensible way than an arbitrary 80 (or 90, or 100, all of which are
common enough) column cut-off.

That 80 column point may be half way between words, or in the middle of
a sub-expression, or any number of other bad choices.[2]


It is also notable that studies of printed and written English are
fairly consistent in their findings: people find narrow columns much
easier to read than wide columns.

An easy example of this is to compare, for yourself, the difficultly of
reading text on a website that has a narrow column of text -- say, a
newspaper or a Blogger or WordPress blog -- with something that spreads
text the full width of a maximized browser.

I find, as do most people (according to Science!!), that the former is
vastly easier to read.  

This is why newspapers and books have chosen the format they have:
because it works, effectively, for communicating to people.

Regards,
        Daniel


Footnotes: 
[1]  ...assuming you are writing for an English speaking audience, which
     is a reasonable assumption in this group, I believe.

[2]  Yes, a better editor /would/ make a lot of this moot.  If you can
     supply one I would certainly consider revising my position here. :)

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html