有时候你必须在你的源代码中写入最好的内容。你如何缩进由此停止的东西。
您可以将其缩进:
very long
statement;
other statement;
这使得区分以下代码变得更加困难,如示例所示。另一方面,你可以将它缩进一级:
very long
statement;
other statement;
这样可以更容易,但是可能会发生,长行是嵌套块的开头,你要缩进,如下所示:
if ((long test 1) &&
(long test 2) &&
(long test 3)) {
code executed if true;
}
在这种情况下,再次难以阅读。我能想到的第三种可能性就是不打破长线,现代编辑可以处理它并创建柔和的线条。但是对于另一个编辑器,你必须侧向滚动,你不能影响位置,编辑器会打破你的长线。
您更喜欢哪种可能性?你有其他想法来解决这个问题吗?你有理由支持你的偏好吗?
答案 0 :(得分:41)
我喜欢自己的大括号因为我更容易看到条件和内部块作为一个项目(如果你知道我的意思):
if ((long test 1)
&& (long test 2)
&& (long test 3))
{
code executed if true;
}
我喜欢用条件开始附加条件行,因为我发现“加入”条件非常重要,并且在上一行的末尾往往会被忽略。
我也尝试缩进,使得括号的效果明显(虽然试图避免长条件通常是一件好事)。
我尝试构建东西,以便我可以轻松地“扫描”“东西”:)
答案 1 :(得分:30)
你应该尝试阻止写入长度超过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!)
}
通过布尔代数简化您的条件并尝试反转条件和返回值可以提供很多帮助。 : - )
另见:Can you simplify this algorithm? 另请参阅2:C#的Refactor能够为您提供帮助。 ; - )
一个简单的例子,想象一下,如果没有在另一个容器中使用更长名称的typedef,那么多长时间。
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...
希望你得到一般的想法,这样你就不需要想出一个肮脏的换行符。 ; - )
我唯一能看到长线的地方是你的函数的原型或者在调用它们时,你应该尝试在最后一个可能的逗号之后断开并继续下一行。而不是在每次之后执行此操作并浪费多行使滚动变得臃肿并且您的功能过于突出...如果您经常看到这些长行,您可以将返回类型放在函数名称前面的行上。
void longFunctionName(ParameterType1 parameter1, ParameterType2 parameter2,
ParameterType3 parameter3, ParameterType4 parameter4)
答案 2 :(得分:8)
一般来说,我这样做:
if (condition) {
something;
}
用于块分隔符。但是,如果长线的情况我必须分手,我用这个:
if (
(long test 1) &&
(long test 2) &&
(long test 3)
) {
code executed if true;
}
与rbobby答案的主要区别:
这具有使参数/条件列表看起来有点像代码块的视觉效果(但是使用parens而不是花括号。我发现对称性令人愉悦。它还避免在一条线上打开一个裸露的花括号(我认为看起来很糟糕。)
答案 3 :(得分:7)
我有两个简单的规则:
所以,在if的情况下:
if ((long test 1) &&
(long test 2) &&
(long test 3)) {
code executed if true;
}
答案 4 :(得分:4)
我支持,“不要与IDE对抗。”
然而,我的IDE(Eclipse,Visual Studio)想要破解它们是如何被破坏的。
这可能意味着语言之间存在不一致,这是可以的。
答案 5 :(得分:3)
我对这里的内容略有不同:
if ((long test 1) &&
(long test 2) &&
(long test 3))
{
code executed if true;
}
我喜欢在行尾添加布尔运算符。
长方法名称或包含大量参数的方法如下:
reallyLongMethodName (paramA,
paramB,
paramC);
与上面的param名称对齐;不是括号......
另外,为了减少缩进,我已经开始在我的代码中使用多个返回点,以及在循环中继续和中断。例如
for(int i = 0; i < MAX; i++)
{
if(!isPrime(i)) // predefined prime finding func
continue;
//now we have only prime values of i
}
答案 6 :(得分:2)
我将括号内的表达保持在开头的水平:
if ((long test 1) &&
(long test 2) &&
(long test 3)) {
code executed if true;
}
这使得每个表达式处于哪个级别显而易见。
答案 7 :(得分:2)
我过去曾问过类似的问题:
Where to wrap a line of code, especially long argument lists?
这类问题的难点在于其主观性,所以我无法接受答案。
我认为重要的是保持缩进样式在整个代码库中保持一致。
答案 8 :(得分:2)
始终缩进,但如果陈述是特殊的;我喜欢排列测试,我在左边放了额外的&&
运算符:
if ( (long test 1)
&& (long test 2)
&& (long test 3))
{
code executed if true;
}
向左拉&&
以与if
对齐也是可能的,但我觉得这个替代方案难以阅读。
答案 9 :(得分:1)
使用astyle或任何你使用的自动压头。它似乎做得很好,通常还有更重要的事情要考虑。
答案 10 :(得分:1)
我认为只要符合以下条件,使用哪种方法并不重要:
如果你正在进行团队开发,那么做试图就你之间的约定达成一致,如果你不能达成协议,那么通过一些神秘的投票机制,并且没有人可以指挥。
答案 11 :(得分:1)
以特定方式格式化代码的唯一原因是使其可读。这本质上是主观的 - 以一种看起来很好的方式做到这一点,并且你觉得第一次看代码的人会更有可读性。而且我会摒弃传统智慧并说,不要担心任何共同的标准 - 有两个原因
1)在这种情况下很难,因为虚线有很多不同的可能性
2)它不会给你买任何东西。期。再一次,代码格式化只是为了让你的代码可读,有一种标准的方式来格式化代码的细节并不会给你带来可读性。
答案 12 :(得分:0)
在我看来,78或80个字符的行宽是有用的,因为它可以让在同一个屏幕上让多个文件彼此相邻打开变得更容易。
理由,quote by Linus Torvalds怎么样? :)
答案就是如果你需要的话 超过3级压痕, 无论如何你都搞砸了,应该修好 你的计划。
我通常会关注Google C++ coding style的一个集团(你可以将其改编为Java,我猜)和this C++ coding style。
答案 13 :(得分:0)
我几乎从不在同一行上缩进。但是,我非常罕见地重新初始化了一堆像这样的变量
a
= b
= c
= d
= e
= f
= 0;
执行类似这样的操作的一个关键是将赋值运算符作为下一行的第一个字符。这将给予maint。程序员在他们看到WTF的时刻,强迫他们看,而不仅仅是掩饰它。
包含一个很长的陈述,我会在任何我觉得有意义的地方做到这一点......不一定是第一次缩进。所以:
reallyLongMethodName (paramA,paramB,paramC);
不会像
那样格式化reallyLongMethodName (paramA,
paramB,
paramC);
但最终会更像
reallyLongMethodName (paramA,
paramB,
paramC);
所有参数都与左括号一起排列。
对于if和whiles,我会做类似
的事情if((long test 1)
&& (long test 2)
&& (long test 3))
{
code executed if true;
}
答案 14 :(得分:0)
对于Java,Oracle提供了这些约定。 Java Code Conventions - Oracle.
例如,
longName1 = longName2 * (longName3 + longName4 - longName5)
+ 4 * longname6; // PREFER
longName1 = longName2 * (longName3 + longName4
- longName5) + 4 * longname6; // AVOID
另一个:
//DON’T USE THIS INDENTATION
if ((condition1 && condition2)
|| (condition3 && condition4)
||!(condition5 && condition6)) { //BAD WRAPS
doSomethingAboutIt(); //MAKE THIS LINE EASY TO MISS
}
//USE THIS INDENTATION INSTEAD
if ((condition1 && condition2)
|| (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt();
}
//OR USE THIS
if ((condition1 && condition2) || (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt();
}
该文件中给出了更多的例子。