Do JUCE Devs have a C++ Style Guide/Coding Rules document?

General JUCE discussion
1

Hi JUCE team,

I was just wondering if the core JUCE developer group have and apply a “Coding Rules” document/reference for the project, which might be also applied by other JUCE programmers?

I myself personally try to adhere to the “Google C++ Style Guide”, but I know there are others out there - and I wonder what might be the policy for the core JUCE devs? It’d be really useful to have this available as a reference when onboarding new JUCE developers in my own team, and as well I’d quite like to comply with it, if it indeed exists.

Here’s the Google C++ Style Guide, for reference - perhaps there is one for JUCE out there?

2

Is this what you’re looking for?

2 Likes
3

Thanks - yes, that would be what I’m looking for. Its a pity this isn’t in the JUCE repo, though, for reference by newcomers, although its better than not having one. I wonder if the core JUCE devs have updates to this, meanwhile?

4

It looks like it was updated in Feb 2025, which wasn’t long ago, so I assume the devs are keeping it up to date.
I agree it could be easier to find for newcomers if it was in the repo or online documentation, rather than a blog post. iPlug2 has a style-guide as part of their documentation, which you can find easily without trying.
That said, it’s better than what many frameworks provide, and it’s not so hidden (I found it with a simple Google search and it was the first result), but you won’t find it if you don’t look for it.

5

Yes, thanks for pointing out I suppose I should have probably searched first ..

In any case, I wonder if this coding rules document can get updated and make its way into the repo? I think it would be very valuable for newcomers to JUCE to read as an onboarding document ..

6

It might be worth mentioning this .clang-format file. It’s a slightly more up-to-date version of the one that was originally shared by the JUCE team.

1 Like
7

Just keep in mind that the JUCE coding standard is a) mostly good advice, but also b) has a bunch of opinions that are really just someone’s preference or idiosyncratic choices, and c) recommends a few things that are generally considered to be bad.

So just because JUCE itself has a particular code style doesn’t mean you as the user of JUCE needs to use that code style. (Personally I hate almost every aspect of their stylistic choices.)

4 Likes
8

In my code, I’ve moved towards using snake_case() for method names, for consistency with the standard library. I do still CamelCase for type names though, I like my types to be distinct from methods ¯_(ツ)_/¯

2 Likes
9

c) recommends a few things that are generally considered to be bad.

I’d be curious to learn more about this factor.

Coding Rules/standards are very useful, in my opinion, in terms of getting someone onboarded with an existing codebase. Of course, individual tastes and styles differ, and that’s okay - but for a lot of projects, it also matters to understand the standards, such as they are, that have been previously applied by others - whether they are tasteful or otherwise - just to get a bit of a leg up on the project.

1 Like
10

The JUCE coding style recommends this:

if (something)
    whatever;

over the practice of inserting braces, which is generally considered safer (goto fail anyone?), like so:

if (something) {
    whatever;
}

Of course the reason is that the JUCE preferred braces style would make it look like this, which wastes a lot of space:

if (something) 
{
    whatever;
}

A lot of things in coding styleguides are quite subjective but I was under the impression most developers were in agreement that not using braces here is bad practice.

2 Likes
11

I like how the JUCE style guide put a space after a pointer or reference instead of before. It’s is so much more intuitive in my opinion.

12

I like referring to the core guidelines for good vs bad practice and it seems from looking at a few examples in that document, they may favour the one line if statements. For example in F.56: Avoid unnecessary condition nesting they have the following example…

// Bad: Deep nesting
void foo() {
    ...
    if (x) {
        computeImportantThings(x);
    }
}

// Bad: Still a redundant else.
void foo() {
    ...
    if (!x) {
        return;
    }
    else {
        computeImportantThings(x);
    }
}

// Good: Early return, no redundant else
void foo() {
    ...
    if (!x)
        return;

    computeImportantThings(x);
}

It’s not that the rule is saying don’t use braces, you could use braces here, but an early return is exactly the kind of time I would personally reach for this style of if statement.

For me (and this is purely personal) I prefer this style for an early return regardless of the bracing style, (IMO) having the braces adds unnecessary visual clutter.

// Very cluttered
    if (!x)
    {
        return;
    }

    computeImportantThings(x);

// Still cluttered
    if (!x) {
        return;
    }

    computeImportantThings(x);

// This is my favourite
    if (!x)
        return;

    computeImportantThings(x);

// Uncluttered, but I like to see the return statement standout
    if (!x) return;

    computeImportantThings(x);

I should also add that the google style guide shared earlier also allows for this style of if statement (although by the sounds of it for legacy reasons).

That being said MIRSA says this

If you use single statements as bodies of if or if…else constructs, then attempting to change the body into a compound statement might result in logic errors and unexpected results. This rule ensures that braces are not missed or forgotten when attempting to turn a single statement body into a compound statement body. Failure to use compound statements might provide unexpected results and cause developer confusion. Use { } braces to create compound statements. Use braces even when the if statement is simple and contains only a single statement.

I have to say from 12 years of developing C++ in this style, it’s not an issue I ever recall encountering.

IME overall I find people normally tend to have very positive comments about the JUCE style.

Personally I would urge any team that doesn’t have coding standard yet to work on one together using a number of sources to inform your choices, it can be a good team building exercise. Once you’ve gone with something though try to stick to it, no need to keep making changes back and forth. Occasional updates particularly when there is ambiguity is fine.

6 Likes
13
14

I just use linters and do whatever they recommend (with the occasional exception).
No point arguing over standards that can’t be enforced/automated.

https://clang.llvm.org/extra/clang-tidy/

2 Likes
15

I essentially use braces everywhere except for something like an early return.

This is also something that annoys me about automatic formatters like clang-format: they are not flexible enough. Which such a tool it’s always one way or the other, whereas a human would sometimes use one approach and sometimes another. Consistency is great but foolish consistencies are hobgoblins or something.

1 Like
16

This is why we need AI tools that do more than write buggy code for you IMO.

I’d much prefer to write the code myself and have an AI linter/formatter that knowns my own personal formatting preferences and best practices from whatever guidelines I refer it to. The existing formatters and linters aren’t flexible enough as you say.

17

That’s a misrepresentation of the JUCE code style. The style says if there’s only one line in an if clause don’t use braces, otherwise use braces… and that’s for all if/else options… so

if (something)
    do_one_thing();

if (something)
    {
    do_thing_one();
    do_thing_two();
    }

if (something)
    {
    do_one_thing();
    }
else
    {
    do_thing_one();
    do_thing_two();
    }

Rail

3 Likes
18

Naturally if there’s more than one line you need braces. But you’re right, the JUCE guidelines say that braces can be omitted for “trivially simple statements”. I still think that’s generally considered to be bad advice.

P.S. Your example does not use the JUCE braces style. :wink:

19

It’s news to me that omitting braces around single-line statements is “generally considered” bad advice. Do the core guidelines say that? Is the argument mostly about consistency of all blocks having braces?

20

Not just to you apparently. :wink: I tried to find a conclusive source but what I could find is mostly people arguing one way or the other. Still, I believe most coding guidelines strongly recommend always using braces (but I haven’t read them all). More modern languages such as Swift avoid this issue by requiring braces.

The argument is avoiding bugs like goto fail. Adding braces costs nothing and it avoids a class of mistakes.

Linters can also help to avoid the same mistake and compiler warnings have become better at pointing out potential issues, and we’re using fewer C-style macros these days, so it’s possible to detect these bugs too if you enable enough warnings.

However, last week I was working on code that I inherited and came across this beauty:

if (something)
    if (something_else)
         do_stuff();
    else
         do_other_stuff();

A couple of braces could have avoided the bug there. (And yes, you probably know not to do this but whoever wrote this code didn’t.)

1 Like