Re: CodingStyle

Re: CodingStyle

[Stefan Richter]

Pavel Machek wrote:
> +Avoid extra spaces around ! operator, and do not place spaces around (s.

How about:

	Avoid extra spaces after the ! operator.
	Do not place spaces around parentheses.

Because "foo && !bar" is certainly OK.

Or more draconian for the former and less so for the latter rule:

	Do not put whitespace between any of the unary operators and
	their operand.

	It is usually unnecessary to have whitespace around parentheses
	as part of expressions, around brackets, or around the operators
	. and ->.

Rule 1 certainly applies likewise to ++, --, unary +, unary -, !, ~,
(typecast), unary *, unary &, sizeof.

Rule 2 applies to all of ( ), [ ], ., ->, except where line breaks and
indentation warrant whitespace, or where whitespace helps to read
expressions with more levels of braces. Although the latter should be
avoided anyway.
-- 
Stefan Richter
-=====-=-==- =--= --=-=
http://arcgraph.de/sr/

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: CodingStyle

[Stefan Richter]

Pavel Machek wrote:
> +Avoid extra spaces around ! operator, and do not place spaces around (s.

How about:

	Avoid extra spaces after the ! operator.
	Do not place spaces around parentheses.

Because "foo && !bar" is certainly OK.

Or more draconian for the former and less so for the latter rule:

	Do not put whitespace between any of the unary operators and
	their operand.

	It is usually unnecessary to have whitespace around parentheses
	as part of expressions, around brackets, or around the operators
	. and ->.

Rule 1 certainly applies likewise to ++, --, unary +, unary -, !, ~,
(typecast), unary *, unary &, sizeof.

Rule 2 applies to all of ( ), [ ], ., ->, except where line breaks and
indentation warrant whitespace, or where whitespace helps to read
expressions with more levels of braces. Although the latter should be
avoided anyway.
-- 
Stefan Richter
-=====-=-==- =--= --=-=
http://arcgraph.de/sr/

CodingStyle

[HarryWei]

> 2010/12/11 Robert P. J. Day <rpjday@crashcourse.ca>
> 
> > On Sat, 11 Dec 2010, HarryWei wrote:
> >
> > > Hi all,
> > >       I just read the CodingSyle at Documentation directory in
> > linux-2.6.23 kernel source code.
> > >       But a problem happened to me like following.
> > >       Functions in linux-2.6.23/fs/fs-writeback.c are "static int" and
> > function name are in different lines.(function name in following line)
> > >       I can't find the rule in CodingStyle. That We often program
> > functions are "static int" and function name are in the same line.
> > >       When do we do the first or second way? What is different between
> > them?
> > >
> > >   Any answer is okay.
> > >   Best regards.
> >
> >   the advantage to the form
> >
> > static int
> > function-name
> >
> > is that, if you're looking for the actual function *definition* in the
> > file, having the function name at the start of a new line means you
> > can search for it with the pattern "^function-name" so that you don't
> > have to wade through all of the invocations of that function.
> >
> >  i like that style; others claim that with proper cross-referencers
> > like cscope, doing that is redundant.  as far as i know, the kernel
> > coding style doesn't take a position on that, but i'm willing to be
> > corrected.
Thanks, i see :)
> >
> > rday
> >
> > --
> >
> > ========================================================================
> > Robert P. J. Day                               Waterloo, Ontario, CANADA
> >                        http://crashcourse.ca
> >
> > Twitter:                                       http://twitter.com/rpjday
> > LinkedIn:                               http://ca.linkedin.com/in/rpjday
> > ========================================================================
> >
> 
> 
> 
> -- 
> Best Regards.
> Harry Wei.
> Do what u like!

CodingStyle

[Opensource [Anthony Olech]]

> -----Original Message-----
> From: Guenter Roeck [mailto:linux@roeck-us.net]
> Sent: 18 April 2013 05:14
> To: Opensource [Anthony Olech]
> Cc: Jean Delvare; Mark Brown; Randy Dunlap; lm-sensors@lm-sensors.org;
> LKML; David Dajun Chen
> Subject: Re: [NEW DRIVER V5 6/7] drivers/hwmon: DA9058 HWMON driver
> 
[...]
> > +	if (cell == NULL) {
> > +		ret = -ENODEV;
> > +		goto exit;
> 
> Just return -ENODEV is good enough here. See CodingStyle, chapter 7.
> 
[...]
> > +exit:
> > +	return ret;
> > +}
[...]

Hi Guenter,

I have read CodingStyle, chapter 7 and it seems to encourage a single exit point from functions.

During development there was some logging done at the (single) exit point but that has been stripped out for submission.
Whilst I can duplicate the logging and do an immediate 'return' at all those points, I am hesitant to do so when chapter 7 of the CodingStyle appears to say to use a single exit point. In addition I had thought that a single exit point from functions was a good thing.

Tony Olech

Re: CodingStyle

[Guenter Roeck]

On Thu, Apr 18, 2013 at 10:48:06AM +0000, Opensource [Anthony Olech] wrote:
> > -----Original Message-----
> > From: Guenter Roeck [mailto:linux@roeck-us.net]
> > Sent: 18 April 2013 05:14
> > To: Opensource [Anthony Olech]
> > Cc: Jean Delvare; Mark Brown; Randy Dunlap; lm-sensors@lm-sensors.org;
> > LKML; David Dajun Chen
> > Subject: Re: [NEW DRIVER V5 6/7] drivers/hwmon: DA9058 HWMON driver
> > 
> [...]
> > > +	if (cell == NULL) {
> > > +		ret = -ENODEV;
> > > +		goto exit;
> > 
> > Just return -ENODEV is good enough here. See CodingStyle, chapter 7.
> > 
> [...]
> > > +exit:
> > > +	return ret;
> > > +}
> [...]
> 
> Hi Guenter,
> 
> I have read CodingStyle, chapter 7 and it seems to encourage a single exit point from functions.
> 
Yes, unless you can return directly. There is even an example.
It actually says "... and some common work such as cleanup has to be done".

> During development there was some logging done at the (single) exit point but that has been stripped out for submission.
> Whilst I can duplicate the logging and do an immediate 'return' at all those points, I am hesitant to do so when chapter 7 of the CodingStyle appears to say to use a single exit point. In addition I had thought that a single exit point from functions was a good thing.
> 
Not if you add a goto to a return statement. That defeats the purpose
of easy readability.

Guenter

RE: CodingStyle

[Opensource [Anthony Olech]]

> -----Original Message-----
> From: Guenter Roeck [mailto:linux@roeck-us.net]
> Sent: 18 April 2013 14:42
> To: Opensource [Anthony Olech]
> Cc: LKML
> Subject: Re: CodingStyle
> 
> On Thu, Apr 18, 2013 at 10:48:06AM +0000, Opensource [Anthony Olech]
> wrote:
> > > -----Original Message-----
> > > From: Guenter Roeck [mailto:linux@roeck-us.net]
> > > Sent: 18 April 2013 05:14
> > > To: Opensource [Anthony Olech]
> > > Cc: Jean Delvare; Mark Brown; Randy Dunlap;
> > > lm-sensors@lm-sensors.org; LKML; David Dajun Chen
> > > Subject: Re: [NEW DRIVER V5 6/7] drivers/hwmon: DA9058 HWMON driver
> > >
> > [...]
> > > > +	if (cell == NULL) {
> > > > +		ret = -ENODEV;
> > > > +		goto exit;
> > >
> > > Just return -ENODEV is good enough here. See CodingStyle, chapter 7.
> > >
> > [...]
> > > > +exit:
> > > > +	return ret;
> > > > +}
> > [...]
> >
> > Hi Guenter,
> >
> > I have read CodingStyle, chapter 7 and it seems to encourage a single exit
> point from functions.
> >
> Yes, unless you can return directly. There is even an example.
> It actually says "... and some common work such as cleanup has to be done".

OK, thank you for clarifying that. I will make the necessary changes.
 
> > During development there was some logging done at the (single) exit point
> but that has been stripped out for submission.
> > Whilst I can duplicate the logging and do an immediate 'return' at all those
> points, I am hesitant to do so when chapter 7 of the CodingStyle appears to say
> to use a single exit point. In addition I had thought that a single exit point from
> functions was a good thing.
> >
> Not if you add a goto to a return statement. That defeats the purpose of easy
> readability.
> Guenter