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

小鱼儿 2022-09-11 01:11 161阅读 0赞

细数编程习惯七宗罪

*  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 工具，提示的错误就很不清晰，但是自己去进一步查找即可。