Messages in this thread | | | Date | Sat, 4 Feb 2012 14:08:59 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] SubmittingPatches: Increase the line length limit from 80 to 100 colums |
| |
* Andrew Morton <akpm@linux-foundation.org> wrote:
> On Fri, 3 Feb 2012 11:07:43 +0100 > Ingo Molnar <mingo@elte.hu> wrote: > > > [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. > > I always use 80-cols, everywhere. Not because I particularly > like it - I find it a bit too small. I use it because it is > the standard, and using it helps me see where and how badly we > violate the standard. > > We've actually done pretty well - linewrap in 80 cols rarely > causes me problems. It's sufficiently rare that when it > *does* happen, it really stands out.
Maybe it got better after the introduction of checkpatch - I stopped using 80col terminals because the situation *was* getting so bad and because i did not feel like fighting a thousand other kernel developers who had different preferences ;-)
> IOW, the changelog is quite the exaggeration.
You are right about that.
> > So lets increase the limit to 100 cols > > I think that's going too far - 96 will be enough and it's a > multiple of 8. > > The multiple-of-8 thing seems pleasing but probably doesn't > matter much. It means that things like > > > if (foo) { > if (foo) { > if (foo) { > if (foo) { > if (foo) { > if (foo) { > if (foo) { > if (foo) { > if (foo) { > if (foo) { > if (foo) { > if (foo) { > if (foo) { > if (foo) { > if (foo) { > > > will line up properly. > > If we really want to improve the world we should jump into a > time machine and set tabstops to 4. Sigh.
I think that would be a distinctly bad decision - people could have crazy, 10 levels nesting in a function and be technically 'compliant'.
8 col tabs _forces clean code_ more often than not. I know about very few functions in the kernel that legitimately need more than 3 or 4 levels of nesting.
And that is why I agree with the 6-tab based warning approach - then we can remove the 80col warning which is really making things actively worse.
Thanks,
Ingo
| |