代码规范、如何写出好代码

时间:2021-05-04 23:58:09

 

代码规范、如何写出好代码

作为一个程序员,肯定希望能写出一手好代码,看起来赏心悦目,又易于理解。既方便日后自己回来翻阅一眼就能明白代码在干什么,又能让接手的人很快上手,看到精妙的地方,不由自主地发出由衷的感叹,悄无声息地改变别人不好的习惯。

如何才能写出好代码呢?
在一次讲座上,我听了一位编程大神的看法,在这里分享给大家。

好的代码应该至少具备下面这6个特点:

  1. 使用空行来分割逻辑
  2. 使用注释和花括号
  3. 不用的代码和引用删除
  4. 不要用中文拼音做变量名
  5. 可用,清晰优雅,高效
  6. 多写代码,多思考

使用空行来分割逻辑

一般代码超过30行左右,我们就在考虑,要不要把这些代码封装到一个方法中去。但是即使把这一大段代码扔到一个方法中去,在主函数里调用这个方法,也不能保证以后不会修改这个方法了。所以为了自己和他人,还是有必要对比较长的代码做一些处理。

一般即使是一个方法里面的代码,逻辑也是可以分成一小块一小块的,这个时候我们在这些逻辑中间加上空行,就能告诉别人,我这个代码这里,两个空行中间的代码关联比较大。
在没有添加任何注释的情况下,因为有空行来分割逻辑,倒也不是一步就吓退想要看你代码的人。

使用注释和花括号

在软件开发的生命周期中,文档应该是一直伴随着的。这样,后面接手的人看文档就知道当时发生了什么。如果项目组有使用文档来规范开发,那就要去遵守这个规定。但是文档也有一个问题,就是代码修改之后就要去修改文档,万一文档没有更新,接手的人反而会受到误导。

文档是个好习惯,在坚持更新项目文档的同时,还要记得更新代码的注释,敲完代码后随手加上的简短的几个字,会提高看代码的效率好多倍。

当你焦头烂额的猜测原来编码的人是怎么想的时候,看到添加了注释的代码,是不是有一种谢天谢地的感觉。

花括号{}在代码中一般是有两种形式:

  • 一种是Visual Studio中C++源码编辑器默认的上下对齐式
int main()
{
    cout<<"我是C++"<<endl;
}
  • 一种是Eclipse中Java源码编辑器默认的左花括号末尾排放式
public class HelloWorld { 
    public static void main(String args[]) { 
        System.out.println("我是Java"); 
    } 
}

C++默认方式,更容易看清代码层次;Java默认方式减少占用的行数。

个人更加倾向于上下对齐式。但是个人意见需要服从团队约定。你所在的团队使用哪种方式,你就要使用哪种方式,和大家保持统一。

并且这两种默认方式在集成开发环境IDE中都是可以调节的。比如Java的代码,我平时这样排版。

public class HelloWorld
{
    public static void main(String args[])
    {
        System.out.println("我是Java");
    }
}

不用的代码和引用删除

我们写代码时,需要修改代码时经常注释之前的代码,然后把自己的代码加上去。但是又不确定自己的代码100%正确,不敢删掉注释的代码,因为可能还会换为原来的代码。

这样导致的后果是以后如果没有看出注释代码的问题,反而觉得很有道理的话,真的会将你的代码重新用注释代码换回来。

我们写代码要相信自己,该删的时候就要删掉。要学会使用SVN或者是Git来进行版本控制。即使当前版本删掉了,回滚到之前版本依然能够找回来。大可不必担心真的会删掉了,这样万一有什么变故,也还是能够找回来的。

我们也会经常注意到编辑器行首有很多黄色的感叹号warning提示。虽然不影响程序正常运行,但是看着就是有点不雅观,而且过多没有使用的引用,或者外部包,框架,库等等也会拖慢程序的运行速度。干掉这些无用的东西既能净化我们的心灵,还能减少不易察觉的隐患。

不要用中文拼音做变量名

现在C#和Java都支持中文变量名,类名。可以试着玩一玩,但是真的不要用到项目中,不只是说中文,还有中文拼音。使用有意义的英文作为变量名更有利于沟通,和外国人沟通方便,和中国人沟通也方便。曾经看到有人设计数据库,字段名全部使用中文拼音缩写,令人费解,而且非常别扭,大概只有自己能看懂吧。

英文变量名也不要用a,b,c,d作为变量名,使用有意义的单词全称一眼就知道这个变量,这个类是做什么用的。大家都很忙,没时间猜来猜去。

可用,清晰优雅,高效

具体到一个实际的功能,代码是可用的,看起来清晰优雅的,运行起来高效的才是好代码的标准。

要做到这三点,首先要明确需求,考虑全面一点,从正确性,边界值,反例三个角度去思考问题,定下详细的需求,掌握需求方的意图。
其次,需要先做一个Demo,用于双方进一步确认需求。没有Demo,双方都不是很确定对方有没有get√到我的意思。有了Demo,绝大部分需求都可以确定下来了。一个粗糙的成品好过一个精美的半成品。不要过早优化,先把粗糙的成品做出来,后续慢慢优化。
最后,具体到代码,很多时候都需要调试代码,不要一上来就断点调试,先看一遍代码,检查代码逻辑,理一理思路,然后采用二分法设置断点输出日志,快速定位问题代码。优化时,确定一个优化的基准,优化之后有对比,用数据来告诉别人优化的效果。

多写代码,多思考

多写代码,多思考;多喝热水,多锻炼。

好的代码是在一定代码量的基础上积累起来的,写的时候要多加思考,不能不知道自己在干什么。

程序员长时间坐在椅子上,对脊椎伤害很大,脖子僵硬。建议多喝热水,多活动。写代码一小时就要停下来休息一下,走一走,动一动。多锻炼身体,身体是革命的本钱。

转载请注明出处:

http://blog.csdn.net/gane_cheng/article/details/52152497

http://www.ganecheng.tech/blog/52152497.html (浏览效果更好)