看看那些不讲码德的编程习惯

本文主要是介绍看看那些不讲码德的编程习惯，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

看看那些不讲码德的编程习惯

卓晴 TsinghuaJoking

在码农中有两种人：程序员与好的程序员。也许我们从事编程工作已经很多年了，并不是所有人都可以像称职的好程序员那样写出高效的代码。下面是Mehreen Tahir在 他的博客里 总结出几种不讲码德的坏习惯，给我们编程拖了后腿。
他的博客里:
https://www.c-sharpcorner.com/article/ineffective-coding-habits-what-to-avoid/

1.注释凌乱

我们经常被告知需要认真在自己的代码中加上注释，使得其他人容易理解代码的功能。但做的不合时宜，注释反而显得代码更蠢。比如下面的例子：

/* 
set the value of the number integer to 32 
*/  
int number = 32;  

对于可以不言自明的编程代码完全不必要画蛇添足增加注释。这些注释被编译器忽略掉，通常编程人员么会将其忽略。如果代码已经一目了然，你还会看这些注释吗？大学教授代码编程的老师会讲：“具有自释性的代码就是好的代码。” 如果你的代码本身复杂，难道觉得你可以只使用一两句话就能够解释的明白吗？

通常一个误区就是认为编写繁琐代码的人能够通过注释将它解释很清楚。不过，这并不是说你永远不用写代码注释了。正确的做法就是在书写简介、紧凑、自释性强的代码同时，懂得选择合适的地方、合适的方法给出代码注释。比如下面的一个例子：

function addSetEntry(set, value) {   
/*  
Don't return `set.add` because it's not chainable in IE 11. 
*/   
    set.add(value);   
    return set;   
}  

2.代码过宽

是不是见过下面这样的代码？

for (int i = 0; i < 10; ++i) { if (i % 2 * 0) continue; array[i] += 2; }  

看似上面代码写的紧凑，但如不书写成下面代码更加易读：

for (int i = 0; i < 10; ++i)   
{    
    if (i % 2 * 0) continue;    
    array[i] += 2;    
}    

3.胶合词语

原文作者使用Agglutination来说明在代码简单将多个词语连写在一起形成复杂的变量、函数名称的臭习惯。比如下面的代码：

public interface ConditionChecker  
{  
      boolean checkCondition();  
}  

这个代码就不如修改成下面的形式：

public interface Condition  
{  
    boolean isTrue();  
}  

对比一下，就可以看出代码的好坏。对于一些具有确定功能的函数名称，比如对Exception的捕获处理的函数，实际上就不需要总是将后缀加上Exception：

• OverflowException
• IndexOutOfRangeException
• InvalidOperationException
  将它们直接写成下面的形式更直接明了：
• Overflow
• IndexOutOfRange
• InvalidOperation
  在任何时候省略冗余词语，可以形成更加高效的代码。
  

  4.欠抽象

  在编程中的抽象（Abstraction）是指通过函数、类、库来将复杂算法进行封装，对外提供简明使用接口。就像我们驾驶汽车，无需过多了解发动机和传统原理那样。如果编程时代码欠抽象，将过多的细节留给使用者，就像需要每位司机都需要懂得汽车工作原理那样。比如下面的代码：

If (profileByUserId.get(user.getId())    
     .containsKey(profile.getId())    
  {    
         ……    
  }    

除非有必要，实现函数调用的接口越简洁越好。比如下面的代码就是的代码更加优雅易读。.

if (user.canView(profile))  
  {  
       ……  
  }  

5.上帝类

人们通常将过大的类（class）称为上帝类，是指维护了太多的功能，违反了单一职责原则，连上帝都看不懂你的代码。
一般一个类同时满足以下3个条件就是上帝类：
（1）CPFD (Capsules Providing Foreign Data) 从多个不相关类（模块）中引用数据。
（2）WOC (Weighted Operation Count) 类的所有函数的圈复杂度之和超过65。
（3）TCC (Tight Capsule Cohesion) TCC < 1/3 类需要具有低内聚的特性（类中直接相关的方法与全部方法之比小于1/3），也就是较少的private方法。
为什么编写上帝类是坏的码德呢？这是因为过大的类往往会有很多重复代码，且被子类继承时也会造成大量内存浪费。

6.拷贝粘贴

重复代码一般是由于复制粘贴造成的。需求迭代过程中为了不影响已有功能，通常是将别人代码copy一份改改。这种坏毛病最大弊端是最直接的弊端就是如果你想修改一段代码逻辑，可能会遗漏，甚至需要多次修改才能确保全部修改完。当然，那种只是拷贝粘贴，连代码都不审查的做法更是人神共愤了。

7.过长的参数

全局变量是个邪恶的东西，数据是共享的并且每个线程都可以修改，太多了容易导致程序不可控，所以大家喜欢将变量以行参的方式传递，久而久之参数列越来越长了。
为什么过长参数列是一种不好的码德呢？
方法参数的数量太多会导致代码可读性非常差，如果有多个重载方法它们的方法参数都非常多，在写代码时很难判断该调用哪一个。当一个方法需要新增功能，每次都可能会新增一个方法参数，这样导致调用方每次都要重新适配，小心被打哦，耗子尾汁。
那么，当参数过长怎么办？可以使用一个数据传输对象来进行传输。或者考虑重构函数来解决过长参数传递。

8.虚荣的预留特性

有的时候会听到合作开发的小伙伴夸夸其谈，讲什么在设计程序代码中预留了扩展性，但这些扩展特性在当下实属聋子的耳朵-摆设。关键这种预留扩展特性 一旦成为风气，过度的抽象和预留扩展最终可能会让软件代码难以理解，提前背上包袱，使得软件开发变得复杂，进展速度慢下来。
此时，需要坚持简单设计原则（Simple Design），删除那些觉的可能未来有用的参数、代码、调用等。
如果代码的改动确实是未来必然会发现的，那么还是建议保留。夸夸其谈未来性更多是指开发人员无依据臆测未来，导致代码模块被过度设计。

这篇关于看看那些不讲码德的编程习惯的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！