latex添加代码注释_在代码中添加注释：好的，坏的和丑陋
的。
latex添加代码注释
江西好玩的地方Stop me if you’ve heard this one before…
如果您之前听过我的话，请阻⽌我...
“Good code is lf-documenting.”
“好的代码是⾃我记录。”
In 20+ years of writing code for a living, this is the one phra I’ve heard the most.
在20多年的代码编写中，这是我最常听到的⼀句话。
It’s cliché.
这是陈词滥调。
And like many clichés, it has a kernel of truth to it. But this truth has been so abud that most people who utter the phra have no idea what it really means.
像许多陈词滥调⼀样，它具有真实性。 但是这个真理已经被滥⽤了，以⾄于⼤多数说这个短语的⼈都不知道它的真正含义。qq隐藏
Is it true? Yes.
是真的吗 是的 。
Does it mean you should never comment your code? No.
这是否意味着您永远不要注释您的代码？ 不⾏
In this article we’ll look at the good, the bad, and the ugly when it comes to commenting your code.
在本⽂中，我们将讨论注释代码时的好，坏和丑陋之处。
For starters, there are really two different types of code comments. I call them documentation comments and clarification comments.
对于初学者来说，实际上有两种不同类型的代码注释。 我称它们为⽂档注释和澄清注释 。
⽂档注释 (Documentation Comments)
Documentation comments are intended for anyone who is likely to consume your source code, but not likely to read
through it. If you are building a library or framework that other developers will u, you need some form of API documentation.
⽂档注释适⽤于可能使⽤您的源代码但不太可能阅读您的源代码的任何⼈。 如果要构建其他开发⼈员将使⽤的库或框架，则需要某种形式的API⽂档。
The further removed from the source code your API documentation is, the more likely it is to become outdated or inaccurate over time. A good strategy to mitigate this is to embed the documentation directly into the code and then u a tool to extract it.
您的API⽂档从源代码中删除的越多，随着时间的推移，它越有可能变得过时或不准确。 减轻这种情况的⼀种好策略是将⽂档直接嵌⼊代码中，然后使⽤⼯具将其提取。
Here’s an example of a documentation comment from a popular JavaScript library called .
这是来⾃流⾏JavaScript库的⽂档注释 。
If you , you’ll e it’s an exact match.
如果 ，您会发现它是完全匹配的。
If you write documentation comments you should ensure that they follow a consistent standard and that they are easily distinguishable from any inline clarification comments you may also want to add. Some popular and well supported standards and tools include for JavaScript, for dotNet, and for Java.
如果您编写⽂档注释，则应确保它们遵循⼀致的标准，并且易于与您可能还想添加的任何在线澄清注释区分开。 ⼀些受欢迎且受到良好⽀持的标准和⼯具包括JavaScript的 ，dotNet的和Java的 。
The downside of the kinds of comments is that they can make your code very “noisy” and harder to read for anyone who is actively involved in maintaining it. The good news is that most code editors support “code folding” which allows us to collap the comments so we can focus on the code.
这些注释的缺点是，它们会使您的代码⾮常“嘈杂”，⽽对于任何积极参与维护代码的⼈来说，它们都更难阅读。 好消息是，⼤多数代码编辑器都⽀持“代码折叠”，这使我们可以折叠注释，以便我们专注
于代码。
澄清评论 (Clarification comments)
Clarification comments are intended for anyone (including your future lf) who may need to maintain, refactor, or extend your code.
澄清注释适⽤于可能需要维护，重构或扩展您的代码的任何⼈(包括您将来的⾃⼰)。
Often, a clarification comment is a code smell. It tells you that your code is too complex. You should strive to remove clarification comments and simplify the code instead becau, “good code is lf-documenting.”
通常，澄清注释是代码的味道。 它告诉您代码太复杂。 您应该努⼒删除澄清注释并简化代码，因为“好的代码是⾃我记录的”。
Here’s an of a bad — though very entertaining — clarification comment.
这是⼀个不好的澄清 ，尽管很有趣。
/
* * Replaces with spaces * the braces in cas * where braces in places * cau stasis.**/ $str = str_replace(array("\{","\}")," ",$str);
Rather than decorating a slightly confusing statement with a clever rhyme — in amphibrach dimeter, no less — the author would have been far better off spending time on a function that makes the code itlf easier to read and understand. Maybe a function named, removeCurlyBraces called from another function named sanitizeInput?
与其⽤灵巧的韵律来修饰⼀个稍微令⼈困惑的语句( ⾄少⽤amphibrach dimeter来装饰) ，作者最好花时间在使代码本⾝更易于阅读和理解的函数上。 也许是从另⼀个名为sanitizeInput函数调⽤的，名为removeCurlyBraces函数？
如何去台湾Don’t get me wrong, there are times — especially when you are slogging through a crushing workload — where injecting a bit of humor can be good for the soul. But when you write a funny comment to make up for bad code, it actually makes people less likely to refactor and fix the code later.
别误会我的意思，有时候，尤其是当您在繁重的⼯作量中苦苦挣扎时，注⼊⼀点幽默可能对灵魂有益。 但是，当您编写有趣的注释来弥补错误的代码时，实际上会使⼈们不太可能在以后重构和修复代
赋得自君之出矣
码。
Do you really want to be the one responsible for robbing all future coders of the joy of reading that clever little rhyme?
Most coders would chuckle and move on, ignoring the code smell.
您是否真的想成为⼀名负责抢劫所有未来编码⼈员的⼈，以使他们阅读这种聪明的⼩韵律？ ⼤多数编码⼈员会轻笑并继续前进，⽽忽略了编码的⽓味。
There are also times when you come across a comment that is redundant. If the code is already simple and obvious,
there’s no need to add a comment.
有时您会遇到多余的评论。 如果代码已经很简单明了，则⽆需添加注释。
Like, don’t do this nonn:
就像，不要胡说⼋道：
/
*t the value of the age integer to 32*/int age = 32;
Still, there are times when no matter what you do to the code itlf, a clarification comment is still warranted.
玻璃杯英文
尽管如此，有时⽆论您对代码本⾝做什么，仍需要澄清说明。
Usually this happens when you need to add some context to a non-intuitive solution.
通常，当您需要向⾮直观解决⽅案中添加⼀些上下⽂时，就会发⽣这种情况。
Here’s a good example from Lodash:
这是Lodash的⼀个很好的例⼦：
function addSetEntry(t, value) { /* Don't return `t.add` becau it's not chainable in IE 11. */ t.add(value); return t; }7月的英文
There are also times when — after a lot of thought and experimentation — it turns out that the emingly naive solution to a problem is actually the best. In tho scenarios it is almost inevitable th
at some other coder will come around thinking they are much smarter than you are and start messing with the code, only to discover that your way was the best way all along.
有时，经过⼤量的思考和实验，事实证明，似乎天真的解决问题的⽅法实际上是最好的。 在这些情况下，⼏乎不可避免地会有其他⼀些编
码器出现，以为它们⽐您聪明得多，并开始弄乱代码，只是发现您的⽅式⼀直是最好的⽅式。
Sometimes that other coder is your future lf.
有时，其他编码员是您未来的⾃我。
In tho cas, it’s best to save everyone the time and embarrassment and leave a comment.
在这种情况下，最好节省每个⼈的时间和尴尬并发表评论。
The captures this scenario perfectly:
完美地捕获了这种情况：
手机红外功能/**Dear maintainer: Once you are done trying to 'optimize' this routine,and have realized what a terri
ble mistake that was,plea increment the following co
Again, the above is more about being funny than being helpful. But you SHOULD leave a comment warning others not to pursue some emingly obvious “better solution,” if you’ve already tried and rejected it. And when you do, the comment should specify what solution you tried and why you decided against it.
同样，以上内容是关于有趣⽽不是有所帮助。 但是您应该发表评论，警告其他⼈，如果您已经尝试并拒绝了它，则不要追求⼀些看似明显
的“更好的解决⽅案”。 并且，当您这样做时，注释应指定您尝试了哪种解决⽅案以及为什么反对该解决⽅案。
Here’s a simple example in JavaScript:
这是JavaScript中的⼀个简单⽰例：
/* don't u the global isFinite() becau it returns true for null values*/Number.isFinite(value)
丑陋的 (The Ugly)
So, we’ve looked at the good and the bad, but what about the ugly?
因此，我们研究了好与坏，但是丑陋呢？
Unfortunately, there are times in any job where you’ll find yourlf frustrated and when you write code for a living, it can be tempting to vent that frustration in code comments.
不幸的是，在任何⼯作中，有时您会发现⾃⼰感到沮丧，⽽当您以谋⽣为⽬的编写代码时，可能很想在代码注释中消除这种沮丧。
Work with enough code bas and you’ll come across comments that range from cynical and depressing to dark and mean spirited.
使⽤⾜够的代码库，您会遇到各种评论，从愤世嫉俗和沮丧到沉闷和刻薄。
Things like the …
事情……
/*This code sucks, you know it and I know it. Move on and call me an idiot later.*/
…
to the
……
/* Class ud to workaround Richard being a f***ing idiot*/
The things may em funny or may help relea a bit of frustration in the moment, but when they make it into production code they end up making the coder who wrote them and their employer look unprofessional and bitter.
这些事情看似很有趣，或者可能会在瞬间缓解⼀些挫败感，但是当他们将其纳⼊⽣产代码时，最终使编写这些代码的程序员和他们的雇主显得不专业且痛苦。
Don't do this.
不要这样
If you enjoyed this article, plea smash the applau icon a bunch of times to help spread the word. And if you want to read more stuff like this, plea sign up for my weekly Dev Mastery newsletter below.
如果您喜欢这篇⽂章，请多次敲击掌声图标，以帮助宣传。 如果您想阅读更多类似的内容，请在下⾯注册我的每周开发精通通讯。苹果7参数详细参数
latex添加代码注释
