Re: [PATCH] SubmittingPatches: Increase the line length limit from 80 to 100 colums

Tejun Heo
2012-02-03T16:14:08Z

Hello,

On Fri, Feb 03, 2012 at 11:07:43AM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <mingo@elte.hu> wrote:
>
> > > If we want to increase the standard to (say) 96 cols then
> > > fine, I'd be happy with that. But until we do that we
> > > should not create such a gruesome mess for those who use 80
> > > cols.
> >
> > The kernel has *already* become a gruesome mess for 80 col
> > users long ago. That was the main reason why I stopped using
> > 80 col terminals two years ago ...
> >
> > So lets stop the pretense.

I don't know. In my experience, a lot of code, especially core part,
mostly follows 80 col limit. It shouldn't be too difficult to write
up a script to count >80col lines in different parts of the kernel.

> [PATCH] SubmittingPatches: Increase the line length limit from 80 to 100 colums
>
> The overwhelming majority of kernel developers have stopped
> using 80 col terminals years ago.
>
> As far as I'm aware I was the last regular kernel contributor
> who still used a standard VGA text console, but both text
> consoles and using them to read the kernel source code has
> become increasingly gruesome years ago so I switched to a wider
> terminal two years ago.

People usually place multiple windows horizontally so it's not like
all those extra pixels go wasted. 80col might even have the benefit
of giving overall higher density in terms of pixel usage.

> Worse than that, people are actively uglifying the kernel code
> to fit things into 80 cols mechanically. They are using
> checkpatch and are interpreting the 80 col warnings the wrong
> way again and again, sucking up reviewer bandwidth that could be
> utilized better.
>
> So lets increase the limit to 100 cols - this is a nice round
> limit, and it also happens to match with most developer xterm
> sizes. Code that goes over 100 cols for no good reasons will be
> arguably something worth fixing. (100 cols is also arguably
> closer to various brain limits such as vision of field and
> resolution restrictions, so we'll likely not have to increase
> this limit for a couple of million years, for all retro human
> genome users.)

That said, yeah, 80col is a pain in the ass and lessening the pressure
a bit might make it a non-problem and 100 is one of the nicer numbers
which aren't power of two.

For me, the biggest reason to stick to 80col has been that, while
being widely disliked, it still was the most common limit people were
using and consistency tends to be more beneficial on these issues. If
we're gonna do this, and I hope we do, let's proactively encourage /
enforce it - ie. let's collectively nag so that 100col quickly becomes
the standard.

Acked-by: Tejun Heo <tj@kernel.org>

Thanks.

--
tejun