工具与资源github.com编辑精选
程序员信以为真的谬误清单
List of falsehoods programmers believe in
2017 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这个 GitHub 仓库收集了一系列“程序员信以为真的谬误”清单，涵盖日期时间、姓名、地址、电话号码、度量单位等主题，用具体反例说明现实世界常比代码假设更复杂。它本身是链接汇总，质量不一；评论区围绕哪些条目有证据、哪些只是观点展开争论。
为什么经久不衰：它把许多隐蔽的边界假设集中成可浏览的清单，能帮助开发者在姓名、地址、时间等常见领域提前发现脆弱设计。
HN 评论精选
批评清单缺乏证据，更像观点汇编而非可靠知识。
如果我们真想成为信息驱动的文化、就重要议题做出知情决策，就应该把这类清单整理成针对每条内容的、有依据的讨论。把一堆夹杂个人观点的“谬误”罗列出来，还在没有证据的情况下称其为“可证明的”，无助于公共知识；我更愿意看到能推翻笼统断言的有效反例。
andrewstuart2查看英文原文
If we really aspire to be an information-driven culture who makes informed decisions about important topics, we really ought to curate lists like these down to actual informed discussions on the items in the list. Printing out a list of "falsehoods" littered with personal opinions and calling them "demonstrable" [1] without a shred of evidence is not going to contribute to general knowledge. There may be some utility in getting me thinking, but for the most part I just find it self-aggrandizing. For what it's worth, I do find this [2] format much more helpful. I'd very much rather see valid counterexamples proving a sweeping statement false than yet another sweeping statement that happens to cover a few sweeping statements. Of course, the above is my personal opinion and may not be shared by the rest of the community, but please can we do better than curating a list of lists we agree with? [1] https://chiselapp.com/user/ttmrichter/repository/gng/doc/trunk/output/falsehoods.html [2] https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/
指出清单质量参差，技术事实与无证据的观点混在一起。
这个清单尴尬地混合了两类帖子：一类是对各种技术规范给出易验证但令人意外的断言，另一类只是提出各种有争议的说法且没有提供具体证据（我认为经济学那条可能最糟）。
bshlgrs查看英文原文
This list is an awkward mix of posts containing easily-verifiable but surprising claims about various technical specifications, and posts which just make a variety of contentious claims with no particular evidence provided (I think the economics one is possibly the worst).
两字符中文名暴露了“姓名至少三字符”的隐含假设。
我在法国小镇工作，以前很少见到中国人；他们的护照有拉丁字母译名，俄罗斯人也一样。后来用户说有些客户找不到，都是中国人——原因是我为减少数据库查询，等用户输入至少 3 个字符才搜索，而很多中文名只有两个字符，如“Xi”“Wu”。写代码时我还以为没人会只有两个字母的名字。
jmnicolas查看英文原文
> My system will never have to deal with names from China I work in a small French town where Chinese people were quite rare until a few years ago. Their passports have a translation of their names in Latin alphabet, same for Russians. However one day one of my user told me "hey I can't find some customers in your app, but I'm 100% sure I recorded them previously. Funnily they're all Chinese". It turns out that to avoid querying the database too much I was starting to look for customers name once the user had entered at least 3 chars. Most of the Chinese names were only 2 chars like "Xi", "Wu" etc. I clearly remember thinking at the time of writing the original code that nobody had only a 2 letter name :)
现实地址系统远比标准表单假设的松散。
地址清单还漏了一些反例：有房产根本没有地址（加州偏远乡村的私有道路常只靠 APN 和最近城镇定位）；收件人不一定需要姓名和地址（有人只画一个 BMW 标志并写最近城镇也寄到了）；无家可归者或乡村居民也未必有街道地址。
Enginerrrd查看英文原文
I read through the entire list of falsehoods about addresses and I think I've got a few more broken assumtpions that weren't listed: * A property will have an address (I live in a very rural area of CA where the roads have forked several times for many miles to get to a property and they are all unnamed private roads. People often just put down the APN and the nearest town (which might be several miles away) as their address. I deal with this one all the time. I routinely have to find their house for the first time. Good luck using GPS here, if you can't read a map, you're S.O.L. [And no, even trying to confirm that you are where you think you are with GPS on your phone is gonna be a challenge. For one, you're miles from cell reception so if you didn't save the map to your phone, you're screwed. For two, under heavy tree and cloud cover, you may not even get a GPS fix on a phone.]) * A recipient needs a name and address My mother lived for a time in a very rural area nearby. She rode a BMW motorcycle and someone she met only briefly once successfully sent her a letter by simply drawing a BMW symbol as the name and address and affixing the nearest town. * A person has a street address Homeless and rural people regularly fail this one.
历次讨论
同类还值得读
直接在浏览器中启动 Linux 内核
Boot a linux kernel right inside your browser.
Fabrice Bellard 的 JSLinux 页面，用 JavaScript 在浏览器里启动一个 Linux 内核，并提供一个可交互的终端环境。
工具与资源上首页 5 次 · 2011–2025bellard.orgHacker News 未公开功能与行为清单（2018）
A List of Hacker News's Undocumented Features and Behaviors (2018)
数据科学家 Max Woolf 整理的 Hacker News 未公开功能与行为清单，涵盖投票机制、排名算法、账号惩罚等社区运作细节。
工具与资源上首页 5 次 · 2019–2025github.comMapSCII：在终端中用盲文和 ASCII 渲染地图
MapSCII – Braille and ASCII map renderer for the console
MapSCII 是一个在命令行终端里渲染地图的开源工具，用盲文字符和 ASCII 字符把地理数据画成可交互浏览的字符地图。
工具与资源上首页 5 次 · 2017–2025github.com顶尖大学的免费在线课程
Free Online Courses from Top Universities
Open Culture 整理的一份免费在线课程合集，汇集了全球顶尖大学（如 MIT、斯坦福、耶鲁等）向公众开放的网络课程资源，涵盖音频、视频等多种形式。
工具与资源上首页 5 次 · 2010–2022openculture.com淘气字符串：容易引发用户输入问题的字符串清单
Naughty Strings: A list of strings likely to cause issues as user-input data
一个 GitHub 仓库，收录了大量容易让程序出问题的用户输入字符串，如特殊字符、emoji、SQL 注入片段、系统命令等，供开发者用于测试输入处理逻辑。
工具与资源上首页 4 次 · 2015–2020github.com