是否存在嵌入太多 if 语句的情况?
目前我正在编写一些代码(我相信)需要相当多的嵌入式 if 语句。嵌入多少 if 语句是否有一些标准?我的大部分谷歌搜索都发现了与 Excel 相关的内容……不知道为什么。
如果有标准,为什么?是为了可读性还是为了让代码运行更流畅?在我看来,主要是为了可读性是有道理的。
我的 if 结构的一个例子:
if (!all_fields_are_empty):
if (id_search() && validId()):
// do stuff
else if (name_search):
if (name_exists):
if (match < 1):
// do stuff
else:
// do stuff
else if (name_search_type_2):
if (exists):
if (match < 1):
// do stuff
else:
// do stuff
else:
// you're stupid
我听说 for/while 循环的嵌套数有 2-3 个限制,但是 if 语句有一些标准吗?
更新: 我现在已经有几年了。请不要使用这么多 if
语句。如果您需要这么多,那么您的设计可能很糟糕。今天,我喜欢找到一种优雅的方式来用最少的 if
语句或 switch
案例来完成这些事情。代码最终变得更干净、更容易测试、更容易维护。通常情况下。
Currently I am working on a bit of code which (I believe) requires quite a few embedded if statements. Is there some standard to how many if statements to embed? Most of my googling has turned up things dealing with excel..don't know why.
If there is a standard, why? Is it for readability or is it to keep code running more smoothly? In my mind, it makes sense that it would be mainly for readability.
An example of my if-structure:
if (!all_fields_are_empty):
if (id_search() && validId()):
// do stuff
else if (name_search):
if (name_exists):
if (match < 1):
// do stuff
else:
// do stuff
else if (name_search_type_2):
if (exists):
if (match < 1):
// do stuff
else:
// do stuff
else:
// you're stupid
I have heard that there's a limit to 2-3 nested for/while loops, but is there some standard for if-statements?
Update:
I have some years under my belt now. Please don't use this many if
statements. If you need this many, your design is probably bad. Today, I LOVE when I can find an elegant way to do these things with minimal if
statements or switch
cases. The code ends up cleaner, easier to test, and easier to maintain. Normally.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
正如兰迪提到的,这种代码的原因在大多数情况下是应用程序的设计不佳。通常我会尝试在您的情况下使用“处理器”类。
例如,假设有一些名为“操作”的通用参数以及具有不同参数的 30 个不同操作,您可以创建一个接口:
然后为您需要的每个操作实现大量处理器,例如:
下一步 - 注册所有处理器当应用程序初始化时在某个数组中:
所以你的主要方法变成这样:
当然,这只是一个例子,你的项目需要一些不同的方法,但我想它可能与我所描述的类似。
As Randy mentioned, the cause of this kind of code is in most cases a poor design of an application. Usually I try to use "processor" classes in your case.
For example, given that there is some generic parameter named "operation" and 30 different operations with different parameters, you could make an interface:
Then implement lots of processors for each operation you need, for example:
Next step - you register all your processors in some array when application is initialized:
So your main method becomes something like this:
Sure, this is just an example, and your project would require a bit different approach, but I guess it could be similiar to what I described.
我认为没有限制,但我不建议嵌入更多这两个 - 它太难阅读,难以调试并且难以进行单元测试。考虑看几本很棒的书,比如重构、设计模式,也许干净的代码
I don't think there is a limit but i wouldn't recommend embeddeding more the two - it's too hard to read, difficult to debug and hard to unit test. Consider taking a look at a couple great books like Refactoring, Design Patterns, and maybe Clean Code
从技术上讲,我不知道嵌套有任何限制。
如果你发现自己走得很深,这可能表明设计很糟糕。
您发布的一些内容看起来可能更适合用作
case
语句。我会关心下一个人的可读性和代码维护,这实际上意味着即使对于第一个人(你)来说,一开始就很难把事情做好。
编辑:
您还可以考虑拥有一个类似
SearchableObject()
的类。您可以创建一个具有通用功能的基类,然后继承 ID、名称等,并且这个顶级控制块将大大简化。Technically, I am not aware of any limitation to nesting.
It might be an indicator of poor design if you find yourself going very deep.
Some of what you posted looks like it may be better served as a
case
statement.I would be concerned with readability, and code maintenance for the next person which really means it will be difficult - even for the first person (you) - to get it all right in the first place.
edit:
You may also consider having a class that is something like
SearchableObject()
. You could make a base class of this with common functionality, then inherit for ID, Name, etc, and this top level control block would be drastically simplified.Tl;Dr 通过任何一种方法,您实际上并不需要超过 10-15 条路径,
您在这里实质上指的是 环复杂度。
因此,每个 if 语句都可能成为代码中的一条新路径,并增加其循环复杂性。有一些工具可以为您测量这一点,并突出显示高复杂性的区域以进行潜在的重构。
是的,也不是。人们普遍认为(McCabe 本人也认为)超过 10 或 15 的循环复杂度就太高了,这表明代码应该重构。
但这并不是一个真正的硬性规则,在某些情况下可以忽略。请参阅这个问题 您维护的任何函数的最高循环复杂度是多少?您将如何进行重构是吗?。
本质上这是为了可读性,这应该使您的代码顺利运行。引用马丁·福勒
Tl;Dr You don't really want anymore than 10-15 paths though any one method
What your essentially referring to here is Cyclomatic complexity.
So every if statement is potentially a new path though your code and increases it's Cyclomatic complexity. There are tools that will measure this for you and high light areas of high complexity for potential refactoring.
Yes and no. It's generally regarded (and McCabe himself argued) that a Cyclomatic complexity of over about 10 or 15 is too high and a sign that the code should be refactored.
This isn't really a hard rule though and can be disregarded in some circumstances. See this question What is the highest Cyclomatic Complexity of any function you maintain? And how would you go about refactoring it?.
Essentially this is for readability, which should make your code run smoothly. To quote Martin Fowler
从技术上讲,您可以拥有任意数量的数量,但如果数量太多,很快就会使代码变得不可读。
我通常会做这样的事情:
我相信你明白了
Technically you can have as many as you like but if you have a lot it can quickly make the code unreadable.
What i'd normally do is something like:
I'm sure you get the picture
Java 中嵌套 if/else 块数量的唯一技术限制可能是堆栈的大小。风格是另一回事。
顺便说一句:冒号是怎么回事?
The only technical limit to the number of nested if/else blocks in Java will probably be the size of your stack. Style is another matter.
Btw: What's with the colons?