使用空格与{}来表示范围的语言的优缺点是什么？[关闭]

在使用空白还是使用括号之类的标记来表示范围方面似乎存在冲突。我已经看到许多人赞扬python对不一致的缩进问题的解决方案，但是许多人不同意：

任何将空格作为标记的语言都必​​须消失。

稍后在相同答案上发布：

直到我真正尝试过为止，我还是有点像反空格一样。我的个人空白布局几乎与python-land中的每个人所使用的布局相匹配可能会有所帮助。也许是因为我有点简约，但是如果您要缩进，为什么还要打扰{}？

我可以从两边看到一些明确的论点：

使用空格：

• 帮助减少代码中不一致的缩进
• 通过将可见标记替换为空白以达到相同目的来清除屏幕

使用令牌：

• 将代码剪切和粘贴到不同级别更加容易（您不必修复缩进）
• 更一致。一些文本编辑器以不同的方式显示空白。
• 目前比较流行。

我有什么遗漏的地方吗？你喜欢哪个？与彼此长期合作后，有什么智慧的话吗？

PS。当语言不为每个控件结构使用相同的标记时，我会讨厌它。VB的End Ifand End While语句确实很烦人，大多数其他语言仅对所有内容使用{}。但这也许是另一个问题的话题...

我认为我们很多程序员（包括我自己）都有将每个决策“逻辑化”的趋势。很好，但并非每个问题都有一个逻辑答案。例如，我怀疑厨师是否会在Chefoverflow上发布问题（如果存在此类问题），以询问苹果派和樱桃派的优缺点。这是您更喜欢的一个问题。

考虑到这一点，我认为最简单的答案是说“有些人喜欢大括号，有些人喜欢空格”，然后再说。

冒着听起来像个疯子的风险，我认为每个声称空白“有助于减少代码中不一致的缩进”的人从未使用过Visual Studio。使用单个命令（我认为默认快捷键是Ctrl + K，D），所有缩进都立即保持一致¹。此外，在粘贴代码时，无需执行任何操作即可立即纠正缩进，并且在编写新代码或将内容包装在一个if或另一个其他块中时，也是如此（重新}键入时会发生格式化）。此外，在完成一条语句后按Enter键始终会将光标置于下一条语句的正确缩进级别，即使前一条语句由于if或类似内容，这使得很难意外地认为某条陈述if不在某条陈述之下。

我要说的不是 Visual Studio很棒。我要说明的是，IDE可以自动执行缩进修复（以及其他格式问题），但是前提是程序的含义不取决于其格式。这为程序员提供了更多机会专注于实际的编程任务。像Python这样的语法会适得其反：不可能编写可以“修复” Python代码缩进的IDE，因为缩进本身指定了某些语义。

¹ _{（我知道VS拒绝重新格式化的一种特殊情况，即跨越多行的数组文字，但这并不重要。）}

我个人觉得我需要在自己的行上放一个标记来引入空行，以使我意识到代码在另一个范围内。

我讨厌在python中使用它的人：

if something
    do something
    do somethingelse

    cleanup
else
    do the other thing

而在象征性的土地上，我讨厌人们复制粘贴而不清理压痕，

if something
{
I have been too lazy
      {
            to clean up
            }
what I pasted
}

或请勿在令牌上使用单独的一行。

if something {
    I find this confusing
}
else {
especially when combined with the previous 
do something
}

我可以阅读所有这三种语言，但是它们不是我期望的那样，我必须花更多的精力来解析它们，并且正如Joel所说的，当事情无法按预期运行时，会让您感到沮丧。

Pro：据我所知，在Python世界中没有缩进/弯矩放置的圣战。代表开发人员做出此决定可能节省了一些麻烦。

缺点：匿名功能仅限于一行。听起来还不错，但我经常发现自己lambda在Scheme中写了多行s（多数情况下是馈入map或apply恰好在一个地方，因此单独声明没有任何意义）。

{}添加冗余。过多的冗余是不好的，很少的冗余是不好的。而且手动输入它是不好的，尤其是。如果很难使用它。

因此，在IDE不好/没有IDE的时候，空白样式可能会稍微好一些。但是使用功能强大的IDE，花括号会更好。

我发现空白语言的问题在于多页条件表达式。在第二页的中间添加一行，并在所有混乱的中间间隔一个空格，这可能会大大改变代码的逻辑。而且即使某人的代码“正确”，尝试阅读它也会造成可怕的猜谜游戏。这个“其他”用于哪个“ if”？与计算不可见的空白字符相比，计算括号要容易得多。并且该站点上的发布机制将它们粉碎成一个单独的空间。

IMHO "{{{{{" is more reliable than "     ".

我认为这不是真正的对抗。
Pythoneer经常批评括号程序员，好像他们很容易违反缩进一样，因为这样做可以。
实际上，即使在了解Python及其缩进作用域之前，我始终使用100％一致的缩进。

事实是，大括号语言还可以在编译器中施加正确的缩进，因此我们将两全其美。看到？没有对可言。

Pythoneers会争辩说，当缩进是语法的一部分时，花括号是没有用的，但不是，花括号可以提高可读性。我尝试对Python进行编程，这对我来说是一种非常有趣的语言，但是您是否尝试过使用if-elif缩进级别超过2或3的链？他们看起来不再那么整洁了。

PS：我写了花括号，但更一般的说，我的意思是定界符标记。左括号可以看作是多余的，但是一种语言可以像这样（事实上，我敢肯定有些语言就是这样，但我不太了解它们）：

if condition:
    statement
    other_statement()
end

PS2：2019年，此答案后的4年。我学习了Python，并完全习惯了它的语义缩进，并且一点也不觉得很难阅读。尤其是在现代IDE的帮助下，这些IDE绘制垂直条以帮助识别缩进块。