On 8/4/21 4:44 PM, Rémi Bernon wrote:
NP: Yes, dinput code is heavily inconsistent, but I don't think it uses the two level indent on line continuation style anywhere yet. Personally I don't find it very readable and I would rather align on the paren.
The problem with aligning to the parenthesis (or other semantic unit) is that it makes things really ugly when the parenthesis falls late in the line. For whatever my opinion is worth, I'm distinctly in favor of a constant eight-space indent, including spreading that to more code.
I share the same preference as zf. I think I've even set my editor to do that after seeing this convention used a lot in msvcrt and a few other places.
As much as I don't like arguing about style variations, this one is actually bothering me. Alignment (on the paren, on operators, etc) is a pretty common style, and I think it actually makes things more readable.
I feel like the fixed two level indentation only helps when writing code, by making the decision simpler, or possibly diffs by saving re-alignments, but it doesn't help reading the code at all, especially in cases with nested parentheses.
On function declaration, and because we often have a lot of declspec (and possibly long ones like STDMETHODCALLTYPE) it may be relevant but otherwise in the code I don't feel like it's an improvement.
Then again, although dinput style is inconsistent it's not using that style yet anywhere (except for function declarations and even only in a few locations), so unless we intend to rewrite it all I don't see reason to add another style variation.
In my recent contributions to dinput and as some of the existing code was already like this, I chose a style similar to the user32 / ntdll style, with space in parentheses (see ansi.c). And unless it really bothers someone I intended to use it for my HID joystick too.
Well, this is already more discussion than is warranted, but anyway...
I don't disagree that aligning to parentheses (or whatever) is prettier, and if it were some other code base I might even prefer it. Problem is, the win32 API has really long names. Some parts of wine (looking at you, wined3d) do as well. That shows up not just in function declarations, but invocations as well (and not just for function names, but everything else as well).
Granted, I'm used to eight-space indentations, but I don't find it much harder to read.
But in general I don't think it's worth arguing about, not even in review. At most I'll fix up and resend a DirectShow patch that uses an alternate indentation style ;-)
Of course, if you end up having nested conditionals that wrap multiple lines, there's a good chance you should use a helper function anyway; those are hard to read regardless of code style.