感动, 这位粉丝给 ws 源码几乎每一行都写了注释 !

// 设置元素的值
// Set the value of the element
ele.value = value

// 执行将元素推到队列尾部的操作
// Perform the operation to push the element to the back of the deque
c.doPushBack(ele)

// 返回该元素
// Return the element
return ele

如果不是器助生成的，真是好有耐心。
有坐，同的容用出地言、目的地言、英文三言分播一遍的感。

@weakish 即使有 AI 辅助, 也肯定人为校准过, 非常费心了

链接是 .dev 你确定不是你自己么

@weakish 这注释写了等于没写吧

这种注释算不得好注释，不如没有，去掉后不影响我阅读代码，反而把 3 行的东西便成了这么多行，意义何在？

@jevonszmx 因为一小片代码的注释就否定所有工作, 以偏概全了

@sleepm 我不理解你的推理逻辑

@sleepm github.dev 是 github 官方的，使用 vscode 浏览代码用的，你在 GitHub 任何一个仓库页面按键盘上的 [.] 键即可打开，建议体验一下

具体观点我就不发表了，说出来不太好听。

@panlatent 同意，就 op 发的代码来说，这些注释无意义

@panlatent 哈哈, 有点过于详尽了. 如果在快速迭代阶段, 我会大片删除函数内的注释, 不过现在代码仓库主干已经非常稳定了, 应该不会再有重大更新, 接受 PR 就当表彰粉丝的热情了.

@herozzm #10 不仅 op 发出来的代码；简单看了 client 的代码。
这个中英文注释还真不如没有注释，真的很影响阅读代码。
谁家的注释是这样子写的！！

@sleepm 魔怔了吧

用 ai 生成的吧

泼个冷水，个人感觉这并不是什么好的做法。真正好的代码应该在简单的地方做到使用命名进行自注释，在复杂有必要的地方才进行注释。每一行都进行注释反而增加了噪声会影响阅读。

```
// 返回客户端连接、HTTP 响应和错误信息
// Return the client connection, HTTP response, and error information
return client, resp, err
```

建议 revert 掉这个 pr

这种注释没必要, 只会把仓库变成屎山, 迭代几次后, 到处都是注释和代码不一致的逻辑

浪费存储和无效阅读

好的代码是能 self explain 的，注释有且只有重要的地方需要写
写在这些无关紧要的地方，你以后改代码，这里的注释改不改？

注释不是越多越好，很多无效注释还会影响阅读，建议 revert 掉这个 pr

无效注释，大部分都在重复代码的含义
// 配置信息
// Configuration information
config *Config

// 缓冲读取器
// Buffered reader
br *bufio.Reader

// 持续帧
// Continuation frame
continuationFrame continuationFrame

// 帧头
// Frame header
fh frameHeader
这种有啥可以注释的

@jptx
@Nazz
. 或者 github1s 这些都用过，都知道
但凡发链接一般都是 .com
粘贴 .dev 有一定概率就是推广

建议移到推广节点，类似标题让我想到 XHS 上的标题党：
“XX 城市这家店劝你不要来” 点进去老板人太热情送太多东西吃不完....
“崩溃了老板大我五十岁不懂得边界感” 点进去是给她升职加薪

好的代码应该是自解释的

@sworld233 你列举的这个应该是使用了 go 语言的代码注释规范，不加上吧，提示不消除又难受

注释要写的是“因为什么要这样做”，因为“这行代码做了什么”代码本身已经可以告诉我们了
所以，就看一楼给出的那三行的话，这注释不如不写

这种注释还是别了
注释还是用来说一下为了解决什么问题 如何做 包括函数名的含义自注释
如果只是简单翻译一下代码 这种注释有什么意义

1982 不教教你的粉丝什么是代码可读性，跑过来炫耀，真好笑。

@sleepm #22 用过应该知道,你只要按[.],域名就会变成.dev 吧,这也是推广?

冷知识
github.dev 其实是由 GitHub 官方推出的 /手动狗头
说白了就是一个一个 web 版的 VsCode ,可以浏览器在线编辑提交 GitHub 仓库内的文件

这个 ai 注释的语气真的挺让人感到别扭的。 理解都要好大一会儿。 注释这么加， 真的没人愿意看的

这位热心的粉丝给你拉了一坨大的

还有耐心，中英注释

别的先不说。原来还有那么多人不知道.dev 啊

不利于维护，之后改代码还要改双语注释，只能说没啥好处

@liquid207 是的，合并前需要大片删除函数内的注释

不要为了写注释而写注释

我觉得挺好的，对于不了解 go 的开发者很友好，至于楼中的一些维护问题以及改代码后注释不对的问题，我不敢苟同，修改注释本来就是维护中的一部分，只改代码懒得去改注释，这就是坏习惯，不是理所当然，而且楼中提到的无意义注释：// 配置信息，// 缓冲读取器，// 缓冲读取器，根本就不会去经常改，哪来的维护麻烦的问题

一看就懂的简单的东西，还这么注释只会影响阅读

AI 搞的？

估计是 AI 生成用来混大量 PR 的 建议 revert 很多地方直接变量可以做到自注释，简单的逻辑也不需要太细致入微注释

突然想到一句话，有些事情真不是勤奋就能做的好的，确实带点天赋。

代码简洁之道：无效注释不仅不能起到说明作用 反而会增加复杂度 注释要简短有力

大可不必都加上注释吧。

另外搞开源就别说粉丝了吧，感觉像是饭圈。。

这注释是给人类看的？ AIGC 污染环境。
反过来讲，都开始研究这种东西的源码了，会连 golang 的基础都看不懂吗？

就是 AI 生成的注释，基本上按照变量名字猜，然后翻译出来。当做 AI 工具还有点用，提交到代码里完全没必要

除了降低代码可读性之外几乎没有任何价值

好的代码应尽量做到代码即注释，需要大量注释才能理解，只能证明代码难以清晰直观地表达意图，需要靠人类的自然语言辅助。

有没有像我一样的，用 copilot ，先写注释，自动生成代码，然后改改代码，然后继续这个循环

(今天中午饭点在知乎看到类似讨论...

感觉作者有点儿疯了:)_

关于 ai 生成注释，反过来想是不是可以写代码时不用写注释了或者只在特殊逻辑的地方写，以后自己或他人再读代码时临时 ai 生成注释

感觉是拿 gpt 批量生成的，好奇原作者会不会合并

反正如果是我，我首先评论一句感谢 pr ，然后发一句感觉没什么用就关闭 pr 了

@0o0O0o0O0o 刚好想到这图，哈哈哈哈

注释一般注释业务、产品背景

这注释说真的。。感觉没啥用。

几乎每行都写注释我第一反应是恐怖，因为这种行为完全没有意义，而且居然还推给上游了。。

挺好奇楼主真的打算合并这个吗。

注释讲究的是适当，不适当的注释还不如没有，go 基础不好就回去专门学基础，没必要再项目中去搞这些。

评论区好多酸烂臭萝卜哦。跟蛆一样，于自己没有任何好处，还要恶心别人一把。

@flyqie 要把多余的去掉，工作量蛮大

@zhaliao

1. OP 标题党，实则在推广自己的项目
2. 我看见大多数评论都在讨论注释的问题，而这正是标题强调的，有何不可？
3. 你这段话，整个评论区里面最受用的其实就是你自己

懂得都懂吧

@jptx 学到了

懂得都懂

@Wxh16144 他写错了，其实是以上所有代码都是注释补全的，这就是注释的意义

这个帖子还是不错的，学习到了 GitHub 仓库按 . 进入编辑器模式。

i = i + 1; // 为 i 加一

aigc 作为一种工具很好用, 但是很恶心把生成的东西丢到论坛社区. 包括
1. 在 b 站这种视频网站下面 @xxxAI 小助手总结一下
2. 在论坛丢 aigc 没验证过的片汤话
现在竟然连代码中都开始加这种没营养影响观感的东西.

写的废话太多了

> 接受 PR 就当表彰粉丝的热情了

@Nazz #11 我个人觉得 "表彰" => "感谢" 更好些

哈哈，确实没什么用，不过感觉这个加一堆注释的代码 挺适合当没有 golang 基础的新手学 golang 的教材的

粉丝？偶像？

这就是 ai 生成的

hn 上有人吐槽过了

大部分代码是能够自我解释的，如果不能，首先考虑重构，再考虑加注释

这种注释等于是路边有棵树，然后挂个牌子写着：“这是树”

注释应该主要用来解释代码为什么这么写吧

我还是喜欢用 melody

// ← 这就是史

@lesisma 嗯，感谢他的贡献，提供吉祥物和完善文档

@dwu8555 习惯问题，我更喜欢 Javascript WebSocket API 而不是 channel.

虔诚式学习就是把数学作业的正确答案虔诚地用红笔注释在自己的答案旁边

您的是虔诚式注释 把整本课本都拿荧光笔涂了

代码注释的重点是解释为什么要这么做，而不是把程序语言语义翻译成自然语言！！！

@jptx 才知道还有快捷方式打开，插件没用了之后都是手改

《代码整洁之道》

@jptx 学到了，还能这样

以现在 AI 的水平，生成这些注释根本不需要人工校验

@jptx 学到了，还有这种快捷键

感觉这注释就是为了注释而注释

@sleepm #3 github.dev 要公开卖的话，估计价格会很离谱

推广贴,这次就不 at 站长了,好自为之

@XuHuan1025 赶紧去艾特

@Nazz 我没有以偏概全否定所有工作啊，我说这注释，这。这。这注释

@nanajj
1.踩着你尾巴了
2.你急了
3.呵呵

我写注释是为了几个月后回看代码知道自己干了什么