评论点赞的接口可以写一起吗_我应该写评论吗？

评论点赞的接口可以写一起吗

We’re often told that comments are very important. Comments are a big and important part of programming. As a beginner it’s difficult to judge and determine how many comments you should add, and what to write in comments!

人们经常被告知评论非常重要。 注释是编程的重要组成部分。 作为初学者，很难判断和确定应该添加多少注释以及在注释中写些什么！

That’s one of the things that are not fixed in stone, everyone seems to have a different and contrasting opinion, and so this leaves you in a limbo filled with insecurity.

这不是一成不变的事情，每个人似乎都有不同和相反的看法，因此这使您陷入了充满不安全感的困境。

This is my line of thinking: you should write comments, as few as you possibly can, to explain your decisions.

这是我的思路： 您应该写一些评论来解释您的决定 。

Let’s dissect this.

让我们对此进行剖析。

Your code should be self explanatory, as much as you can.

您的代码应尽可能自我解释。

High level languages like JavaScript or Python are very readable. You can almost read the code aloud and think it’s plain english, if you name your variables and methods correctly.

像JavaScript或Python这样的高级语言都非常易读。 如果正确命名变量和方法，您几乎可以大声阅读该代码，并认为它是纯英语。

Some things are going to require some more thinking, but even if code is a bit complex, as long as a programmer can read it and determine 100% what the code does, it should not need comments.

有些事情需要更多的思考，但是即使代码有些复杂，只要程序员可以阅读并确定100％的代码功能，它也不需要注释。

You need comments when you have to explain the why of a particular instruction or block. Not the what, that should be inferred from the code. We call it high level for a reason: it’s code we can think about. It’s not machine language or assembly, which is very very hard to read and understand.

当您必须解释特定指令或块的原因时，需要注释。 不是从代码中可以推断出的what 。 我们之所以称其为“高级”，是因为它是我们可以考虑的代码。 它不是机器语言或汇编语言，这很难理解。

Some blocks of your code will need comments to explain others, or even yourself, why you are doing a particular thing. Not always of course, not when it’s obvious.

您的代码中的某些代码段将需要注释，以解释其他代码， 甚至您自己 ，以解释您为什么要做某件事。 当然，并非总是如此，并非显而易见。

By even 6 months down the line, if you work on a separate part of the codebase and then come back to that line of code, you will most likely not remember everything that was at stake when you edited it. You might recall 90% of the reasons you added something, but there was that something else you can’t find out.. a comment would be great for that.

甚至到了6个月后，如果您在代码库的另一部分工作，然后又回到那一行代码，您很可能就不会记得编辑该代码时遇到的一切。 您可能记得90％的原因添加了某些内容，但是有些其他您找不到的原因。发表评论对此很有帮助。

Code is not just instructions and comments. A lot of times you can see why a line of code was added thanks to source control (Git). You look the line up in your Git app, and the history of that line will tell you why you or your coworker edited that 10 months ago. If the Git commit message was helpful and detailed, not “Fix the bug”. That’s also a good documentation, especially good in Open Source projects which can have lots of people touching the codebase.

代码不仅仅是指令和注释。 很多时候，您可以看到为什么要使用源代码控制( Git )添加一行代码。 您在Git应用程序中查找该行，该行的历史记录将告诉您为什么您或您的同事在10个月前进行了编辑。 如果Git提交消息有用且详细，请不要“修复错误”。 这也是一个很好的文档，特别是在开放源代码项目中，可以有很多人接触代码库。

If you’re at a job interview, and you ask yourself “should I add comments in my exercise?” the answer is always yes.

如果您正在面试中，并且问自己“我应该在运动中添加评论吗？” 答案永远是肯定的 。

Will they most likely judge you for your comments as well as for your code. And what you write in the comments, too.

他们最有可能判断您的评论和代码。 还有您在评论中写的内容。

I would certainly do it. No matter how much a code wizard you can be, maybe the company needs to fire you in 3 months and the next person coming to replace you will need to understand your code, as that’s a company asset. They can’t really afford to hire someone that is not willing, or able, to have empathy for other people trying to read the source code.

我一定会的。 无论您有多大的代码向导，也许公司都需要在3个月内解雇您，而下一位接替您的人将需要了解您的代码，因为这是公司的资产。 他们真的负担不起聘请不愿意或无法同情其他尝试阅读源代码的人的人。

翻译自: https://flaviocopes.com/comments/

评论点赞的接口可以写一起吗