Of style, and braces

I always subscribed to Allman style when programming in C; granted, before this project I never had any larger amount of code. Now I do have, and I'm finding that style to be getting in my way more and more.

You see, I do like to have empty lines in my code to separate small, logical chunks in a single block; usually, that means every few lines of code there is a separation. That way, code isn't all clumped together in one giant, incomprehensible block; it reads "light", and is much easier to understand.

Having intro and outro around every block, and code becomes more difficult to read, because it's visually more separated, and no matter how big your monitor is, it can only display so much. The thing is, I prefer to set my own separations, and the ones dictated by style I found useless, at best.

So, yesterday, I had a sort-of satori: what if I move braces around? Sure enough, there are already plenty of styles beside Allman's, you just need to pick one, and refactor code.

So, I went from Allman style:
if ( foo )
{
    bar();
    bar2();
}
else
{
    baz();
    baz2();
}

to one-true-brace-style, and found it okay-ish:
if ( foo ) {
    bar();
    bar2();
} else {
    baz();
    baz2();
}

That left me wanting more, so I decided to try to move outro braces out of sight as well:
if ( foo ) {
    bar();
    bar2(); }
else {
    baz();
    baz2(); }

Surprisingly, I found it to be readable, understandable code. As the saying goes, beauty is in the eye of a beholder; so I won't claim it's beautifully styled code, it certainly takes time to start appreciating it. Still, if you can ignore braces, it's reasonably formatted.

Gains are significant, too. With just one simple trick, I went from almost 10k SLOC down to slightly over 8k; difference is about 1500 SLOC, or about 15%. But more importantly than just numbers, code is so much easier to read, and understand, because related functions are shorter, and thus much less visually apart.

As everything in life, this style too has it's own fair share of downsides. First, and foremost, braces aren't visual fences of code blocks anymore; they are now just for compiler. If you have any of those fancy code editors/IDEs which can color braces, and maybe even indicate block between them, that would be major help. But even so, it's PITA to have to click at code element you're interested in, just to check if it really belongs to block you think it should.

Another issue is that you now relay on proper indentation to convey intended code blocks, formatting. Python was designed that way from the very beginning, but in C it takes time to get used to it. Arguably, that's not really an issue, most programmers do indent their code properly anyway.

Which brings me to final downside: it's possible to encounter code where indentation does not match real blocks, because braces somehow got mismatched. In newly written code, that shouldn't ever happen. Still, it's possible to end with spaghettified code blocks, when one refactors existing code base, and is not careful enough with search-replace, regex. Fortunately, there is always undo.

Still, I like this indent-style, I'll keep it for now.

Edit: well, that didn't last for a long. The indent-style, that is.

You see, the problem is, braces still determine to which code block a particular line belongs, but they aren't "visible", you have to parse code to find them. Syntax highlighting and good editor can help, but usually only one code block at the time. Maybe VS Code can put visual hints around every code block, but I didn't bother, visual cacophony most likely would be overwhelming. 

So, I already switched back to 1TBS, a few days ago. When in doubt, wisdom of the commons (most popular choice) might be, if not the best choice, the least atrocious.