1.引言
....又好笑，又不耐烦，懒懒的答他道，“谁要你教，不是草头底下一个来回的回字么？”孔乙己显出极高兴的样子，将两个指头的长指甲敲着柜台，点头说，“对呀对呀！……回字有四样写法，你知道么？”我愈不耐烦了，努着嘴走远。孔乙己刚用指甲蘸了酒，想在柜上写字，见我毫不热心，便又叹一口气，显出极惋惜的样子
针对于同一个代码变量或者函数方法，张三可能认为可以叫 xxx，李四可能摇头说 不不不，得叫 yyyy ，好的命名让人如沐春风，原来是这个意思；坏的代码命名，同事可能会眉头紧锁，然后送你两斤熏鸡骨头让你炖汤。
比如隔壁小组新来的一个同事，对字符串命名就用 s，对于布尔值的命名就用 b，然后他的主管说他的变量名起的跟他人一样。如何做到信雅达的命名，让同事不会再背后蛐蛐，我是这样想的。
<顺便吆喝一句，技术大厂年前捞人，前后端测试都有，感兴趣试试~>
2. 代码整洁之道
2.1 团队规范
“我在上家公司都是这样命名的，在这里我也要这样命名”
小组里张三给 Service 起的名字叫 UserService 实现类是 UserServiceImpl；小组里李四给 Service 起的名字叫 CustomerService 实现类 CustomerServiceImpl
你跳出来说，统统不对，接口需要区分对待 得叫 IUserService 和 ICustomerService
但是组里成员都不习惯往接口类加个 I；或许这就是 E 人编码吧，不能写 I（我承认这个梗有点烂）
双拳难敌四手，亲，这边建议你按照 UserService 和 CustomerService 起名
这只是个简单的例子，还有就是你认为 4 就是 for，2 就是 to，如果小组内的成员表示认可你的想法，那你就尽管大胆的使用，但是小组成员要是没有这一点习惯，建议还是老老实实 for 和 to，毕竟你没有一票否决权
诸如此类的还有 request -> req、response -> resp 等
以下所有的代码命名建议都不能打破团队规范这一条大原则
2.2 统一业务词汇
在各行各业中，基于业务属性，我们都有一些专业术语，对于专业术语的命名往往在设计领域模型的时候已经确定下来，建议有一份业务词汇来规范团队同学命名，或者以数据库字段为准
比如在保险行业中，我们有保费（premium）、保单（policy）、被保人（assured）等，针对于这些业务词汇，务必需要统一。被保人就是 assured 不是 Insured Person
2.3 名副其实
“语义一定要清晰，不然后续接手的人根本看不懂，我的这个函数名是用来对订单进行删除操作，然后进行 MQ 消息推送的，我准备给他起名为 deleteOrderByCustomerIdAndSendMqMessage”
对，函数名很长很清晰，虽然我的屏幕很宽，但是针对于这样的命名，我觉得不可取，函数名和函数一样应该尽量短小，当你的命名极其长的时候你需要考虑简化你的命名，或者 考虑你的函数是否遵循到了单一职责。
bad😭
deleteOrderByCustomerIdAndSendMqMessage(String userId)
good🤭
deleteOrder(String userId)
sendMq()
我们在做阅读理解的时候，需要结合上下文来作答，同样，我们的命名需要让下一个做阅读理解的人感受到我们的上下文含义。在我们删除订单的时候，假设我们需要用到订单的 ID，那么我们的命名需要是 orderId = 123，而不是 id = 123
bad😭 这个 id 指代的是什么，订单ID 还是用户 ID
id = 123
good🤭
deleteOrder(String userId)
orderId = 123
人靠衣装马靠鞍，变量类型需“平安”，我们在起名的时候需要对的起自己的名字
bad😭 tm的喵，我以为是个 list
String idList = "1,2,3"
good🤭
List<String> idList = ImmutabList.of("1", "2", "3")
默认我的同事的英文水平只有四级，我们变量命名的时候，尽量取一些大众化的词汇，可以四级词汇，切莫六级词汇
bad😭
actiivityOrchestrater
good🤭 活动策划人
actiivityPlanner
普通函数、方法命名以动词开头
bad😭
messageSend
good🤭
sendMessage
减少介词链接，考虑使用 形容词+名词
productListForSpecialOffer -> specialOfferProductList
productListForNewArrival -> newArrivalProductList
productListFromHenan -> henanProductList
productListWithGiftBox -> withGiftBoxProductList \ giftBoxedProductList
productListWithoutGiftBox -> withoutGiftBoxProductList \ noGiftBoxProductList \ unGiftBoxedProductList
消除无意义的前后缀单词： userInfo、userData，info 和 data 的含义过于宽泛，没有实质性意义所以我们可以不用写。或者诸如在 UserService 类中，我们可以可以尝试将 selectUserList 更换为 selectList，因为我们调用的时候，上下文一定是 userService.selectList，阅读者是可以感受到我们的语义的
userInfo -> user
userService.selectUserList -> userService.selectList
做有意义的方法名的区分：在我刚入职的时候，有一个 OrderService 中，存在 4个方法，enableOrder、enableOrderV2、enableOrderV3、enableOrderV4，我问组里的同事，有什么区别，他们告诉我，现在各个外部服务用的不同，不知道有啥区别。所以为了避免给类似我这样的菜鸟产生歧义，建议在方法起名的时候做好区分，以免埋坑。
置顶卡
沉默卡
照妖镜