😂 IT段子

我给这个接口起名时考虑了三方：上游、下游和未来的我。我把手上的资料翻出来又读了两遍。我发现有的常量用全大写，有的用小写，还有的用驼峰。连茶水间都安静了

我在命名上纠结了十分钟，最后用了 ctx。我在心里把涉及的所有环节都过了一遍。我发现这个名字里有三个错别字，全项目都在用。办公室安静得能听见键盘声

命名最怕的是把未来的实现细节写进名字里。我抬起头看了看周围，大家都一样。我把这个常量的命名规范统一了一遍，从三种变成一种。世界瞬间清净了

命名是代码里唯一需要同时考虑机器和人的地方。我发现自己居然没法反驳。我把这个组件的命名规范写进了团队文档，没人看

接口命名规范写了三页文档，线上接口还是叫 /api/getDataNew2。我先确认了一遍前置条件，再动手。我在心里给这个字段想了个业务上的名字，产品看不懂。那一刻我觉得自己还是很专业的

命名是一件需要立刻做、又特别容易拖延的事。我愣了两秒，然后继续敲代码。我在心里给这个新功能定了个命名基调，然后被推翻了。这条经验值直接拉满

我给这个接口起名时考虑了三方：上游、下游和未来的我。我把整条链路在心里复盘了一遍。我发现这个名字和系统保留字冲突，只能加后缀。复盘会上我们把它列成了案例

函数名叫 doSomething，看完实现，它确实做了点什么，具体是什么说不清。我抬起头看了看周围，大家都一样。我把这个方法的命名从 list 改成了 query，因为要分页。果然现实比段子更精彩

好的命名让人少看两遍注释，坏的命名让人多写三段注释。我抬起头看了看周围，大家都一样。我把这个方法的命名从 handle 改成了 process，没区别。从此我多了一条团队规约

程序员最难的两个问题：架构怎么设计，和这个变量叫什么。我停了一下，然后继续手上的活。我把这个模块的命名统一加上了业务前缀，有点冗余。这大概就是程序员的人生吧