On 17/06/2008, at 9:34 PM, Loui wrote:

On Tue, 17 Jun 2008 15:09:08 +0800 "Callan Barrett" wrote:

...

On Tue, Jun 17, 2008 at 1:06 PM, Loui wrote:

...

I made this patch after a little discussion on IRC. Please comment. Cheers!

I am definitely for this behavior, except perhaps that line width limit since we don't use terminals that cut off at 80 characters to edit code anymore. But if you're just suggesting this as a guideline and not as some to be enforced limit I'm good for all of it.

Limiting line width is not only about terminal width. It's also about making code and patches more readable. Imagine having to scan a patch with multiple lines at 200 columns wide or something. It will be a pain having to spot small changes in those lines. It's also a lot easier for human eyes to scan a shorter line of text and be able to quickly return to the beginning of the next line. This is why newspaper and magazine articles are printed in columns rather than running across the whole bloody page.

Sometimes fitting within 80 characters is a bit hard (I'm not talking about scenarios with 4 nested loops - eww), in which case 90 or even 100 characters would be more acceptable than breaking it up in some hideous way. For instance, even in such a simple scenario, I think this looks better:

foo = very_long_line_that_spans_more_than_eighty_characters(bar, baz);

vs:

foo = very_long_line_that_spans_more_than_eighty_characters(bar, baz);

It's still very readable, should fit on all screens these days, diffing/patching would probably work better (think merge conflicts with a different amount of params). This is definitely true in verbose languages like Java, where just one method call takes up more than 80 characters.