为什么使用空格字符的程序员瞧不起用，tab，字符的程序员？

因为空格才是正统。这个问题培训班低端码农是很难理解的。

文本text和字符串string是两个不同的概念

文本是指无样式可打印字符在矩形lattice中的排版。是一个human-readable的概念。你可以明确说出某行某列的那个可打印字符是什么。字符串是给IO设备描述「如何产生一段文本」的指令序列。是一个machine-readable的概念。

文本是平台无关的，字符串是平台相关的。在不同平台不同IO设备，描述同一段文本所需的字符串是不一定相同的。

比如下面这段文本，第一行第一列是a，第二行第一列是b

a b

在windows中可以用字符串

"a\r\nb"

来描述。而在unix中可以用字符串

"a\nb"

来描述。

思考题：json是javascript plain object的字符串表示还是文本表示？

答案：是字符串表示。因为json官网明确规定了哪些控制字符属于空白分隔符。

这也是为什么json的mime类型是application/json而不是text/json。

思考题：html5标准中的server sent event发送的是字符串还是文本？

答案：是文本。因为html5标准没有规定具体用哪个字符表示换行。因此sse协议

只保证「发送端原字符串在发送端平台上所对应的文本」与「接收端收到的文本」相同但并不保证「发送端原字符串在发送端平台上所对应的文本」与「接收端收到的文本在接收端平台上对应的字符串」相同。比如发送端源字符串中的换行符，到接收端产生的最终字符串中后，很可能已经变了。因此发送端和接收端手中是两个完全不同的字符串。

如果你用sse来发送json，发送端和接收端手中将会是两个不同的json字符串，只不过他们表示的javascript plain object恰好相同，这是一种特殊场景下的歪打正着。

因此严格来说，sse不能用于直接推送json。严谨的做法是发送端先把字符串用utf8等编码为二进制串，再用base64把二进制串编码为文本，再推送。

万一某个场景下，接收端A从sse拿到json字符串并没有转成object，而是把这个字符串hash一下作为json的key存到了某个远程数据库里。同时发送端也用sse向另一个不同平台的接收端B推送了同一个json，接收端B也把收到的json字符串hash一下存进那个远程数据库。本来期望判定key相同的，实际判定为不同。

遥远的某一天某个遥远的下游用户卡到这个bug，看到时候不得调死你。

软件工程中的各种隐藏bug，就是一个个低端码农在这么一个个不起眼的「语义与实现的不一致」中累积起来的。

现在你应该明白了为什么空格才是缩进的正统。因为「缩进」是一个文本层面的概念，描述不同行之间的列对齐结构。而'\t'是一个平台相关的控制字符，只能出现在字符串中。

只不过对于缩进不敏感的编程语言，恰好没有影响，这也是一种特殊场景下的歪打正着。如果换成缩进敏感的编程语言，比如haskell，就会出问题。

因此，只要你用的那个语言把源文件内容的语义定义为「源代码的字符串」而不是定义为「源代码文本」，就可以用tab。只不过空格更正统，并不是更正确。

如果我这个回答你看不懂，可以看看 @黄亮anthony 的在另一个问题回答