Question

我正在做Meteor.js教程，这件事引起了我的注意。我对编码有点新意，我不想从错误开始。

对我来说，似乎从某些行中选择信息以使其排列是比不做的更漂亮。我想知道这样做是否是一种好习惯。

实施例

非标签：

export default createContainer(() => {
    return {
        tasks: Tasks.find({}, { sort: { createdAt: -1 } }).fetch(),
        incompleteCount: Tasks.find({ checked: { $ne: true } }).count(),
        currentUser: Meteor.user(),
    };
}, App);

选项卡（对我而言似乎更好）：

export default createContainer(() => {
    return {
        tasks:              Tasks.find({}, { sort: { createdAt: -1 } }).fetch(),
        incompleteCount:    Tasks.find({ checked: { $ne: true } }).count(),
        currentUser:        Meteor.user(),
    };
}, App);

Answer 1

是的，我也喜欢你的风格。但是，当您更改属性的名称（或在IDE中自动重命名它们）时，维护是多么容易。

我认为人们不使用这种风格的主要原因是维护它是不可能的（非常困难的）。

如果你共享你的代码，其他人可能没有相同的标签设置，根本不会看起来很漂亮。

如果它只是您自己的代码，请按您喜欢的格式进行格式化。你的风格非常易读，但你可能会觉得很难维护。

Answer 2

我会尽可能客观地回答，因为这是一个Q＆amp;一个网站，不适合自以为是的辩论：

Tabbing - PRO：

视觉提示，可以说是更快的视觉解析键和值

标签 - CONTRA：

标签宽度取决于编辑器，不同的标签宽度可能会破坏对齐
添加或删除密钥可能需要编辑所有其他值＆＃39;压痕

我在小/静态代码片段中看到过这种缩进，其主要目的是促进理解/教学。我很少看到生产代码中使用的缩进，这些缩进会经常更改或重构。

Answer 3

一旦你开始加入一个大型团队，样式中存在巨大的差异......

如果您从该列表中添加或删除某个键，则必须重新格式化多行。

当我通过版本控制试图弄清楚对文件做了哪些更改时，它会被各种空白区域变化所困扰，然后我必须检查它们是否重要。

保持杂乱无章！

Answer 4

正如其他人所说，这取决于你自己的偏好。要知道的是，你不一定要自己做标签。您可以编写代码，然后在文本编辑器中使用jsbeautifier或本地reindenter等资源。

Answer 5

我们需要对齐吗？

如果这些实际上是以完美的方式对齐的，那么开发人员阅读代码应该更容易完成哪些任务？

例如，我们是否需要同时查看两条或更多条线来比较它们？

为什么我们需要比较这些线？

tasks (a colection)
incompleteCount (a number)
currentUser (an object)

我找不到一个这样的例子，所以我的结论是：无需比较 - 无需对齐。

是否存在对齐的事情？

现在，如果您找到将这段代码与标签对齐的理由，那么让我们看一下对齐的版本，并尝试查看它是否以某种有用的方式实际对齐。

事实证明，它最初看起来只是一个更结构化的代码。

方法名称与Tasks对象对齐的事实并没有增加整体可读性 - 在本例中它甚至没有与第三行对齐：

| <- this is the last column that is aligned
|Tasks.|
|Tasks.|
|Meteor.| <- // not aligned anymore, shift one character.

因此，此时标签结构已经开始破坏。

现在，如果你看一下其余部分，你可能会发现事情没有对齐。让我们切断视觉结构的左栏，然后单独查看选项卡式变体的右栏：

... .find({}, { sort: { createdAt: -1 } }).fetch(),
... .find({ checked: { $ne: true } }).count(),
...  .user(),

如果你问我，如果我试图将它作为一个整体来看是一团糟，那么标签在这里没有帮助。

这种对齐有什么含义？

需要不必要的努力

这是最烦人的一个。 IDE中的自动格式化工具不能很好地支持这种对齐。实际上，您可能会使用IDE进行操作，以便在您触摸这些行时随时更新此格式。

可能会干扰版本控制。

是的，您可以在各种版本控制工作流程中转换某种忽略witespace 功能，但是再次 - 我们需要花费很多开销。

设计不一致

代码不是一成不变的，而是在不断发展。如果稍后添加某些内容，则可能会破坏不相关行中的对齐。

tasks:          |
incompleteCount |
currentUser     |
someOtherMethodAddedLater | <- the first three have to keep up with this one

另一个不一致的地方是字符宽度在所有字体中都不是常数，正如有人想象的那样。

有等宽字体和非等宽字体，带标签的装饰只适用于等宽字体。如果在IDE中使用非等宽字体，则制表符布局会生效，因为行中非空白字符后的任何空格都不具有在视口中具有确定位置的属性。

不是视觉提示，恰恰相反！

尝试查找与属性名称对应的右侧的行： a4，没有用鼠标选择源代码。

aa:                                    Methods.methodY(453),
ab:                                    Methods.methodZ(554),
a1:                                    Methods.methodX(143),
a2:                                    Methods.methodZ(235),
a3:                                    Methods.methodY(223),
a4:                                    Methods.methodY(334),
a5:                                    Methods.methodY(445),
a6:                                    Methods.methodZ(554),
a7:                                    Methods.methodX(734),
a11:                                   Methods.methodX(143),
a12:                                   Methods.methodZ(235),
a13:                                   Methods.methodY(735),

问题在于，使用witespace，在没有水平网格线的情况下匹配左侧和右侧的项目并不容易。

当您尝试使用标签格式化代码时也会发生同样的情况。

这在没有空格的文本中不是问题，因为非空白字符构成整个文本行的可视链接。例如，在本文中，按行分组单词并不是一个问题。

因此，当您将代码页视为视觉模式时，它可能最初看起来更有条理，但实际上它与视觉链接的联系更少，并且更难以阅读。

因此，虽然使用制表符是一种使代码页在某种程度上具有视觉吸引力的做法，但答案是 - 不，这不是一个好习惯。

选择代码是为了对齐，编写更好的代码是一个很好的实践吗？

5 个答案: