sql缩进提高语句的可读性_为什么要使用列缩进来提高代码的可读性

sql缩进提高语句的可读性

by Leonardo Carreiro

莱昂纳多·卡雷罗(Leonardo Carreiro)

为什么要使用列缩进来提高代码的可读性 (Why you should use column-indentation to improve your code’s readability)

I think that the most important aspect of programming is the readability of the source code that you write or maintain. This involves many things, from the syntax of the programming language, to the variable names, comments, and indentation. Here I discuss the last one of these, indentation.

我认为编程最重要的方面是您编写或维护的源代码的可读性。 从编程语言的语法到变量名，注释和缩进，这涉及很多事情。 在这里，我讨论其中的最后一个缩进 。

It’s not about indentation size, or the choice between tabs and spaces, or if it should be required in a language such as Python. A lot of people like to use a maximum line length for each line of code, usually 80 or 120 characters. With this idea, there is no maximum length, and sometimes you’ll need to use the horizontal scrollbar. But don’t freak out, it is not for the whole code — it’s just for some parts of it.

这与缩进大小，制表符和空格之间的选择无关，也与Python等语言中的要求无关。 许多人喜欢为每行代码使用最大行长，通常为80或120个字符。 有了这个主意，就没有最大长度了，有时您需要使用水平滚动条。 但是请不要惊慌，它并不适用于整个代码，而仅适用于部分代码。

使用代码缩进的四个改进示例 (Four examples of improvements using code indentation)

第一个例子 (First example)

Take a look at this code:

看一下这段代码：

The readability is not so good, and you could end up with something like this to avoid the mess:

可读性不是很好，为了避免混乱，您可能会得到如下所示的结果：

And your seven lines have turned into almost 40 lines. This with just three or four properties per object. If it was eight properties, it would become 70 lines.

而您的七行已变成近40行。 每个对象只有三个或四个属性。 如果它是8个属性，它将变成70行。

The idea that I’m talking about is to use something like this (I call it “column- indented” code):

我正在谈论的想法是使用类似以下的代码(我称其为“列缩”代码)：

第二个例子 (Second example)

It’s not just for object literals. It can be used for any piece of code that is a group of similar lines. This process can be quick. You can copy the first line, paste it, and then overwrite the changing pieces in each line.

这不仅仅是对象文字。 它可以用于一组相似行的任何代码。 这个过程可能很快。 您可以复制第一行，将其粘贴，然后覆盖每行中的更改项。

It can be used in JS import too. Compare these two versions:

它也可以在JS import使用。 比较这两个版本：

These thirteen imports are alphabetically ordered by the path. All of them are from the vs folder — five from vs/base and eight from vs/platform.

这十三种导入按路径的字母顺序排列。 它们全部来自vs文件夹-五个来自vs/base ，八个来自vs/platform 。

You can’t see that without moving your eyes back and forth across each line. Doing this is annoying. Of course, you don’t need to make statistics about how your files are importing others. But at some time you will read this code to see if you imported something from the correct file, or if a file was already imported.

您必须在每一行上来回移动眼睛才能看不到它。 这样做很烦人。 当然，您无需统计有关文件如何导入其他文件的统计信息。 但是有时您会阅读此代码，以查看是否从正确的文件中导入了某些内容，或者是否已经导入了文件。

Now see how it looks when the same code is column-indented:

现在看一下相同代码以列缩进时的外观：

Doesn’t that make it a little better?

那不是更好一点吗？

第三个例子 (Third example)

In this example, we have a method declaration from TypeScript compiler:

在此示例中，我们有来自TypeScript编译器的方法声明：

Again, you can see the difference between the lines more easily. It helps you to read all the five lines at the same time, spending way less effort. And, if you need to add a parameter in each of these 5 lines, you can do it just one time, using the multiline cursor in almost all code editors.

同样，您可以更轻松地看到线之间的差异。 它可以帮助您同时阅读所有五行内容，从而减少了工作量。 而且，如果您需要在这5行中的每行中添加一个参数，则可以使用几乎所有代码编辑器中的多行光标一次完成此操作。

第四个例子 (Fourth example)

Here is the final example, with the original and comparison together:

这是最后的示例，将原始示例和比较示例结合在一起：

Pros:

优点 ：

• Your code looks cleaner.
  您的代码看起来更干净。
• Your code has improved readability
  您的代码提高了可读性
• You may be able to reduce the number of lines in your code
  您也许可以减少代码中的行数

Cons:

缺点 ：

• The auto-formatting option of code editors can interfere with the layout
  代码编辑器的自动格式化选项可能会干扰布局
• When adding one line to a block of lines, sometimes you have to change all the other lines
  在一行中添加一行时，有时您必须更改所有其他行
• It can be time-consuming to write code
  编写代码可能很耗时

哪些工具可以帮助实现这一目标？ (What tools can help to achieve this?)

I did indentation this way, manually, for some time. It’s boring, but once you start doing it, you can’t stop. You look at your code, all those repeated lines that could be column-indented to be more readable, and you can’t go on without doing it. It’s addictive.

我以这种方式手动缩进了一段时间。 这很无聊，但是一旦开始做就无法停止。 您看一下代码，所有那些重复的行可能会以列缩进以提高可读性，如果不这样做，您将无法继续。 令人上瘾。

I use Visual Studio and Visual Studio Code, so I tried to find an extension or plugin that helps achieve this. I didn’t find any. So in November 2017 I started to create my own extension for Visual Studio Code and named it Smart Column Indenter.

我使用Visual Studio和Visual Studio Code，因此我尝试找到有助于实现此目的的扩展或插件。 我没找到 因此，在2017年11月，我开始为Visual Studio Code创建自己的扩展并将其命名为Smart Column Indenter 。

I published a first usable version in the same month. Take a look at how it works:

我在同月发布了第一个可用版本。 看一下它是如何工作的：

There are areas where the extension could be improved. Currently, it only works with *.ts, *.js and *.json files. I think that it could help with XML and HTML files too, like column-indenting the same attributes of repeated tags, or different tags that are repeated in a group of lines.

在某些方面可以改进扩展。 当前，它仅适用于*.ts ， *.js和*.json文件。 我认为它也可以帮助处理XML和HTML文件，例如将重复标签的相同属性列缩进，或者在一组行中重复的不同标签。

Once the code is selected for column-indentation, the algorithm works in three steps:

一旦选择了用于列缩进的代码，该算法将分三个步骤工作：

1. Lexical analysis (or tokenization) of the code. I installed the TypeScript npm package as a dependency and used the Compiler API to avoid reinventing the wheel here.

   代码的词法分析(或标记化)。 我安装了TypeScript npm软件包作为依赖项，并使用了Compiler API以避免在这里重新发明轮子。

2. Execute the Longest Common Subsequence (LCS) algorithm passing each line of code as a sequence of tokens. This is the hard part. A lot of references on the internet talk about the LCS for just two sequences as input, which is easily solved with dynamic programming. As we usually want to column-indent more than two lines of code, the problem becomes finding the longest common sequence (LCS) of multiple strings. This is a NP-hard problem. As this is a generic problem, I created a separated npm package (multiple-lcs) with a basic implementation to accomplish this. It isn’t the best solution in some cases, but it is workable.

   执行最长公共子序列(LCS)算法，将每行代码作为令牌序列传递。 这是困难的部分。 互联网上有很多参考文献都只是将两个序列作为输入来讨论LCS，这可以通过动态编程轻松解决。 由于我们通常希望对两行以上的代码进行列缩进，因此问题就变成了找到多个字符串的最长公共序列(LCS)。 这是一个NP难题 。 由于这是一个通用问题，因此我创建了一个单独的npm软件包( multi-lcs )，并使用基本实现来完成此任务。 在某些情况下，它不是最佳解决方案，但它是可行的。

3. Rewrite the code to column-indent the tokens that appear in the LCS. Each token in the LCS is placed in a new column.
   重写代码以对LCS中出现的令牌进行列缩进。 LCS中的每个令牌都放置在新列中。

For some types of tokens, such as strings or variables names, the type name is used instead the content in the LCS algorithm. The result is a larger sub-sequence.

对于某些类型的令牌，例如字符串或变量名，将使用类型名代替LCS算法中的内容。 结果是较大的子序列。

I put all the logic in a separate npm package (smart-column-indenter). If you want to create an extension or plugin like this for another JavaScript-based IDE, you can use this package.

我将所有逻辑放在单独的npm软件包( smart-column-indenter )中。 如果要为另一个基于JavaScript的IDE创建这样的扩展程序或插件，则可以使用此包。

My initial reason to create this solution was proof-of-concept. I would like to know what other programmers think about my solution. If you liked it, please clap.

创建此解决方案的最初原因是概念验证。 我想知道其他程序员对我的解决方案的看法。 如果喜欢，请鼓掌 。

If you have constructive criticism, or know of other tools that do the same thing, please leave a comment. This is an article that I found useful.

如果您有建设性的批评，或者知道其他做同样事情的工具，请发表评论。 这是我觉得有用的文章 。

Thanks for reading.

谢谢阅读。

Update (2018–03–29): After it was published a few days ago, I got a lot of feedback, most of them are negatives, but thank you all anyway, it’s good to know why a lot of people don’t like it. I found out later that people usually call it “code alignment”, you won’t find anything about “column indentation”, so if you want to search more about this, search for “code alignment” instead. I did it, and I found an interesting blog post from Terence Eden’s Blog, as most of the negative comments are about issues with VCS merges, history and dirty diffs, I’ll copy his conclusion: “If our tools make understanding those ideas more difficult, it’s the tools which need to change — not us.”

更新(2018-03-29)：在几天前发布之后，我得到了很多反馈，其中大多数是负面的，但无论如何还是要谢谢，很高兴知道为什么很多人不喜欢它。 后来我发现人们通常称其为“代码对齐”，您将找不到关于“列缩进”的任何信息，因此，如果您想对此进行更多搜索，请搜索“代码对齐”。 我做到了，我从Terence Eden的Blog中找到了一篇有趣的博客文章 ，因为大多数负面评论都是关于VCS合并，历史记录和肮脏差异的问题，我将复制他的结论：“如果我们的工具能使人们更好地理解这些想法，困难，这是需要改变的工具，而不是我们。”

Update (2018–05–03): As if someone at GitHub team had read the negative comments about code alignment here, now you can ignore white spaces in code review.

更新(2018–05–03)：好像GitHub团队的某人在这里阅读了有关代码对齐的负面评论， 现在您可以在代码审查中忽略空格 。

Update (2018–05–20): If you use Visual Studio (not Code), Shadman Kudchikar made a similar extension, you can read about it here or download it here.

更新(2018年5月20日)：如果您使用Visual Studio(没有代码)， Shadman Kudchikar提出了类似的扩展，你可以看到它在这里或下载它在这里 。

类固醇 (Factoid)

We have now 22" screens with 1920x1080 resolution. There is no reason to limit yourself to 80 characters per line, although you need to decide on the maximum limit. The origin of this 80-characters limit is:

现在，我们拥有22英寸分辨率为1920x1080的屏幕。尽管您需要确定最大限制，但没有理由将自己限制为每行80个字符。此80个字符的限制的起因是：

翻译自: https://www.freecodecamp.org/news/how-to-columnize-your-code-to-improve-readability-f1364e2e77ba/

sql缩进提高语句的可读性