blocks|key|540987|text|赞成。如果一个函数有4个或5个嵌套的if/switch/loop/try语句，则应该将其部分提取到各自的函数中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|540988|这将使代码更具可读性，因为提取的函数名称通常比代码本身更具描述性。|540989|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I agree with you. If a function has more than 4 or 5 nested if/switch/loop/try statements, parts of it should be extracted into their own functions. 

This will make the code more readable because the extracted functions' names are usually more descriptive than the code itself.

blocks|key|541074|text|这完全取决于您的代码试图解决的问题。有时您别无选择，只能使用非常深的缩进级别，尽管它肯定是一个code+smell。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|541075|我认为你是对的，在4到5个级别是合理的，更多，你可能应该重构这个方法。|541076|同样值得注意的是，多年来人们一直在尝试量化代码质量和设计指标。其中一个比较常见的指标是cyclomatic+complexity。|541077|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Code_smell|1|http://en.wikipedia.org/wiki/Cyclomatic_complexity^0|1B|A|0|0|0|17|L|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$A|X|B|Y|1|Z]]|C|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]]]

It depends entirely on the problem you code is trying to solve. Sometimes you have no choice but to have quite deep levels of indentation, though it certainly is a <a href="http://en.wikipedia.org/wiki/Code_smell" rel="noreferrer">code smell</a>.

I think you're right in that 4 or 5 levels or so is reasonable, more and you should probably be looking to refactor the method.

It's also worth noting that people have been trying to quantify code quality and design metrics for many years. One of the more common metrics is <a href="http://en.wikipedia.org/wiki/Cyclomatic_complexity" rel="noreferrer">cyclomatic complexity</a>.

blocks|key|541019|text|实际上，对不可读代码影响最大的不是缩进级别的数量，而是您正在查看的模块/函数/方法的长度。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|541020|当然，长段通常具有更多级别的缩进，因为代码块是内联使用的，而不是拆分的，因此两者之间存在关系。就我个人而言，我认为如果一个方法有超过两个屏幕的代码和超过6个级别的缩进，就会有一种味道。|541021|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Actually, it's not the number of indentation levels that most contributes to unreadable code, it's the length of the module/function/method that you're looking at.

Of course, long sections typically have more levels of indentation because blocks of code are used inline rather than broken out so there is a relation between. Personally, I think there's a smell if a method has more than a couple of screenfuls of code and more than 6 levels of indentation.

blocks|key|2451686|text|我认为这可能取决于情况，但通常你会想要更少的嵌套。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2451687|嵌套的循环可能会降低性能，而嵌套的if语句通常可以减少到更少的级别。|2451688|问题是，在开发的早期，您经常会遇到试图优化的问题。我认为，在进行3%2B级别的嵌套之前，您应该始终花一点时间来考虑可能性。|2451689|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I think it can depend on the situation, but generally you'll want less nesting.

Nested loops can kill performance, and nested if statements can ofter be reduced down to less levels.

The problem is that often you run into issues trying to optimize too early in your development. I think that you should always take a little time to consider the possibilities before doing 3+ levels of nesting.

blocks|key|3660254|text|关于缩进，我唯一的烦恼就是使用了两个关键字，其中一个依赖于另一个关键字。例如：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3660255|switch+(c)+{
++++case+'x':
+++++++foo+=+bar;|code-block|syntax|javascript|3660256|这很糟糕，你不能在交换机之外有一个案例，所以：|3660257|switch+(c)+{
case+'x':
++++foo+=+bar;|3660258|。。那就好多了。在if+/+else+if+/+else的开关中，缩进变得很疯狂。我也强烈建议在缩进时保持80+(最多110列限制)。没有人喜欢向右滚动30列来查看您正在做什么，而向后滚动30列来查看您是如何处理结果的:)不要介意在服务器上以愚蠢的80x25控制台模式编辑您的代码的可怜的灵魂。|3660259|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

My only pet peeve regarding indentation is when two keywords are used and one depends on the other. For instance:

<pre><code>switch (c) {
 case 'x':
 foo = bar;
</code></pre>

That is bad, you can't have a case outside of a switch, so:

<pre><code>switch (c) {
case 'x':
 foo = bar;
</code></pre>

.. would be much better. Indentation tends to get crazy in switches with if / else if / else. I also highly recommend keeping an 80 (at most 110 column limit) while indenting. Nobody likes scrolling 30 columns to the right to see what your doing, and 30 columns back to see how you handle the results :) Never mind that poor soul that has to edit your code in dumb 80x25 console mode on a server.

blocks|key|5774272|text|虽然我要说的内容来自于简单的C语言立场，但它也可能适用于C%2B%2B。我喜欢Linux内核的编码风格，即:8个字符宽度的制表符缩进(自然制表符)和80x25终端上适合的任意级别的缩进(即不超过80个字符的宽度)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5774273|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Although what I'm going to say comes from a plain C standpoint, it might apply to C++ as well. I favor the Linux kernel coding style, that is: 8 characters-wide tab indentation (natural tab) and as many levels of indentation as there fit on a 80x25 terminal (without exceeding the 80 characters width, that is).

blocks|key|3660349|text|太多的缩进可能是你应该重构的信号:创建更多具有好名字的小方法。这样，你就可以将逻辑分解成更容易吞噬的更小的部分。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3660350|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Too much indentation is probably a sign that you should refactor: create a couple more small methods with good names. That way you break up the logic into smaller pieces that are easier to gobble up.

blocks|key|541087|text|这涉及到一个函数应该有多长的问题。如果你把你的函数体限制在十行或更少，那么很难得到太多级别的缩进。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|541088|我认为4或5级太多了。几乎可以肯定的是，您可以将其中一些内部循环或条件条件分解到它们自己的函数中。|541089|我自己对三层缩进感到反胃。即使是两个层次也会让我重新考虑我在做什么。|541090|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

This relates to the question of how long a function should be. If you keep your function bodies to ten lines or fewer, then it's really hard to get too many levels of indentation.

I think 4 or 5 levels is too many. You can almost certainly factor out some of those inner loops or conditionals into their own functions.

I feel queasy with three levels of indentation myself. Even two levels causes me to reconsider what I'm doing.

blocks|key|5774343|text|只要您可以在编辑器中同时看到所有的左方括号和右方括号，就可以进行多级缩进。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5774344|这往往会限制你在实践中最多4个级别。|5774345|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Many levels of indentation is fine as long as you can see the all the open and close brackets at the same time in your editor.

This tends to limit you to maybe 4 levels max in practice.

blocks|key|3660402|text|然而，需要注意的一点是，某些嵌套层次是必要的，不应该被抽象出来。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3660403|如果你在一个4D数组上进行某种暴力迭代，那么你就会自动得到四层嵌套，如果有一条If语句，那么你就会有五层，而不需要特别复杂的代码段。|3660404|所以嵌套的层次并不一定是问题所在，问题在于每层嵌套的复杂性。如果你混合了WHILEs，FOREACH，IFs和SWITCHes，那么也许你应该精简它们。|3660405|基本点是嵌套的级别并不总是复杂性的指标。|3660406|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

One thing to note however is that some nesting levels are necessary and should not be abstracted out.

If you have some sort of brute force iteration over a 4D array, then you've got four levels of nesting automatically, and if there's is an IF statement, then you have five levels without having a particularly convoluted section of code. 

So the level of nesting isn't necessarily the problem, it's the complexity attached to each level of nesting. If you are mixing WHILEs, FOREACHs, IFs and SWITCHes then maybe you should boil them down. 

The basic point is that levels of nesting aren't always an indicator of complexity.

blocks|key|2445597|text|IIRC，Linus+Torvalds会同意你的观点我相信他坚持在linux内核代码中使用8个空格的缩进和80个字符的行长。当你在这种方案下缩进到4或5级时，你的代码看起来会很糟糕。为了保持代码的可读性，你不得不尝试重构代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2445598|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

IIRC, Linus Torvalds would agree with you. I believe he insists on an 8-space indent and a 80-character line length for the linux kernel code. When you get to 4 or 5 levels of indent under that scheme your code would look scrunched horribly. You're forced to try to refactor the code just to maintain readability.

blocks|key|5774397|text|我曾经认为Linus在这一点上有点强硬，他说不超过3个级别，否则你的代码就会崩溃，也就是说，遵循这个原则对我的控制流的推理有很大帮助。也就是说，我不得不用不同的方式来解释它。直观的解释是你应该创建越来越多的itsy+bitsy函数。我不建议将这种想法推向极端，因为这会使您的控制流和副作用很难推断，因为所有副作用都被函数调用遮蔽了，导致您到处都是。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5774398|对我有很大帮助的是延迟处理和更简单的循环。以此为例：|5774399|//+Remove+vertices+from+mesh.
for+each+vertex+in+vertices.to_remove:
{
++++for+each+edge+in+vertex.edges:
++++{
++++++++for+each+face+in+edge.faces:
++++++++{
+++++++++++++face.remove_edge(edge);
+++++++++++++if+(face.size()+<+3)
+++++++++++++++++++face.remove();
++++++++}
++++++++edge.remove();
++++}
++++vertex.remove();
}|code-block|syntax|javascript|5774400|上面有4级缩进的可怕的东西是笨拙的(当它不是伪代码形式时更是如此，它可能需要更新纹理贴图，等等，需要更多级别的缩进)。我们可以这样做：|5774401|for+each+vertex+in+vertices.to_remove:
{
++++for+each+edge+in+vertex.edges:
++++++++edges_to_remove.insert(edge);
}

for+each+edge+in+edges_to_remove:
{
++++for+each+face+in+edge.faces:
++++++++faces_to_rebuild.insert(face,+edge);
}

for+each+face,edge+in+faces_to_rebuild:
{
++++face.remove_edge(edge);
++++if+(face.size()+<+3)
+++++++++face.remove();
}

for+each+edge+in+edges_to_remove:
++++edge.remove();

for+each+vertex+in+vertices_to_remove:
++++vertex.remove();|5774402|虽然这涉及到更多的数据传递和一些额外的状态，但它使每个循环变得简单得多。当我们有了这些更简单的循环时，它们变得更容易并行化，并且内存访问模式可以开始呈现缓存友好的性质，并具有适当的数据结构。|5774403|我发现，支持这种类型的延迟处理不仅可以减少这些缩进，还可以简化我理解代码正在做什么的能力，因为控制流非常简单，而且它们都只导致一种类型的一致副作用。这使得它更容易看到每个循环正在做什么，并一目了然地理解它是否在做正确的事情，因为每个循环都致力于引起一种类型的副作用，而不是许多不同类型的副作用。令人惊讶的是，尽管有额外的工作，它通常会提高高速缓存的一致性，也为多线程和SIMD打开了新的大门，最终我得到了比开始时更高效的结果。|5774404|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

I used to think Linus was a bit of a hard-ass on this when he said no more than 3 levels or else your code is broken, i.e., but following that principle has helped me a lot in reasoning about my control flows. That said, I had to interpret it differently. The intuitive interpretation is that you should create more and more itsy bitsy functions. I don't recommend taking that idea to the extreme as that can make your control flows and side effects just as difficult to reason about when all the side effects are obscured by function calls leading you all over the place.

What helped me enormously was favoring deferred processing and simpler loops. Take this as an example:

<pre><code>// Remove vertices from mesh.
for each vertex in vertices.to_remove:
{
 for each edge in vertex.edges:
 {
 for each face in edge.faces:
 {
 face.remove_edge(edge);
 if (face.size() &lt; 3)
 face.remove();
 }
 edge.remove();
 }
 vertex.remove();
}
</code></pre>

That monstrous thing with 4 levels of indentation above is awkward (and more so when it's not in pseudocode form where it might have to update texture maps and so on requiring even more levels of indentation). We can instead do this:

<pre><code>for each vertex in vertices.to_remove:
{
 for each edge in vertex.edges:
 edges_to_remove.insert(edge);
}

for each edge in edges_to_remove:
{
 for each face in edge.faces:
 faces_to_rebuild.insert(face, edge);
}

for each face,edge in faces_to_rebuild:
{
 face.remove_edge(edge);
 if (face.size() &lt; 3)
 face.remove();
}

for each edge in edges_to_remove:
 edge.remove();

for each vertex in vertices_to_remove:
 vertex.remove();
</code></pre>

While that involves more passes over the data and some additional state, it makes every loop much simpler. And when we have these simpler loops, they become easier to parallelize, and the memory access patterns can start taking on a cache-friendly nature with decent data structures in place.

I've found that favoring this type of deferred processing not only reduces those indentations but also simplifies my ability to comprehend what the code is doing since the control flows are dead simple and they're all causing only one type of uniform side effect. It makes it so much easier to see what each loop is doing and comprehend whether it is doing the right thing or not at a glance, since each one is dedicated to causing one type of side effect, not many different types of side effects. And surprisingly, in spite of the extra work, it often improves cache coherence, and also opens up new doors for multithreading and SIMD, and I end up getting an even more efficient result than I started.

How many levels of indentation do you consider reasonable?

I feel that having a C++ function with 4/5+ levels of indentation is normally a bad thing. It implies that you have to mentally keep track of 4/5+ things the whole time.

Is my opinion justified?

(yes, I can avoid having multiple levels of indentation by not indenting at all:)

Levels of Indentation

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

你认为多少级别的缩进是合理的？我觉得有一个缩进级别为4/5+的C++函数通常是一件坏事。这意味着你必须在心理上一直跟踪4/5+的事情。我的观点正确吗？(是的，我可以通过根本不缩进来避免多级缩进：)

问缩进级别
EN

回答 12

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问缩进级别EN

回答 12

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问缩进级别
EN