恨死 go 的导出变量命名规则了

[zhwguest]

是否包导出居然是靠首字母大小写来区分，写着写着，一个变量想修改为包外可见，居然要修改几十上百个文件。

这是一种什么样的思想....

[lightjiao]

@voidmnwzp 我回答中说的 async await 无栈协程可以做到对内存的高效利用
据我所知 java 里没有 async await ，java 也是吃内存大户（但 kotlin 有 async await ）。

也许你会说除了 java 和 go ，其他语言不好招人。但我想说的是：golang 本来也不好招人，吹的人多了，就好招了

[lightjiao]

@voidmnwzp 你提到的跑一百万个协程的内存与效率问题，可以搜索一下 async 与 goroutine 的对比

不是所有协程都是有栈协程（ 4k 的栈大小），async 这种编译时的无栈协程对内存的利用率天然更好

[xhxhx]

惊了！第一次听说要把 id 改成 ID 的！
只需要新定义 Person.GetId 的方法就能解决的问题，为什么变成要修改几十个文件？
话说一个包下几十个文件，这就是十年服务端的功力吗，涨见识了

[MoYi123]

关于 code review, 你完全可以把 export id 拆出来, 分 2 次提交, 根本不会有什么问题.

[whyso]

用了快十年才发现这个规则？用了快十年还没习惯 go 特立独行的设计？现在吐槽是不是有点晚

[ohwind]

@kiwi95 #52 人们亦有权利憎恨一种语言。至于我？我有说过我要换吗？

[gaifanking]

@itskingname 仔细看，楼主讲的是原本 private 但是有很多包内引用，现在改成 public 这些无辜的包内引用也要跟着改

[cmdOptionKana]

看了附言。

1. 可以弄个 Person.GetId 方法
2. 一个包分几十个文件，这本身可能就有问题，又不是 Java ，分那么多个文件干嘛，徒增麻烦
3. 从你附言来看，这种改动还是少见的啊，你原本说常见，并不成立
4. 既然少见，顶多算个小问题吧

[MoYi123]

补充一下我熟悉的其他编程语言的情况
python, 用下划线区别
c++ ,public, private, 但是通常私有成员变量的命名会区别于公开成员变量比如, _name, m_name, name_

感觉只有 java 是可以直接改吧? 但是 java 也是推荐 get/set.
不太懂你觉得好的语言是哪个?

[kiwi95]

id 改 ID ，那再加一个 ID()方法是最简单的。GetID()命名不是推荐的 style 。再说 op 是要暴露给外界读，那加一个方法不是本来就是最优设计？


@ohwind #86 憎恨/恨死了这样的用语可能我用的少，无法共情你们。

[Bazingal]

@MrSheng 不知道你是怎么理解的，我哪里说别人不能表达喜欢了？

[Huelse]

刚开始确实很难理解，就像我刚学 rust 的时候就很疑惑为啥其他基本类型是全小写，唯独 String 是大写开头的，后来我才突然意识到 String 不是基本类型而是个对象，char 才是基本类型。

因此你可以这样理解 go 的导出命名规则，大写就相当于是说明导出（对象）而不是内部（基本类型）。

[lasuar]

@Mexion #67
@zhwguest #71

包内引用的情况无需讲明，因为这种情况不会产生“需要修改为 pub 字段的需求”；唯一的可能是在开发过程中，包内的引用相关代码需要提取到包外，这不是说不会发生，而是不会频繁发生。对于楼主的情况，需要提取几十个文件到包外，这已经是处于后期开发进程，并且是对项目的较大更改。

[PureWhiteWu]

为什么直接加一个 Export 函数不行？

[dragonsunmoon]

别问, 问就是 大道智减 😅

[chaniqure]

大小写这个还好，我开发过程中，觉得恶心的有两点，一个就是包，一个文件夹就是一个包，导致我想创建一个 util 包，里面包含 str ，json ，dict 那些公共的工具包，还不行，因为没有重载的概念，导致，util 得创建 str_util ，json_util 这样的文件夹，另外一个就是循环引用的问题

[aababc]

@kiwi95 这个 getter/setter 明显就不是 go 的风格

[itskingname]

@gaifanking 包装一个函数就可以了

func _innerFunc() {...}

func OuterFunc() {
return _innerFunc()
}

[lysS]

@hanxiV2EX 这个可以的啊

[voya]

我曾见一位一开始写 java 的同事，觉得 golang 的 error 设计太繁琐，在公司的业务代码里自己按照 java 那一套封了一个 error handler, 然后被打回让重改。这点上不是 golang 不好用，而是他习惯了其他规则，一上来就觉得不合理，不对，连语言本身特性、设计都懒得去了解和思考