unrelated note: I understand the setting IncludeBlocks is set to Preserve (and it should probably stay this way by default, but it would be nice to update the other Include* settings (in another pull request) to properly sort the includes: (1) the main include, (2) everything else (Bitcoin Core includes) (3) third-party library includes (boost, Qt), (4) stdlib includes (those that do not end in .h). This way, one could toggle the IncludeBlocks to get the desired behavior.

Why change the C++ Coding Style? I got used to the current one, which encourages structs for POD as a separate thing.

We can define it that way as well (though I don't agree with the distinction vs classes), but not specifying it directly results in different versions formatting structs differently, so we should define it explicitly

Ran clang-format -i -- **.cpp **.h **.hpp in src/ for both AfterStruct true & false, and compared diffs. Man was it close.

Even though struct & class can be used interchangeably in C++, only with different defaults for public/private, I think we might as well benefit from the fact that we have 2 concepts and use them to communicate which types are POD (more C-like) or not. (C# includes both too but places limits on struct such as disabling support for inheritance and treating them as value types by default).

I took for granted that the omission of struct on this line in developer-notes.md was intentional. Comes from #4498, but conversation unfortunately doesn't touch on struct. Author of that PR copyrighted a C-only library one year earlier (https://github.com/bitcoin-core/secp256k1/blob/master/COPYING#L1). It also has opening curlies on same line as struct.

Happy to have explicitly defined, but my vote is for false and not changing developer-notes.md. - Dropping the second commit.

I would be fine with both as long as it's explicit. I still find the rationale that struct and class should be formatted similarly, it's harder for me to explain why struct is more like a for loop than a class...

85'849 lines

I have no idea what these numbers mean, I checked same-line opening braces with

% grep -E '^\s*\bstruct\b\s+[^;{]*\{' --include="*.h" --include="*.cpp" -r src/ | wc -l
     393

and quickly vibe coded a script that does newlines:

#!/bin/bash

echo "Analyzing struct brace placement in Bitcoin Core..."

# Count same-line braces
same_line=$(grep -E '^\s*struct\s+[^;{]*\{' --include="*.h" --include="*.cpp" -r src/ | wc -l)

# Count next-line braces using awk
next_line=$(find src/ \( -name "*.cpp" -o -name "*.h" \) -exec awk '
/^[[:space:]]*struct[[:space:]]+[^;{]*$/ {
    struct_line = NR
    getline
    if (/^[[:space:]]*\{/) {
        count++
    }
}
END { print count+0 }
' {} \; | awk '{sum+=$1} END {print sum}')

echo "Structs with same-line brace: $same_line"
echo "Structs with next-line brace: $next_line"
echo "Total: $((same_line + next_line))"

which vibe-revealed:

Analyzing struct brace placement in Bitcoin Core...
Structs with same-line brace:      393
Structs with next-line brace: 223
Total: 616

So the counts don't really matter in my opinion, we have a few hundred of each, there's no clear winner based on usage, let's come up with better arguments for either.

The line-counts where from the resulting git diffs. Admittedly they are imprecise due to surrounding context and other clang-format changes, but they give a rough relative estimate.

Thanks for vibing, almost double on same line. I'd say that does matter.

Edit:

it's harder for me to explain why struct is more like a for loop than a class...

Maybe seeing struct as a small/passive/record thing and seeing class as more of an alive/process thing with multiple methods and internal logic makes it closer to a function? Main thing for me is to keep to what a majority of the current code and coding style says, otherwise this change should probably be discussed more broadly.

Admittedly they are imprecise

I'd say ~85000 vs ~400 is a bit more than imprecise :)

almost double on same line

That's not how we usually decide outcomes, rather by better explanations - especially since many of those aren't counting declarations, e.g

• bitcoin/src/bitcoin-cli.cpp

  Line 241 in f7d2db2

  struct evbuffer *buf = evhttp_request_get_input_buffer(req);

• bitcoin/src/httpserver.cpp

  Line 565 in face812

  struct event_base* EventBase()

• bitcoin/src/httpserver.cpp

  Line 579 in face812

  HTTPEvent::HTTPEvent(struct event_base* base, bool _deleteWhenTriggered, const std::function<void()>& _handler):

• bitcoin/src/net.cpp

  Line 3162 in f58de87

  if (sock->Bind(reinterpret_cast<struct sockaddr*>(&sockaddr), len) == SOCKET_ERROR) {

I'm fine with both, but have better explanations for the one I'm proposing. Ultimately I don't think it matters much, as long as it's explicit since current behavior results in inconsistencies.

Maybe seeing struct as a small/passive/record thing and seeing class as more of an alive/process

That sounds more philosophical to me, I don't think that's how we're using them (or how formatting is usually decided)? Most definitions I see state: it's just a class with public members, e.g. https://en.wikipedia.org/wiki/Struct_(C_programming_language)#C++

a class is the same as a struct but with different default visibility

Not sure why the formatting should be closer to an if or a switch or a loop, I don't see how it's closer to those that to a class.

Clang-format itself usually bundles the class and struct formatting together:

• https://github.com/llvm/llvm-project/blob/d397751b56e30d88e3f00464c5a5fdfb2771978d/clang/lib/Format/TokenAnnotator.cpp#L5943-L5947
• https://github.com/llvm/llvm-project/blob/d397751b56e30d88e3f00464c5a5fdfb2771978d/clang/lib/Format/UnwrappedLineFormatter.cpp#L492-L495

Ran clang-format -i -- **.cpp **.h **.hpp in src/ for both AfterStruct true & false, and compared diffs. Man was it close.

Even though struct & class can be used interchangeably in C++, only with different defaults for public/private, I think we might as well benefit from the fact that we have 2 concepts and use them to communicate which types are POD (more C-like) or not. (C# includes both too but places limits on struct such as disabling support for inheritance and treating them as value types by default).

I took for granted that the omission of struct on this line in developer-notes.md was intentional. Comes from #4498, but conversation unfortunately doesn't touch on struct. Author of that PR copyrighted a C-only library one year earlier (https://github.com/bitcoin-core/secp256k1/blob/master/COPYING#L1). It also has opening curlies on same line as struct.

Happy to have explicitly defined, but my vote is for false and not changing developer-notes.md. - Dropping the second commit.