这不是关于代码行.正如Steve Mcconnell和Bob Martin所说(关于编码最佳实践的两个非常好的参考资料),一种方法应该只做一件事而且只做一件事.然而,做一件事需要多行代码就是它应该有多少行.如果"一件事"可以分解成更小的东西,那么每个东西都应该有一个方法.
好的线索你的方法做了不止一件事:
方法中多个级别的缩进(表示太多逻辑分支只能做一件事)
"Paragraph Breaks" - 逻辑代码组之间的空格表示该方法不止一件事
仅举几个.鲍勃马丁也说保持在10左右.就我个人而言,我通常会尝试射击10.如果它开始接近20,这是一个精神上的旗帜,要密切关注这种方法.但最终,LoC对于几乎任何事情来说都是一个糟糕的指标.它只是一个有用的指标,可能潜在地指出真正的问题.
这不是关于代码行.正如Steve Mcconnell和Bob Martin所说(关于编码最佳实践的两个非常好的参考资料),一种方法应该只做一件事而且只做一件事.然而,做一件事需要多行代码就是它应该有多少行.如果"一件事"可以分解成更小的东西,那么每个东西都应该有一个方法.
好的线索你的方法做了不止一件事:
方法中多个级别的缩进(表示太多逻辑分支只能做一件事)
"Paragraph Breaks" - 逻辑代码组之间的空格表示该方法不止一件事
仅举几个.鲍勃马丁也说保持在10左右.就我个人而言,我通常会尝试射击10.如果它开始接近20,这是一个精神上的旗帜,要密切关注这种方法.但最终,LoC对于几乎任何事情来说都是一个糟糕的指标.它只是一个有用的指标,可能潜在地指出真正的问题.
没有具体的数字.
如果您必须向律师或其他人证明某些数字,请找出适合您商店典型开发编辑窗口的最大行数,并使用它.
你甚至不应该这样看待它,但任何一个函数都不应该有任何复杂的事情发生.
应将每个工作单元委托给自己的单元可测试的描述性命名方法. 做到这一点,你所有的方法都是微小的,可读的,没有计算线......
我看到的最大的攻击者是在if语句中间爆炸的3-4 +布尔条件.用一个好名字将所有内容包装在一个布尔值中,然后将构成它们的任何部分包装起来都是复杂的.
首先,请注意长度限制完全独立于通常的度量标准,即"函数只做一件事,做得好吗？" 如果该问题的答案不是肯定的,那么无论如何,该功能可能都不是好的,无论长度如何.
与最大长度相关,来自Code Complete的引用,通常被认为是关于编码实践主题的最佳书籍之一:
有时,复杂的算法会导致更长的例行程序,在这种情况下,应该允许例程有机地增长到100-200行.(一行是一个非注释,非空白的源代码行.)数十年的证据表明,这种长度的例程不会比较短的例程更容易出错.让嵌套深度,变量数量和其他与复杂性相关的考虑因素等问题决定了例程的长度,而不是强加长度限制本身.
如果要编写超过约200行的例程,请小心.没有一项报告显示降低成本,降低错误率,或两者都有较大的例程,区分大于200行,并且当你传递200行代码时,你必然会遇到可理解性的上限.
京公网安备 11010802040832号 | 京ICP备19059560号-6 