源代码中的选项卡与空格 [英] Tabs versus Spaces in Source Code

问题描述

源代码中的标签与空格


Xah Lee，2006-05-13


编码计算机程序时，''通常选项卡或

代码缩进空格。关于

存在大量混淆，这是更好的。它已成为所谓的宗教瓦拉？ a ??

对琐事的激烈争斗。在这篇文章中，我想解释一下它背后的情况是什么，哪些是正确的。


简单地说，标签是正确的，空格是不当。为什么？这可能看起来非常简单，因为事实上的混乱球：语义学

的标签是缩进的内容，而使用空格来对齐代码

是一个黑客。


现在，技术专家们可能会反对这个简单的结论，因为他们喋喋不休地讨论不同的编辑等等。由行业程序员看到的标签创建的所谓问题由b / b
引起：（1）技术极客的邋and和缺乏批判性思维

导致他们不理解制表符和

空格字符的语义目的。 （2）由于第一个原因，他们已经创建并且

传播了大量的非理解和误用，其程度为

许多工具（例如vi）不能很好地处理标签并使用空格

对齐代码已经被广泛使用，因此最终空间似乎实际上更受欢迎和看似简单。


简而言之，这是一种误解的现象，因为它会产生一种文化环境，因此会产生一种文化环境。

这种弊端和踢法是真实的还是正确的。像这样的情况

在unix中发生了很多。对于一个非unix示例，文件名是'

后缀，称为?? extensiona ??，其中文件的类型代码变为

部分文件名。 （例如a ??。txta ??，a ??。htmla ??，a ??。jpga ??）。

另一个着名的例子是业界的HTML实践，其中

设计糟糕的标签来自公司的竞争贪婪，而愚蠢的编码以及编码人员及其工具的误解是如此的广泛传播他们强制通过

最终的标准化来实现正确的方式，这种标准化是由不合理的数量引起的，但是设置了

练习。


现在，技术专家可能仍然反对，使用标签需要

编辑器来设置他们的位置，而普通文件不会带有

信息。这是一个很好的问题，解决方案是推进科学研究，以便您的源代码以某种方式嵌入这样的

信息。这将是进步。但是，这从来没有想过

因为a ?? unix philosophiesa ??已经让人们对黑客进行了调整

并且很浅薄。在这种情况下，许多人只会使用字符

用于分隔单词以便缩进或对齐，

并用激进的程度传播练习。


现在，鉴于

unixers和unix洗脑行业的编码器已经搞乱了标签与空格的混乱局面......哪个

我们今天应该使用吗？我没有一个好的主张，除了

使用哪个适合你，但把更多的批判性思维放在

之类的事情上，以防止这样的事故。


Tabs vs Spaces可以被认为是参数与硬编码值，或者

HTML vs ascii格式，或XML / CSS vs HTML 4，或结构与视觉，或者

语义与格式。在这些中，总是很容易从

转换为后者，但从后者到

前者几乎不可能。而且，这是因为前者编码了后者丢失的信息。如果我们看看制表符与空格的问题，确实，

很容易将标签转换为源代码中的空格，但更多

很难从空格转换为标签。因为，缩进作为缩进

实际上包含有关缩进的语义信息。使用

空格时，这些关键信息会在空间中丢失。


此问题与源代码中的另一个问题密切相关：

柔和的线条与EOL的物理硬包裹线条（

线条字符的结尾）。这个问题比标签vs

空间有更多的后果，并且unixer'的不假思索已经在计算行业中造成了深远的损失。由于unix的EOL思维方式，它有基于EOL的b $ b创建语言（除了

Lisp系列和Mathematica之外的所有语言）和基于的工具EOL（cvs，diff，grep，

，基本上是unix中的每个工具），基于EOL的想法（软件通过计算EOL来估算价值b $ b，硬编码的电子邮件报价系统通过

a ??> a ??前缀，以及许多unix工具中的静默行截断），这样的任何进展或开发都朝向aa ??算法代码单元??

概念或语言语法被抑制。我没有在这个问题上写过一个完整的

账户，但是我在这篇文章中已经触及它了：一个??伤害

的硬包装Linesa？ ，
http://xahlee.org/UnixResource_dir/ writ / hard-wrap.html

----

这篇文章存档于：
http://xahlee.org/UnixResource_dir/w...vs_spaces.html


Xah
xa*@xahlee.org

a ?? http://xahlee.org/

Tabs versus Spaces in Source Code

Xah Lee, 2006-05-13

In coding a computer program, there''s often the choices of tabs or
spaces for code indentation. There is a large amount of confusion about
which is better. It has become what''s known as a??religious wara?? a??
a heated fight over trivia. In this essay, i like to explain what is
the situation behind it, and which is proper.

Simply put, tabs is proper, and spaces are improper. Why? This may seem
ridiculously simple given the de facto ball of confusion: the semantics
of tabs is what indenting is about, while, using spaces to align code
is a hack.

Now, tech geekers may object this simple conclusion because they itch
to drivel about different editors and so on. The alleged problem
created by tabs as seen by the industry coders are caused by two
things: (1) tech geeker''s sloppiness and lack of critical thinking
which lead them to not understanding the semantic purposes of tab and
space characters. (2) Due to the first reason, they have created and
propagated a massive none-understanding and mis-use, to the degree that
many tools (e.g. vi) does not deal with tabs well and using spaces to
align code has become widely practiced, so that in the end spaces seem
to be actually better by popularity and seeming simplicity.

In short, this is a phenomenon of misunderstanding begetting a snowball
of misunderstanding, such that it created a cultural milieu to embrace
this malpractice and kick what is true or proper. Situations like this
happens a lot in unix. For one non-unix example, is the file name''s
suffix known as a??extensiona??, where the code of file''s type became
part of the file name. (e.g. a??.txta??, a??.htmla??, a??.jpga??).
Another well-known example is HTML practices in the industry, where
badly designed tags from corporation''s competitive greed, and stupid
coding and misunderstanding by coders and their tools are so
wide-spread such that they force the correct way to the side by the
eventual standardization caused by sheer quantity of inproper but set
practice.

Now, tech geekers may still object, that using tabs requires the
editors to set their positions, and plain files don''t carry that
information. This is a good question, and the solution is to advance
the sciences such that your source code in some way embed such
information. This would be progress. However, this is never thought of
because the a??unix philosophiesa?? already conditioned people to hack
and be shallow. In this case, many will simply use the character
intended to separate words for the purpose of indentation or alignment,
and spread the practice with militant drivels.

Now, given the already messed up situation of the tabs vs spaces by the
unixers and unix brain-washing of the coders in the industry... Which
should we use today? I do not have a good proposition, other than just
use whichever that works for you but put more critical thinking into
things to prevent mishaps like this.

Tabs vs Spaces can be thought of as parameters vs hard-coded values, or
HTML vs ascii format, or XML/CSS vs HTML 4, or structural vs visual, or
semantic vs format. In these, it is always easy to convert from the
former to the latter, but near impossible from the latter to the
former. And, that is because the former encodes information that is
lost in the latter. If we look at the issue of tabs vs spaces, indeed,
it is easy to convert tabs to spaces in a source code, but more
difficult to convert from spaces to tabs. Because, tabs as indentation
actually contains the semantic information about indentation. With
spaces, this critical information is lost in space.

This issue is intimately related to another issue in source code:
soft-wrapped lines versus physical, hard-wrapped lines by EOL (end of
line character). This issue has far more consequences than tabs vs
spaces, and the unixer''s unthinking has made far-reaching damages in
the computing industry. Due to unix''s EOL ways of thinking, it has
created languages based on EOL (just about ALL languages except the
Lisp family and Mathematica) and tools based on EOL (cvs, diff, grep,
and basically every tool in unix), thoughts based on EOL (software
value estimation by counting EOL, hard-coded email quoting system by
a??>a?? prefix, and silent line-truncations in many unix tools), such
that any progress or development towards a a??algorithmic code unita??
concept or language syntaxes are suppressed. I have not written a full
account on this issue, but i''ve touched it in this essay: a??The Harm
of hard-wrapping Linesa??, at
http://xahlee.org/UnixResource_dir/writ/hard-wrap.html
----
This post is archived at:
http://xahlee.org/UnixResource_dir/w...vs_spaces.html

Xah
xa*@xahlee.org
a?? http://xahlee.org/

推荐答案

实际上，空格更适合缩进代码。一个空格字符所占用的空间的确切数量将始终（或者至少倾向于b
）相同，而键盘驱动程序的每个组合，操作
精确改变tab键的功能。

在输入tab时没用对于缩进，当我的文本编辑器将

简单地将其转换为三个空格，或者更糟的是，自动添加和混合选项卡

带空格以便我不知道有多少实际的空白字符

是什么类型真正占用了所有空白。我承认它

通常不重要，但是你回去尝试使你的代码更好，并且发现自己要求WTF？


毫无疑问地为圣战添加了第二个火花，

Eli


-

经济学是自由意志的最聪明证明，

构建。

Actually, spaces are better for indenting code. The exact amount of
space taken up by one space character will always (or at least tend to
be) the same, while every combination of keyboard driver, operating
system, text editor, content/file format, and character encoding all
change precisely what the tab key does.

There''s no use in typing "tab" for indentation when my text editor will
simply convert it to three spaces, or worse, autoindent and mix tabs
with spaces so that I have no idea how many actual whitespace characters
of what kinds are really taking up all that whitespace. I admit it
doesn''t usually matter, but then you go back to try and make your code
prettier and find yourself asking "WTF?"

Undoubtedly adding the second spark to the holy war,
Eli

--
The science of economics is the cleverest proof of free will yet
constructed.

Xah Lee写道：

Xah Lee wrote:

源代码中的标签与空格

Xah Lee，2006-05-13

在编写计算机程序时，通常会选择标签或
代码缩进的空格。关于
存在大量混淆，这是更好的。它已成为所谓的宗教瓦拉？一场激烈的琐事斗争。在这篇文章中，我想解释它背后的情况是什么，哪些是正确的。

简单地说，标签是正确的，空格是不合适的。为什么？鉴于事实上的混乱球，这看起来似乎非常简单：制表符的语义是缩进的意思，而使用空格来对齐代码
是一种黑客攻击。

Tabs versus Spaces in Source Code

Xah Lee, 2006-05-13

In coding a computer program, there''s often the choices of tabs or
spaces for code indentation. There is a large amount of confusion about
which is better. It has become what''s known as a??religious wara?? a??
a heated fight over trivia. In this essay, i like to explain what is
the situation behind it, and which is proper.

Simply put, tabs is proper, and spaces are improper. Why? This may seem
ridiculously simple given the de facto ball of confusion: the semantics
of tabs is what indenting is about, while, using spaces to align code
is a hack.

i同意，标签是正确的，我总是使用tab键缩进...它放入4

空格。

Eli Gottlieb写道：

Eli Gottlieb wrote:

实际上，空格更适合缩进代码。一个空格字符占用的确切空间总是（或至少倾向于）相同，而键盘驱动程序，操作系统，文本编辑器，内容的每个组合/文件格式和字符编码全部
精确地改变tab键的作用。


你认为标签的弱点是他们的力量。它们编码''1级

缩进''，而不是固定宽度。当然，标签的呈现方式不同

由不同的编辑 - 这就是重点。如果你想缩进为2

或3或7个字符宽，你可以查看你的偏好，而不是强迫它在世界其他地方的

。这是一种合乎逻辑的而不是固定的编码。


键入tab是没有用的。对于缩进，当我的文本编辑器将它简单地转换为三个空格，或者更糟糕的是，自动添加和混合标签
与空格，以便我不知道有多少实际的空白字符
什么类型的真的占用了所有的空白。我承认它通常并不重要，但是你回去试着让你的代码更漂亮，然后发现自己要问WTF？。


听起来问题是你的编辑器，而不是标签。但我不排除

PEBCAK。 ;）


毫无疑问，为圣战添加第二个火花，

Actually, spaces are better for indenting code. The exact amount of
space taken up by one space character will always (or at least tend to
be) the same, while every combination of keyboard driver, operating
system, text editor, content/file format, and character encoding all
change precisely what the tab key does.
What you see as tabs'' weakness is their strength. They encode ''1 level of
indentation'', not a fixed width. Of course tabs are rendered differently
by different editors -- that''s the point. If you like indentation to be 2
or 3 or 7 chars wide, you can view your preference without forcing it on
the rest of the world. It''s a logical rather than a fixed encoding.

There''s no use in typing "tab" for indentation when my text editor will
simply convert it to three spaces, or worse, autoindent and mix tabs
with spaces so that I have no idea how many actual whitespace characters
of what kinds are really taking up all that whitespace. I admit it
doesn''t usually matter, but then you go back to try and make your code
prettier and find yourself asking "WTF?"
Sounds like the problem is your editor, not tabs. But I wouldn''t rule out
PEBCAK either. ;)

Undoubtedly adding the second spark to the holy war,

毫无疑问。让我们保持文明，不管吗？请将

交叉发布限制在最低限度。 （针对小组，不是你个人

Eli）。


-

Edward Elliott

加州大学伯克利分校法学院（博尔特大厅）

在eddeye dot net抱怨，

Undoubtedly. Let''s keep it civil, shall we? And please limit the
cross-posting to a minimum. (directed at the group, not you personally
Eli).

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net

这篇关于源代码中的选项卡与空格的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！