[PATCH] dinput/tests: Make overlapped format tests more robust.

[Zebediah Figura (she/her)]

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.