从来没优雅过

话说如果我来写的话，第一反应肯定想不到 Linus 的写法，还是会对边界做判断的。但我会把判断写成卫式，在循环之前，当 target 就是 l->head 时替掉 l->head ，而不是循环结束才根据 prev 是否为 NULL 来判断。那样我觉得不如先判断更符合直觉。

Linus 这种写法的妙处不在于代码量少了多少。行数少不一定是好代码。关键在于，通过使用指针的指针，把需要修改->head 和 prev->next 的情况统一起来，不需要给边界情况 l->head 单独写一个分支来修改，把特殊情况化为一般情况，一致性好，实际上代码（因为边界情况考虑不周而）出错的概率更小了。

@PolarBears 哈哈，我也在搞这事。nginx 跑起 lua mod 后简直就是一个丐版 waf😄

@Sliverburger 所以我的意思是不要考虑优雅了，新开项目坚持纯 3 ，旧项目需要用 2 的就在屎山上继续堆

2022 年了，不用考虑兼容 2 了。如果真的还有必须用 2 的遗留环境，那就不用考虑什么优雅不优雅了，反正已经是屎山。

先把工作网络和顾客网络分开再谈限速

用 Windows 要愉快编程……老老实实选微软御用技术栈呗。

新需求到手不要马上改，先厚着脸皮拖三天进度……反正三天后又变了

团队有 coding style 就拿出来怼他。没有……说个捷豹。

@coderluan 这位把话题递归扯到元异议，就变成一个没法继续下去的哲学话题了……

已故乔帮主说跟聪明人合作最大的好处是不需要顾忌对方的自尊心……

RPM 系和 DEB 系主流发行版里打包好的包都是按 FHS 来。

而单位自用业务系统里的业务功能部分，不论是搞外包的传统行业的信息化还是自养开发团队的互联网，普遍倾向于按业务领域划分，everything-under-business-prefix……

把文件按作用分类到不同目录，而不是按业务领域，有些可能的好处。因为通常文件在文件系统里的权限、性能、易变性是按作用而不是按业务领域来划分的。

比如[/usr]/[bin|sbin]下的可执行程序、[/usr]/lib 下的动态链接库，/usr/share 下的静态数据，通常不需要普通用户有写入权限；/var/lib 下的数据库、/var/log 下的日志通常需要各自的 uid 有写入权限；/etc 下的配置通常在程序和数据做小版本升级时不需要改动，但管理员可能要单独修改；/run 下的 pid 、socket 最好在系统重启后就没了，以免判断错误。等等。
再比如，在资源受限的环境（比如路由器），可执行程序和不可变数据可以做成只读的压缩文件系统，启动后部分解到内存或者按需解开；配置文件需要改变后持久化到闪存；日志通常不需要持久保留。

按 FHS 划分就很容易为不同业务功能但相同作用的文件设置统一的存储策略。而按业务领域划分，从这个角度看反而是散乱的。

我见过很多不做运维的纯开发人员都对 FHS 困惑和反感😄

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

CSS 是没有层级的，有层级的是 DOM