ekuiper
ekuiper copied to clipboard
lf-edge
refactor: unify constants
@ngjaying
例如 : internal/converter/protobuf/fieldConverterSingleton.go:26 这种的就属于protobuf 的专属的 可以放到一个pkg里面。
internal/pkg/jwt/jwt_rsa.go:22 这种的 属于 jwt 里面的，也只会这这里用到 ，这种也是可以的。 但是internal/constants.go:51 这种的 Sink ，应该是 全局专属名字，统一定义，方便管理 。
不然容易出现这种潜在的问题，例如
if "mqtt_source.json" == fileName { fileName = "mqtt.json" }
还有一些命名不规范的问题， 有的用下划线 ，有的用大小写，有的用全大写。
@ngjaying
例如 : internal/converter/protobuf/fieldConverterSingleton.go:26 这种的就属于protobuf 的专属的 可以放到一个pkg里面。
internal/pkg/jwt/jwt_rsa.go:22 这种的 属于 jwt 里面的，也只会这这里用到 ，这种也是可以的。 但是internal/constants.go:51 这种的 Sink ，应该是 全局专属名字，统一定义，方便管理 。
不然容易出现这种潜在的问题，例如
if "mqtt_source.json" == fileName { fileName = "mqtt.json" }还有一些命名不规范的问题， 有的用下划线 ，有的用大小写，有的用全大写。
是的，我大致同意你的观点。主要是如何定义边界，比如 LoggerKey, 我还是倾向于放在 context 包里，比较容易保留语义，也说明是包的一部分，很多原生包里就有定义常数，有利于包的内聚；放在internal就没有语义了。我觉得这个PR的更改有些部分就有点“矫枉过正”了。命名不规范问题确实应该更改。
这个边界定义的话确实有点抉择，这样直接放到internal下面的话，是有点不妥当。
如果 超过三个子包中使用该常量，建议放到internal 中，是否可以呢？
如果定义在包下的话，我建议使用小写开头。其实变量名已经就能够解释语义了，我理解的包可能用来说明项目结构，规划功能会好一点。
ngjaying @.***> 於 2022年8月15日週一 下午10:02寫道：
@ngjaying https://github.com/ngjaying
例如 : internal/converter/protobuf/fieldConverterSingleton.go:26 这种的就属于protobuf 的专属的 可以放到一个pkg里面。
internal/pkg/jwt/jwt_rsa.go:22 这种的 属于 jwt 里面的，也只会这这里用到 ，这种也是可以的。 但是internal/constants.go:51 这种的 Sink ，应该是 全局专属名字，统一定义，方便管理 。
不然容易出现这种潜在的问题，例如 if "mqtt_source.json" == fileName { fileName = "mqtt.json" } 还有一些命名不规范的问题， 有的用下划线 ，有的用大小写，有的用全大写。
是的，我大致同意你的观点。主要是如何定义边界，比如 LoggerKey, 我还是倾向于放在 context 包里，比较容易保留语义，也说明是包的一部分，很多原生包里就有定义常数，有利于包的内聚；放在internal就没有语义了。我觉得这个PR的更改有些部分就有点“矫枉过正”了。命名不规范问题确实应该更改。
— Reply to this email directly, view it on GitHub https://github.com/lf-edge/ekuiper/pull/1365#issuecomment-1215049440, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANHWJ2AJH4ROOJSAQXWH2PDVZJEYTANCNFSM56LDAR3Q . You are receiving this because you were mentioned.Message ID: @.***>
如果 超过三个子包中使用该常量，建议放到internal 中，是否可以呢？
这个其实没有什么硬性标准，我觉得主要还是看语义。例如，go系统包里很多都有常量，包括 time.MilliSecond 这种，语义上就是time的一部分，所以可以作为包的常量在外部使用。
如果定义在包下的话，我建议使用小写开头。其实变量名已经就能够解释语义了，我理解的包可能用来说明项目结构，规划功> 能会好一点。
包的常量如果是内部使用，当然可以小写。大写就是希望外部访问的。Go官方的文档effective go 里，包名还是建议起到语义划分的作用，类似命名空间，可以看看这个文档 https://go.dev/doc/effective_go#package-names，里面的例子 bufio.Reader 和 io.Reader 使用包名区分不同的Reader，而不是全部放在一个包，用名字区分类似internal.bufioReader, internal.ioReader.
有些跟包联系不太紧密的常量，我觉得可以单独提出来。但是，Go里面其实不太建议集中放在一个包里并使用没有语义的包名，比如internal.JSON 这种。