[aur-dev] [PATCH] Remove all vim mode lines. Add HACKING file.

[Sebastian Nowicki]

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

> On Tue, 17 Jun 2008 15:09:08 +0800
> "Callan Barrett" <wizzomafizzo at gmail.com> wrote:
>
>> On Tue, Jun 17, 2008 at 1:06 PM, Loui <louipc.ist at gmail.com> 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.