logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

Shut-up-and-get-back-to-work-style.md (2632B)

    

  1. ---
  2. date: 2019-04-29
  3. layout: post
  4. title: The "shut up and get back to work" coding style guide
  5. tags: ["philosophy"]
  6. ---
  8. So you're starting a new website, and you open the first CSS file. What style do
  9. you use? Well, you hate indenting with spaces passionately. You know tabs are
  10. right because they're literally made for this, and they're only one byte, and
  11. these god damn spaces people with their bloody spacebars...
  13. Shut up and use spaces. That's how CSS is written[^1]. And you, mister web
  14. programmer, coming out of your shell and dipping your toes into the world of
  15. Real Programming, writing your first Golang program: use tabs, jerk. There's
  16. only one principle that matters in coding style: don't rock the boat. Just do
  17. whatever the most common thing is in the language you're working in. Write your
  18. commit messages the same way as everyone else, too. Then shut up and get back to
  19. work. This hill isn't worth dying on.
  21. If you're working on someone else's project, this goes double. Don't get snippy
  22. about their coding style. Just follow their style guide, and if there isn't one,
  23. just make your code look like the code around it. It's none of your goddamn
  24. business how they choose to style their code.
  26. Shut up and get back to work.
  28. Ranting aside, seriously - which style guide you use doesn't matter nearly as
  29. much as using one. Just pick the one which is most popular or which is already
  30. in use by your peers and roll with it.
  32. <div style="margin-bottom: 5rem"></div>
  34. ...though since I'm talking about style anyway, take a look at this:
  36. ```c
  37. struct wlr_surface *wlr_surface_surface_at(struct wlr_surface *surface,
  38.                                            double sx, double sy,
  39.                                            double *sub_x, double *sub_y) {
  40.     // Do stuff
  41. }
  42. ```
  44. There's a lot of stupid crap which ends up in style guides, but this is by far
  45. the worst. Look at all that wasted whitespace! There's no room to write your
  46. parameters on the right, and you end up with 3 lines where you could have two.
  47. And you have to mix spaces and tabs! God dammit! This is how you should do it:
  49. ```c
  50. struct wlr_surface *wlr_surface_surface_at(struct wlr_surface *surface,
  51.         double sx, double sy, double *sub_x, double *sub_y) {
  52.     // Do stuff
  53. }
  54. ```
  56. Note the extra indent to distinguish the parameters from the body and the
  57. missing garish hellscape of whitespace. If you do this in your codebase, I'm not
  58. going to argue with you about it, but I am going to have to talk to my therapist
  59. about it.
  61. [^1]: For the record, tabs are objectively better. Does that mean I'm going to write my JavaScript with tabs? Hell no!