Why you should care about whitespace

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

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