Carlos 置顶2019-01-11我感觉我就是一个有代码洁癖的人，写代码时有自己的原则和规范方法，其中做到易读和结构简洁是首要原则，这里面像命名，缩进，空行这种静态规则，有IDE的帮助还算比较容易做到。对于不少人来说比较难做到的可能是代码逻辑的组织。前几天刚看了个同事写的代码，关于视频课程管理的，表结构设计也是他做的。业务上要求课程需要属于某个等级，等级属于类别，类别属于厂商，为了做到同一个课程向不同客户展示不同的价格，又设计了个课程价格关系模型。这几个子项都有对应的业务模型和业务接口类。问题来了，添加课程时，在课程的某一个controller方法里，分别通过getparameter获取参数，构造数据对象，然后调用业务逻辑接口执行插入，最终完成多个业务模型的操作，有的是一对多再来个循环。一个方法里干这么多事情，我都接受了，居然把获取参数和给对象赋值无规律的穿插进行，偶尔还穿插来个参数校验，并且还在方法内部把获取过来的参数加个中文注释。删除课程数据时，需要把关联子模型数据也删除掉，他把各个子模型的删除方法都写到课程的service里。另外还存在A引用B，B又引用A，同时A又被其他好几个地方引用，不同引用之间通过不同参数走不同分支，并且有些参数在哪个场景下传过来的，他自己也弄不清了。带来这样问题就是写代码前，没把逻辑脉络梳理清楚，完全跟着感觉走，就一个简单的增删改查能写成这样，真怀疑要是把一个后端数据服务的代码给他写不知道能给写成啥样。展开作者回复: 如果逻辑没有理清楚，就开始写代码，就有可能后面越改越乱。
我想起来前面有人说的小黄鸭的办法，把代码逻辑讲给小黄鸭听。能讲出来，逻辑就被梳理了一遍。
我在评审代码的时候，如果看到太复杂的代码，我就问作者问题，问为什么这样，问什么不那样做。几个问题下来，代码就会顺利些。 2
2019-01-11读烂代码就想抽人。
类似于new一堆对象。然后在几十行以后才使用 如果命名规范还好，如若不规范就要点回去看。
还有这样奇怪的代码，写了个循环便利集合，但是循环中只有
if（list.get（0）！=null）｛
return list.get（0）；
｝
每次读这样的代码。全都要研究一下这个循环是干啥的。
还有这样的，解决异常。try包了一大串代码，找哪一行抛的异常很费劲。
还有实体类型字段，String state=“1”；
然后后面备注。1代表啥，2代表啥，3代表啥。
不老老实实写个枚举或者常量嘛？
还有代码里的无端空行。写一行，空一行......一个半屏幕滚动能看完的代码，硬是看了两个半屏幕。
关键是还没法去说，毕竟同事之间。只是默默祈祷，不要让自己维护他的代码就好。展开作者回复: 😂我看这个留言，满是欢乐啊。
为什么没办法说呢？ 一般这种问题，说了就是帮助他提高啊。 当然，我也理解有些公司文化不开放。
我替你想两个办法，一个是琢磨琢磨怎么说他会愉快滴接受，并且感谢你。或者，琢磨琢磨怎么搞个规范，让流程帮助他。 他变好了，你也工作轻松，心情愉快，对吧？ 多赢！ 这种事情，也能给你带来成就感，不信你就试一试😄。 6
2019-01-11范老师，阿里的代码规约检查插件已经有了，还挺好用的作者回复: 谢谢你！ 我要记得下次把这个修订了。
5
2019-01-13阿里巴巴 java 开发规范，官方已提供了 idea、eclipse 插件，详情可以访问官方链接：https://github.com/alibaba/p3c/blob/master/README.md
此外还有FindBugs、PMDPlugin、CheckStyle
、JavaNCSS、sonarlint，可以多管齐下，为你保驾护航。作者回复: 谢谢提供这么多资源🙏
4
2019-01-111.属性明确加上private
2.泛型赋值的时候自动判断类型，不用显示加
3.if的第一个或条件不需要
4.if使用大括号
5.map一般用来转换，这块用迭代foreach就行了
6.不用使用顺序迭代，本来集合list就有顺序
7.toSring显示标明override展开作者回复: > 1.属性明确加上private
如果是个公开类，需要使用private修饰符。 如果是内部类，使用缺省的修饰符也可以。
> 2.泛型赋值的时候自动判断类型，不用显示加
是的。
> 3.if的第一个或条件不需要
如果把缺省的无参构造函数补上，这个条件就明显地不需要了。
> 4.if使用大括号
对的。
> 5.map一般用来转换，这块用迭代foreach就行了
> 6.不用使用顺序迭代，本来集合list就有顺序
是的，foreach足以。
> 7.toSring显示标明override
是的，这是一个违反规范的地方。 3
2019-01-14希望能多点最佳实践，最近几期好像有点重复了作者回复: 好的，以后多考虑加点实践。
2
2019-01-12看自己的代码不顺眼，看别人的也是，开源代码很多就看着赏心悦目。总感觉那方面还需要加强，总是不得其法作者回复: 我们这个专栏就是讨论怎么写好代码的。我们慢慢来。 讨论区有很多高手，多参与讨论，多做练手题。一定会有收获的。
2
2019-01-18代码首先是给自己看的，然后是给别人看的，最终还要给以后的自己看的
只有让人一眼望去，其中想要表达的逻辑能清晰明了，一览无遗，这才是好代码 1
2019-01-11分享两条简单、有价值的实践：
在编辑器中设置使用指定的空格数（一般四个）替换tab键；
范老师之前提到的，用if else 替换三目运算符，以及用 i += 1; 替换 ++i;等，可以让代码逻辑更易于理解，降低阅读成本。作者回复: 好使😊，tab键，可以在IDE设置好，vi也可以设置，把tab换成四个空格。
1
2020-01-14对o 为啥不加大括号？？？ 脑子进水了？？？
2019-08-27编码规范除了个人要有良好的编码习惯外，最好还是能有一些工具来辅助，比如阿里的编码规范插件，还有团队协作编码，基础的规则，可以使用EditorConfig制定。- 2019-05-21代码不是写给自己看的，也没有代码不需要迭代开发，规范的代码能提高协作的效率
- 2019-01-14“我替你想两个办法，一个是琢磨琢磨怎么说他会愉快滴接受，并且感谢你。或者，琢磨琢磨怎么搞个规范，让流程帮助他。 他变好了，你也工作轻松，心情愉快，对吧？ 多赢！ 这种事情，也能给你带来成就感，不信你就试一试😄。”
为了看到规范代码。我做了以下的事：
1. 自己先更加严格要求自己的代码。
2. 参加了阿里巴巴代码规范的认证考试，并拿到了证书。
3. 把证书给领导看一眼（证明我自己是规范的），然后说规范很有用。
4.领导表示，嗯，他也觉得是这样。
5.领导在群里通知，建议大家考一下，费用公司报销。
5几个月过去了，我还是唯一一个我们单位执证上岗的。
6. 报了范老师的课程。无法要求别人，但是更不能停止精进自己！最起码不能让别人骂我的代码！
希望这段留言不会被我同事或者领导看到，紧张。
不过，被看到了，貌似也有好处，没准我们公司的代码明天就规范化了呢。展开作者回复: 赞！ 领导和同事看到你的留言也没问题的，规范是多赢的局面，大家都进步。规范这东西，用的人越多力量越大，效率越高。
同事们没有规范，大概率是还没有意识到规范的好处。前几篇文章我自己都觉得都有点啰嗦。但是我就是要把这些基本的理念，翻过来调过去的讲，从不同的角度讲。有了这些意识以后，技术的东西就都是小事了。我也建议你分享一下专栏的这几篇文章给同事们。
我想一想有什么形式，可以让三五个小伙伴组成一个小组，把代码规范就启动起来，还不增加大家的工作负担。也许后续我们可以写一个专题文章。专栏的小伙伴们，也帮着想想办法。 
2019-01-12代码规范是协作的基础，质量的保证，因此促成了开发的高质量、高效率
2019-01-12为什么后面追加要改成流逝的数据？作者回复: 这就是要找的问题呀😄
2019-01-11这个课程是以java作为基础的吗？虽然还是可以读懂，但是有些细节比较模糊作者回复: 虽然是通用的原则，但是主要是用Java代码示范。 非常抱歉，我需要把这些意识的东西，用一门编程语言展示出来，我刚好对Java比较熟，就使用了Java语言。
要是代码不明白，留言区留言，我在回复里给解释下。- 2019-01-11现在有什么统一的规范吗，我对于变量命名，方法命名，对于英语不是很好词汇量不是很多的人感觉有点困难，有什么ide可以用吗
作者回复: 我建议在一个广泛使用的规范上拓展，比如Java的编码规范，Google的Java编码风格，阿里巴巴的Java编码指南。
一般的编码规范会提供IDE插件。有人留言阿里巴巴的Java编码指南就已经有插件了。你找找看。
另外，IDE插件，并不能解决所有的编码规范问题。 我们第一篇会讨论很多编码规范，但是篇幅限制，也不全，偏重的是让大家养成基本的意识和习惯。所以，找一个业界广泛接纳的规范吧，如果你的公司没有自己的规范。也试着把规范在团队、公司推广，利人利己利公司😄 - 2019-01-11现在有什么统一的规范吗，我对于变量命名，方法命名，对于英语不是很好词汇量不是很多的人感觉有点困难，有什么ide可以用吗
作者回复: 在你的上一条留言回复了，你找找看。
2019-01-11编码规范没有绝对的好与坏，最重要的是大家要遵守，目的就是为了高效率的协作，就像范老师所说的流水线要顺畅作者回复: 你这个总结好，就是的，流水线要顺畅👍，顺畅就有效率。
2019-01-11刚开始工作,感觉自己写的代码好low,时间复杂度很高,自己写的都不想看,(╥╯^╰╥),还得磨练,这个需要加强,加油.作者回复: 加油，时间它是你的朋友。我们的进步就是来自于我们知道自己知道的不多。 Stay stupid, stay hungry!