为了写好代码，你坚持了哪些好习惯？

Posted 2022-10-04 再见孙悟空_

目录

前言

一.良好的编码规范

1.命名规范

2.格式规范

3.逻辑规范

4.注释规范

5.其他规范

1）工程包命名

2）类文件命名

3）. 图片等资源文件命名

4）.程序中变量 常量命名

二.写好代码注释

三.review重构代码

四.多学习优秀的源码

五.保持平和的心态

总结

---

前言

代码的质量会影响到产品的性能和好坏，代码水平也是程序员业务水平的直观体现，那么我们如何才能写好代码呢？接下来和大家分享一些写好代码的习惯。

一.良好的编码规范

编码规范我认为是考量程序员是否合格的一个重要因素，因为写代码不规范真的会让团队的整体效率都降低。好的编码规范可以指导开发人员更加高效、高质量地进行开发，呈现给用户体验好、性能优、稳定性佳、安全性高的产品。

那么说起代码规范，代码规范具体都指哪些方面的规范呢？

1.命名规范

文件、资源、方法、接口、属性、变量

所有涉及到需要自己定义的部分都需要按照规范来命名，不然整个项目长期堆下来就是一团糟，维护起来相当的困难。

2.格式规范

缩进排版规范,我给大家推荐一个工具，checkStyle（AS和Idea都有这个工具）。

AS checkStyle 插件可以通过自定义配置文件来统一团队的代码风格和代码规范，降低团队的交流成本，一般配合 save actions Reborn 使用更佳。关于checkStyle的配置文件网上也不少，大家自行去网上搜索，不单独赘述了。

3.逻辑规范

如：相同方法要抽取到工具类中以供全局调用、一个方法不要写几千行，方法过于复杂就要再单独抽离方法等。

4.注释规范

注释这部分内容文章第二章节会单独说明。

5.其他规范

如：一行声明一个变量、所有的变量必须在声明时初始化、for循环不要调用线程、项目中禁止使用过多的静态变量等等

示例：我自己写项目遵循的开发规范（去华为云开发者社区、csdn等优秀社区都可以搜索相关的开发规范）

1）工程包命名

工程包名

com. 公司名称简写.应用名称简写（拼音或者英文）.activity  放工程的主Activity 以及BaseActivity

com. 公司名称简写.应用名称简写（拼音或者英文）.activity.list  在activity下面建一个文件夹list放所有的ListActivity   

com. 公司名称简写.应用名称简写（拼音或者英文）.adapter 放和主activity对应的adapter 以及通用adapter

com. 公司名称简写.应用名称简写（拼音或者英文）.adapter.item 放和listAcitivity对应的Adapter

com. 公司名称简写.应用名称简写（拼音或者英文）.bean  放javabean类

com. 公司名称简写.应用名称简写（拼音或者英文）.util  放各种工具类  （图片，字符，时间，dalog 等）

com. 公司名称简写.应用名称简写（拼音或者英文）.net  放和服务器交互的类

com. 公司名称简写.应用名称简写（拼音或者英文）.view 放 自定义view的类

com. 公司名称简写.应用名称简写（拼音或者英文）.db  放 本地数据库操作相关的类

当然 上面的公司名称可以换成别的 ，尽量用简写或者英文  比如qq:  就可以写成 com.tencent.qq.activity，大家明白这个意思就好。

2）类文件命名

1. activity 

activity 我习惯分为两种考虑， 一种是列表数据的， 第二种是普通的activity 。这么分有个好处就是找这个类的时候方便。当你看到这个界面时列表数据的时候 直接搜索listActivity就能过滤掉一大部分，然后再筛选会简单很多。这个大家从上面我定义的包名中就看出来了。

所以 activity的命名是 ： 功能简写+Activity

      功能简写+ListActivity

登录：LoginActivity

用户列表：UserListActivity

2. layout xml

全部小写，用_隔开     xml命名 分为几种

主Activity用到的xml ： activity_activity名称简写.xml       activity_login.xml

include的xml：include_功能简写.xml             include_top_search.xml

adapter中用到的xml：item_adapter名称简写.xml   item_user_list.xml

dialog用到的xml：dialog_功能简写.xml                dialog_show_tips.xml

自定义view用的xml  ：view_view名称简写.xmlview_header.xml  这个就是共用的view  也可以用common_view名称简写.xml替换

xml中 控件id命名：

模块名称_view的逻辑名称_view缩写

用户名EditText :  login_username_et

登录确认Button： login_confirm_btn

LayoutView   lv
RelativeView rv
EditText et
TextView tv
Button btn
ImageButton imgBtn
ImageView iv
CheckBox   cbx
RadioButton rbtn

其他的类似  不一一列举  这些都不是规定死的 ，大家自己定义，前提能区分开不同的控件并且能让别人看懂。

3.工具类等

工具类功能简写+Util : DialogUtil.java   、  TextUtil.java 

3）. 图片等资源文件命名

 背景图片: bg_功能_说明  bg_login_commit
 图标图片: icon_功能_说明  icon_tab_set

功能也可以换为 acvitiy名称简写

共用的图片 前面都加 common

4）.程序中变量 常量命名

在说这个之前要给大家补充一下  标识符命名。就是变量和常量名字

我一般就用两种： 

1 驼峰(Camel)命名法:又称小驼峰命名法，除首单词外，其余所有单词的第一个字母大写。
    protected TextView mWatchCountInfoTv;
    protected TextView mNicknameTv;
    protected TextView mLocationTv;
    protected TextView mVideoTopicTv;
    protected TextView mVideoTitleTv;
2.下划线命名法:单词与单词间用下划线做间隔。

private static final int MSG_SHOW_GIFT = 20;
    private static final int MSG_SHOW_EXPRESSION = 21;
    private static final int MSG_SHOW_RED_PACK = 22;
    private static final int MSG_SHOW_JOIN_USER = 23;

静态常量   

名称都是 功能说明_类别   统一下划线命名法

private static final int MSG_SHOW_GIFT = 20;
private static final int MSG_SHOW_EXPRESSION = 21;
private static final int MSG_SHOW_RED_PACK = 22;
private static final int MSG_SHOW_JOIN_USER = 23;

变量

这个分为两种全局变量、局部变量，全局变量 以m开头，局部变量不用。

全局变量：

protected VideoEntity mCurrentVideo;
protected int mShareType;
protected MyHandler mHandler;
protected int mLikeCount;
protected int mCommentCount;

局部变量：

 TextView tview = new TextView();

 Button button = new Button();

上面已经介绍过 xml中id命名的方法了

所以变量和那个规则基本一致： 功能逻辑名称简写+view 简写

private ImageView mPhoneVerifyIv;
private Button mConfirmBtn;
private EditText mPhoneNumberEt;
private TextView mSelectCountryNameTv;
private TextView mSelectCountryCodeTv;

之前写的一篇文章【软件开发规范六】《Android开发编码规范》

二.写好代码注释

​

代码注释我认为是很有必要的，这里说的代码注释是那些必要的，一些简单的功能没有必要加太多的注释说明。

举个简单的例子：某项目中有一个项目重点工程列表功能，后来又新增了在施项目列表功能，再后来又新增了停工项目重点列表功能，这个时候一般的开发人员都会考虑复用，就是用一个类，不用写三个类，因为列表内字段都很类似，这个时候开发人员直接用的一个类，然后我贴一下代码大家感受下有注释和无注释两者区别：

无注释：

有注释：

​

很明显加上注释以后，大家一眼就能看出这个类的作用，三个功能列表都是这个类的代码，后期维护起来会非常方便，如果不加注释，可能只有开发这个功能的开发人员清楚，其他人或者后期进入公司维护这个项目的开发人员只能通过读代码分析出三个功能是复用的一个类，很明显效率就会降低很多，所以在开发过程中一定要养成一个写注释的习惯，代码注释相当于产品说明书，太重要了。

写代码注释要注意的几个问题：

尽量减少不必要的代码注释，说的直白点就是大家都知道的东西就没必要加注释，加了就是画蛇添足

​

类似这种的就属于画蛇添足，我看代码能很直观的知道这是点击登录后调用的逻辑，不需要解释，写了感觉一点意义没有。

注释一定写清楚作用，对于特殊处理的逻辑，要注释这样处理的原因

代码的注释不是越详细越好，概况的说清楚这段代码的作用即可。

三.review重构代码

​

review代码刚入行的时候就听别人说过，但是在前两家公司的时候，基本都是各做各的，每个人分工不同，也就是说自己写的代码自己维护，也不涉及到其他人，真正让我知道review代码的是在第三家公司的领导。

当时我在第三家公司工作的一年多时间，从入职第一天写的代码到我离职的前一天，我写的所有的代码，我的领导都会帮我review一遍,每次review完我写的代码，他都会把我叫过去和我说哪里写的不行、哪里需要改、怎么改、参照哪处的代码。也是在那家公司项目组领导的指导下，我开发水平有了很大的提升，到现在回想起来，内心非常感谢他。

可以说是那个领导帮我养成了review代码的习惯，刚去的时候被他说过几次，我每次写完也会review一遍，最开始我仅仅是不想再被他吐槽写的烂，因为大家都懂的，程序员就怕别人说自己菜，后来时间长了发现写完功能后review一遍代码，然后修改一下会让代码规范整洁很多；其次有些功能会加深理解。后来我离职去了下一家公司也一直保留写完代码后再重新review一遍的习惯。

review代码几点小的建议：

做完一个小功能后或者发布一个版本后review一遍，这个时间点比较适合，新功能还在讨论需求中，会有空余时间可以用来review。

代码review都看哪些东西，我其实一般主要就看三方面：

代码规范 命名、格式、易读性等

代码涉及到的一些算法或者逻辑等

代码是否可整合，比如同一类的方法是否可以增加参数复用、自定义组件是否可以重新封装增强扩展性。

当然如果系统性的review代码不仅仅这三点，大家根据自己实际情况来做。

四.多学习优秀的源码

​

如何让自己的代码写的看起来很高大上、有水平、很规范。很多老菜鸟一般都会脱口而出：看源码啊...

这个看源码没毛病，看源码肯定会有所收获，源码基本都是标准规范化的模板，但是说实话，我真的没咋认真读过那些底层源码，除了刚学习java那会老师说必须仔细看API，去源码找方法，后来基本没咋看过源码，因为我真的看不下去。

我一般都喜欢带着问题或者有一定目的去做事情，你就直接让我看一堆源码，我容易犯困。我个人习惯是看那些大厂的DEMO，比如我做云直播,我就看XX团队的DEMO的代码是怎么写的；我做推送我就看某推送团队的API文档说明，学习文档说明里面附带的DEMO源码是如何写的。所以个人习惯看大厂发布的最新版本的DEMO源码，因为首先我能看懂，其次能直接帮我解决问题。再后来我就看github上面主流的一些开源DEMO，都是star高的开源项目，这些项目都有一个共同点，就是代码都写的很规范。学习代码规范的同时还能顺便了解项目中都依赖了哪些新的框架、采用了哪些新的技术，总而言之就是找适合自己的优秀的项目去学习。

五.保持平和的心态

​

程序员这个职业其实对个人的心态要求很高，控制不好自己的心态真的不太适合做这行工作。

因为每天都会面对各种复杂的问题，做不完的功能，改不完的BUG...

描述一个场景：你正在改一个特别难处理的bug,但是开发环境却在这时候出问题了，配置了半天还是解决不了，开发环境还是一直有问题，恰好这时候产品经理突然过来和你说之前另外一个功能模块的需求设计需要推翻重新做并且需要尽快加班改完。产品经理通知所有相关人员参加新需求讨论交底会议，会上研发经理要求大家晚上留下来加班讨论改版后的系统架构设计和数据库相关改动设计，此时你的内心想必是有很多神兽飘过...

​

很多开发的小伙伴碰到这种情况，心态就发生变化了，bug也改不下去，功能也不想做，即便硬着头皮去改去做也会有很多问题，因为心态没调整好，逻辑没有梳理清晰，做出来的功能一定是问题一大堆。

调整心态的方法：

1.站起来活动活动，让自己冷静冷静。

2.去各种摸鱼群里面吹吹水、吐槽吐槽，都可以缓解我们紧张烦躁的情绪。

3.去各种技术社区去浏览浏览文章或者写写文章。

总之就是做一些事情，先转移一下注意力，先把自己心态调整好，这样才能高效的投入到工作中。

总结

代码是一环扣一环的，从逻辑、可读、简洁、效率、维护，这些标准都决定了代码的好坏。

从看到学再到写，在提升自己代码能力的同时，还要注意代码的质量优化，一个好的程序，是由好的代码模块组合而成的，而在我们写程序的时候就应该多加考虑和设计，这样不仅是对代码负责也是对自己负责，写好优质代码是一个程序员应尽的责任。