万一你醒来时花儿正在手中_醒来让你的床清理代码

万一你醒来时花儿正在手中

This post is all about clean code: Why is it important? How do I write clean code?

这篇文章都是关于干净的代码的：为什么它很重要？ 我该如何编写干净的代码？

Messy code is like cookies. Or, drugs, if that’s your speed. You say to yourself, ‘eh, just one won’t hurt’. And you are right, depending on the cookie (or the drug). But then, before you know it, you have 100, and whatever minimal harm the one caused you is now multiplied and wreaking havoc on your arteries/physique/dopaminergic neural systems.

凌乱的代码就像Cookie。 或者，如果那是您的速度，那就是毒品。 您对自己说：“嗯，只有一个人不会受伤”。 您是对的，取决于Cookie(或药物)。 但是，在不知不觉中，您有100人，而无论造成的最小伤害，现在都成倍增加，对动脉/体格/多巴胺能神经系统造成了严重破坏。

Messy code is like that. You start out on a blank code canvas and begin typing away. Over the next few days, you begin to add functionality to your app, and the coding is quick and easy. You are happy.

凌乱的代码就是这样。 您从空白代码画布开始，然后开始键入。 在接下来的几天里，您将开始向您的应用程序添加功能，并且编码变得简单快捷。 你很高兴。

Fast-forward one week. You now have 60 different variables. Your functions are 20 lines long. Everything in your code is interdependent, and every time you change a single line, you get an unexpected bug. You are not happy.

快进一个星期。 您现在有60个不同的变量。 您的函数长20行。 代码中的所有内容都是相互依赖的，并且每次更改一行时，都会遇到意外错误。 你不开心

This problem does not go away on its own, and will only get worse as your code grows more complex. Imagine 100 million lines of code (aka, the typical code in a modern car), all written in this haphazard fashion. Things can get messy; every single choice you make counts.

这个问题不会自行消失，只会随着代码变得越来越复杂而变得更糟。 想象一亿行代码(又名现代汽车中的典型代码)，它们都是以这种随意的方式编写的。 事情可能变得凌乱； 您做出的每一个选择都很重要。

If you are a backpacker, you know what I mean. New backpackers pack lots of things into their pack. They think ‘this one-pound jar of peanut butter won’t make a difference’, until they’ve added 20 extra one-pound things which they now have to carry on their back for 10 miles. Experienced backpackers know that the weight adds up, and will make small decisions to reduce it at every opportunity. Some backpackers cut off the bottom half of their toothbrush for this reason — no opportunity is too small.

如果您是背包客，您就会明白我的意思。 新的背包客将很多东西打包。 他们认为“这一磅花生酱罐不会有所作为”，直到他们添加了20磅额外的一磅东西之后，他们现在必须背负10英里。 有经验的背包客知道重量会累加，因此会做出小小的决定，以在每一个机会减少重量。 由于这个原因，一些背包客砍掉了牙刷的下半部分-没有机会会太少。

We Developers can learn from the Backpackers.

我们的开发人员可以向背包客学习。

什么是干净代码？ (What Is Clean Code?)

Ralph Waldo Emerson once said:

拉尔夫·沃尔多·爱默生曾经说过：

Clean code reads like well-written prose.

干净的代码读起来像写得很好的散文。

Actually, it was Grady Booch who said this. Either way, he makes an interesting point — Someone looking at our code for the first time should be able to read it easily. Our code should tell people what it does. Let’s walk through an example to demonstrate this:

实际上，是格雷迪·布赫 ( Grady Booch )这样说。 无论哪种方式，他都提出了一个有趣的观点-第一次看我们的代码的人应该能够轻松阅读它。 我们的代码应告诉人们它的作用。 让我们来看一个例子来说明这一点：

←This is a function that I took from an early CLI application that I built with a partner. It’s been trimmed down a bit.

←这是我从与合作伙伴一起构建的早期CLI应用程序中获得的功能。 它已经被修剪了一点。

.

。

.

。

←Here’s what it looked like before it was cleaned up

←这里是它清理之前的样子

When asked to make sense of the code, which one of these would you rather be presented with? Obviously, the first one. If you are like me, you will look at the second one and not even bother. As programmers, we are lazy, and this is a virtue. Nobody wants to parse through long, confusing functions; we want to be told the meaning of a function in simple, readable terms.

当被要求理解代码时，您希望使用其中之一？ 显然是第一个。 如果您像我一样，您会看第二个，甚至不会打扰。 作为程序员，我们很懒惰，这是一种美德。 没有人想通过冗长而令人困惑的功能来解析； 我们希望以简单易懂的术语来告知函数的含义。

The first example is also, happily, much easier to debug. It’s much easier to separate relevant details from non-relevant details when they are refactored into completely different functions. Looking at the second example, even if you were the one who coded it (ehem *cough*), it is difficult to know at first glance exactly which lines are doing what, and what bigger task they lend themselves toward.

令人高兴的是，第一个示例更容易调试。 当将相关细节重构为完全不同的功能时，将相关细节与不相关细节分开会容易得多。 看第二个例子，即使您是编码的那个例子(ehem *咳嗽*)，乍一看也很难确切地知道哪些行在做什么，以及它们要承担哪些更大的任务。

怎么做 (How To Do It)

If you are wanting to clean up your code but don’t know how, here are a few places you can start:

如果您想清理代码但不知道如何做，那么可以从以下几个地方开始：

1.)以有用的方式命名变量和函数。 (1.) Name Your Variables and Functions in a Helpful Way.)

While I was refactoring my example, I came across this line:

在重构示例时，我遇到了以下问题：

It wasn’t immediately clear to me what this function did. Did it execute the main functions of choice 4? Was 4 being used as a lame substitute for the word “for”? The problem is there’s no verb in this function’s name. Let’s be more explicit:

目前尚不清楚该功能的作用。 它是否执行选择项4的主要功能？ 4是否被用作“ for”一词的la脚替代品？ 问题在于此函数的名称中没有动词。 让我们更明确一点：

I know this seems insignificant, but remember, learn from the Backpackers!

我知道这似乎微不足道，但请记住，向背包客学习！

2.)摆脱掉，] {-0] \ |？'：@＃4 ^`：”。'/” p;” [p;'] (2.) Get Rid Of ,]{-0]\|?’:@#4^`:”.’/”p;”[p;’])

Glance over these lines:

浏览以下几行：

This → (“, “)[0] ← is an eyesore. Reading these lines, it’s not immediately obvious what they are for. It’s simple enough to figure out, but they do not read like well-written prose. The meaning could be stated much more clearly:

这→(“，”)[0]←是令人讨厌的。 阅读这些行，并不清楚它们的用途。 找出原因很简单，但是他们读起来并不像写得好的散文。 含义可以说得更清楚：

What does the first method do? It gets the name from the response! Once again, this is small but it goes a long way.

第一种方法有什么作用？ 它从响应中获取名称！ 再次，这虽然很小，但是很长的路要走。

3.)将逻辑分为辅助方法 (3.) Separate Logic into Helper Methods)

Here we have an if/else clause:

这里我们有一个if / else子句：

This would look much better if we simply condensed the 2nd-5th lines into a statement (read: method name) about what they do:

如果我们仅将第2-5行压缩成一个关于它们的作用的语句(读：方法名)，那看起来会好得多：

They show the event!

他们展示了活动！

If you look back at the finalized version of the code, you’ll see that these lines, along with the lines from the previous examples, are all delegated to helper methods, which are conglomerated into a single method which is called “search_and_show_event_with_details” :

如果回头看一下代码的最终版本，您会发现这些行以及前面示例中的行都委托给helper方法，这些方法合在一起成为一个名为“ search_and_show_event_with_details”的方法：

These are just a few examples of how you can refactor your code to make it more readable. Doing this everywhere will make a huge difference in your code, and those reading your code will thank you for it.

这些只是如何重构代码以使其更具可读性的几个示例。 随处执行此操作将对您的代码产生巨大的影响，而阅读您的代码的人将为此而感激。

一些经验法则 (Some Rules of Thumb)

1.)尽量减少缩进 (1.) Keep Your Indents to a Minimum)

You don’t want your code to look like this:

您不希望您的代码看起来像这样：

from Google Images

来自Google图片

If your code has large whitespace arrows like the example above, you can almost certainly refactor. You should probably start getting concerned at 3 indents, maybe less.

如果您的代码像上面的示例一样具有较大的空格箭头，则几乎可以肯定地进行重构。 您可能应该开始担心3个缩进，也许更少。

2.)函数应接受2-3个或更少的参数 (2.) Functions Should Accept 2-3 Arguments or Less)

This is just a rule I’ve heard floating around, and not hard or fast. My guess is that if your function is taking in more than this, it’s likely doing more than one thing. Functions should do one thing, and one thing only.

这只是我听说过的一条规则，并非一成不变。 我的猜测是，如果您的函数承担的职能不止于此，那么它可能要做的不止一件事。 函数应该做一件事，而只能做一件事。

3.)尽量减少评论 (3.) Keep Comments to a Minimum)

If your code needs extra explanation, it must not be doing a good job of explaining itself. Maybe it can be made more clear without using a comment. Plus, as discussed in this video, “comments are often lies waiting to happen.” That is, if the code that is being described by the comment changes, the comment will also need to change— if it doesn’t, it will be incorrect and misleading. This is not to say that comments are a bad thing, because they are not. This rule of thumb is definitely context-dependent, but still worth considering.

如果您的代码需要额外的说明，那么它一定不能很好地说明自己。 也许可以不加评论而使其更加清晰。 另外，如本视频所述 ，“评论常常是等待发生的谎言。” 也就是说，如果注释所描述的代码发生更改，那么注释也将需要更改；否则，注释将是不正确的并且具有误导性。 这并不是说评论是一件坏事，因为它们不是。 此经验法则绝对取决于上下文，但仍值得考虑。

The more I gain experience with coding, the more I realize how important it is to have clean code. Projects/applications get complex VERY quickly. If your code is jumbled/messy, or even if it isn’t immediately obvious what the code does, it can become a headache that only cuts into efficiency. I have not yet worked on a large development team, but I can only imagine what it will be like to work on a large/complex project with many contributors, if the code is not clear and readable. In summary, I will leave you with this graph:

我获得的编码经验越多，我就越清楚拥有清晰的代码的重要性。 项目/应用程序变得非常复杂。 如果您的代码混乱不堪，甚至无法立即看出代码的作用，也可能会变成头痛，只会降低效率。 我尚未在大型开发团队工作过，但是我只能想象如果代码不清晰易读，在具有许多贡献者的大型/复杂项目中工作将是什么样子。 总而言之，我将为您提供以下图表：

source: https://www.geeksforgeeks.org/7-tips-to-write-clean-and-better-code-in-2020/

来源： https : //www.geeksforgeeks.org/7-tips-to-write-clean-and-better-code-in-2020/

翻译自: https://medium.com/@ryanwerner_57863/wake-up-make-your-bed-clean-your-code-1a1bed2b3cec

万一你醒来时花儿正在手中