
The “shut up and get back to work” coding style guide - gbear605
https://drewdevault.com/2019/04/29/Shut-up-and-get-back-to-work-style.html
======
ChrisRR
I prefer the first example that he says is crap. It has all the arguments
grouped together to make it slightly easier to read.

I don't buy the argument about wasted whitespace. If you cramp too much of
your code into dense one-liners, it makes the code unreadable.

Secondly, I'd say that code width is unnecessarily narrow. 120 characters is
fine to fit two files side-by-side on a 1920x1080 monitor with space to spare.
80 characters is just too close.

Thirdly, I'd typedef "struct wlr_surface" to "wlr_surface_t" (assuming I were
writing this in C. I don't know if this is actually CSS)

~~~
P_I_Staker
Yes these things are subjective though. I don't love having to scroll right to
see params.

------
frou_dh
Matching the style that's already used in a file is certainly timeless advice.

Still, if a particular project or group has stringent opinions about code
formatting, but at the same time can't be bothered to work out how to get a
tool to apply most or all of that formatting, it's a bit of a bozo situation.
Automation is what computers are for, after all.

------
P_I_Staker
Hopefully, he's only talking about basic style guidelines, and not coding
standards. Especially in C, there's practices that should be banned. Good
naming conventions are arguably useful as well. I agree that endless arguments
about the best way to indent and use brackets are harmful.

------
sandov
Maybe

    
    
        struct wlr_surface*
        wlr_surface_surface_at(struct wlr_surface *surface, double sx, 
                               double sy, double *sub_x, double *sub_y)
        {
            // Do stuff
        }

------
sixothree
I would argue that the first piece of code provided as an example is much more
readable than the other.

------
ncmncm
When I worked for Gumby and Ian, messing around with indentation instead of
working was a firing offense.

