Why you should care about whitespace

Why you should care about whitespace

Short talk about the importance of handling whitespace properly to improve the authoring experience and diffs quality. MercadoLibre Front-end Meetup. December, 2014.

B35b6fc3b6a61787be1b3750511fbd95?s=128

Luciano Battagliero

December 12, 2014
Tweet

Transcript

  1. WHIT——ES·· PA····—— —————CE··

  2. Hi, there! I’m Luciano Battagliero @battaglr

  3. Why you should care about whitespace

  4. Well, to be fair...

  5. Most of the time you shouldn’t need to worry about

    those slippy invisible things
  6. Unless you’re programming in whitespace, then it’s kind of a

    big deal... and maybe you’re with too much time in your hands
  7. Our tools should take care of them without too much

    intervention from our side.
  8. After all, we have far more interesting things to do

  9. Why are they relevant then?

  10. They enhance the authoring experience

  11. Making our code easier to read and to understand

  12. And our diffs more meaningful and easier to review

  13. Whitespace in programming

  14. Two main types

  15. Syntactically significant whitespace

  16. Syntactically insignificant whitespace

  17. We are going to focus on the latter

  18. They can be omitted without changing the meaning of the

    code
  19. Most are equivalent and interchangeable

  20. Usually a sequence of them are equivalent to a single

    one
  21. Whitespace characters

  22. Space

  23. Tab

  24. Newline or line ending

  25. Get X-ray vision!

  26. To see the whitespace characters, you can enable the “show

    invisibles” option in your editor
  27. Pick a side

  28. Tabs vs. spaces

  29. The never ending war

  30. Indenting with spaces

  31. Fixed width

  32. var foobar = function(obj, attrs) { ··var i = 0,

    ······len = obj.length; ··for (i; i < len; i++) { … } }
  33. Okay!

  34. Indenting with tabs

  35. Variable width (usually configurable)

  36. var foobar = function(obj, attrs) { ——var i = 0,

    ——————len = obj.length; ——for (i; i < len; i++) { … } }
  37. Okay!

  38. Indenting with spaces and tabs

  39. var foobar = function(obj, attrs) { ——var i = 0,

    ——····len = obj.length; ——for (i; i < len; i++) { … } }
  40. Okay? Okay!

  41. Indenting with whatever

  42. var foobar = function(obj, attrs) { ——var i = 0,

    ··————len = obj.length; ··for (i; i < len; i++) { … } }
  43. Tab stops that don’t correlate with the amount of space

    characters could result in code that is really hard to read
  44. var foobar = function(obj, attrs) { ———var i = 0,

    ··——————len = obj.length; ··for (i; i < len; i++) { … } }
  45. Complete mayhem!

  46. How to avoid this invisible chaos?

  47. Choose one

  48. Stick with it

  49. Use it consistently

  50. Choose. One. Stick. With. It. Use. It. Consistently.

  51. Trim and exterminate

  52. var foobar = function(obj, attrs) {· ··var i = 0,···

    ······len = obj.length;·· ·········· ··for (i; i < len; i++) { … } }····
  53. OH. MY. GOD!

  54. Do you want to go to the end of the

    line with a keystroke? Good luck!
  55. Were you expecting to land on the first column? Bummer!

  56. var foobar = function(obj, attrs) { ··var i = 0,

    ······len = obj.length; ··for (i; i < len; i++) { … } }
  57. That’s better!

  58. Mo' lines, mo' problems

  59. Each OS handle newlines characters differently

  60. Were you expecting an universally accepted standard? You, fool!

  61. LF, CR or CRLF

  62. var foobar = function(obj, attrs) {¬ ··var i = 0,¬

    ······len = obj.length;¬ ¬ ··for (i; i < len; i++) { … }¬ }¬
  63. LF: Unix, Linux and OS X

  64. var foobar = function(obj, attrs) {\n ··var i = 0,\n

    ······len = obj.length;\n \n ··for (i; i < len; i++) { … }\n }\n
  65. CR: Mac OS 9-

  66. var foobar = function(obj, attrs) {\r ··var i = 0,\r

    ······len = obj.length;\r \r ··for (i; i < len; i++) { … }\r }\r
  67. CRLF: Windows and MS-DOS

  68. var foobar = function(obj, attrs) {\r\n ··var i = 0,\r\n

    ······len = obj.length;\r\n \r\n ··for (i; i < len; i++) { … }\r\n }\r\n
  69. The thing is: you can mix all three in a

    single file!
  70. An apparently harmless copy and paste could be the beginning

    of something very, very messy
  71. var foobar = function(obj, attrs) {\r ··var i = 0,\r\n

    ······len = obj.length;\n \n ··for (i; i < len; i++) { … }\r\n }\r
  72. Holy invisible cow!

  73. Psst! Git will consider that the whole line was modified

    even if the only change was the newline character
  74. Oh! Good luck with a merge conflict in a file

    that uses different newline characters
  75. Normalizing newlines in Git

  76. `.gitattributes`

  77. * text=auto

  78. *.css text eol=lf *.html text eol=lf *.js text eol=lf

  79. No newline at end of file

  80. You sure have seen the following message

  81. \ No newline at end of file

  82. That’s due to how Unix and Unix-like systems handle text

    files
  83. Some files without a newline character at the end of

    it may not be recognised as a proper text file
  84. Certain utilities could behave oddly if they aren’t able to

    recognize the end of a file and the beginning of another
  85. By adding just one character we could avoid possible odd

    behaviours
  86. Diff without noise

  87. Oh, look I have another merge conf... *throws laptop out

    of window*
  88. A clean codebase means clean diffs

  89. Clean diffs make our work faster

  90. Our reviews easier

  91. And our merge conflicts a bit less irritating

  92. When things are already messy

  93. What if you’re working on a dirty codebase?

  94. Avoid modifying whitespace on a file unless you have a

    good an objective reason
  95. Avoid to commit changes in lines where only whitespace has

    been modified together with changes in the code
  96. A file to rule them all

  97. `.editorconfig`

  98. root = true [*] charset = utf-8 end_of_line = lf

    indent_style = space indent_size = 4 insert_final_newline = true trim_trailing_whitespace = true
  99. [*.md] trim_trailing_whitespace = false

  100. [package.json] indent_size = 2

  101. For more info go to editorconfig.org

  102. Why don’t we just configure our tools?

  103. Within a team not everybody uses the same one

  104. You depend on every single one of the team members

    doing it to make it work
  105. It’s tedious and time consuming

  106. And who wants to do that anyway?

  107. Questions?

  108. Thanks!

  109. Countless whitespace characters were harmed in the making of this

    presentation