如果你打破长代码行,你如何缩进下一行的东西？

有时候你必须在你的源代码中写入更好的内容.你如何缩进由此停止的东西.

你可以缩进它:

very long
statement;
other statement;

这使得区分以下代码变得更加困难,如示例所示.另一方面,你可以缩进一级:

very long
   statement;
other statement;

这样可以更容易,但可能会发生,长行是嵌套块的开始,您要缩进,如下所示:

if ((long test 1) &&
   (long test 2) &&
   (long test 3)) {
   code executed if true;
}

在这种情况下,再次难以阅读.我能想到的第三种可能性就是不打破长线,现代编辑可以处理它并创建柔和的线条.但是对于另一个编辑器,你必须侧向滚动,你不能影响位置,编辑器打破你的长队.

你更喜欢什么样的可能性？你有其他想法来解决这个问题吗？你有理由支持你的偏好吗？

1> user53794..：

---

我喜欢自己的大括号因为我更容易看到条件和内部块作为一个项目(如果你知道我的意思):

if ((long test 1)
    && (long test 2)
    && (long test 3)) 
{
    code executed if true;
}

我喜欢用条件开始附加条件行,因为我发现"连接"条件非常重要,并且在前一行的末尾往往会被忽略.

我也试着缩进使得括号的效果是显而易见的(虽然试图避免长条件通常是一件好事).

我尝试构建东西,以便我可以轻松地"扫描""东西":)

---

好吧,它可能看起来不常见,但我总是将它放在一个新的行上,让它在闭合括号的同一列中排成一行,这样当向上滚动时我可以很容易地直观地匹配它们.好吧,每个人都有自己的方式放置它们.;-)

---

+1匹配大括号.它让事情变得更加清晰,为什么不呢？

---

+1将操作员置于新行的开头.这使得非常明显的是哪些行是连续的,而只扫描每行的前几个字符.

---

支撑风格是一场巨大的火焰战争,在给予这两种选择之前,不应允许任何人给出机会(真正的机会,如整个项目).我知道我首先讨厌我现在喜欢的风格.但既然我已经使用了很长时间,那就不再重要了.

---

这并不罕见,它只取决于您所看到的惯例.根据我的经验,这几乎是50/50(有些wierdos缩进{}以及属于块的代码)

2> Tamara Wijsm..：

---

您应该尝试阻止写入超过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!)
}

通过布尔代数简化您的条件并尝试反转条件和返回值可以提供很多帮助.:-)

另请参阅:您可以简化此算法吗？ 另请参阅2:C#的Refactor能够为您提供帮助.;-)

使用类型定义并尝试避免使用长名称

一个简单的例子,想象一下,如果没有在另一个容器中使用较长名称的typedef,那么多长时间.

struct Day
{
  // Some data
};
struct Event
{
  // Some data
};
typedef list Events;
typedef map Days;
// Some other container that would else be long...

...(您应该尝试分析为什么您的线很长并找到解决方案)

希望你得到一般的想法,这样你就不需要想出一个肮脏的换行符.;-)

我看到长行的唯一地方是你的函数的原型或者在调用它们时,你应该尝试在最后一个可能的逗号之后断开并继续下一行.而不是在每次之后执行此操作并浪费多行使滚动变得臃肿并且您的功能过于突出...如果您经常看到这些长行,您可以将返回类型放在函数名称之前的行上.

void longFunctionName(ParameterType1 parameter1, ParameterType2 parameter2,
                      ParameterType3 parameter3, ParameterType4 parameter4)  

---

对我来说,长线出现是因为我给我的变量赋予了非常富有表现力的名字.我不介意长变量名称(只要它们易于阅读),因为我使用的大多数编辑器都具有自动完成功能.

---

使用if语句时请不要省略(大括号)括号(如本答案中所示).每次你这样做,一只小狗死了.甚至乔恩斯基特也承认犯了错误.

3> Cory Petosky..：

---

一般来说我做:

if (condition) {
     something;
}

用于块分隔符.但是,如果长线的情况我必须分手,我用这个:

if (
    (long test 1) &&
    (long test 2) &&
    (long test 3)
) {
    code executed if true;
}

与rbobby答案的主要区别:

操作员在每一行的末尾而不是后续行的开头,以非常清楚地在视觉上指示该行是不完整的

在条件元素之前的第一行换行 - 这有助于保持代码"形状"一致.

关闭paren没有缩进.

这具有使参数/条件列表看起来有点像代码块的视觉效果(但是使用parens而不是花括号.我发现对称性令人愉悦.它还避免在一条线上打开一个裸露的花括号(我认为看起来很糟糕) .

4> Juliano..：

---

我有两个简单的规则:

声明块:一个缩进;

线条延续:两个缩进或括号对齐,无论是进一步缩进.

因此,在if情况下:

if ((long test 1) &&
        (long test 2) &&
        (long test 3)) {
    code executed if true;
}

---

这实际上很可怕