可以说，作为程序员来说，对于程序员有哪些约定俗成，或者说大家都心知肚明的【码德】，大家一定都有很多想说的，那么下面就来浅浅的谈一下吧。在正式谈起话题之前，首先推荐一下程序员码德宝典《Java开发手册》，就是这本电子书了，内容很详细，推荐阅读

下面言归正传，真是开始话题讨论。

程序员有哪些约定俗成的“码徳”？

说到程序员有哪些约定俗成的【码德】，可以说，作为约定俗成的东西，那么存在必然是合理的。作为程序员你遵守了，那么你不仅会赢得他人对你同等的尊重，在一定程度上，遵守码德也能保护你自身，比如说：

1.代码保存：每天记得保存当天的代码，如果代码未及时保存，那么电脑卡死或者重启，你就白忙活一场；刚开始个人就遇到过这样的情况，好不容易写了一大段复杂的逻辑，突然电脑卡死，自动重启后什么也没了，甚是后悔；

2.代码提交备注：在提交代码到SVN或者其他代码管理工具时，要提供明确详细的提交备注，这样不管对于同事还是对于你个人后续查阅提交记录，都会有事半功倍的效果；

3.看得懂的命名：说到命名，也是日常开发中遇到最多的。一个清晰的看得懂的命名，对于自己对于他人后期维护你代码的话，都是仁义的体现，好的名字见名知义；不好的名字头大如钵；

4.重要的注释：代码注释在一定程度上对于自己或者对于他人理解业务逻辑都有很大的帮助，但是注释不是越多越好，太多的注释耽误开发时间不说，往往也没有很大的用处；因此重要的恰到好处的注释不能少；

5.功能迭代变更；当某个业务功能发生变更时，在更改调用到的方法时，如果其他方法也调用到当前方法，那么最好就是升级调用的方法而不是更改原有方法的逻辑，防止其他功能出现莫名异常；

6.接口相关：当接口不再调用时，尽量不要删除，可以逐步淘汰该接口，如果直接删除可能会导致其他业务调用时异常。

其实，日常工作中程序员还有很多约定俗称的【码德】，大家可以热情参与进来讨论吧。

哪些不规范的编程行为最让人头疼？

说到哪些不规范的编程行为让人头疼，其实对应于上面约定俗成的码德来说，任意的一项没有按约定来，对于后来接收的程序员来说都是很让人头疼的。比如说：

1.不知所云的命名：开发过程中会遇到一些没有任何意义的字段名、方法名、类名、接口名等，通过这些命名，即看不出来想要表达的内容也看不出究竟是什么业务内容，比如： a,b,c...a1..b2等等；

2.无止境的依赖：在开发过程中会遇到有些开发者引入过多的依赖，而过多依赖导致的依赖冲突也不及时处理，在一些情况下会导致应用程序出现不知名的异常，这种情况下排查问题很不方便且没有头绪，因此依赖要够用且简明，能解决的依赖冲突要提前处理；

3.无结构的代码：对于SpringMVC开发结构来说，controller负责控制层，不应有具体业务逻辑；service层负责具体业务逻辑实现；mapper层服务与数据库的交互。但是总是能够看到controller层的业务逻辑冗长难懂，或者说一个业务逻辑方法中代码没有抽取小方法而导致方法行数过多，逻辑过于复杂等；

4.可怜的注释：注释对于代码的维护和代码的理解来说，作用很大，但是总能遇到整个方法，甚至整个文件都没有注释的，这样的代码维护起来整个脑瓜都是嗡嗡的；

5.没有代码规范：没有代码规范的代码，往往维护比较困难，理解比较费劲，性能往往也不会太好，这个时候就需要多读读我再文章开篇提到的《Java开发手册》，真的很好很实用，也能减少日常代码开发的维护量。

以上就是个人对于程序员【码德】的一些个人的理解，大家感兴趣的欢迎评论区留言一起讨论吧。