How Python affected my C/C++ brace style

Before I even begin this post, one important disclaimer. When you're working on some existing body of code, by all means stick to its coding style. Even if you don't like it. This is the #1 most important advice I can give anyone on coding style (in case you're wondering, #2 is to be consistent).

In the 12-or-so years I've been programming in C and C++, I've mostly been using the Allman/ANSI style of braces:

while (x == y)
{
    something();
    somethingelse();

    if (condition)
    {
        do_this();
        do_that();
    }
}
finalthing();

I'm not sure why I picked it from the start - there are some vague memories of it being default in MS Visual C++ 6, although the exact details aren't important.

As any self-respecting programming newbie, I held on to this style religiously, and was genuinely disgusted by alternative styles like the K&R style:

while (x == y) {
    something();
    somethingelse();

    if (condition) {
        do_this();
        do_that();
    }
}
finalthing();

Over the years, as I found myself in need of editing existing code written in some other style, I became less fervent and preferred consistency. But I still used the ANSI style for any new code I wrote.

A strange thing happened when I began writing a lot of Python code. Python, as you know, doesn't have braces, which makes it conceptually closer to the K&R style in C:

while x == y:
    something()
    somethingelse()

    if condition:
        do_this()
        do_this()

finalthing()

As Python slowly but firmly caught its place as my favorite programming language, this style started growing on me, and I even began wondering why I don't use the K&R style for C and C++.

Readability and cleanness is an important strength of Python as a language and an ecosystem. Thankfully, most Python programmers are familiar with PEP 8 which rather strictly defines the coding conventions for Python and is used by the entire standard library, as well as most well-known 3rd party modules.

Far less programmers are familiar with PEP 7, which in a manner similar to PEP 8 dictates the programming style to be used for the official C implementation of Python, as well as extension modules written in C.

When I started contributing to Python and perusing its internals, I noticed that C code written with PEP 7 in mind has the same nice consistency as Python code written in PEP 8 style, and since the brace style advocated by PEP 7 is K&R, I finally broke down and adopted it for my C/C++ coding.

One annoyance I still haven't resolved with this style is with long conditions. Consider this Python code:

if (cond1 == 'val1' and cond2 == 'val2' and
    cond3 == 'val3' and cond4 == 'val4'):
    do_something()

I find it visually unappealing because it's hard to discern where the condition ends and where the body of the if starts. I even opened an SO question on the topic a while ago and discovered I'm not the only one struggling with this dilemma. Some interesting ideas were raised, although no one really has a perfect solution for this.

Unfortunately, this problem manifests itself in the K&R brace style in C/C++ for the same reason:

if (cond1 == "val1" && cond2 == "val2" &&
    cond3 == "val3" && cond4 == "val4") {
    do_something()
}

While it doesn't really exist in ANSI style, because the opening brace on a line of its own cleanly separates the condition from the body:

if (cond1 == "val1" && cond2 == "val2" &&
    cond3 == "val3" && cond4 == "val4")
{
    do_something()
}

Still, K&R brace style (and PEP 7 style in general) is the one I prefer now. Switching brace styles turned out to be not very difficult. But remember that being consistent is still far more important than any single style.