有什么编程的好习惯建议吗？
▍有什么编程的好习惯建议吗？
和大家分享一些写好代码的习惯：
一.良好的编码规范
编码规范我认为是考量程序员是否合格的一个重要因素，因为写代码不规范真的会让团队的整体效率都降低。好的编码规范可以指导开发人员更加高效、高质量地进行开发，呈现给用户体验好、性能优、稳定性佳、安全性高的产品。
那么说起代码规范，代码规范具体都指哪些方面的规范呢？
1.命名规范
文件、资源、方法、接口、属性、变量
所有涉及到需要自己定义的部分都需要按照规范来命名，不然整个项目长期堆下来就是一团糟，维护起来相当的困难。
2.格式规范
缩进排版规范,我给大家推荐一个工具，checkStyle（AS和Idea都有这个工具）。
AS checkStyle 插件可以通过自定义配置文件来统一团队的代码风格和代码规范，降低团队的交流成本，一般配合 save actions Reborn 使用更佳。关于checkStyle的配置文件网上也不少，大家自行去网上搜索，不单独赘述了。
3.逻辑规范
如：相同方法要抽取到工具类中以供全局调用、一个方法不要写几千行，方法过于复杂就要再单独抽离方法等。
4.注释规范
注释这部分内容文章第二章节会单独说明。
5.其他规范
如：一行声明一个变量、所有的变量必须在声明时初始化、for循环不要调用线程、项目中禁止使用过多的静态变量等等
示例：我自己写项目遵循的开发规范（去华为云开发者社区、csdn等优秀社区都可以搜索相关的开发规范）
1）工程包命名
工程包名
com. 公司名称简写.应用名称简写（拼音或者英文）.activity 放工程的主Activity 以及BaseActivitycom. 公司名称简写.应用名称简写（拼音或者英文）.activity.list 在activity下面建一个文件夹list放所有的ListActivitycom. 公司名称简写.应用名称简写（拼音或者英文）.adapter 放和主activity对应的adapter 以及通用adaptercom. 公司名称简写.应用名称简写（拼音或者英文）.adapter.item 放和listAcitivity对应的Adaptercom. 公司名称简写.应用名称简写（拼音或者英文）.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用户列表：UserListActivity2. 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.去各种技术社区去浏览浏览文章或者写写文章。
总之就是做一些事情，先转移一下注意力，先把自己心态调整好，这样才能高效的投入到工作中。
总结
代码是一环扣一环的，从逻辑、可读、简洁、效率、维护，这些标准都决定了代码的好坏。
从看到学再到写，在提升自己代码能力的同时，还要注意代码的质量优化，一个好的程序，是由好的代码模块组合而成的，而在我们写程序的时候就应该多加考虑和设计，这样不仅是对代码负责也是对自己负责，写好优质代码是一个程序员应尽的责任。
本文分享自华为云社区《【云驻共创】为了写好代码，你坚持了哪些好习惯？》，作者：再见孙悟空_。
▍有什么编程的好习惯建议吗？
不管是学习什么，都要有一些好习惯，那么编程学习中哪些好习惯值得一直坚持下去的呢？
01、代码规范
对于个人而言，良好的代码规范能提升代码质量，减少低级的代码错误。任何编程语言都有自己的一套规范，好的规范能让代码更易阅读。对于团队而言，每个人写代码的思维方式、技术水准不同，保持一致的规范，能保证项目结构不混乱调用，有效降低写作沟通成本，更好地保障线上的稳定性。
02、学会阅读源码
现在资源泛滥，代码一抓一大把，CSDN、GitHub、博客、书籍源代码等，琳琅满目的。在编程学习中，阅读源码我们可以学到很多东西：别人对设计模式的熟练使用、别人对整个架构的布局等，不仅能帮助我们在早期形成良好的代码意识，更提高我们debug的能力。
03、独立思考并解决问题
作为一枚程序员，我们天生就是来解决问题的。因此最忌讳的就是，遇到困难时，没有经过自己的思考，就截图抛向别人。
04、学会沟通
在你学习编程的过程中，什么都自己完成，会封闭自己，造成困扰掉进死胡同。 要学会使用免费的资源或平台或同事朋友，哪怕是随便的一问，也许就会给你解题的思路，你会学习得更快（同辈压力和更多沟通）。
05、不断学习的能力
互联网时代的技术来得快，去得更快。如果没有足够强的求知精神，就无法跟上变化。除了写代码，程序员的日常还包含编写技术方案、需求文档、数据库结构、PPT等，这些技术性工作可能已经排满了工作的八小时。
有的好习惯做着做着就习惯了，谈不上坚持，最终成了喜欢的自己。
▍有什么编程的好习惯建议吗？
学框架，不纠结细节
一定要记住，思考问题不要从细枝末节去往上推，而应该是从枝干到叶梢。我们平时解决问题，都是从叶梢开始，往枝干去分析，但是大家在分析到枝干的时候，就会停下来，因为解决了当前的叶梢问题。
但是，这个就是你成不了大佬的原因，你没有形成所谓的思维框架。
说一个最近的事吧，圈子里有个咨询问题，需要让三方APP不能随着系统的字体大小变化，该如何处理？
他给我说他的方法是，在创建后进行重新设置字体，这样子解决问题。引出的问题就是，经常会卡死，ANR，我给他反馈，解决思路是错误的。
解决问题一定要找到源头，而这个问题的源头是什么呢？
1 系统字体设置具体改动了哪些值？
2 这些值是怎么在Activity生效的？
3 找到判定三方应用的系统Flag？
4 在创建的地方，直接绕过三方APP，完成功能？
通过这个思路，给到他一个建议，他按照这个处理，最终解决了问题。这是我听到他的问题，脑子里面快速思考的问题。
这个是解决问题的一个逻辑，一个无敌解决方案。如果说再往上延伸，就是你要能够理解，系统是由哪几部分组中，哪些是内部，哪些是外部，他们如何关联，如果调用，是否有一个特殊的路径，如果是，就可以设置断点，轻松分析问题。
▍有什么编程的好习惯建议吗？
遵循编码规范：编程时应该遵循编码规范，例如变量命名、缩进格式、注释等，这样可以让代码更加易于阅读和维护。分而治之：将大的问题分解成小的子问题，逐个解决，避免过于依赖特定环节，也便于代码的维护和重构。保持代码简洁：代码应该尽可能地简洁明了，去除不必要的复杂性和重复性，使其更容易理解和调试。避免硬编码：通过配置文件或者常量定义等方式避免硬编码，方便后期的维护和修改。使用版本控制：使用版本控制软件（如 Git）来管理代码，使得开发进程更加规范、稳定，并便于回退和协作。测试驱动开发：在编写代码之前先写好测试代码，并且通过对测试用例的实现来逐步完善程序设计，以确保代码的正确性和可用性。
▍有什么编程的好习惯建议吗？
1.英文命名
中文和拼音命名是大忌，不要用，不要用，不要用（重要的事情说三遍），我帮人调过拿中文命名的代码（编程语言是C#），那就是个折磨。一台笔记本，四个小时都耗在奶茶店里了。为什么？因为那人他不用英文，用的拼音还不时夹杂着中文，一个winform窗体他记不到原名是什么了，整个窗体报废了，还是登陆的模块，直接连带剩下的窗体一起报废，只能全部重写，也是代码大部分还在，能复制粘贴进行调试，改命名，不然直接完蛋。
2.写注释
一定要写，尤其是越复杂的模块越要不怕麻烦写注释，因为代码现在你看起来会，但是几天后？半个月？几个月后呢？自己再去看，没有注释，自己都不知道自己当时写的啥，为什么要这么去写。但是，写注释不是什么代码的注释都要写的，你要是是教学出书除外，但是像变量的定义，强制转换等这些就没必要写，浪费时间。而涉及到核心模块的一定要写，比如说：我拿c#写一个图书管理系统，那图书馆理系统最为核心的是什么？图书的借阅，这一模块一定要好好的写注释。可能初学阶段都是自己一个人总揽全部的工程，但是以后和人合作呢？你不写注释，别人怎么知道你的某段代码为什么要这样去写，写的逻辑是什么，对接了api什么的等。
3.多运用断点
断点用得好，bug可以很快找出来。多运用断点，可以缩小bug的范围，快速高效。
4.写文档
我个人其实也不喜欢写文档的，很痛苦，尤其是反反复复修改，打印出来的结果不尽人意。你可以不那么正经的写文档，但是一定要有一个框架或者思维导图，这样你编程编起来才不会是无头苍蝇，做到哪里是哪里，最好还是写文档，方便自己理清思路。
5.灵活运用搜索引擎
出bug了，不要一下就去问人，百度，Google这些上面的解决方案一定是有的（对于初学者而言），查完搜索引擎上也没有，再去问人。一些资料也可以通过搜索引擎找得到的。
6.格式
tab键这些用起来，不要学百度的前端的代码那样，写的真的很恶心人，没有缩进，也不空格，全部挤在一起，只是为了防止自己的代码被人爬走，有时候，不仅不缩进，还把h5和css塞一起。格式用的好，代码的阅读和bug的查找会舒服很多
------------------
推荐阅读：
有人说彩票除非中一等奖，否则其它的奖迟早都会全部还回去，怎么看？
上一篇：黄瓜藤泡水喝会有什么功效？
下一篇： 担任过国家副总理的开国将帅有哪些？
