职业与工作方法stackoverflow.blog
用空格的开发者比用制表符的开发者赚得更多
Developers who use spaces make more money than those who use tabs
2017 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 Stack Overflow 博客分析了开发者调查数据，发现用空格缩进的开发者平均薪资高于用 Tab 缩进的开发者。文章把程序员日常的“空格 vs Tab”之争和收入数据联系起来，但评论普遍提醒：这更可能是高薪公司风格指南、编辑器默认等混杂因素造成的相关性，而非缩进方式本身带来高薪。
为什么经久不衰：它用真实调查数据挑动程序员最熟悉的格式战争，同时是“相关不等于因果”的生动案例，因此多年后仍值得一读和讨论。
HN 评论精选
效应过大，必有混杂因素；高薪公司强制空格等可解释部分差异。
这个效应大得不太合理。Gelman 等人有篇论文说，不可能有很多独立变量都对薪资有巨大影响；说空格 vs Tab 有 10% 的效应，等于说它是开发者最重要的十件事之一。所以一定有混杂因素：顶尖学校是否都教用空格？编辑器默认值是否相关（调查没收集）？起始语言或使用语言总数？过去讨论还提到高薪公司强制用空格，这似乎也合理。这个结果很大、显然不是统计偶然，却很难理解。
srl查看英文原文
This is a huge effect. Implausibly huge? I'm reminded of Gelman et al's piranhas: http://www.stat.columbia.edu/~gelman/research/unpublished/piranhas.pdf. The "folk theorem" version is that you can't have very many independent variables that all have large effects on salary. Saying that spaces vs tabs has a 10% effect is tantamount to saying that its one of the ten (or fewer) most important things about a developer. So there must be a confounder. What could it be? - Do the top schools all instruct students to always use spaces? This should have been partly taken care of when the author controlled for level of education though, right? - Choice of editor? This seems like a weird one, but editor defaults are definitely linked to tabs vs spaces, and the survey didn't even collect data on this. - Starting language? - Total number of languages used? Spaces are tolerable in more languages than tabs are. Of course, I'd expect "both" to beat "spaces" if this was the case. None of these strikes me as particularly plausible, except maybe the last one. This result is kind of bothersome, because it's big, obviously not a statistical fluke, and hard to understand. EDIT: a past thread (https://news.ycombinator.com/item?id=20719010) suggested that some higher paying companies mandate spaces. This also seems plausible.
质疑结果可能由大公司的风格偏好驱动。
会不会是少数几家薪资丰厚的大雇主在影响结果？比如 Google 的 C++ 风格指南就要求用空格而非 Tab。
piker查看英文原文
Could it be that a few large, well-compensating employers are shifting the result? (E.g., https://google.github.io/styleguide/cppguide.html#Spaces_vs._Tabs)
理论最佳方案因不普及和工具支持不足而难以落地。
理论上，Tab 缩进、空格对齐是处理空白的最佳方式。但实践中有两个障碍：大多数开发者不熟悉这种用法，代码库用 Tab 缩进时容易有人破坏规则；另外 Vim 默认不容易把 Tab 高亮出来，Tab 和空格看起来一样，难以一眼判断空白是否规范。
mg查看英文原文
In theory, tabs for indention and spaces for alignment would be the best way to handle whitespace. Unfortunately in practice, two factors are in the way: 1) Most developers are confused by this type of whitespace usage. Simply because it is the less popular practice. So when you have a codebase that uses tabs for indention, you get more broken commits from developers who stumble in keeping the system intact. 2) Out of the box, VIM has no easy way to colorize tabs. So when you look at your code, tabs and spaces look the same. You cannot say from just if the whitespace is ok or messed up. You can show all non printing chars with "show list" but that is not very nice on the eyes. Or you can configure "show list" to only highlight tabs but then you lose the ability to show all non printing chars.
空格可避免不可见 Tab 造成的对齐混乱，适应公司缩进规则成本低。
我很久以前就选空格：Tab 会把光标移到下一个制表位但不可见，一旦有人按 Tab 对齐，换一个 Tab 宽度查看就会乱；强制“Tab 只用于缩进”也常因人为失误而失败；全用等宽字符就不会有位置问题。我在 2/3/4/8 空格缩进的公司都干过，适应公司规则很容易，好处大于麻烦。
kstenerud查看英文原文
I settled on spaces long ago for the following reasons: - Tabs move the cursor to the next "tab position" but are invisible, which means that whenever someone hits tab in the middle of something (accidentally or otherwise for alignment), you end up with messed up looking text and alignment as soon as you view it with a different tab size. - Trying to enforce "tabs only for indentation" rarely works without headaches because humans. - Using monospaced characters everywhere means that you'll never encounter positional issues ever. I've worked in 2-space, 3-space, 4-space, and 8-space indentation houses and honestly, I don't see the point of viewing indentation in your preferred size. It's easy to adapt to the house rules, and the benefits outweigh the headaches.
历次讨论
同类还值得读
用十年时间自学编程（1998）
Teach Yourself Programming in Ten Years (1998)
Peter Norvig 1998 年的经典文章，回应“21天/24小时学会编程”一类速成书，主张真正精通编程需要约十年持续、有意识的练习。
职业与工作方法上首页 11 次 · 2007–2025norvig.com编辑精选如何成为一名程序员：简短、全面而个人的总结
How to be a Programmer: A Short, Comprehensive, and Personal Summary
一篇广为流传的程序员成长指南，作者以个人经验系统总结了成为优秀程序员所需的各项技能——从调试、测试、沟通到团队协作与身心健康。
职业与工作方法上首页 6 次 · 2008–2015samizdat.mines.edu编辑精选不要自称程序员
Don't Call Yourself a Programmer
经典职业建议文章劝软件工程师不要把自己局限在“程序员”这个标签上，而要从公司业务角度说明自己创造的价值；文中讨论了成本中心与利润中心、头衔、求职与职业选择，也顺带批评了学术界的价…
职业与工作方法上首页 5 次 · 2011–2021kalzumeus.com编辑精选创作者的日程与经理的日程
Maker's Schedule, Manager's Schedule (2009)
Paul Graham 在这篇文章里把时间表分成两类：管理者的日程以小时为单位，会议可以填满一天；创作者（程序员、写作者等）的日程则以半天为单位，需要长时间不被打断的连续块。
职业与工作方法上首页 5 次 · 2009–2021paulgraham.com编辑精选为什么程序员的薪酬不与生产力成正比
Why programmers are not paid in proportion to their productivity
讨论为什么程序员的薪酬往往不随其生产力成比例增长：生产力难以客观量化，薪酬更多受组织预算、岗位定价和个人议价能力影响。
职业与工作方法上首页 5 次 · 2009–2022johndcook.com