程序员好做么(程序员好做么)

[摘要]程序员们有什么好的编程习惯？和大家分享一些写好代码的习惯：一 良好的编码规范编码规范我认为是考量程序员是否合格的一个重要因素，因为写代码不规范真的会让团队的整体...

程序员们有什么好的编程习惯？

和大家分享一些写好代码的习惯：

一.良好的编码规范

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

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

1.命名规范

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

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

2.格式规范

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

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

3.逻辑规范

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

4.注释规范

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

5.其他规范

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

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

1）工程包命名

工程包名

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

2）类文件命名

1. activity

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

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

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.去各种技术社区去浏览浏览文章或者写写文章。

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

总结

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

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

本文分享自华为云社区《【云驻共创】为了写好代码，你坚持了哪些好习惯？》，作者：再见孙悟空_。

程序员们有什么好的编程习惯？

1.取个好名字

名如脸，不管是包名，类名还是函数方法和变量，不要随意命名，像什么 foo, bar, a,b,c 这种没有任何意义的名字会污染你的整个代码。

2.先构思再写代码

拿到一个需求最开始是分析需求，拆解问题，将大问题拆解为更小问题，思路清晰了代码写起来才快。

能用Google就不用百度，百度搜出来的东西一是广告太多，难以辨识，二是质量太差，容易被带偏。

3.写注释

“最好的注释就是代码本身”，这句话不是你不写注释的借口，相信我你的代码时间久了自己都不知道什么意思。必要的地方加上注释不仅方便别人理解你的代码，也方便自己。

注释里尽量写为什么，而不是做了什么。

做了什么，看代码就好，代码不会骗人。但为什么要写成这样，有时候就非常让人困惑。有可能是处理某个 corner case，有可能是绕过某个系统限制，也可能是什么奇葩需求，这种代码，没有当时的 context，过几个月看，像甲骨文一样，不知道是想干什么。再有年轻力壮的，看不顺眼来优化一下，以后就不知道哪个地方会崩了。

4.写单元测试

没有单元测试的代码不是跑不起来，而是无法对预期结果做出正确的承诺。单元测试是个短期内投入回报比低，但是长期投入回报比巨大的事情。无论是定位问题还是代码重构，有单元测试犹如系上保险带走钢丝。

5.dont repeat yourself

重复的代码不要出现两次以上，学会将类似的代码进行封装，减少代码的冗余。 这句话的另一层意思是不要重复造轮子，有成熟的方案就直接用，不要什么都想着自己实现。

6.做好版本管理

git 是个好东西。

7.不炫技：不要代码里面强加炫技的代码，按规范来写。

8.练打字速度，写中文注释，注释写清目的和解决问题，注意事项，坑，关联调用，设计思想，以前试验过的方法。

9.长命名变量，方便定位。报错中写个uuid，方便定位。表名加前缀，id用唯一化，合并同步时方便。表中留几个备用字段。

10.断开互联网开发，提高工作效率。做好数据备份。多用代码生成器写代码。

11.多阅读优秀代码

学习优秀的开源代码，这是让自己进步最好的捷径，不一定研究透一个完整的框架，哪怕是管中窥豹也比不去看有收获。

12.多读书

多读点经典书籍，评价是否经典可以去豆瓣看评分，8.0以上的书籍都值得读。

13.学好英语

英语再差也要做到能熟练阅读英文文档的水平，不然每天只能看二手资料，看翻译的东西不仅不严谨而且时效性很差，毕竟技术日新月异。

14.保持健康

编码身体坐直，不然很早就会出现颈椎问题， 保持一定的运动习惯，不然工作三年就有肚腩， 少熬夜，保证每天6~8小时的睡眠时间，不然头发掉的早，还容易猝死。休息时别玩游戏，多健身。

15.不止coding

程序员很难通过“技术”这单一的技能挣到工作之外的钱，技术管理者不是最牛的，而是领导能力出众的，技术大V不是技术最牛的，但是写作方面很优秀，独立开发者技术也不是最牛的，但是有很好的产品能力，做编程网课培训的往往能把一个知识点深入浅出地讲透，最牛的程序员都在实验室闷头搞科研，所以别只盯着“技术”这一个方向。多方位提高自己。

上一页12下一页