英文:
Naming convention for not-exported type names in Go
问题
我喜欢使用帕斯卡命名法来命名我的类型 - 以大写字母开头。在Go语言中，这意味着该名称是可导出的。
为了避免导出，我开始使用下划线作为类型名称的前缀，而不是将第一个字母转为小写。
例如：不使用type Column struct{}，而是使用type _Column struct{}来避免导出。
我还没有见过这种命名方案的使用情况，但也没有找到任何不使用它的理由。
由于golint接受它而没有投诉，我猜这样做是可以的？
结论：根据答案和评论，我决定继续使用小写的类型名称。
英文:
I like to name my types using Pascal case - starting with an upper case letter. In Go this implies the name is exported.
To avoid export, I've started to prefix the type name with undercsore instead of lower-casing the first letter.
E.g: Instead of
type Column struct{}, I use type _Column struct{} to avoid export.
I haven't seen this naming scheme used, but neither found any reason not to use it.
Since golint accepts it without complaint, I guess this is OK?
Conclusion: Based on answers and comments I've decided to stay with lower-cased type names.
答案1
得分: 5
我建议优先使用column而不是_Column，因为标准库中的命名风格遵循这种约定。
在风格指南的命名部分中没有明确说明这一点，但基于下划线通常不被鼓励的事实，我认为使用_Column最多也不是惯用的写法。
英文:
I'd suggest using column in preference to _Column, on the basis that the style used by the standard libraries follow that naming convention.
This is not explicit in the Names section of the style guide, but based on the fact that underscores are generally discouraged, I'd say that using _Column is, at best, not idiomatic.
答案2
得分: 2
我喜欢并且不喜欢超级混合。
有一些习惯用法和强制使用的工具。
社区遵循标准，使得代码库在他人阅读和理解时相对容易。
我认为这是Go语言最好的特点之一。
当然，通道和goroutine很好用。
但能够轻松阅读代码库通常更有价值。
英文:
"I like to" and go don't super mix.
There are idiomatic bits and tooling enforced bits.
The community sticking to the standards makes for codebases that can be reasonably easy to read and comprehend by others.
I find this to be one of the best attributes of go.
Sure, channels and goroutines are nice.
Easily being able to read a codebase is often much more valuable.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论