目录 搜索 介绍指导原则简单性可读性生产力标识符选择标识符是为了清晰,而不是简洁标识符长度上下文是关键不要用变量类型命名你的变量使用一致的命名方式使用一致的声明样式成为团队合作者注释关于变量和常量的注释应描述其内容而非其目的公共符号始终要注释不要注释不好的代码,将它重写与其注释一段代码,不如重构它包的设计一个好的包从它的名字开始好的包名应该是唯一的避免使用类似 `base`,`common` 或 `util` 的包名称尽早 `return` 而不是深度嵌套让零值更有用避免包级别状态项目结构考虑更少,更大的包通过 `import` 语句将代码排列到文件中优先内部测试再到外部测试使用 `internal` 包来减少公共API确保 `main` 包内容尽可能的少API 设计设计难以被误用的 API警惕采用几个相同类型参数的函数为其默认用例设计 API不鼓励使用 `nil` 作为参数首选可变参数函数而非 `[]T` 参数让函数定义它们所需的行为错误处理通过消除错误来消除错误处理计算行数WriteResponse错误只处理一次为错误添加相关内容使用 `github.com/pkg/errors` 包装 `errors`并发保持自己忙碌或做自己的工作将并发性留给调用者永远不要启动一个停止不了的 goroutine 暂无相关搜索结果! 本文档使用 topgoer 发布 为其默认用例设计 API 几年前,我就对 functional options[7] 进行过讨论[6],使 API 更易用于默认用例。 本演讲的主旨是你应该为常见用例设计 API。 另一方面, API 不应要求调用者提供他们不在乎参数。最后编辑: kuteng 文档更新时间: 2021-01-09 21:47 作者:kuteng
几年前,我就对 functional options[7] 进行过讨论[6],使 API 更易用于默认用例。 本演讲的主旨是你应该为常见用例设计 API。 另一方面, API 不应要求调用者提供他们不在乎参数。最后编辑: kuteng 文档更新时间: 2021-01-09 21:47 作者:kuteng