开发的过程中注意下自己的代码质量

Posted 2022-01-30 NoClay

背景

大多数项目中，存在着或多或少的“屎山”代码，这些代码臭不可闻，又无法进行变更，让人每次看到都不仅眉头紧皱，直呼What’s up! 为了不让别人在接手自己代码时一边厚礼蟹，一边优美的中国话，所以在开发的过程中也要关注自己的代码质量问题。
本文仅从android开发角度阐述。

魔法值

代码中遗留魔法值，比如1000，0， 10， 1.0，这些值单独出现在某一处代码，会让人摸不着头脑，且如果涉及到传参协议的地方，如果用魔法值为key，很可能在解析数据的地方会出现错误的解析。这些既不美观，也存在风险。

if(count >= 100)
	map.put("data", targetData);

修改后

//计数器最大值
public static final int MAX_COUNT_OF_PEOPLE = 100;
//传参协议data
public static final String KEY_DATA = "data";
if(count >= MAX_COUNT_OF_PEOPLE)
	map.put(KEY_DATA, 	targetDAta);

xml布局中的文案，Toast中的文案等

类似xml中的文案，尽量在strings.xml中声明资源，避免使用hardcode，否则可能存在如下问题：

• 同一文案出现在多个地方，修改时需要查找，可能遗漏
• App出现其他语言设置时，兼容工作量极大。
  举个例子：

textView.setText("你好" + userName);

定义strings.xml资源

values/strings.xml 默认语言区域
  <string name="title_say_hello">你好%s</string>
values-es/strings.xml 西班牙语区域
  <string name="title_say_hello">Hello %s</string>

textView.setText(String.format(getResources().getString(R.string.title_say_hello), userName));

类或变量命名不规范

此类情况包含以下几种情况：

• 类名不符合驼峰命名法
• 抽象类没有Abstract标识
• 基类没有Base前缀标识
• 类的成员变量名，将变量名全大写，导致误以为该变量为常量。

方法过长或方法参数过长

代码长短可以直接说明它复不复杂、阅读成本高不高，长度度量往往是复杂度分析里最简单直接的手段。此处，有效代码长度 = 代码行 - 空白行 - 注释行。尽量保持95%的方法的有效代码行数在42以内。
一个方法体中包含上百行代码，或者参数列表有五六个参数，会导致该方法的可读性变差。而且该方法很可能变成一个模块的实现，而不是某一个小功能的实现，让方法变得难懂。

一个方法应该仅实现一个最小的功能

如果一个方法体内做过多的功能，会导致代码的可读性变差，难以想象一个方法体内把几件事都完成，如果这样，整个逻辑也会变得复杂难懂。
如果出现这样的情况，应该尽可能的将一个比较长的方法，功能复合的方法，拆分出几个子方法。

降低圈复杂度

圈复杂度以条件分支的多少来表示程序的复杂度。数量上表现为独立线性路径条数 也是覆盖所有情况所需的最少测试用例数。圈复杂度越高，判断逻辑越复杂，越难维护和测试。 尽量保持95%的方法的圈复杂度在10以内，作为方法/模块，一个圈复杂度很高的模块，意味着很多个决策点，这类模块多半运行超过一个明确定义的任务，从设计模式上来说，违背了单一职责原则。另一方面，此类代码阅读性较差，逻辑分支越多，维护越困难，后期对这个模块的改动，会很容易导致其他功能出现Bug。

• 提取函数、合并条件式、替换算法、令函数携带参数等方式
• 将diff(equal), iaValid, isInValid等方法放在对象类中实现
• 将对数据Bean进行的操作封装到对应的数据类代码中