5 ms·
The “shut up and get back to work” coding style guide
- ChrisRR 8y agoI 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 8y agoYes these things are subjective though. I don't love having to scroll right to see params.
- frou_dh 8y agoMatching 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.
- sixothree 8y agoI would argue that the first piece of code provided as an example is much more readable than the other.
- ncmncm 8y agoWhen I worked for Gumby and Ian, messing around with indentation instead of working was a firing offense.
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- sandov 8y agoMaybe struct wlr_surface* wlr_surface_surface_at(struct wlr_surface *surface, double sx, double sy, double *sub_x, double *sub_y) { // Do stuff }
- P_I_Staker 8y agoHopefully, 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.