linux-kernel - Re: [PATCH v2 2/3] iio: light: ROHM BH1745 colour sensor

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] [day] [month] [year] [list]

Message-ID: <20240608162035.6965cad5@jic23-huawei>
Date: Sat, 8 Jun 2024 16:20:35 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Mudit Sharma <muditsharma.info@...il.com>
Cc: Javier Carrasco <javier.carrasco.cruz@...il.com>,
 ivan.orlov0322@...il.com, lars@...afoo.de, krzk+dt@...nel.org,
 conor+dt@...nel.org, robh@...nel.org, linux-kernel@...r.kernel.org,
 linux-iio@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 2/3] iio: light: ROHM BH1745 colour sensor


> >>>
> >>> Nit: black line before return (it applies to several functions in this
> >>> driver, but again, not in all of them).  
> >>
> >> Hi Javier,
> >>
> >> Thank you for the review on this.
> >>
> >> Can you please point me to resource/section of code style guide for
> >> reference which talks about new line before 'return'.
> >>
> >> Best regards,
> >> Mudit Sharma
> >>
> >>
> >>  
> > 
> > AFAIK that is not written in stone, but many common practices are not
> > documented anywhere (e.g. names of error/ret variables). They just copy
> > what the majority of the code in that subsystem does. There is indeed a
> > tendency to add a blank line before the last (unconditional, not
> > labeled) return, but I am sure that some code does not follow that.
> > 
> > Having said that, I don't have a strong opinion (it was a nitpick) on
> > that, but what I would definitely recommend you is following **some**
> > pattern. There are some functions where you added a blank line, and some
> > others (the majority, I think), where you didn't. Given that this is new
> > code, uniformity would be appreciated.
> > 
> > Unless an IIO maintainer (I am NOT one) says otherwise, I would find
> > both approaches (blank/no line) reasonable, even though I like the blank
> > line in that particular case :)
> > 
> > Best regards,
> > Javier Carrasco  
> 
> Thanks for the explanation here.
> 
> I agree with having a consistent pattern and will make the necessary 
> changes to v3.
> 
> Best regards,
> Mudit Sharma
> 
I'm feeling grumpy today and you are the unlucky ones, given it's
been a day of much scrolling.

Crop your replies to just the relevant context as I've done here.

Yes, I prefer the blank line in most cases. However as noted the more
important factor is local consistency.  Aim here is to make your code
as easy to review as possible - having it all look the same is a good
way to help that.

Jonathan