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

Ingo Molnar
2012-02-04T13:09:20Z

* 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