美化java代码,从合理注释开始

　　

"干净的代码应该像写好的散文一样”——罗伯特·c·马丁

　　 　　

不良代码的通病就是有很多注释。这是凌乱的源代码最明显的迹象。

　　

每个程序员的目标应该是编写干净和富有表现力的代码,以避免代码注释。每个变量,函数和类的目的应该隐含在其名称和结构中。

　　

当其他人读取您的代码时,他们不应该阅读注释以了解你的代码正在做什么。命名良好的类和函数应该引导读者通过你的代码,就像一本写得很好的小说一样。当读者看到一个新的类或功能时,他们不应该对他们在里面看到的东西感到困惑难以理解。

　　

请记住,开发人员的工作时间很少花在编写代码上,花在阅读代码和理解代码上的时间要多得多。

　　

　　

　　

在代码中命名是非常重要的。您应该花费大量精力准确而精确地命名每一段代码,以便其他开发人员能够理解您的代码。

　　 　　//按状态查找员工 　　List找到(状态状态){ 　　… 　　} 　　 　　

在此示例中,名称找到不够描述,因此此函数的作者需要留下描述函数功能的描述性注释。当我们看到从另一个模块调用的发现函数时,它的作用是一个谜。它发现了什么呢?究竟是什么意思?它返回了它发现的东西吗?怎么找到它发现的东西?就像鲍勃叔叔在他的书《干净代码》中所说,如果你需要写注释,你就无法通过代码表达自己真实的用意。

　　

我们不希望检查每个函数上面的注释,以了解它的作用。

　　 　　 　　ListgetEmployeesByStatus(状态状态){ 　　… 　　} 　　 　　

现在很明显能看出来这个函数的具体作用,这使得注释变得多余。这让我想到了注释糟糕的下一个方式。

　　

　　

这些混乱了你的代码,完全没必要。

　　 　　//此函数发送电子邮件 　　空白sendEmail () { 　　… 　　}//此函数发送电子邮件 　　公共类员工{ 　　… 　　}/* * 　　* @param CD的标题标题 　　* @param作者CD的作者 　　* @param跟踪CD上的曲目数 　　*/公共空间addCd(琴弦标题,作者,int) { 　　… 　　} 　　 　　

多数情况是强制冗余。很多公司在每个功能和类别上都要求这一点。如果你的上司要求这样做,请他们不要。

　　

　　

　　

如果您有一个很长的功能或需要记录代码的哪一部分做了什么,那么您可能违反了这些规则:

　　

1。功能应该做一件事。
　　

　　

2。功能应该很小。
　　

　　

这是一个例子

　　 　　//此函数计算价格,与销售额进行比较//促销,检查价格是否有效,然后//向用户发送促销电子邮件 　　公共空间dosomething () {//计算价格 　　… 　　… 　　…//将计算出的价格与促销活动进 　　… 　　… 　　…//检查计算的价格是否有效 　　… 　　… 　　…//向用户发送促销信息 　　… 　　… 　　… 　　} 　　 　　

当你成功地将逻辑的每个部分封装到一个单独的函数中时,代码不需要注释就会表现的应该像它的作用描述一样。

　　

重构如下:

　　 　　 　　公共空间sendPromotionEmailToUsers () { 　　calculatePrices (); 　　compareCalculatedPricesWithSalesPromotions (); 　　checkIfCalculatedPricesAreValid (); 　　sendPromotionEmail (); 　　} 　　 　　

而不是注释代码的每个部分,每个逻辑块应该很好地封装在它自己的函数中。

　　

首先,这提高了<强>可读性强。每个代码块不必逐行读取。我们可以简单地读取辅助函数名称并理解它的作用。如果我们想要了解每个函数内部的更多细节,就能去看具体实现。

　　

其次,它提高了<>强可测试性强。在上面的示例中,我们可以为每个函数单独进行单元测试。如果不封装这些单独的函数,则很难测试较大函数sendPromotionEmailToUsers()的每个部分。执行多个功能的功能很难测试。

　　

最后,它提高了<强>可重构性强。通过将逻辑的每个部分封装到自己的函数中,将来更改维护更容易,并且单独功能的函数会被隔离以仅更改该函数的行为。当我们使用局部变量的长函数在整个函数中持续存在时,由于函数的紧耦合,很难在不导致其他地方变化的情况下重构函数。

　　

　　

美化java代码,从合理注释开始