css首行缩进字符间距行高_黑暗代码风格的学院：换行，间距和缩进

css首行缩进字符间距行高

Hey guys! Let me walk you through the next part of our dark-style code academy. In this post, we will discover some other ways how to slow down the reading speed of your code. The next approaches will help you to decrease maintenance and increase a chance to get a bug in your code. Ready? Let's get started.

大家好！ 让我向您介绍我们的深色代码学院的下一部分。 在本文中，我们将发现其他一些方法来降低代码的读取速度。 下一种方法将帮助您减少维护并增加获得代码错误的机会。 准备？ 让我们开始吧。

换行，间距和缩进可能会导致死亡 (Line breaks, spacing, and indentation may kill)

How do people read books? From up to bottom, from left to right (at least majority). The same happens when developers read code. One line should give only one thought, therefore every line should match only one command. If you want to confuse other developers you'd better violate those principles. And I will show you how.

人们如何读书？ 从上到下，从左到右(至少占多数)。 开发人员阅读代码时也会发生同样的情况。 一行应该只考虑一个问题，因此每一行应该只匹配一个命令。 如果要混淆其他开发人员，则最好违反这些原则。 我会告诉你如何。

情况1 (Case #1)

Look at this piece of code. One idea per line. It is so clean so it makes me sick.

看一下这段代码。 每行一个主意。 太干净了，让我恶心。

return elements
    .Where(element => !element.Disabled)
    .OrderBy(element => element.UpdatedAt)
    .GroupBy(element => element.Type)
    .Select(@group => @group.First());

We can join all statements into one line, but it's going to be too easy. In this way, the developer's brain will understand that something is wrong and will parse your statements from left to right. Easy-peasy!

我们可以将所有语句合并为一行，但这太简单了。 通过这种方式，开发人员的大脑将了解到出了什么问题，并将从左到右解析您的陈述。 十分简单！

The better way is to leave a couple of statements per one line and some on own separate one. The best scenario is when a developer might not even notice some statements which will lead to misunderstanding and to a bug eventually. In another way, we will just slow down his understanding of this code due to the parsing and "WTF" screaming.

更好的方法是在每一行中保留几个语句，而另一些则单独保留。 最好的情况是，开发人员甚至可能没有注意到一些会导致误解并最终导致错误的语句。 换句话说，由于解析和“ WTF”的尖叫，我们只会减慢他对这段代码的理解。

return elements.Where(e => !e.Disabled)
    .OrderBy(e => e.UpdatedAt).GroupBy(e => e.Type)
    .Select(g => g.First());

How cool is that? You can add some indentation so other developers will be aligning your code for decades if they need to rename elements variable.

多么酷啊？ 您可以添加一些缩进，以便其他开发人员如果需要重命名elements变量，将使您的代码保持数十年。

return elements.Where(e => !e.Disabled)
               .OrderBy(e => e.UpdatedAt).GroupBy(e => e.Type)
               .Select(g => g.First());

Send me a postcard if this approach passed code review in your team.

如果此方法在您的团队中通过了代码审查，请寄给我一张明信片。

Lesson: Leave a couple of statements per one line and someplace on their own lines.

课程：每行各行几条陈述，并在自己行中的某处。

情况＃2 (Case #2)

Absolutely the same idea here. But this code you can see more often.

这里的想法完全相同。 但是您可以经常看到此代码。

var result = 
    (condition1 && condition2) || 
    condition3 || 
    (condition4 && condition5);

Action items are the same as well. Split lines to confuse as much as you can. Play a little with line breaks to choose the best option.

动作项目也相同。 分割线以使您尽可能地感到困惑。 玩点换行，选择最佳选项。

var result = (condition1 && condition2) || condition3 || 
    (condition4 && condition5);

And plus some indentation to make it like normal code.

加上一些缩进使其像普通代码一样。

var result = (condition1 && condition2) || condition3 || 
             (condition4 && condition5);

Remember, you have to keep a balance between the unreadability of your code and the believability of your excuse.

请记住，您必须在代码的可读性和借口的可信度之间保持平衡。

Lesson: Play with line breaks to choose the best option.

课程：玩换行符以选择最佳选项。

情况＃3 (Case #3)

What about this one?

这个如何？

if (isValid) 
{ 
    _unitOfWork.Save();
    return true; 
} 
else 
{ 
    return false; 
}

Same problem but in another shade. Here is the best way to join all statements into one line and, of course, leave curly braces.

同样的问题，但又有阴影。 这是将所有语句合并为一行并保留大括号的最佳方法。

if (isValid) { _unitOfWork.Save(); return true; } else { return false; }

This approach will work only in case you don't have many statements in then and else blocks. Otherwise, your code may be rejected on the code-review stage.

只有在then和else块中没有很多语句的情况下，这种方法才有效。 否则，您的代码可能会在代码审查阶段被拒绝。

Lesson: Join small if/for/foreach statements into one line.

课程：将小的if/for/foreach语句合并为一行。

情况＃4 (Case #4)

80 characters per line is a standard which is preferable even today. This allows you to keep a developer concentrated while reading your code. Moreover, you can open two documents simultaneously per one screen when you need and there is a place left for your solution explorer.

每行80个字符是一个标准，即使在今天也是首选。 这使您可以在阅读代码的同时保持开发人员的注意力。 此外，您可以在需要时在每个屏幕上同时打开两个文档，并且有一个地方可供解决方案浏览器使用。

bool IsProductValid(
    ComplexProduct complexProduct, 
    bool hasAllRequiredElements, 
    ValidationSettings validationSettings)
{
    // code
}

The easiest way to slow down reading your code is to let other developers scrolling your code horizontally. Just ignore the rule of 80 characters.

减慢代码读取速度的最简单方法是让其他开发人员水平滚动代码。 只需忽略80个字符的规则。

bool IsProductValid(ComplexProduct complexProduct, bool hasAllRequiredElements, ValidationSettings validationSettings)
{
    // code
}

It is super easy to forget what was before you start scrolling or miss the line where you have started. Nice trick.

超级容易忘记开始滚动之前的内容，或者错过开始的行。 好招

Lesson: Ignore the rule of 80 characters on purpose.

课程：故意忽略80个字符的规则。

案例5 (Case #5)

An empty line in the right place is a powerful instrument to group your code up and increase reading speed.

在正确位置的空行是一种强大的工具，可以将您的代码分组并提高读取速度。

ValidateAndThrow(product);

product.UpdatedBy = _currentUser;
product.UpdatedAt = DateTime.UtcNow;
product.DisplayStatus = DisplayStatus.New;

_unitOfWork.Products.Add(product);
_unitOfWork.Save();

return product.Key;

An empty line in the wrong place along with other tips from these lessons may help you to save your job. Which empty line do you prefer?

在错误的地方出现空白行以及这些课程中的其他技巧可能会帮助您节省工作。 您更喜欢哪个空行？

ValidateAndThrow(product);
product.UpdatedBy = _currentUser;
product.UpdatedAt = DateTime.UtcNow;

product.DisplayStatus = DisplayStatus.New;
_unitOfWork.Products.Add(product);

_unitOfWork.Save();
return product.Key;

Lesson: Place empty lines randomly.

课程：随机放置空行。

情况＃6 (Case #6)

When you commit your code to a repository, there is a teeny-tiny possibility that you can take a look at what you are committing. DONT DO THIS! It is ok if you added an extra empty line like this.

当您将代码提交到存储库时，很有可能您可以查看自己提交的内容。 不要这样做！ 可以添加一个额外的空行，这样是可以的。

private Product Get(string key) 
{
    // code
}

private void Save(Product product) 
{
    // code
}

Or, which is better, some extra spaces on the empty line here (just select line 5).

或者，更好的方法是在此处的空行上留一些多余的空间(只需选择第5行)。

private Product Get(string key) 
{
    // code
}

private void Save(Product product) 
{
    // code
}

Why do you need it? The code is still working (but that's not for sure). You still understand your code. Another developer will understand your code less. You can' just add some extra spaces overall methods at once in your project (code review is our enemy), but using this practice you will get some mess in a couple of weeks of active development.

你为什么需要它？ 该代码仍在工作(但不确定)。 您仍然了解您的代码。 另一个开发人员会减少您的代码。 您可以在项目中一次添加一些额外的总体空间方法(代码审查是我们的敌人)，但是使用这种做法，在几周的积极开发中会有些混乱。

One additional benefit from using extra spaces per line is that when other developers will commit some related functionality, their IDE may automatically fix file formatting. On code review, they will see thousands of same red and green lines. If you know what I mean ;)

每行使用额外的空间的另一个好处是，当其他开发人员提交某些相关功能时，他们的IDE可能会自动修复文件格式。 在代码审查中，他们将看到数千条相同的红线和绿线。 如果你明白我的意思 ;)

For this reason, you can set up tabs on your IDE if you have spaces on your project and vice versa.

因此，如果项目中有空格，则可以在IDE上设置选项卡，反之亦然。

Lesson: Do not look at the code before commit.

课程：提交之前请勿查看代码。

案例＃7 (Case #7)

Bypass those developers who can see extra space in this code. They are dangerous for your career.

绕过那些可以在此代码中看到额外空间的开发人员。 它们对您的职业生涯很危险。

product.Name = model.Name;
product.Price = model.Price;
product.Count =  model.Count;

Lesson: Know your enemy.

教训：认识你的敌人。

Hard work will make your code unmaintainable. When you gather lots of small issues then they will be growing without your input. Junior developers will be writing their code by your template. Once, on a wonderful day, during your code review, you will hear "WFT?" from your team lead and you will get an opportunity to use the famous phrase: "What? We always do like this." And then you can point him to a thousand places like this one. Enjoy.

艰苦的工作会使您的代码难以维护。 当您收集到许多小问题时，如果没有您的投入，它们将会不断增长。 初级开发人员将通过您的模板编写代码。 有一次，在美好的一天中，在代码审查期间，您将听到“ WFT？”。 从您的团队领导那里，您将有机会使用著名的短语：“什么？我们总是这样做。” 然后您可以将他指向类似这样的一千个地方。 请享用。

翻译自: https://habr.com/en/post/517690/

css首行缩进字符间距行高