Code readability: Use early return/continue/break

[hoffie]

Is your feature request related to a problem? Please describe.
Jamulus code currently has places with large levels of nesting/indentation. This is hard to read and follow through.
Example: https://github.com/jamulussoftware/jamulus/blob/master/src/audiomixerboard.cpp#L1138

The example has 7 levels of indentation which requires cognitive load to remember which level is what (a function, a for loop, an if).

Describe the solution you'd like
I propose usage of early continue/break (in loops) and return (in functions). This eases cognitive load.

Shortened, reworked code from the example:

void CAudioMixerBoard::ApplyNewConClientList ( CVector<CChannelInfo>& vecChanInfo )
{
    // get number of connected clients
    const int iNumConnectedClients = vecChanInfo.Size();

    Mutex.lock();
    {
        // we want to set the server name only if the very first faders appear
        // in the audio mixer board to show a "try to connect" before
        if ( bNoFaderVisible )
        {
            UpdateTitle();
        }

        // search for channels with are already present and preserve their gain
        // setting, for all other channels reset gain
        for ( int i = 0; i < MAX_NUM_CHANNELS; i++ )
        {
            bool bFaderIsUsed = false;

            for ( int j = 0; j < iNumConnectedClients; j++ )
            {
                // check if current fader is used
                if ( vecChanInfo[j].iChanID != i )
                {
                    continue; // <-- It's about this pattern
                }
// ...

I propose changing code in places where it is most relevant and places which are touched anyway.
I'm not suggesting that the whole codebase must be changed right now. I'm merely evaluating if PRs which do this would be accepted.

Describe alternatives you've considered
Keep things as they are.

Additional context
https://softwareengineering.stackexchange.com/questions/18454/should-i-return-from-a-function-early-or-use-an-if-statement
https://danp.net/2015/11/02/reducing-go-nesting.html
https://medium.com/better-programming/are-early-returns-any-good-eed4b4d03866

[ghost]

Using early return/continue/break is not a coding style unless you insist on it even when it makes matters worse.
The opposite is also not a coding style unless ... worse.
I do believe you made a readability improvement in this case.

[hoffie]

Using early return/continue/break is not a coding style

Thanks. I understand that you are saying it would be better to avoid calling the proposal a "coding style change"? I have modified the title accordingly.

unless you insist on it even when it makes matters worse.

I don't want to propose that. :)

[softins]

I fully support early return/continue/break to avoid excessive nesting!

[pljones]

In terms of readability - there's a lot that could change. I don't like deep nesting and tend to press for it to change whenever I get the chance at work.

I think in Jamulus it was avoided to prevent missing unlocking Mutex locks - don't jump out of a lock, it stays locked! At least if you only have one entry and one exit, it's easier to verify.

I think there was also some debate over how well certain compilers optimised the code with early returns -- i.e. they added more code and/or made it worse performing. I'm not sure - I just always avoided changing things like this.

[gilgongo]

Hi - just moving this to a discussion, and if there's some defined action to be taken from that we can raise a ticket and progress that accordingly if that's OK.