为什么“ ifif else”语句实际上从不采用表格式？

if   i>0 : return sqrt(i)  
elif i==0: return 0  
else     : return 1j * sqrt(-i)

VS

if i>0:  
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

给定以上示例，我不明白为什么我实际上从来没有在代码库中看到过第一种样式。对我来说，您将代码转换为表格格式，可以清楚地显示所需内容。第一列实际上可以忽略。第二列标识条件，第三列为您提供所需的输出。至少在我看来，它直截了当且易于阅读。但是我总是看到这种简单的案例/切换情况是以扩展的，制表符缩进的格式出现的。这是为什么？人们是否发现第二种格式更具可读性？

唯一可能出现问题的情况是代码更改并变得更长。在那种情况下，我认为将代码重构为长缩进格式是完全合理的。每个人都只是因为它总是做第二件事而做第二种吗？作为恶魔的拥护者，我想还有另一个原因可能是因为人们根据if / else语句的复杂性找到了两种不同的格式，这令人困惑？任何见识将不胜感激。

原因之一可能是您没有使用流行的语言。

一些反例：

Haskell的守卫和模式：

sign x |  x >  0        =   1
       |  x == 0        =   0
       |  x <  0        =  -1

take  0     _           =  []
take  _     []          =  []
take  n     (x:xs)      =  x : take (n-1) xs

Erlang模式：

insert(X,Set) ->
    case lists:member(X,Set) of
        true  -> Set;
        false -> [X|Set]
    end.

Emacs Lisp：

(pcase (get-return-code x)
  (`success       (message "Done!"))
  (`would-block   (message "Sorry, can't do it now"))
  (`read-only     (message "The shmliblick is read-only"))
  (`access-denied (message "You do not have the needed rights"))
  (code           (message "Unknown return code %S" code)))

通常，我看到表格式在函数式语言（以及基于通用表达式的语言）中非常流行，而换行在其他语言中最为流行（主要是基于语句的）。

更具可读性。原因如下：

• 几乎每种语言都使用这种语法（不是全部，大多数 -尽管您的示例似乎是Python）
• isanae在评论中指出，大多数调试器是基于行的（而不是基于语句的）
• 如果必须内联分号或花括号，它看起来会更加难看
• 从上到下阅读更顺畅
• 如果您除了琐碎的return语句之外的其他内容， 这看起来非常难以理解
  • 略读代码时，任何缩进的有意义语法都会丢失，因为条件代码不再在视觉上分离（与Dan Neely分离）
  • 如果您继续将项目修补/添加到1行if语句中，这将特别糟糕。
• 仅当您所有的if支票的长度都相同时才可读
• 这意味着您不能将复杂的语句格式化为多行语句，它们必须是一体式的
• 当我逐行垂直阅读而不是试图将多行解析在一起时，我更有可能注意到错误/逻辑流
• 我们的大脑比水平的长文本更快地阅读窄而高的文本

尝试执行任何操作的那一刻，最终将其重写为多行语句。这意味着您只是浪费时间！

人们也不可避免地添加如下内容：

if i>0:  
   print('foobar')
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

在确定此格式比其他格式好得多之前，并不需要经常这样做。啊，但是您可以将它们全部内联！ 恩德兰在内部死亡。

或这个：

if   i>0 : return sqrt(i)  
elif i==0 and bar==0: return 0  
else     : return 1j * sqrt(-i)

真的，真的很烦。没有人喜欢格式化这样的东西。

最后，您将开始“制表符多少个空间”问题的圣战。根据设置，在屏幕上以表格格式完美呈现的内容可能无法在我的屏幕上呈现。

无论如何，可读性不应该取决于IDE设置。

我坚信“代码被读取很多次，而被写入的次数很少，因此可读性非常重要。”

当我阅读别人的代码时，对我有帮助的关键是遵循我的眼睛经过训练可以识别的“正常”模式。我可以很容易地阅读缩进形式，因为我已经看过很多次了，几乎自动注册了（我的认知工作很少）。这不是因为它“更漂亮”，而是因为它遵循了我惯用的约定。大会胜过“更好” ...

除了已经提到的其他缺点外，表格布局还增加了版本控制合并冲突的几率，需要人工干预。

当需要重新排列表格格式的代码块时，版本控制系统会将这些行中的每一行都视为已修改：

diff --git a/foo.rb b/foo.rb
index 40f7833..694d8fe 100644
--- a/foo.rb
+++ b/foo.rb
@@ -1,8 +1,8 @@
 class Foo

   def initialize(options)
-    @cached_metadata = options[:metadata]
-    @logger          = options[:logger]
+    @metadata = options[:metadata]
+    @logger   = options[:logger]
   end

 end

现在假设与此同时，在另一个分支中，程序员在对齐的代码块中添加了新行：

diff --git a/foo.rb b/foo.rb
index 40f7833..86648cb 100644
--- a/foo.rb
+++ b/foo.rb
@@ -3,6 +3,7 @@ class Foo
   def initialize(options)
     @cached_metadata = options[:metadata]
     @logger          = options[:logger]
+    @kittens         = options[:kittens]
   end

 end

合并该分支将失败：

wayne@mercury:/tmp/foo$ git merge add_kittens
Auto-merging foo.rb
CONFLICT (content): Merge conflict in foo.rb
Automatic merge failed; fix conflicts and then commit the result.

如果要修改的代码未使用表格对齐方式，则合并将自动成功。

（此答案在我自己的文章中被“ pla窃”，不鼓励代码中的表格对齐方式）。

如果所有内容始终适合分配的宽度，则表格格式可能会非常不错。但是，如果某些东西超出了分配的宽度，那么通常有必要使表的一部分与其余部分不对齐，或者调整表中其他所有东西的布局以适合长项。

如果源文件是使用旨在处理表格格式数据的程序进行编辑的，并且可以通过使用较小的字体大小来处理过长的项目，并将它们在同一单元格中分成两行，等等，那么使用表格格式可能就有意义格式化的频率更高，但是大多数编译器都希望源文件没有此类编辑器为了保持格式而需要存储的标记。在最佳情况下，使用缩进量可变但没有其他布局的行并不像表格格式那样好，但是在最坏情况下，它不会引起那么多问题。

有一个'switch'语句为特殊情况提供了这种功能，但是我想这并不是您要问的。

我已经看过if语句是否采用表格式，但是必须有大量条件才能使其值得。3如果以传统格式最好地显示语句，但是如果您有20条，那么将其以大块格式显示起来会更容易，而大块的格式可以使其更加清晰。

重点是：清晰度。如果它更易于查看（并且您的第一个示例不容易看到：分隔符在哪里），则将其格式化以适合这种情况。否则，请坚持人们的期望，因为这总是更容易识别。

如果您的表达确实如此简单，那么大多数编程语言都提供？：分支运算符：

return  ( i > 0  ) ? sqrt( i)
      : ( i == 0 ) ? 0
        /* else */ : 1j * sqrt( -i )

这是一种简短的可读表格格式。但是重要的是：我一眼就能看出“主要”行动是什么。这是一个退货声明！该值由某些条件决定。

另一方面，如果您有执行不同代码的分支，那么我发现缩进这些块的可读性更高。因为现在根据if语句有不同的“主要”操作。在一种情况下，我们抛出，在一种情况下，我们记录并返回或仅返回。取决于逻辑，会有不同的程序流，因此代码块封装了不同的分支，并使它们对开发人员更为突出（例如，快速读取函数以掌握程序流）

if ( i > 0 )
{
    throw new InvalidInputException(...);
}
else if ( i == 0 )
{
    return 0;
}
else
{
    log( "Calculating sqrt" );
    return sqrt( -i );
}

正如enderland已经说过的那样，您假设您只有一次“返回”作为操作，并且可以将“返回”标记为条件的结尾。我想提供一些额外的细节，说明为什么这将无法成功。

我不知道您首选的语言是什么，但是我已经用C编码很长时间了。围绕着许多编码标准，其目的是通过不允许在初始编码中或在以后的维护期间易于出错的代码构造来避免一些标准编码错误。我对MISRA-C最熟悉，但是还有其他一些，并且通常它们都有相似的规则，因为它们使用相同的语言来解决相同的问题。

编码标准经常解决的一个普遍错误是这个小陷阱：

if (x == 10)
    do_something();
    do_something_else();

这并没有按照您的想法做。就C而言，如果x为10，则您调用do_something()，但是无论x的值如何，do_something_else()都会被调用。仅紧接“ if”语句之后的操作是有条件的。这可能就是编码人员的意图，在这种情况下，维护人员可能会陷入困境。否则可能不是编码人员想要的，在这种情况下会出现错误。这是一个受欢迎的面试问题。

编码标准中的解决方案是对所有条件操作都强制使用大括号，即使它们是单行也是如此。现在我们得到

if (x == 10)
{
    do_something();
    do_something_else();
}

要么

if (x == 10)
{
    do_something();
}
do_something_else();

现在它可以正常工作，并且对于维护人员来说很清楚。

您会注意到这与您的表样式格式完全不兼容。

其他一些语言（例如Python）研究了这个问题，并决定由于编码人员正在使用空格来使布局清晰明了，所以最好使用空格而不是花括号。因此，在Python中，

if x == 10:
    do_something()
    do_something_else()

对x和= 进行调用，do_something()并do_something_else()以x == 10为条件，而

if x == 10:
    do_something()
do_something_else()

表示仅以do_something()x为条件，并且do_something_else()始终被调用。

这是一个有效的概念，您会发现几种语言都在使用它。（我是在Occam2中第一次看到它的，时光倒流。）不过，您可以轻松地看到您的表样式格式与该语言不兼容。

表格布局在少数情况下可能很有用，但是在if中很少有用。

在简单的情况下，？：可能是一个更好的选择。在中等情况下，通常更适合使用开关（如果您的语言适合的话）。在复杂的情况下，您可能会发现呼叫表更合适。

在重构代码时，有很多次我将其重新排列为表格形式，以使其显得明显。我很少这样说，因为在大多数情况下，一旦您理解了问题，便有了更好的解决方法。有时，编码惯例或布局标准禁止这样做，在这种情况下，注释是有用的。

有关的问题?:。是的，它是三元运算符（或者我想将其视为值）。乍一看，这个示例对于？：有点复杂（并且过度使用？：不利于可读性，但会伤害它），但是经过一番思考，可以将该示例重新排列为以下形式，但是我认为在这种情况下，开关是最易读的解。

if i==0: return 0
return i>0?sqrt(i):(1j*sqrt(-i))

我看不到表格格式有什么问题。个人喜好，但我会使用这样的三元：

return i>0  ? sqrt(i)       :
       i==0 ? 0             :
              1j * sqrt(-i)

无需return每次重复：）