代码整洁之道小感悟.docxVIP

代码洁净之道小感悟 2021-12-08 多年的工作中，屡次被别人的代码坑的苦不堪言，回想起当年我留下的代码，确定也坑害了后来的同僚。当阅读JDK源码或者其他优秀开源工程时，叹服作者代码构建之精良，他们都有共同的特点：精确的变量名、恰到好处的设计模式、具体而不赘述的注释等等。如今重读本书，总结一下内容并加上本人的一些见解与大家共享。 代码是团队沟通方式 ?工作的沟通，不只是电子邮件或者面对面言语沟通，代码也是沟通方式之一。用代码实现需求，只是万里长征走完了第一步，必需让代码表达本人的设计思想。试想一下，你担任的功能被另外一个同事接手，假如你的代码结构清楚、注释合理，他就不用频繁的询问代码疑点，不用打断你的工作。编写代码的时候，应当考虑到别人的阅读感受，削减阅读妨碍，为整个团队制造代码，而不是你本人。 让营地比来时更洁净 ?这是美国童子军规的谚语，美国童子军相当于半军事化管理的青少年夏令营。夏令营结束后孩子们离开营地，要打扫卫生保持洁净，让营地比来时更洁净。在软件开发过程中，可以理解为不要破坏规章，不要引入混乱。假如团队已经制定了代码规范，比如类名必需有子系统前缀比如BiOrderService(Bi指BI业务部门)，就连续遵照下去；再比如，团队已经供应了公共库比如MD5的加密，那就不要再次引入新的MD5库。很多新手程序员接活儿后，看到不宠爱的规范就另起炉灶，需要某些工具类也不询问老司机公共库有没有，直接引入本人生疏的库，形成兼容性或者其他问题。 合适的命名 ?合适的命名是头等大事，正如给重生儿起个好名字那样重要。不合适的命名通常是词不达意、误导观众、过度缩写等，由于英文并非我们的母语，找个合适的单词命名好像真的很难。我建议是先把业务弄清楚，组织会议定下常用业务领域的单词，禁止组员各自创造。比如代码里使用canteen表示饭堂，那就不要再创造DinnerHall，既啰嗦又误导同僚。 看看反例： // 手机号 String phone = ; // 猎取地址 private String getDiZhi(); //修改密码 private void modifyPassword(String password1 ,String password2) 看看正例： // 手机号 mobileNo比phone更精确 String mobileNo= ; // 避开英文拼音混杂 private String getAddress(); // 参数的命名要区分意义 private void modifyPassword(String oldPassowrd,String newPassword) 短小的方法 ? 方法有多短小才合适没有定论，但是长达500行的一个方法，确定让阅读者起宰人之心。过长的方法，让阅读者不晓得从何看起，看了前面遗忘后面。将简单的方法，拆分成规律相对简约的短方法。 看看反例： // 猎取个人信息 private UserDTO getUserDTO(Integer userId) { //猎取基本信息 … 此处写了10行 //猎取最近的一次订单信息 … 此处写了30行 // 猎取钱包余额、可用优待券张数等 … 此处写了30行 return userDTO; } 看看正例： // 猎取个人信息 private UserDTO getUserDTO(Integer userId) { //猎取基本信息 UserDTO userDTO= getUserBasicInfo(userId); //猎取最近的一次订单信息 userDTO.setUserLastOrder(getUserLastOrder(userId)); // 猎取钱包、可用优待券张数等 userDTO.setUserAccount(getUserAccount(userId)); return userDTO; } private UserDTO getUserBasicInfo(Integer userId); private UserLastOrder getUserLastOrder(Integer userId); private UserAccount getUserAccount(Integer userId); 削减if/else嵌套 ? 为什么要削减嵌套，莫非嵌套看上去不时髦吗？我已经看到某位同事的一段代码嵌套达到9层，他本人再去维护的时候都看晕了。代码过度嵌套的结果是只要原作者才能读懂，接盘侠一脸茫然。 看看反例： // 修改用户密码，这个例子只要3层嵌套，