Juce coding standards & members initialization


#1

Just wondering which style will take over in juce:

struct MyClass
{
    MyClass()
    : a()
    , b{}
    {
    }

    float a;
    float b;
    float c = 0.0f;
    float d{};

    float e = 1.0f;
    float f {1.0f};
    float g { 1.0f };
};

It seems you went for c/e lately?


#2

Yep, c/e is the preferred way of doing things.


#3

Not fancying those curly braces then?


#4

Makes it look too much like a function declaration for my taste. (Obviously for non-primitive types you do have to use curly braces).

e.g.

bool foo1 { true };          // variable
bool foo2 { return true; }   // function

#5

As far as I know, doesn’t make any difference for primitive types like floats whether the assignment or the curly braces are used. (For more complicated types I’ve encountered cases where a compiler didn’t want to accept using = to initialize the members.)


#6

Fair enough.

int magicFunction(int magicNumber);
int magicNumber{10};

Sort of - only the literals make it really obvious for me…and I’ve got the auto formatter set up so things look like this with a bit of spacing in there.

int magicFunction(int magicNumber);
int magicNumber{ 10 };

#7

Looks like a fuck up not a function that one :wink:

edit: a fucktion?


#8

oh yeah, whoops. Well, you know what I meant :slight_smile:


#9

Yeah but they are a bit more distinct now :wink:

bool foo1 { true };          // variable
bool foo2() { return true; }   // function

And a function is just a funny kind of variable anyway :wink:


#10

Still in your defence. I do think the equals states what’s going on more clearly than braces. But if the C++ tide is drifting towards braces I don’t know if want to stand in its way


#11

How much is the decision c/e reasoning and/or how much is it taste?

I must admit I like a better as all initialisation is in one place whereas c/e can lead to the initialisations being cluttered in the class declaration.


#12

Yeah, I understand. Really don’t like the look of code that’s just full of braces though, It just all starts looking like LISP…


#13

a is cumbersome when you have multiple constructors which all require variables to be initialised in the same way. c and later are more DRY.


#14

‘a’ is just bloody horrible. Init order is much easier to manage with the initalizers all next to the definitions…


#15

It will also save you if you forget to initialise a member.

There is one key difference between using = and { } in that the latter will emit narrowing errors at compile time so is safer. You may be lucky enough to get a compiler warning for a conversion but having the build break is more secure in my opinion.