On 09/11/2017 06:46 PM, Eric Rahm wrote:
Thanks everyone!
This got a bit derailed but it's clear that a unified style for binary
operators is desired.
I received several emails off-list in support of my original proposal,
a few people reiterated their preference for operators on the newline
Thanks everyone!
This got a bit derailed but it's clear that a unified style for binary
operators is desired.
I received several emails off-list in support of my original proposal, a
few people reiterated their preference for operators on the newline and we
rehashed that conversation. Overall giv
Le 08/09/2017 à 02:24, Martin Thomson a écrit :
> On Fri, Sep 8, 2017 at 1:08 AM, Ehsan Akhgari wrote:
>> The great majority of code changing is quite expected for any project
>> switching to clang-format, since as it turns out automated tools are much
>> better at doing this grunt work than human
On 9/7/17 4:45 PM, Ehsan Akhgari wrote:
$ git grep '\s(>|>=|<|<=|==|!=)\s*$' -- '*.c*' | wc -l
2794
Don't you get plenty of false positives for '>' with that regexp though?
For example:
dom/bindings/BindingUtils.h:template
js/public/HashTable.h:struct IsPod >
etc
/Mats
On Fri, Sep 8, 2017 at 1:08 AM, Ehsan Akhgari wrote:
> The great majority of code changing is quite expected for any project
> switching to clang-format, since as it turns out automated tools are much
> better at doing this grunt work than humans are. The reason projects choose
> to switch to usi
On 09/07/2017 07:23 AM, Jean-Yves Avenard wrote:
On Thu, Sep 7, 2017 at 3:03 AM, Eric Rahm wrote:
As I said, I was hoping to avoid rehashing this point, but the general
consensus from the last rather contentious post [1] was that changing from
the prevalent style of the codebase for primarily a
On 09/07/2017 04:17 AM, Mike Hommey wrote:
On Thu, Sep 07, 2017 at 12:47:51AM -0700, Chris Peterson wrote:
On 2017-09-06 8:06 PM, Ehsan Akhgari wrote:
The interesting points to consider is the data that Nick alluded to in
the previous discussion about the existing prevalent style.
Also, the po
On Thu, Sep 7, 2017 at 3:03 AM, Eric Rahm wrote:
> As I said, I was hoping to avoid rehashing this point, but the general
> consensus from the last rather contentious post [1] was that changing from
> the prevalent style of the codebase for primarily aesthetic reasons was
> hard to justify (points
On Thu, Sep 07, 2017 at 12:47:51AM -0700, Chris Peterson wrote:
> On 2017-09-06 8:06 PM, Ehsan Akhgari wrote:
> > The interesting points to consider is the data that Nick alluded to in
> > the previous discussion about the existing prevalent style.
> >
> > Also, the point you up about the pragmati
On 2017-09-06 8:06 PM, Ehsan Akhgari wrote:
The interesting points to consider is the data that Nick alluded to in
the previous discussion about the existing prevalent style.
Also, the point you up about the pragmatic aspect of the need to be able
to use automated tools in order to manage our
On 09/06/2017 09:03 PM, Eric Rahm wrote:
As I said, I was hoping to avoid rehashing this point, but the general
consensus from the last rather contentious post [1] was that changing
from the prevalent style of the codebase for primarily aesthetic
reasons was hard to justify (points about readab
On Wed, Sep 6, 2017 at 7:18 PM, Mike Hommey wrote:
> On a personal note, I find > 2000 as in the first sample more readable
> than the latter. So much so that I'd actually prefer the logical
> operators to be on the next line than boolean operator being on the
> previous.
A small +1. =)
-tom
___
As I said, I was hoping to avoid rehashing this point, but the general
consensus from the last rather contentious post [1] was that changing from
the prevalent style of the codebase for primarily aesthetic reasons was
hard to justify (points about readability were made on both sides). Nick
pointed
On Wed, Sep 06, 2017 at 12:30:58PM -0700, Eric Rahm wrote:
> Hi folks-
>
> *Note: Previously we've discussed the placement of logical operators && and
> ||; a decision was made and I do not wish to re-litigate that here*.
>
> Currently we have a somewhat convoluted set of rules about where to pla
Hi folks-
*Note: Previously we've discussed the placement of logical operators && and
||; a decision was made and I do not wish to re-litigate that here*.
Currently we have a somewhat convoluted set of rules about where to place
boolean operators when breaking long lines [1]. Essentially we say t
15 matches
Mail list logo
