linux-kernel - Re: [PATCH 1/3] staging: panel: (coding style) Matching braces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 26 May 2014 17:05:13 +0200
From:	Willy Tarreau <w@....eu>
To:	Dominique van den Broeck <domdevlin@...e.fr>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] staging: panel: (coding style) Matching braces

On Mon, May 26, 2014 at 04:45:05PM +0200, Dominique van den Broeck wrote:
> 
> Hello Willy,
> 
> > I don't want to be nit-picking, but since we're talking about style...
> > for me these "} else {" statements are harder to parse than having them
> > on two lines this way :
> > <...>
> >
> > It's just a matter of taste I know, but for me they read easier, probably
> > because the braces do not affect alignment and the lines appear exactly
> > similar with or without the braces.
> 
> I don't mind at all about this. 
> 
> Even if I'm into C code for quite a long time now, I'm still new in kernel
> development (just completed the Eudyptula Challenge) and I thought it could
> be both a harmless and useful way to start contributing and get used with it
> to focus a bit on ./checkpatch.pl suggestions (which is the actual entity to
> blame about it).
> 
> This is the reason why I submitted the patch but it's not a personal
> preference. If you prefer these braces laid out the older way, I'll let
> them as is next time. If there's another usages I should know about, just
> let me know.

You shouldn't bother too much about these style issues in fact. You'll
ask 4 people, you'll get 4 different opinions and will end up with
frustration depending on who will reply with just a "NAK", and sometimes
your change will cause a regression because it's easy to to a mistake
when just changing style.

The best thing to do in general if you want to slowly get into the kernel
is to focus on features you're actually using and which do not work the
optimal way. It's then easy to start by adding debugging code all over
the drive, find where the functions are called from and progressively
get an idea of what does what. Buying cheap small devices is a fun way
to do this BTW :-)

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/