From:  Benjamin Bouvier <>
Date:  28 Sep 2017 16:55:05 Hong Kong Time

Re: C++ coding style rule for keeping class fields together


Agreed with Lars. In particular regarding (b), I tend to read unknown code
by starting with the data (the "what") then look at how it's manipulated
(the "how"). This stylistic change would be a huge regression to me, and
there are already some places where the fields are grouped at the end,
which I've found these very confusing.

That being said, I agree having the fields grouped is much better than the
messes that are JSContext or JSRuntime, sometimes intertwining fields and
methods which don't even seem related to the fields defined just before.


2017-09-28 9:10 GMT+02:00 Lars Hansen :

> I dislike this proposal.  (a) A lot of the code I work with already have
> fields-at-the-beginning as the predominant pattern in the smaller classes
> (jit, wasm) so this would be major churn for no gain.  (b) For large
> classes this is an anti-pattern, like having all the vars at the beginning
> of a function in C; it separates the data from the functions that work on
> that data.  (c)  It brings private and public parts of the code close
> together, and separates public data from public methods.
> --lars
> On Wed, Sep 27, 2017 at 6:18 PM, Jason Orendorff 
> wrote:
> > Hi everyone.
> >
> > I'd like to add a style rule: in a struct/class/union, put all the fields
> > (that is, non-static member variables) together, at the end.
> >
> > Maybe this is dumb, but while working with Rust I got used to this. Rust
> > doesn't allow methods to be defined within a struct or enum. And wow is
> it
> > easier to see what's going on. "Show me your tables..." and all that.
> >
> > (At the end is better than at the top because you *can't* always put all
> > the fields together at the top. Sometimes you have to declare a type
> first.
> > Sometimes it's a nested class that's rather a lot of code.)
> >
> > If nobody objects in a day or two, I'll add the new rule here:
> >
> >
> > -j
> > _______________________________________________
> > dev-tech-js-engine-internals mailing list
> >
> >
> >
> _______________________________________________
> dev-tech-js-engine-internals mailing list