讨论：功能分解？ [英] DISCUSSION: Functional Decomposition?
问题描述
嗨。
我刚看了一下一直使用Maven的J2EE项目。所有的
方式！
因此，默认情况下，某种类型的代码检查器会为方法提供一个红色标记
超过45行（还有任何超过80的字符串
字符）。
在线程中忙于发布代码应该是一个序列
或一个班轮（regexp vs. / if / for / orelse）这个问题在我脑海中浮现。
为什么程序员会分解很长的方法，这是一个巨大的序列进入
序列然后调用几个微小的私有方法？这是一个很好的
的事情吗？为什么？
Maven已经决定了一个很长的方法就是The Bad Thing。
我认为Maven认为这是理所当然的。我也认为这是一个非常愚蠢的假设。还有一个愚蠢的价值。
为什么有45行？如果有限制请求，为什么20或115行不会这样做？b / b
他们问过维护者他们喜欢读什么并且修改了吗？
我花了几美元才能花在这上面，但是为什么这只是愚蠢的只是开了2
美分。
有人想打个电话吗？或者加薪？
快乐编码？
- Michael S
Hi.
I just had a look at a J2EE-project that uses Maven all the way. All the
way!
Hence, by default, some kinda code-checker gives a red flag for a method
being longer than 45 lines (and also for any line longer than 80
characters).
While being busy posting in threads regarding if code should be a sequence
or a one liner (regexp vs. for/if/for/orelse) this matter came to my mind.
Why do programmers break up long methods that is a huge sequence into
several tiny private methods that the sequence then calls? Is this a good
thing? Why?
Maven have already decided that a long methods is The Bad Thing.
I think Maven takes that for granted. I also think it is a really dumb
assumption. And a dumb value.
Why 45 lines? If there is call for a limit, why wouldn''t 20 or 115 lines do
the trick?
Have they asked maintainers what they like to read and modify?
I have a couple of mind-dollars to spend on this, but just did open with 2
cents on why this is just dumb.
Anyone wanna call? Or raise?
Happy Coding?
- Michael S
推荐答案
迈克尔，
Hi Michael,
因此，默认情况下，某种类型的代码检查器会为方法长度超过45行（以及任何长于80行的行）提供红色标记为什么程序员会分解很长的方法，这些方法是一个巨大的序列进入序列然后调用的几个微小的私有方法？这是一件好事吗？为什么？
Hence, by default, some kinda code-checker gives a red flag for a method
being longer than 45 lines (and also for any line longer than 80 characters).
Why do programmers break up long methods that is a huge sequence into
several tiny private methods that the sequence then calls? Is this a good
thing? Why?
这里有一些（肯定不完整）理由来自我方：
- 一个人只能抓到一个特殊的信息量
一次。此外，方法代码符合人们习以为常的纸张格式。
- 它会自动记录您的代码，因为您必须找到
a）这个方法的好名字
b）一个很好的调用点（使结构更加obvoius）
c）自动创建一个概述，因为方法视图中的
，你会看到不同的里程碑
的方法实现。
d）Auto- XML-Commenter现在可以轻松解析代码并创建更好的有意义的类 -
视图和文档。
- 因为现代IDE的智能感知这个
变得更有意义。您只需按
键即可切换到该功能。你有
方法的摘要标签描述。所以你只需要查看方法的基本信息。
有时很长的方法都可以。但我建议
不要超过45左右。
这是我14年的个人建议/经验
软件开发。
ciao Frank
-
Dipl.Inf。 Frank Dzaebel [MCP / MVP C＃]
http://Dzaebel.NET
我已经尝试了两种方法 - 长方法和许多更短的方法。
更短的方法获胜因为：
1.代码更易于阅读和理解。而不是100行
功能，你有5个较小的20行功能，由5行
功能驱动。这个五行函数作为代码的其余部分的索引。当有一个名为CalculateSalesTax（）的函数时，找到计算销售税的代码很容易
。
2.大功能几乎是永远不会重复使用。小功能通常是b $ b。所以这些小功能中的一些在其他地方会变得有用。根据我的经验，他们中的很多人都是。因此，除了
三个100行功能外，最终还是有8个20行功能和
两个5行驱动功能。
I''ve tried it both ways -- long methods, and many shorter methods.
Shorter methods win because:
1. The code is easier to read and understand. Instead of a 100-line
function, you have five smaller 20-line functions driven by a 5-line
function. That five-line function acts as the index for the rest of
the code. It''s a lot easier to find the code that calculates sales tax
when there is a function named CalculateSalesTax().
2. Large functions are almost never reusable. Small functions often
are. So some of those little functions will turn out to be useful in
other places. In my experience, a lot of them are. So instead of
three 100-line functions, you end up with eight 20-line functions and
two 5-line driver functions.
Michael，
使用多行代码可以将可量化的值放在
上这很难量化。这背后的想法是保持你的功能很小，并弥补较小的
功能调用。这有助于代码的可维护性，因为操作
被更好地封装，使您可以更轻松地修复和更改
，而无需更改一大块代码。
希望这会有所帮助。
-
- Nicholas Paldino [.NET / C＃MVP]
- mv*@spam.guard.caspershouse.com
"迈克尔S" < a@b.c>在消息中写道
新闻：OG ************** @ TK2MSFTNGP09.phx.gbl ...
Michael,
The use of a number of lines is a way to place a quantifiable value on
something that is difficult to quantify. The idea behind this is to keep
your functions small, and make up the larger operations of calls to smaller
functions. This lends to the maintainability of the code, since operations
are encapsulated better, allowing you to make fixes and changes easier
without having to alter one big large blob of code.
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Michael S" <a@b.c> wrote in message
news:OG**************@TK2MSFTNGP09.phx.gbl...
嗨。
我刚看了一个一直使用Maven的J2EE项目。所有的方式！
因此，默认情况下，某种类型的代码检查器会为一个方法提供一个红色标记，其长度超过45行（对于任何超过80行的行也是如此） >字符）。
虽然忙于在线程中发布关于代码应该是序列
还是单行（regexp vs. for / if / for / orelse）这个问题来到我的大脑。
为什么程序员会分解很长的方法，这些方法是序列随后调用的几个微小的私有方法的一个巨大的序列？这是一件好事吗？为什么？
Maven已经决定了一个很长的方法就是The Bad Thing。
我认为Maven认为这是理所当然的。我也认为这是一个非常愚蠢的假设。还有一个愚蠢的价值。
为什么有45行？如果有限制请求，为什么不会有20或115行呢？
他们是否向维护人员询问他们喜欢阅读和修改的内容？
<我有几个心灵花钱在这上面，但只是开了2美分为什么这只是愚蠢。
任何人都想打电话？或者加注？
快乐编码？
- Michael S
Hi.
I just had a look at a J2EE-project that uses Maven all the way. All the
way!
Hence, by default, some kinda code-checker gives a red flag for a method
being longer than 45 lines (and also for any line longer than 80
characters).
While being busy posting in threads regarding if code should be a sequence
or a one liner (regexp vs. for/if/for/orelse) this matter came to my mind.
Why do programmers break up long methods that is a huge sequence into
several tiny private methods that the sequence then calls? Is this a good
thing? Why?
Maven have already decided that a long methods is The Bad Thing.
I think Maven takes that for granted. I also think it is a really dumb
assumption. And a dumb value.
Why 45 lines? If there is call for a limit, why wouldn''t 20 or 115 lines
do the trick?
Have they asked maintainers what they like to read and modify?
I have a couple of mind-dollars to spend on this, but just did open with 2
cents on why this is just dumb.
Anyone wanna call? Or raise?
Happy Coding?
- Michael S
这篇关于讨论：功能分解？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
