论文网
注释相关论文范文例文,与代码整洁与代码质量相关毕业论文怎么写
本论文是一篇注释相关毕业论文怎么写,关于代码整洁与代码质量相关毕业论文的格式范文。免费优秀的关于注释及代码及函数方面论文范文资料,适合注释论文写作的大学硕士及本科毕业论文开题报告范文和学术职称论文参考文献下载。
40;,他是平台内部的.首先期望观察的结构是整体组织架构,因此站在这个视角层级来看,平台、产品、测试这些都是一个整体.然后分别站在平台、产品、测试再往下看.推荐使用层次的do来表达函数要做的事,这样,可以有效避免函数中不同的抽象层级混杂.不管怎样,函数只做一件事情是最重要的实践,需要好好理解.2.3每个函数一个抽象层级
函数中混杂不同的抽象层级,往往让人迷惑,读者无法判断哪些是基础概念哪些是细节.读者无法提纲挈领的代价是：它无法快速学习、快速理解,从而为更多的bug埋下隐患.
2.4使用描述性名称
如：testtableHtml?SetupTeardownIncluder.render.
如果长一点的名称可以更加清晰,不要犹豫,用清晰的吧.
2.5函数参数
最好是0,其次是1个,再次是2个,避免3个及以上的参数个数.参数过多会使得客户程序员上手的代价加大,优秀代码的可能性降低.
参数与函数名位于不同的抽象层级,它要求必须了解目前并不特别重要的细节.
输出参数比输入参数更加难以理解.一般只有在特定的情况下才使用输出参数.比如C#中Int.TryParse（）,为了避免使用无必要的异常表达错误,提供了输出参数.
该文出处:http://www.sxsky.net/benkelunwen/060208067.html
这里的标志参数指的是通过特定的参数来控制函数的行为,比如Log（xxxxx,true）.这里true/false控制函数是否记录日志.标识参数明显违背了函数只做一件事的原则.
另外,标识参数有一些变体,比如传输一个整型值,根据具体值来做判断到底该做何事.
二元参数比一元参数更难理解,如assertEquals（excepted,acutal）,经常会把参数的位置搞反.有2个参数读者和客户就要考虑顺序问题,如果命名又不佳的话,就会经常弄错.
三元参数比二元更加难懂.如果参数看起来需要两个、3个或者3个以上参数就说明一些参数应该封装为类.至少达到3个就要认真考虑是否应该合并参数,是否过于陷入细节了.
2.6抽离Try/Catch代码
将try/catch代码隔离出来,避免影响主程序逻辑,例：
Try{
DeletePage（page）；//DeletePage是一个方法
}
Catch（Exceptione）{
LogError（e）；//LogError是一个方法
}
错误处理就是一件事.try/catch总是单独出现的,里面最好不要包含普通语句,如上例.
| 有关论文范文主题研究: | 关于注释的论文范文检索 | 大学生适用: | 硕士毕业论文、函授毕业论文 |
|---|---|---|---|
| 相关参考文献下载数量: | 19 | 写作解决问题: | 本科论文怎么写 |
| 毕业论文开题报告: | 论文提纲、论文结论 | 职称论文适用: | 论文发表、职称评中级 |
| 所属大学生专业类别: | 本科论文怎么写 | 论文题目推荐度: | 最新题目 |
3注释
3.1核心观念
注释的恰当用法是弥补在用代码表达意图时遭遇的失败.注释会撒谎,这个比较令人费解,但是它真实地存在于我们的系统中,并且是大量存在.原因很简单,程序员不能坚持维持注释,程序存在的时间越久,注释的可信度、可读程序就很低.程序员虽然有保持注释精读的责任,但是更应该做的是整理代码,减少注释,注释过多往往是一种程序“腐化的坏味道”.
3.2好的注释
不可省略地涉及到法律的信息,比如开源协议.提供信息的注释应该是用好名称不易传达的补救措施.
例：
//returnsaninstanceoftheresponderbeingtested.
ProtectedabstractResponderresponderInstance（）；
不如：
ProtectedabstractResponderresponderBeingTested；
如果找不到responderBeingTested这样的好名字,则用注释提供信息是好的做法.但是应该首先尽力去想一个可以表达意图的有意义的名字.
对意图进行解释.对某些可以选择的实现决定进行解释.
将一些晦涩难懂的参数或者返回值的意义编译为更加可读的形式.
警示.这里指的是一些特定行为的代码注释.比如某个测试可能会运行很长时间之类的注释.
TODO注释.未完成的列表.完成后要删除掉.
3.3坏的注释（1）喃喃自语.这种情况大量存在,属于程序员的自言自语,基本是垃圾代码的借口或者错误决策的修正.
（2）多余的注释.大量存在没有什么意义的废话注释.
（3）误导性注释.不够精确或者干脆写错了.
（4）循规式注释.指的是应文档化工具的需求就添加的本来不需要注释的注释.
（5）日志式注释.指的是本代码文件的修改历史类,将每天的修改记录写上,这完全没有必要,可以被现代源码管理工具取代,它影响了代码阅读.
（6）废话注释.
（7）可怕的废话注释.
（8）能用函数或者变量的时候就不用注释.
（9）位域标记.这类注释用于标记一个特别的位置.这种用法应该在特定的情况下使用,
注释相关论文范文例文
（10）括号后的注释.这里指的是代码太长了,在}后添加注释表示×××代码段结束.这类注释一般是程序需要整理的标志.
（11）归属于署名.现在源码管理可以取代,基本不需要了.
（12）注释掉的代码.
（13）HTML注释.
（14）非本地信息.
（15）信息过多.
（16）不明显的联系.
4格式
对格式的研究也是非常严谨的.以多个著名优秀开源项目的实际代码格式分析来研究,诸如一行应该多少个字符,应该空几个这样的看似细小的问题.其中对“顺序”、“缩进”的处理、这些处理对读者理解之间的影响研究等.通过对类的成员：共有、私有成员变量、方法进程“顺序排列”,通过“缩进”或者“不缩进”,表达语义远近的研究,还是非常有借鉴意义的.
5类
对于函数,通过计算代码行数衡量大小.对于类,我们采用不同的衡量方式计算权责.权责同职责：
①类应该符合单一权责原则；②类应该内聚；③保持内聚会得到需要短小的类.
关于类的组织这个话题比较大,比较原则性,要注意理解不同设计原则之间的因果依赖关系.
参考文献：
[1]ROBERTC.MARTIN.Cleancode[M].北京：电子工业出版社,2012.
责任编辑（责任编辑：杜能钢）
注释相关论文范文例文,与代码整洁与代码质量相关毕业论文怎么写参考文献资料：