细数编程习惯七宗罪(持续更新)

细数编程习惯七宗罪

• SQL 写在 java 文件里

  写错不容易发现，维护成本高。强烈建议写在 xml 里，配合 idea 插件 mybatis ，不但有智能提示，而且写错也会提醒，另外 mapper.java 接口和 xml 实现互相跳转。

• 英文不过关，有些英语单词看着就不专业

  比较专业的，比如：

  • management (mgmt 或 mgnt)、manager (mgr)

  • 权限：这个我用得比较杂，用auth、priv(privillege)、permission

  • 负责人用：charge man (chrg man)，这个单词我不是很满意，可能直接使用 owner 比较好

• 3、DTO 被多个controller接口复用作为入参

  复用就复用，如果入参完全或几乎一样，复用也罢，但为啥有些人在入参差异这么大的情况下还复用同一个DTO？我极其反对多controller接口共用同一个DTO

  DTO里用不上的字段多了就成了干扰，导致维护艰难。因为被不同的controller接口复用，不看代码根本不清楚哪些字段是必填选填的，也压根不知道前端会传什么参数。

• mapper方法查询使用 List<Map<String, Object>> 或者 Map<String, Object> 作为出参，也有使用 map作为mapper方法入参的

  偷懒一时爽，维护非常痛苦。就多复制一个DTO的力气都不愿意付出吗？

• 方法参数非常多，没有用一个 POJO 装起来

  这个我也犯过，因为当时的我认为这样直观，后来反省了挺多，觉得这样不太利于调用者，调用者会觉得乱。而且有些类型相同的参数相邻，使用接口的人可能会弄错顺序而没法被编译器发现

• 方法没的入参用作出参

  一般建议入参只是入参，返回值作为出参，这比较直观。

  我觉得入参既作为入参又作为出参，方法最好是void返回，且只有一个入参，方法名是packXxx(param)、packageXxx(param)、fill(param)、fillInXxx(param) 等，表示打包和填入值。

  绝对禁止那种入参有多个，都作为出参的，比如 method(List list, Map map) 这种在执行完后list和map里的值被改变了的。这种真的非常难阅读，尤其是 method 方法里面又将 list 和 map 传入其他方法并进行改变的，非常非常难阅读

  虽然《Clean Code》不建议入参又作为出参的做法，不过在实际编码中，还是看到了即使是规范的公司也是存在这种写法，这种写法肯定是有其方便性

• 不写注释，或写得很冗长

  • 完全不写注释是不行的，写注释要在关键的、自己认为难理解的地方、绕的地方写。

  • 写得冗长事无巨细，会导致信息更加容易过时，比如业务调整而没有调整注释，注释适当模糊，也是有好处的。

    打个比方，一般邮件或信息会写 “xxx 先生/女士”，它并不会详细得去区分是先生还是女士，这就是适当模糊，因为区分先生和女士需要额外的精力，而且如果xxx变性了还得改过来，也容易出现本来是先生被搞错成女士。所以写注释也一样，适当模糊能避免你的注释因为变化而过时。

    有些时候错误确实是没必要提示得事无巨细的，比如以前用 PL/SQL Developer 工具，提示的错误就很不清晰，但是自己去进一步查找即可。