何时将代码拆分为函数的黄金法则是什么？

Question

将代码分解为模块化/解耦的函数和类是很好的，但是如果你做得太多，你会得到非常碎片的代码，这也是不好的。

何时将代码拆分为函数的黄金法则是什么？

Answer 1

这确实取决于项目的规模和范围。

我倾向于将事物分成函数每次有重复的事情，并且重复概括/抽象，遵循DRY的黄金法则（不要重复自己< /强>）。

就分割类而言，我倾向于遵循面向对象编程的口号，即将不同的东西隔离开来，如果一个类实现更多的一个大的理论“想法”或实体，则拆分类。

但老实说，如果您的代码过于分散且不透明，那么您应该尝试将重构视为不同的方法/范例。

Answer 2

如果我能给它一个好名字（比它取代的代码更好），它就变成了一个函数

Answer 3

可能我自己的个人规则是，如果它超过2行，并且在同一页面（ASP.net）上被引用不止一次，或者在几页上分布几次，那么我会写一个这样做的功能。

Answer 4

我认为你通常不得不考虑一大堆代码有可能被重用。它有经验可以解决这个问题并提前计划。

Answer 5

我同意专注于可重用性和消除重复的答案，但我也相信可读​​性至少同样重要。所以除了重复之外，我还会寻找不止一件事的代码片段（类，函数，块等）。

如果与代码关联的名称没有描述它的作用，那么现在是将该代码重构为每个都具有single responsibility和描述性名称的单元的好时机。这个separation of concerns将有助于可重用性和可读性。

有用的代码可以长时间存在，因此您（或理想情况下其他人）可以返回并轻松理解几个月或几年前编写的代码非常重要。

Answer 6

我被告知，你不止一次做的任何事都应该是一种功能。任何类似的东西都应该有一个父类，最重要的是咨询你组织内的源代码“标准”。后者主要处理格式化。