功能多与少

发布于 08-07 21:24 字数 133 浏览 4 评论 0原文

我有一点争论,想知道人们的想法:

在 C++(或一般情况下)中,您是否更喜欢将代码分解为许多较短的函数,其中 main() 仅包含按逻辑顺序的函数列表,还是您更喜欢仅在必要时使用函数(即,当它们会被重用很多次时)?或者也许介于两者之间?

I had a little argument, and was wondering what people out there think:

In C++ (or in general), do you prefer code broken up into many shorter functions, with main() consisting of just a list of functions, in a logical order, or do you prefer functions only when necessary (i.e., when they will be reused very many times)? Or perhaps something in between?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

乙白2024-08-14 21:24:25

小功能,请

传统观点认为功能越小越好,我认为这是事实。事实上,有一家公司拥有一种分析工具,可以通过与单元测试数量相比做出的决策数量来对各个功能进行评级。

理论上,您可能无法降低整个应用程序的复杂性,但您可以完全控制任何给定函数的复杂性。

一种名为圈复杂度的测量被认为与不良代码呈正相关...具体来说,通过一个方法的路径越多,它的 CCN 编号就越高,它写得越差,就越难理解,因此越难改变,甚至越难开始,单元测试就越多会需要。

好的,找到工具了。它被称为,嗯,Change R风险分析和P预测指数。

最近,“信息只编码一次”的原则出现了新的缩写词,特别是 DRY (不要重复自己)和DIE(重复是邪恶的) ...
我相信我们可以部分感谢 RoR 社区推广这一理念......

Small functions, please

It is the conventional wisdom that smaller functions are better, and I think it's true. In fact, there is a company with an analysis tool that rates individual functions by how many decisions they make compared to the number of unit tests that they have.

The theory is that you may or may not be able to reduce complexity in an entire application, but you have complete control over how much complexity is in any given function.

A measurement called cyclomatic complexity is thought to correlate positively with bad code...specifically, the more paths there are through a method the higher its CCN number is, the more poorly it is written, the harder it is to understand and hence change or even get right to start with, and the more unit tests it will need.

Ok, found the tool. It is called, ahem, the Change Risk Analysis and Predictions index.

Lately, the principle of encoding information only once has grown new acronyms, specifically DRY (Don't Repeat Yourself) and DIE (Duplication is Evil) ...
I believe we can in part thank the RoR community for promoting this philosophy...

数理化全能战士2024-08-14 21:24:25

拆分功能,但绝不拆分功能。

功能可以分为多个层,然后每个层可以拆分为不同的功能。例如,当我们处理正弦序列时,求和和减法的主循环应该在主要功能。这可以被认为是第 1 层。现在,用于查找功率的功能可以被分类到第 2 层。这可以被实现为子功能。同样求阶乘也属于第 2 层,这将是另一个子函数。始终考虑功能,而不是计算行数。行数可能从 3 到 300 不等,没关系。这将为我们的代码增加更多的可读性和可维护性。这就是我关于分裂的想法。

Split the functions, but never split functionality.

Functionality may be classified into layers, then each layer may split into different functions. For example, when we are processing a sine series, the main loop for summing and subtracting should be in primary function. This may consider as layer 1. Now the functionality for finding power may classified in to layer 2. This can be implemented as a sub function. Similarly finding factorial also belongs to layer 2 which would be another sub function. Always consider functionality, never count number of lines. Number of lines may vary from 3 to 300, doesn't matter. This will add more readability and maintainability to our code. This is my idea about splitting.

初见2024-08-14 21:24:25

我认为唯一的答案是介于两者之间。如果你尽可能地分解函数,它就会变得不可读。同样,如果你们不分手,它也会变得难以理解。

我喜欢将函数按照语义差异进行分组。它是某种计算的一个逻辑单元。保持单元小,但足够大以实际做一些有用的事情。

I think the only answer is something in between. If you break up functions every time possible, it becomes unreadable. Likewise, if you never break up, it also becomes unreadable.

I like to group functions into semantic differences. It is one logical unit for some calculation. Keep the units small, but big enough to actually do something useful.

小草泠泠2024-08-14 21:24:25

我最喜欢的函数粒度经验法则是“每行不超过 24 行,每行 < 80 个字符”——这不仅仅是因为 80 x 24 终端“在我刚开始的时候”风靡一时;我认为这是一个合理的函数指南,你可以“一目了然地掌握”,至少在 C 或比 C 丰富不了多少的语言中。“一个函数只做一件事”,又名“一个函数有一个函数”(在“功能”的含义是“角色”或“目的”!-) 是我在“太多功能”可以轻松打包在 24 行的语言中使用的次要规则。但“词汇满眼”准则——24 x 80——仍然是我的主要准则。

My favorite granularity rule of thumb for a function is "no more than 24 lines of < 80 characters each" -- and that's not just because 80 x 24 terminals were all the rage "back when I started"; I think it's a reasonable guideline for functions you can "grasp as one eyeful", at least in C or languages not much richer than C. "A function does only one thing", AKA "a function has one function" (playing on the meaning of "function" as "role" or "purpose"!-) is a secondary rule I use in languages where "too much functionality" can easily be packed in 24 lines. But the "lexical eyeful" guideline -- 24 x 80 -- is still my main one.

谎言2024-08-14 21:24:25

小功能好,越小越好。

大约五到八行代码是我对函数大小的上限。除此之外,它太复杂了。您应该能够:

  1. 假设被调用者执行其名称所指示的操作,
  2. 在几秒钟内阅读函数的定义, 并
  3. 快速说服自己第一个假设意味着当前函数是正确的。

另一件事是,您应该在编写函数代码之前使用它们。当您了解打算如何使用该函数时,您将了解该函数必须遵守哪些前置条件和后置条件。

任何乍一看不明显正确的内容都应该在实时评论中被证明是正确的。如果这很困难,请将子功能排除在外。

Small functions are good and smaller ones are better.

About five to eight lines of code is my upper limit on function size. Beyond that, and it's too complicated. You should be able to:

  1. Assume that a callee does what its name would indicate,
  2. Read a function's definition in a matter of seconds, and
  3. Convince yourself quickly that the first assumption implies that the present function is correct.

The other thing is that you should use your functions BEFORE you write their code. When you see how you intend to use the function, then you'll see what pre- and post-conditions said functions must respect.

Anything that isn't obviously correct at first glance should be proven correct in the running commentary. If that's difficult, factor sub-functions out.

放手`2024-08-14 21:24:25

我相信,任何有助于代码重用和可读性的方法都是最好的。

仅仅为了完成这一任务而创建大量的一行函数并不能提高可读性,因此应该将它们分组到有意义的类中,然后拆分函数,以便您可以快速理解该函数中发生的情况。

如果你必须跳过去才能理解发生了什么,那么你的设计就有缺陷。

Whatever helps with code reuse and readability works best, I believe.

Making lots of one line functions just to do it doesn't help with readability so they should be grouped in classes that makes sense, and then split up the functions so that you can understand quickly what is going on in that function.

If you have to jump all over to understand what is going on then your design is flawed.

唐婉2024-08-14 21:24:25

我更喜欢适合一屏代码的函数(或方法),因此我可以一目了然地看到我需要引用的任何内容以了解该函数的工作原理。我的编辑器窗口中通常有大约 50 行空间,通常也有 80 列,因此我可以在监视器上并排放置两行,并在两段代码之间交叉引用。

因此,我通常认为 50 行左右是最大值。我唯一会考虑允许更多的是当你有一个大的长初始化函数或完全线性的函数(没有变量、条件或循环)时,因为这不是你需要那么多上下文的东西,而且有些 API 需要整个一堆初始化来启动和运行,并将其分成更小的函数并没有多大帮助。

不过,总的来说,漂亮、小、易于理解、只做一件事并且命名良好的函数比那些长达数百行、需要跟踪数十个变量、缩进深度达 10 级的庞然大物要好得多。

I prefer functions (or methods) which fit within one screenful of code, so I can see at a glance anything I need to reference to understand how that function works. I generally have about 50 lines of space in my editor windows, which are also generally at 80 columns so I can fit two side by side on a monitor and cross reference between two pieces of code.

So, I generally consider 50 lines to be about the maximum. The only time I would consider allowing more is when you have one big long initialization function or something that is completely linear (no variables, conditionals, or loops), since that's not something where you need all that much context and some APIs require a whole bunch of initialization to get up and running, and splitting it into smaller functions wouldn't really help much.

On the whole, though, nice, small, easy to understand functions that do one thing and are well named are vastly preferable to big sprawling monstrosities that are hundreds of lines long and dozens of variables to keep track of with indentation going 10 levels deep.

缱倦旧时光2024-08-14 21:24:25

另一个简单的原因是:当一段代码被重用一次或两次以上时,应该创建一个函数。对于非常小的代码(例如一两个语句),宏通常可以缓解问题。

Another simple reason: A function should be made when a block of code is being reused more than once or twice. For very small bits of code (say one or two statements), macros often alleviate the problem.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文