go 项目目录名称，如果要多个单词要不要用下划线分割？

[dyllen]

我知道规范是说尽量单个单词或简写。如果真需要多个单词，全小写不做任何分割？

不分割：clientapi,serverapi

分割：client_api,server_api

有的还可能需要更多单词

[mcfog]

全小写不分割，适当缩写 （最多两个单词）

https://github.com/kubernetes/kubernetes/tree/master/pkg
https://github.com/etcd-io/etcd/tree/main/pkg
https://github.com/prometheus/prometheus

随便找几个知名项目的例子参考

[nobot]

4.1 [推荐] 包命名
保持 package 的名字和目录一致。
尽量采取有意义、简短的包名，尽量不要和标准库冲突。
包名应该为小写单词，不要使用下划线或者混合大小写，使用多级目录来划分层级。
包名可谨慎地使用缩写。当缩写是程序员广泛熟知的词时，可以使用缩写。例如：
strconv (string conversion)
syscall (system call)
fmt (formatted I/O)
如果缩写有歧义或不清晰，不用缩写。

项目名可以通过中划线来连接多个单词。
简单明了的包命名，如：time 、list 、http 。
不要使用无意义的包名，如：util 、common 、misc 、global 。
package 名字应该追求清晰且越来越收敛，符合‘单一职责’原则。而不是像 common 一样，什么都能往里面放，越来越膨胀，让依赖关系变得复杂，不利于阅读、复用、重构。注意，xx/util/encryption 这样的包名是允许的。

4.2 [必须] 文件命名
采用有意义，简短的文件名。
文件名应该采用小写，并且使用下划线分割各个单词。

[CHTuring]

其实我有个疑问，不分割的话，自己看着不难受吗。更别说 Code Spell Checker 的下划线...

[dyllen]

@mcfog 简单的好缩写，他们是开源库好搞一点，像做业务开放，感觉很难缩写

https://github.com/etcd-io/etcd/blob/main/pkg/grpc_testing/recorder.go

我看这个开源项目用的是下划线分割：

https://github.com/influxdata/telegraf/blob/master/plugins/inputs/jti_openconfig_telemetry/collection.go

plugins 目录下好多都是下划线分割，这种真不好简写，简写或者不分割很不清晰的感觉。

[dyllen]

@CHTuring
@mcfog

我看了几个开源库，还是有不适合简写或者不分割连一起的情况，还是用下划线分割下更清晰明了。

[RedBeanIce]

@dyllen 确实，你是对的。请找到适合自己的代码编写方式。

业务开发，开源开发，是两种玩法。

[mainjzb]

golang 官方推荐是不要用下划线
rust 官方推荐是使用下划线（建议转 rust 逃

[mcfog]

@dyllen

test/testing 这种属于特殊固定后缀是排除的，类似还有 go 文件后缀_linux _arm 等等

就我个人经验，超过两个单词的取名我没有碰到过改不了的，import path 是一个完整的概念，目录名一样可以承载信息，最后一段 package name 只要最 unique 的信息，承担标识符的角色，其余信息可以组织在目录里。

另外还有一个点是很多项目的 package 拆分都太细了，导致内部依赖复杂，大量不必要的 export

就你举的例子，那个 package “Subscribe and receive OpenConfig Telemetry data using JTI”， 也就名字里的前后部分是不必要的重复，直接就叫 jti 或者 openconfigtelemetry （不确定缩写成 oc 是否合适）就行了。就好像 etcdclient 如果叫 grpc_etcd_client 也是三个单词，并不合理。
而反过来这个名字也在目录里表明了这是一个 input 相关的 plugin ，并不需要叫 jti_input_plugin

[leonshaw]

@mcfog 当你不确定叫 jti 还是 openconfigtelemetry 时，说明两个都不准确

[mcfog]

@leonshaw 我既不了解 telegraf 也不了解 jti 或 openconfig ，只是点开 op 的例子看了项目里的 md ，就着上下文解释一下自己的观点。

你如果觉得有更合适的名字也关心 telegraf 项目，不妨开 pr 和社区沟通讨论，这和 op 要讨论的话题无关

[gxm44]

适合自己就好，但一定要统一

[bv]

https://google.github.io/styleguide/go/decisions

https://github.com/golang/go/wiki/CodeReviewComments

[katsusan]

分割与否对编译和运行没有一点影响,可读性方面在 readme 里写清楚各个目录的职责比纠结这个有意义

[leonshaw]

@mcfog 我提不出更合适的名字，更不会在不了解的情况下提出“更合适”的名字来佐证观点

[hesetiema]

中线分割感觉是最好看的

[miusmile]

项目名一律按小写中横线分割，也就是减号 -------

[Philippa]

我会分，有些情况不加下划线压根无法看。而且很多 libs 在超长的 var 那种也会分，比如 google 自家的 grpc 也是如此

[warlock]

我习惯 目录不加 文件加下划线

[lotusgrm]

如果是目录的话，全部小写不添加下划线分割，但是如果是 go 源文件的话，我会使用下划线分割，这也是 uber go 推荐的开发规范

[wudanyang]

> Go package names should be short and contain only lowercase letters. A package name composed of multiple words should be left unbroken in all lowercase. For example, the package tabwriter is not named tabWriter, TabWriter, or tab_writer.

https://google.github.io/styleguide/go/decisions.html