iOS开发（25）
一直以来，身边总会有这样的声音——“如何提高自己的代码质量”，我想这个话题可能大家会比较感兴趣，所以在这里分享一下我在iOS开发中对如何提高代码质量的一些心得体会，其他的语言可以以此做一个参照。
1. 基础知识及技巧
想写出高质量代码，并不是一蹴而就的，它需要有一定的基础以及大量的代码知识积累，这里我重点强调与代码质量密切相关的几点：
首先得掌握好开发语言，iOS开发有二种语言——Objective-C和Swift，不管你选择哪种都可以，不过现在Objective-C还是主流，但我相信未来肯定是Swift的天下，关于Objective-C可以看看，这本书讲解了非常多使用Objective-C的技巧。
其次你就需要去了解iOS开发平台特性以及工作原理，了解清楚这些之后，充分利用他的一些特性写出更加地道的代码。
2. 数据结构和算法
计算机科学本来就是由数学发展而来的，数据结构与算法的重要性不言而喻，当然，不是说你不学习算法就不能做开发了，而是说学好数据结构和算法，当你遇到问题时，你可以以更加优雅高效地解决问题。
3. 设计模式
设计模式是一个老生常谈的话题，市面上充斥着各种的设计模式，我们无需对所有的设计模式都需要了解，只需要了解一些常用的设计原则即可，这里给你推荐一本书——，学完之后应该能解决你的绝大部分问题了。
4. 代码标准
一个团队中人来自不同的地方是非常正常的，每个团队中代码风格有时往往又会不一样，这个时候代码标准在团队合作中尤为重要，谁也不希望一个项目中代码风格各异，相互之间都不愿看别人的代码。标准怎么定是一个老生常谈的话题，我个人职业生涯中经历过很多次的代码标准讨论会议，大家有时会坚持自己的习惯不肯退让。代码规范问题我推荐团队的&（），
5. 拆解功能，再写代码
拿到需求除非你很清楚你要怎么做，否则绝对不能直接下手写代码，而是我们需要先思考如何对功能进行拆解以及如何去解决问题，思考目前的方案是否有效？有没有更优的方案？如果你把问题拆解好了，实现其实是非常简单的事。
6. 代码审查
在项目起始阶段进行代码审查会帮助我们更好地使用已经建立起来的代码体系，因为如果我们没有使用过某些现有代码，那么可以从当前的开发者中获得反馈信息。在项目进行过程中，我们会时不时地向团队增加新的开发人员，代码审查可以极大地降低这些新加入人员的熟悉时间。特别地，我们可以让新加入的开发人员很有信心地开发新特性，因为我们可以在合并前审查代码并且对于他们所编写的任何代码提供有价值的反馈信息。
对于分布式团队来说，代码审查更加具有实际意义。团队协同在构建协作环境上会带来很大的帮助作用，我们可以即时提出想法，然后讨论，再进行开发。虽然由于不在同一地点我们会失去一些东西，不过我们却可以在代码审查过程中通过深入的讨论来获得好处。
7. 单元测试
自从Xcode 5以来，Xcode就会默认带上XCTest单元测试库，但单元测试一直没有引起大家的注意，大家可能考虑到写单元测试太破费时间了，但单元测试的一个非常显著的优点是，当你需要修改大量代码时，尽管放心修改，只需要保证单元测试用例通过即可，无需瞻前顾后。
8. 充分自测
自测对于程序员来说是一个头痛的问题，有些程序员总想着让测试帮找问题，连自己的运行结果都不看就把App丢给测试，这是非常不负责任的。作为一个程序员在写完代码后至少需要跑完一遍全部流程以及一些简单的异常情况再交给测试，不然，随便用几下就Crash的东西，会给测试人员这人不靠谱以及技术真low的印象，再说，你准备在别人面前展示自己研究的工作成果时，突然之间Crash掉了，你真的好意思吗？充分自测也是基本的职业素养体现~所以充分自测非常重要！充分自测非常重要！充分自测非常重要！重要的事说三遍~
9. 善用开源
在我刚学iOS开发时，那时的iOS开源代码还是比较少的，我当时都是去官网去看一些代码，ASI还是非常火的网络框架，现在完全就不一样了，各种各样的轮子都有了。当然，在这些轮子的背景下并非所有的开源质量就很高，但一般情况下中口碑好的、使用人多的、关注度高的开源项目，质量是有一定的保证的，这其中的道理很简单。即便存在一些问题，也可以通过提交反馈，不断改进。而充分利用开源项目，能帮助你节省很多时间，把精力专注在最需要你关心的问题上。
能被关注的开源项目，都是领域内的高手所写，向这些牛人学习编程技巧，能让你知道如何能写出高效的代码，学习别人解决问题的方式，培养自己对代码更灵敏的嗅觉。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：84647次
积分：1034
积分：1034
排名：千里之外
原创：23篇
评论：12条
(1)(1)(1)(1)(7)(4)(6)(8)(2)如何编写高质量代码 - 简书
<div class="fixed-btn note-fixed-download" data-toggle="popover" data-placement="left" data-html="true" data-trigger="hover" data-content=''>
写了32593字，被71人关注，获得了91个喜欢
如何编写高质量代码
第一章 熟悉Objective-C
Objective-C的语法中频繁使用方括号，而且不吝于写出极长的方法名。以为这样写出来的代码十分易读。
Objective-C应该多注意一些细节，还有一些许多容易为人忽视的特性。还有一些并未完全理解或是容易滥用的某些特性，导致写出来的代码难于维护且不易调试。
第一条：了解Objective-C语言的起源
Objective-C与C++、Java等面向对象语言类似，不过该语言使用“消息结构”（messaging structure），而非“函数调用”（function calling）。
// Messageing (Objective-C)
Object *obj = [Object new];
[obj performWith:parameter1 and parameter2];
// Function calling (C++)
Object *obj = new O
obj-&perform(parameter1, parameter2);
o Objective-C为C语言添加了面向对象特性，是其超集。Objective-CShi用动态绑定的消息结构，也就是说，在运行是才会检查对象类型。接受一条消息后，究竟应执行何种代码，有运行期环境而非编辑器来决定
o C语言的核心概念：
第二条：在类的头文件中尽量少引用其他头文件
第三条：多用字面量语法，少用与之等价的方法
学会用语法简化来编写代码。苹果针对很多基础类型采用了简写方式，实现语法简化。
NSNumber *
value = [NSNumber numberWithInt:12345];
value = [NSNumber numberWithFloat:123.45f];
value = [NSNumber numberWithDouble:123.45];
value = [NSNumber numberWithBool:YES];
简化后的语法：
NSNumber *
value = @12345;
value = @123.45f;
value = @123.45;
value = @YES;
装箱表达式:
NSString *path = [NSString stringWithUTF8String: getenv("PATH")];
NSString *path = @( getenv("PATH") );
NSArray *array = @[a, b, c];
编辑器会转化成:
id objects[] = { a, b, c };
NSUInteger count = sizeof(objects)/ sizeof(id);
array = [NSArray arrayWithObjects:objects count:count];
字面量语法有一个小小的限制，就是除了字符串意外，所创建出来的对象必须属于Foundation框架才行。如果自定义了这些类的子类，则无法用字面量语法创建其对象。
字面量语法创建出来的都是不可变的。若想可变，字需要复制一份：
NSMutableArray *mutable = [@{@1, @2, @3} mutableCopy];
o 应该使用字面量语法创建字符串、数值、数组、字典。这么做更加简明扼要。
o 应该通过取下标操作来访问数组下表活字典中的键所对应的元素
o 用字面量语法创建数组或字典时，若值中有nil，则会抛出异常。因此，务必保值里不含nil。
第四条：多用类型常量，少用#define预处理指令
编码时定义常量：
不应该在头文件里声明预处理指令，这样做真的很糟糕，当常量名称有可能相互冲突时更是如此。
#define ANIMATION_DURATION 0.3
在预处理的过程中会把所有的ANIMATION_DURATION全部替换。
解决办法：
static const NSTimeInterval kAnimationDuration = 0.3;
o还要注意：如果常量局限于某“编译单元”(也就是实现文件)之内，则在前面加字母k；如果常量在类之外课件，子通常以类名为前缀。
变量一定要同时用static与const来声明。如果试图修改由const修饰符所生命的变量，那么编辑器会报错。而且如果一个变量既声明为static，又声明为const，那么编辑器根本不会创建符号，而是回想#define预处理指令一样，把所遇到的变量都替换为常值。用这种方式定义的常量带有类型信息有时候需要对外公开某个常量。此类常量需放在“全局符号表”中，以便可以在定义该常量编译单元之外使用。定义如下：
extern NSString *const EOCStringC
extern *const EOCStringConstant = @"AVLUE";
o 不要用于处理指令定义常量。这样定义出来的常量不含类型信息，编辑器只会在编译钱执行查找和替换。即使有人重新定义了常量值，编辑器也不会产生警告信息，这将导致程序中常量值不一致。
o 在实现文件中使用static const来定义“只在编辑单元内可见的常量。
o 在头文件中使用extern来声明全局常量，并在相关实现文件中定义其值。这种常量要出现全局符号表中，所以其名称应加以区隔，通常用与之相关的l类名做前缀。
第五条：用枚举表示状态、选项、状态码
o 在列出枚举内容的同时绑定枚举数据类型NSUInteger，这样带来的好处是增强的类型检查和更好的代码可读性。如果不加数据类型范围的话，它是模糊的，这个数值可能非常大，可能是负数，无法界定。
o 用 NS_ENUM与NS_OPTIONS宏来定义枚举类型，并指明其底层数据类型。这样做可以确保枚举是用开发者选定的底层数据类型来实现的，而不会采用编辑器所选用的类型来实现的。
o 在处理枚举类型的switch语句中不要实现default分支。这样的话，加入新的枚举之后，编辑器就会提示开发者：switch语句并未处理所有枚举
——对于一般的开发来说，枚举类型可能不会涉及到复杂的数据。
第二章 对象、消息、运行期
第六条：理解属性这一概念
“属性”是Objective-C的一项特性，用于封装对象中的数据。Objective-C对象通常会把所需要的数据保存为各种实例变量。getter用于读取变量值，setter用于写入变量值。
要访问属性，可以使用“点语法”，编辑器会把“点语法”转换为对存取方法的调用，使用“点语法”的效果与直接调用存取方法相同。使用属性还有很多优势，比如：如果使用了属性的话，那么编辑器就会自动编写访问这些属性所需的方法，此过程叫做“自动合成”。这个过程由编辑器在编辑期执行，所以编辑器里看不到这些“合成方法”的源代码。除了合成方法之外，编辑器还要自动向类中添加适当类型的实例变量，并在属性名前面加下划线，一次作为实例变量的名字。
注意：如果想阻止编辑器自动合成存取方法，可以使用@dynamic关键字，他会告诉编辑器不要自动创建实现属性所用的实例变量，也不要创建存取方法。
o 原子性（atomic/nonatomic）o 读写权限（readwrite/readonly/）o 内存管理语义（assign/strong/weak/unsafe_unretained(该特性表达一种“费用有关系”)）
o 可以用@property语法来定义对象中所封装的数据。
o 通过特制来置顶存储数据所需的正确语义。
o 在设置属性所对应的示例变量时，一定要遵从该属性所声明的语义。
o 开发iOS程序时应该使用nonatomic属性，因为atomic属性严重影响性能。
第七条：在对象内部尽量直接访问实例变量
使用点语法，通过存取方法来访问相关实例变量，和不经由存取方法，而是直接访问实例变量的区别：o 由于不经过OBjective-C的“方法派发”步骤，所以直接访问实例变量的速度当然比较快。在这种情况下，编辑器所生成的代码会直接访问保存对象实例变量的那块内存。o 直接访问实例变量时，不会调用其“设置方法”，这就绕过了为相关属性所定义的内存管理语义。比方说，在ARC下访问一个声明为copy的属性，那么并不会拷贝该属性，只会保留新值并释放旧值。o 如果直接访问实例变量，那么不会触发“键值观测”(KVO)通知。这样是否会产生问题，还取决于具体的对象行为。o 通过属性来访问有助于排查与之相关的错误，因为可以给“获取方法”和“设置方法”中新增断点，监控该属性的调用者及访问时机。
有一种折中方案，那就是：在写入实例变量时，通过其“设置方法”来做，而在读取实例变量时，则直接访问之。此方法既能提高读取操作的速度，又能控制对属性的写入操作。
在初始化方法中，正常情况应该直接访问实例变量，因为子类可能“覆写”设置方法。此时若是通过“设置方法”来做，那么调用的将会是子类的设置方法。但是如果带初始化的实例变量声明在超类中，而我们有无法在子类直接访问此实例变量的话，那么只能调用“设置方法”了。
o 在对象内部读取数据时，应该直接通过实例变量来读，而写入数据时，则应该通过属性来写。o 初始化方法及dealloc方法中，总是应该直接通过是实例变量来读写数据。o 有时会使懒加载技术配置某份数据，这种情况下，需要通过属性来读取数据。
第八条：理解“对象等同性”这一概念
根据”等通行“来比较对象是一个非常有用的功能。不过，==操作符有时比较出来的结果未必使我们想要的，因为该操作比较的是两个指针本身，而不是其所指的对象。
NSObject协议中的isEqual:方法来判断两个对象的等同性。
NSString类实现了一个独有的等同性判断方法：isEqualToString:。（传递的必须是字符串，否则返回undefined）
NSArray类和Dictionary：isEqualToArray:
isEqualToDictionary:（不是数组或字典，会自动抛出异常）
等同性判断的执行深度
NSarray检测方式先看两个数组所含对象个数是否相同，若相同则在每个对应位置执行isEqual:
某一实例是根据数据库里的数据创建而来，那么其中可能会有另外一属性，此属性是“唯一标识符”------主键。那么只根据标识符来判断等同性即可。是否需要在等同性判定方法中检测全部字段取决于受测对象。只有类的编写者才可以确定两个对象实例在何种情况下应判定为相等。
容器中可变类的等同性
先将set里存放一个可变数组，在放入一个具有相同内容的数组，set里只会存放一个数据；
在存放一个不同的可变数组，set里会存放两个；
将第二个可变数组改成与第一个可变数组相等，set里会存放两个相同数据；
但将set复制一份，只会有一个数据
o 若想检测对象的等同性，请提供“isEqual:”与hash方法。o 相同的对象必须具有相同的哈希码，但是两个哈希码相同的对象未必相同。o 不要盲目的逐个检测每条属性，而是应该依照具体需求来制定检测方案。o 编写hash方法时，应该使用计算速度快而且哈希码碰撞几率低的算法。
第十条：在既有类中使用关联对象存放自定义数据
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
打开微信“扫一扫”，打开网页后点击屏幕右上角分享按钮
被以下专题收入，发现更多相似内容：
分享 iOS 开发的知识，解决大家遇到的问题，讨论iOS开发的前沿，欢迎大家投稿~
· 29380人关注
欢迎iOS开发大神投稿~~
· 640人关注
· 11人关注
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
选择支付方式：怎样编写高质量的Java代码 - 喜糖 - 博客园
移动开发工程师 。涉及 android、ios、jni
posts - 277, comments - 21, trackbacks - 0, articles - 0
本文来自，他首先向大家讲述怎样辨别一个项目代码的好坏、如何区分优秀代码和腐化代码，最后给大家讲述如何写出高质量的Java代码。&代码质量概述&
怎样辨别一个项目代码写得好还是坏？优秀的代码和腐化的代码区别在哪里？怎么让自己写的代码既漂亮又有生命力？接下来将对代码质量的问题进行一些粗略的介绍。也请有代码质量管理经验的朋友提出宝贵的意见。&代码质量所涉及的5个方面：编码标准、代码重复、代码覆盖率、依赖项分析、复杂度分析。这5个方面很大程序上决定了一份代码的质量高低。我们分别来看一下这5方面：&
编码标准：这个想必都很清楚，每个公司几乎都有一份编码规范，类命名、包命名、代码风格之类的东西都属于其中。
代码重复：顾名思义就是重复的代码，如果你的代码中有大量的重复代码，你就要考虑是否将重复的代码提取出来，封装成一个公共的方法或者组件。
代码覆盖率：测试代码能运行到的代码比率，你的代码经过了单元测试了吗？是不是每个方法都进行了测试，代码覆盖率是多少？这关系到你的代码的功能性和稳定性。
依赖项分析：你的代码依赖关系怎么样？耦合关系怎么样？是否有循环依赖？是否符合高内聚低耦合的原则？通过依赖项分析可以辨别一二。
复杂度分析：以前有人写的程序嵌套了10层 if else你信吗？圈复杂度之高，让人难以阅读。通过复杂度分析可以揪出这些代码，要相信越优秀的代码，越容易读懂。
上面解释了代码质量相关的5个方面，在实际开发环境中，已经有很多工具为我们解决以上5个方面的问题，下列5个eclipse插件分别对这5个问题有很好的支持：&
编码标准：
代码重复：
代码覆盖率：
依赖项分析：
复杂度分析：
注：某些插件需要科学上网才能更新&1. 编码标准（CheckStyle的使用）&在Eclipse上安装好了CheckStyle插件后，我们来建一个类用它跑一下。这个类很简单，一个常见的用户实体，包含了ID，用户名、密码、邮件等属性，并包含get set方法，一个标准的POJO。运行CheckStyle检查一下：&
一个我们平时再普通不过的一个类，被CheckStyle弄出这么多问题，情何以堪，我们来看看究竟是什么情况？&看一下这些警告信息：&line 1、，说缺少package-info.java文件。&line 2、，说第一句注释要以&.&结尾。&line 30、，缺少java doc注释。&line 35、，getId不是继承的方法，必须指定abstract,final或空。另外也缺少java doc注释。&这个类基本就这四类毛病，缺少package-info.java文件，这个文件是做什么的呢？他是用来描述包注释的类，有一定的特殊性，要想详细了解请百度。如果对你的项目没有太大的影响，可以忽略它。配置CheckStyle的方法我们等会再说。第一句注释要以&.&结尾，这看你的习惯，你确定需要这个，你就保留，不需要就忽略。缺少Java doc，对于Java类的属性来说，注释是必要的，所以这个要保留。不是继承的方法，需要加上final关键字，如果你有这个习惯，就保留，反之忽略。&我们这里只是建立了一个最简单的类用CheckStyle来检查，随着你的类代码越来越多，逻辑越来越复杂，CheckStyle能检查出来的毛病也越来越多。&常见的CheckStyle错误有这些：&
1.Type is missing a javadoc commentClass&&&缺少类型说明&2.&{& should be on the previous line&&{& 应该位于前一行&3.Methods is missing a javadoc comment&方法前面缺少javadoc注释&4.Expected @throws tag for &Exception&&在注释中希望有@throws的说明&5.&.& Is preceeded with whitespace &.&&前面不能有空格&6.&.& Is followed by whitespace&.&&后面不能有空格&7.&=& is not preceeded with whitespace&&=& 前面缺少空格&8.&=& is not followed with whitespace&&&&=& 后面缺少空格&9.&}& should be on the same line&&&&&}& 应该与下条语句位于同一行&10.Unused @param tag for &unused&&没有参数&unused&，不需注释&11.Variable &CA& missing javadoc&变量&CA&缺少javadoc注释&12.Line longer than 80characters&&&行长度超过80&13.Line contains a tab character&行含有&tab& 字符&14.Redundant &Public& modifier&冗余的&public& modifier&15.Final modifier out of order with the JSL&suggestionFinal modifier的顺序错误&16.Avoid using the &.*& form of import&Import格式避免使用&.*&&17.Redundant import from the same package&从同一个包中Import内容&18.Unused import-java.util.list&Import进来的java.util.list没有被使用&19.Duplicate import to line 13&重复Import同一个内容&20.Import from illegal package&从非法包中 Import内容&21.&while& construct must use &{}&&&while& 语句缺少&{}&&22.Variable &sTest1& must be private and have accessor method&变量&sTest1&应该是private的，并且有调用它的方法&23.Variable &ABC& must match pattern &^[a-z][a-zA-Z0-9]*$&&&&&&&变量&ABC&不符合命名规则&^[a-z][a-zA-Z0-9]*$&&24.&(& is followed by whitespace&&&&&(& 后面不能有空格&25.&)& is proceeded by whitespace&&)& 前面不能有空格
可以看出CheckStyle检查出来的问题，大多是编码规则以及风格上的问题，这是编写高质量代码最基本的。值得注意的是，我们将一些优秀的开源代码用CheckStyle来检查也会检查出不少问题，这不能不说这些开源不优秀，而是每个公司组织有自己的编写规范度，这个度既可以减少程序员的工作量又可以让代码的可读性合格，但这个度不一样符合CheckStyle的完整标准。所以我们一般使用CheckStyle都不会用他的默认标准，而是通过配置，制定适合自己的编码规则。&自定义CheckStyle规则：&
打开CheckStyle配置，新建一个配置，选择外部配置文件。在这之前最好导出一个Eclipse自带的CheckStyle配置文件（sun_checks.xml），然后重命名作为一个外部的配置导进去，这么做的目的是导入之后可以修改相应的配置，达到自定义配置的目的（因为Eclipse自带的配置是加锁的，不能修改）。导入之后，点击右边的&Configure&进行编辑。&先去掉缺少package-info.java文件的提示：&
再将第一句注释要以&.&结尾这个规则去掉，双击&Style javadoc&，将窗口内&checkFirstSentence&勾选去掉。&
对于实体类，属性有了注释，get set方法也不需要注释了，双击&Method javadoc&将allowMissingPropertyJavadoc勾选中。&
&getId不是继承的方法，必须指定abstract,final或空&，如果你懒得在方法上加&final&，这条规则也可以去掉。&
如果你不想每一个参数都加&final&，还需要把参数的final规则去掉：&
另外还有一个错误&'id' hides a field.&，原因是方法的参数和类里面定义的域重名了，但使用eclipse生成的get set方法都会这样，所以可以忽略此项。&
至此我们再使用checkstyle检查一篇，发现仅剩下属性缺少注释这个警告。&
对每个属性加上java doc注释，所有问题都清除了。以此类推，解决checkstyle问题的方法就是：1、按规则解决代码问题；2、如果觉得这个问题对你的项目质量影响不大，则可以忽略它。&2. 代码重复（PMD的CPD的使用）&对于多人开发的项目，难以避免出现重复代码的问题，尽管我们尽量对共用的代码进行了封装，但随着需求的增加、人员技术水平差异、沟通不足等原因，重复代码会越来越多。这不仅严重影响代码质量，也无形中增加了代码量。&注：精简的程序和高复用度的代码是我们一直追求的目标。&PMD的CPD工具就是为检查重复代码而生的。右键项目---&PMD----&Find Suspect Cut and Paste,执行重复代码检查：&
检查出来的重复代码，可以双击查看。然后根据业务逻辑以及代码特征，决定要不要做封装、怎么封装。&3. 代码覆盖率（Eclemma的使用）&一份质量合格的代码，不仅包含功能程序本身也包含了对应的测试代码，Eclemma插件可以用来统计测试代码覆盖整体代码中的比率，以此来评估代码的功能性和稳定性。&使用Junit编写好测试用例之后，右键Coverage As---&Junit Test，运行测试用例，Eclemma会统计出相关的代码覆盖率：&
根据这个结果，你可以看出自己编写的测试用例覆盖到了那些代码，而没有覆盖到的代码，则有可能成为代码质量的盲区。&4. 依赖项分析（JDepend的使用）&随着程序业务逻辑的增加，代码的依赖关系也变的越来越复杂，JDepend插件可以统计包和类的依赖关系，分析出程序的稳定性、抽象性和是否存在循环依赖的问题。右键包---&Run JDepend Analysis：&
看一下这几项指标：&
CC（Number of Classes)：被分析package的具体和抽象类（和接口）的数量，用于衡量package的可扩展性。如果一个类中实现了其他类，如实现了监听类，则监听类的数目也记录在此。
AC（Abstract classes）：抽象类和接口的数量。
Ca（Afferent Couplings)：依赖于被分析package的其他package的数量，用于衡量pacakge的职责。即有多少包调用了它。
Ce（Efferent Couplings)：被分析package的类所依赖的其他package的数量，用于衡量package的独立性。即它调用了多少其他包。
A（Abstractness)：被分析package中的抽象类和接口与所在package所有类数量的比例，取值范围为0－1。
I（Instability)：I＝Ce/（Ce＋Ca），用于衡量package的不稳定性，取值范围为0－1。I＝0表示最稳定，I＝1表示最不稳定。即如果这个类不调用任何其他包，则它是最稳定的。
D（Distance)：被分析package和理想曲线A＋I＝1的垂直距离，用于衡量package在稳定性和抽象性之间的平衡。理想的package要么完全是抽象类和稳定（x＝0，y＝1），要么完全是具体类和不稳定（x＝1，y＝0）。取值范围为0－1，D＝0表示完全符合理想标准，D＝1表示package最大程度地偏离了理想标准。即你的包要么全是接口，不调用任何其他包（完全是抽象类和稳定），要么是具体类，不被任何其他包调用。
Cycle：循环依赖的数量。
有个这个报告我们就可以有针对性的对代码进行设计和重构。&5. 复杂度分析（Metrics的使用）&对于阅读代码的人来说，越简单的代码越好理解和维护，如果你的代码阅读起来很费劲或者你自己过段时间后再来看都看不懂，你就得想办法解决下代码的复杂度问题了。Metrics插件可以帮你做到这点。&首先在Java透视图下右键一个项目----&Properties，选择Metrics，勾选Enble Metrics。&
然后Window---&Show View----&Other----&Metrics View&
打开Metrics视图，点击右上角运行图标，即可得到复杂度分析的结果：&
可以根据复杂度指标，对自己的程序进行优化。&小结&本文介绍了和java代码质量相关的5个方面问题，并介绍对应eclipse插件的用法和作用。在我们实际开发中，尽量根据自己公司和团队的情况来制定一些检查规则，来提高代码质量。并且在大多数情况下，会有两个检查环节，即本地检查和持续集成环境的检查，我们常用的Hudson就可以集成很多插件。&