如果你打破了长的代码行，你怎么缩进下一行的东西？
有时候，你必须用源代码写出更好的分界线。 你怎么缩进这个东西。
你可以缩进它一样的：
very long statement; other statement; 这使得难以区分下面的代码，如示例所示。 另一方面，你可以将它缩进一层：
very long statement; other statement;
这使得它更容易，但是它可能发生，长行是嵌套块的开始，你想缩进，如下所示：
if ((long test 1) && (long test 2) && (long test 3)) { code executed if true; }
在这种情况下，它很难阅读。 我能想到的第三种可能性就是不要排长队，现代编辑们可以处理它，并创造出柔和的线条。 但是另外一名编辑则需要横向滚动，而且不能影响职位，编辑会打破你的长处。
你更喜欢什么样的可能性？ 你有其他的想法来解决这个问题吗？ 你可以支持你的偏好有一个很好的理由？
我喜欢在自己的线上的括号，因为我很容易看到条件和内部块作为一个项目（如果你知道我的意思）：
if ((long test 1) && (long test 2) && (long test 3)) { code executed if true; }
而且我喜欢用条件是什么来开始附加的条件行，因为我发现“join”条件非常重要，在上一行的结尾往往会被忽略。
我也尝试缩进，使得括号的效果是明显的（虽然试图避免长条件通常是件好事）。
我尝试和结构的东西，使我可以轻松地“扫描”“东西”:)
您应该尽量防止写入超过80个字符的文本，而不是将其打破：
- 尝试通过转换条件和封装代码来最小化缩进。
Linus Torvalds：如果你需要3个以上的缩进级别，
并应该修复你的程序。
这也有使代码更具可读性的副作用，除此之外，封装的其他条件可以在其他地方使用。
bool encapsulatedLongCondition() // Add some parameters { if (!condition1) return false; if (!condition2) return false; // ... (Other conditions) return true; } if (encapsulatedLongCondition()) { // ... (Call some methods, try not to introduce deeper if/loop levels!) }
通过布尔代数简化你的条件，并尝试反转条件和返回值可以帮助很多。 🙂
另见： 你能简化这个algorithm吗？ 另请参阅2：C＃的重构有能力为您提供帮助。 😉
- 使用types定义，并尽量避免长名称
一个简单的例子，想象一下在没有typedef的Days中使用另一个容器中的更长名字的时间。
struct Day { // Some data }; struct Event { // Some data }; typedef list<Event> Events; typedef map<Day, Event> Days; // Some other container that would else be long...
- …（你应该尝试分析为什么你的线路很长，find解决scheme）
希望你能得到大致的想法，这样你就不需要拿出一个肮脏的换行符。 😉
唯一会出现长行的地方出现在你函数的原型中，或者在调用它们的时候，你应该试着在最后一个逗号后打破，然后继续下一行。 而不是在每个之后做，并浪费了多条线，使滚动臃肿，你的function突出了太多…如果您经常看到这些长行，您可以将返回types放在函数名称前的行。
void longFunctionName(ParameterType1 parameter1, ParameterType2 parameter2, ParameterType3 parameter3, ParameterType4 parameter4)
我有两个简单的规则：
- 声明块：一个缩进;
- 续行：两个缩进或括号alignment，无论是进一步缩进。
所以，如果是这样的话：
if ((long test 1) && (long test 2) && (long test 3)) { code executed if true; }
一般我做：
if (condition) { something; }
为块分隔符。 但是，如果我不得不分手的情况下，我使用这个：
if ( (long test 1) && (long test 2) && (long test 3) ) { code executed if true; }
rbobby的答案的主要区别：
- 在每行末尾的操作符，而不是后续行的开始，以非常清楚地表明行不完整
- 在条件元素之前的第一行中断行 – 这有助于保持代码“形状”一致。
- closuresparen不缩进。
这有一个使参数/条件列表看起来有点类似于代码块的视觉效果（但是用parens而不是大括号），我发现对称性令人愉快，它也避免了在一行上有一个裸露的花括号（我认为这看起来很糟糕） 。
我站在一起， “不要打IDE。”
不过，我的IDE（Eclipse，Visual Studio）想要断线是如何被打破的。
这可能意味着语言之间的不一致，这是确定的。
我将括号内的expression式保留在开头的级别：
if ((long test 1) && (long test 2) && (long test 3)) { code executed if true; }
这使得每个expression式处于哪个级别是明显的。
我已经在这里写了一些东西，
if ((long test 1) && (long test 2) && (long test 3)) { code executed if true; }
我喜欢在行尾有我的布尔运算符。
长方法名称或者有很多参数的方法如下所示：
reallyLongMethodName (paramA, paramB, paramC);
与上面的param名字排列在一起; 不是支架…
此外，为了减less缩进，我已经开始在我的代码中使用多个返回点，以及继续并在我的循环中断开。 例如
for(int i = 0; i < MAX; i++) { if(!isPrime(i)) // predefined prime finding func continue; //now we have only prime values of i }
总是缩进，但如果陈述是特殊的; 我喜欢排列testing，并且把额外的&&运算符放在左边：
if ( (long test 1) && (long test 2) && (long test 3)) { code executed if true; }
把&&放到左边也是可以的，但是我觉得这个select比较难读。
随着astyle，或者你正在使用的自动压头。 这似乎做了一个足够好的工作，通常有更重要的事情要考虑。
我过去曾经问过类似的问题：
在哪里包装一行代码，尤其是长参数列表？
这类问题的难点在于其主观性，所以我无法接受答案。
我认为重要的部分是保持缩进风格在整个代码库中是一致的。
我会说，使用什么方法并不重要，只要符合以下标准：
- 这是明智的
- 在整个代码中应用相同的约定。
如果你在一个团队的发展，如果你不能达成协议，并且没有人可以指定，那就试着去同意你之间的约定，通过一些神秘的投票机制。
在我看来，78或80个字符的行宽是有用的，因为它使在同一屏幕上打开多个文件变得更加容易。
理由， Linus Torvalds的引用呢？ 🙂
答案就是如果你需要3级以上的缩进，那你就搞不定了，应该修好你的程序。
我通常会遵循Google C ++编码风格的组合 （我可以把它改编成Java），而且这种C ++编码风格也是如此 。
我几乎从不缩进同一行。 不过，我已经非常less见了，重新初始化了一堆这样的variables
a = b = c = d = e = f = 0;
做这样的事情的一个关键是保留赋值操作符作为下一行的第一个字符。 这将给予保留。 程序员在看到WTF时刻，迫使他们看，而不仅仅是掩盖它。
包装一个很长的声明，我会做到这一点，我觉得它是有道理的…不一定在第一个缩进。 所以：
reallyLongMethodName (paramA,paramB,paramC);
不会被格式化
reallyLongMethodName (paramA, paramB, paramC);
但最终会更喜欢
reallyLongMethodName (paramA, paramB, paramC);
所有参数与左括号alignment。
对于如果和时间，我会做类似的事情
if((long test 1) && (long test 2) && (long test 3)) { code executed if true; }
以特定的方式格式化代码的唯一原因是使其可读性。 这本质上是主观的 – 以一种看起来不错的方式进行，而且对于第一次看代码的人来说，你觉得这样做更具可读性。 而且我会反对传统的观点，并且说，不要担心任何共同的标准 – 有两个原因
1）在这种情况下很难，因为折线有很多不同的可能性
2）它不会给你买东西。 期。 再一次，代码格式化只是为了让你的代码可读，有一个标准的方式来格式化你的代码的细节不会购买你的可读性。
