Defend this coding style

>>62177722
Something that doesn't work.
You guys might think that coding styles are black and white lined but in the end people pay you to code and to get shit working.
No one fucking cares if your code follows the constraints of the clients and works almost bug free.

>>62177743
the people who have to maintain it do

>>62177722
I am going to have to say that you would still get paid if that code did what was required. Good thing that only other programmers give a shit but the business does not.

>>62177751
Cry me a river.
I still get paid even if I care about refactoring one day and not the next.

>>62177722
What's wrong with that?

>>62177780
It goes against what he believes is good programming.
You see these people bitch when they have to touch anyone's code that isn't theirs.

>>62177722
> see a shitty style
> run a reformatter on it
> style is as i like it

i see no problem here.

>>62177722
idk if it qualifies as a style if it's internally inconsistent.
in any case code like

{ x
; y
; z
; w
}

is not hard to find. IMO it looks fine. the real drawback to using this sort of style is that it leads to (relative to a dangling { and ; style) complicated git diffs when you prepend something to the list

>>62177743
It might be okay if you're doing contract work, but that shit doesn't fly in a collaborative environment.

>>62177743
These braces are placed in a way that a huge bug is impending tho.

>>62178351
Not only compilcated diffs but also missing where the braces are, they are barely visible and you will easily get bugs when you think something isn't in a block when it is