长条件表达式为 1TBS
重要提示：这个问题并不是关于某种支撑样式相对于另一种支撑样式的优越性。我目前正在转换风格，以便自己评估哪种风格最适合我的情况，我喜欢 Allman 和 1TBS 一样。
使用 1TBS 支撑样式的用户，如何格式化 if 语句和后续代码中的长条件？
if ((this_is_the_first_part_of_a_long_condition)
&& (the_second_part_is_shorter__wait_no_it_is_not)
&& (and_one_more_for_the_road)) {
here_comes_the_block_code();
}
我觉得一定有更好的办法。我当前的方法是在代码块的第一行之前添加一个空行。奥尔曼在这种情况下看起来也不是很好，尽管在我看来更具可读性。
另一个使用 for 循环的例子：
for (int relevant_counter_variable_name = START_VALUE;
intelligent_expression_that_may_include_the_counter_variable;
relevant_counter_variable_update) {
first_code_line_inside_the_block();
}
不太好...
KNF（8 个空格缩进）在这里会有所帮助，但我想避免这种情况。我还有其他几个选择，但我想听听是否有某种标准方法。
Important note: this question is not about the superiority of a bracing style above another. I am currently switching styles in order to evaluate for myself which one I think works best in my situation, and I like Allman as much as 1TBS.
Users of 1TBS bracing style, how do you format long conditions in an if statement and the subsequent code?
if ((this_is_the_first_part_of_a_long_condition)
&& (the_second_part_is_shorter__wait_no_it_is_not)
&& (and_one_more_for_the_road)) {
here_comes_the_block_code();
}
I feel that there must be a better way. My current way is to add an empty line before the first line of the code block. Allman does not look very good in this case either, although more readable in my opinion.
Another example with for loops:
for (int relevant_counter_variable_name = START_VALUE;
intelligent_expression_that_may_include_the_counter_variable;
relevant_counter_variable_update) {
first_code_line_inside_the_block();
}
Not so nice...
KNF (8 spaces indent) would help here, but I would like to avoid that. I have a couple other options, but I'd like to hear if there is some kind of standard way.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我双缩进连续行：
I double-indent continued lines:
为了绝对的清晰度和可读性，我只是浪费了一些变量：
那里！ 1TBS 的所有荣耀。没有风格混合。没有丑陋。 Indent(1) 可以处理它，而无需
/* *INDENT-OFF* */作弊。您甚至可以为条件指定有意义的名称，例如
I'd simply waste a few variables for absolute clarity and readability:
There! 1TBS in all its glory. No style mixing. No ugliness. Indent(1) can deal with it without
/* *INDENT-OFF* */cheating.You could even give the conditions meaningful names, such as
混合搭配
我确实同意混合风格经常被人皱眉。
但是，我敢说，在可能的情况下，可以为了可读性而改变规则。
如果样式严格强制执行，（公司编码政策）
我通常这样做：
只需对所有条件使用一级缩进，
以及大括号内代码的另一个附加级别。
这是尽可能可读的，不会冒犯任何纯粹主义者。
Mix-n-match
I do agree that mixing styles is often frowned upon.
But, i dare say that where possible, the rule can be bent for readability.
In cases where the style is strictly enforced, (company coding-policies)
I usually do this:
Just use one-level of indents for all the conditions,
and another additional level for the code inside the braces.
This is as readable as it gets, without offending any purists.
每个级别使用单个空格缩进，无论需要与否，每个条件都使用括号。
对于复杂的情况，奥尔曼式括号可以很好地工作。
一般方法适用于无法容纳在一行中的代码的延续，或函数参数列表。
每个闭合元件与打开元件在同一水平处缩进，因此出现“));”对于“Trace.WriteLine(String.Format(”)和独立的“;”对于“return”
。YMMV。
Single space indenting for each level, use parentheses for each condition whether needed or not.
For complicated conditions Allman-style parentheses can work well.
General approach works for continuation of code that won't fit on one line, or for lists of function arguments.
Each closing element is indented at same level as the opening element, hence the "));" for "Trace.WriteLine(String.Format(" and the freestanding ";" for "return".
YMMV.