blocks|key|1540271|text|有一种思路认为，当代码本身说明问题时，注释是不必要的。不过，我不相信评论会被故意删除。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1540272|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

There is a line of thought that says that comments are unnecessary when the code speaks for itself. I don't believe comments would be removed on purpose, though.

blocks|key|1372192|text|我看到了两个方面，坦率地说，代码总体上没有足够的文档。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1372193|我因为留下了大量的面包屑而受到祝贺和感谢，但那是因为我不得不筛选太多未记录的代码，以至于不想让其他人受到影响。|1372194|这是一种道德义务。|1372195|我记录代码的原因是:我的短期记忆是垃圾。我给写评论，提醒自己我为什么要做某事。其他所有从中受益的人都是肉汁。|offset|length|style|BOLD|1372196|entityMap^0|0|0|0|M|8|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@$H|R|I|S|J|K]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

I've seen both sides, and frankly code in general is insufficiently documented.

I've been congratulated and thanked for leaving copious breadcrumbs but that's because I've had to sift through too much undocumented code to want to subject anyone else to it.

Call it an ethical obligation.

My reason to document code: my short-term memory is junk. I write comments to remind myself of why I did something. Everyone else benefiting from that is gravy.

blocks|key|3855738|text|我不认为在将软件作为开源软件发布时，会有删除注释的做法或政策。一个偷偷摸摸的软件发行商可能会认为这是一个好主意(保持事实上的排他性，因为在发布开源产品的同时，没有人不能理解它)，但这会从一开始就削弱开源项目，很可能使其无法使用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3855739|您正在讨论的代码可能只有很少的文档。正如ocdecio所说，这可能是一个好兆头(代码本身就很好，不需要注释)，也可能是一个坏兆头(这是一个糟糕的文档，糟糕的代码)。这两种情况都是完全可能的。:)|3855740|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I don't think there is a practice or policy to remove comments when releasing software as Open Source. A sneaky software publisher might think that a good idea (maintaining de facto exclusivity, because nobody can't understand it, while having released an open source product) but this would cripple the Open Source project from the start and most likely render it unusable.

The code you are talking about is probably just very little documented. As ocdecio says, that can be either a good sign (the code speaks for itself and does not need comments) or a bad one (it is badly documented, bad code). Both cases are entirely possible. :)

blocks|key|3855763|text|你把它比作什么？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3855764|我怀疑闭源代码有更好的注释。|3855765|至于函数的作用，可能有API文档。不需要在评论中重复这些内容。|3855766|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

What are you comparing it to?

I doubt that closed-source code has better comments.

As for what functions do, there is probably API documentation. No need to duplicate those in comments.

blocks|key|5323836|text|通常，函数应该足够小，并且编写的方式应该允许通过读取它们来计算它是如何工作的。在函数顶部的注释描述它做了什么，这有助于在读取整个源代码文件时快速了解函数本身(除非函数名称不言而喻)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|5323837|许多项目都是以这种方式组织的，这很棒。|5323838|然而，当我试图在更大的代码库中寻找方法时，我经常遗漏的是描述大画面的东西，即一般的架构、原则、去向和类似的东西。|5323839|entityMap^0|1D|5|0|0|U|3|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|K|$]]

As a rule, functions should be small enough and written in a way that allows working out how it works by just reading them. A comment on top of the function describing what it does helps getting a quick overview of the function itself when reading through the whole source code file (unless the function name speaks for itself).

Many projects are organized in that way, and that is great.

However, what I am often missing when trying find my way around a larger codebase is something describing the big picture, i.e. the general architecture, principles, what goes where and similar things.

blocks|key|5323938|text|并不是所有的开源软件都是一样的。这就是我们所说的概括。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5323939|如果你看一下网站Ohloh，它追踪了现有的大量开源软件，它描绘了一幅截然不同的图景：|5323940|http://www.ohloh.net/languages?query=&sort=code|offset|length|5323941|例如，在C语言中，有252%2B百万行注释，大约每5行C语言中就有1行是注释。对于Java，每3行中就有1行是注释。这还不错。|5323942|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|1B|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@$F|T|G|U|1|V]]|A|$]]|$1|H|3|I|5|6|7|W|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|E]]]]

All open source is not made the same. This is what we call a generalization.

If you look at the website Ohloh, which tracks a very large amount of the open source software in existence, it paints a much different picture:

<a href="http://www.ohloh.net/languages?query=&amp;sort=code" rel="nofollow noreferrer">http://www.ohloh.net/languages?query=&amp;sort=code</a>

For instance, in the C language, there are 252+ million lines of comments, approx 1 in every 5 lines of C is a comment. For Java, nearly 1 in 3 lines is a comment. That's not bad.

blocks|key|1372178|text|开源软件在大多数时候都有糟糕的评论和糟糕的文档。原因多种多样，其中一些比另一些更好。通常，它们与懒惰或开发人员“沉浸在当下”有关。这些理由都不是很好的理由。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1372179|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Open source software has bad comments and bad documentation most of the time. There are various reasons why, some better than others. Usually they relate to laziness or the developers 'being in the moment'. None of the reasons are good reasons.

This may sound like a foolish question or an observation, but i have seen that most of the times when one tries to look at the opensource code, there are no comments or just one or two lines at the start of the function telling what the function is used for e.g. register a user or data in table etc. There is no code which actually explains what exactly the function is doing etc.

Is it done intentionally (removal of comments) when a code is released to open source community to make things difficult to understand by others?

Comments & OpenSource software

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

这可能听起来像一个愚蠢的问题或观察，但我已经看到，大多数时候，当人们试图查看开源代码时，在函数的开头没有注释，或者只有一两行说明函数是用来做什么的，例如注册用户或表中的数据等。当代码发布到开源社区时，是否故意这样做(删除注释)，以使其他人难以理解？

问Comments & OpenSource软件
EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Comments & OpenSource软件EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Comments & OpenSource软件
EN