[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180822002314.GC18444@lunn.ch>
Date: Wed, 22 Aug 2018 02:23:14 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: David Miller <davem@...emloft.net>,
Stephen Hemminger <stephen@...workplumber.org>,
Netdev <netdev@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v1 3/3] net: WireGuard secure network tunnel
On Tue, Aug 21, 2018 at 04:59:52PM -0700, Jason A. Donenfeld wrote:
> On Tue, Aug 21, 2018 at 4:54 PM David Miller <davem@...emloft.net> wrote:
> >
> > From: "Jason A. Donenfeld" <Jason@...c4.com>
> > Date: Tue, 21 Aug 2018 16:41:50 -0700
> >
> > > Is 100 in fact acceptable for new code? 120? 180? What's the
> > > generally accepted limit these days?
> >
> > Please keep it as close to 80 columns as possible.
> >
> > Line breaks are not ugly, please embrace them :)
>
> Okay! Will do. Thanks for the response.
Hi Jason
I find the coding style document,
Documentation/process/coding-style.rst makes good arguments about why
it is like this:
Now, some people will claim that having 8-character indentations
makes the code move too far to the right, and makes it hard to read
on a 80-character terminal screen. The answer to that is that if
you need more than 3 levels of indentation, you're screwed anyway,
and should fix your program.
In short, 8-char indents make things easier to read, and have the
added benefit of warning you when you're nesting your functions too
deep. Heed that warning.
If you were to decided on 100, you might then want to go more than 3
levels deep, rather than heed the warning and refactor the code into
lots of smaller functions.
There is also:
Functions should be short and sweet, and do just one thing. They
should fit on one or two screenfuls of text (the ISO/ANSI screen
size is 80x24, as we all know), and do one thing and do that well.
It is worth reading the document in full, just for the rationale.
Andrew
Powered by blists - more mailing lists