内容简介:编码风格在编程中是一个相对乏味的主题,但是合适的编码风格对一个有效的程序员是至关重要的。 它有三个组成部分:我已经在最佳的代码是自我解释的,良好的命名起着至关重要的作用。Go的命名约定与Java非常矛盾。尝试之后,我发现它是有效的,在创建简洁的代码同时并没有降低可读性。 Go是一种相对与更底层接近的语言,人们用它来编写网络,驱动程序和docker容器代码。在这些环境中,使用简洁的名称是合适的。
编码风格在编程中是一个相对乏味的主题,但是合适的编码风格对一个有效的 程序员 是至关重要的。 它有三个组成部分:
- 程序结构 ( application layout)
- 编码规则或风格
- 命名约定
我已经在 清晰架构(Clean Architecture)的 Go 微服务: 程序结构 ¹中讨论了程序结构,因此本文将介绍后两点。
编码规则或风格
-
没有包级别(package level)变量。
包级别变量打破了函数封装并使函数有了不确定。我在本程序中遵循了这个规则,唯一的例外是在“容器”包中,因为它负责程序级配置,在这里很难做到。其实即使在“容器”包中也可以去除掉包级别变量,但它需要付出很多努力,有些得不偿失。但是,由于包级别变量仅限于“容器”包中,因此导致的破坏大大减少。
-
尽量少使用常量
常量也是包级别,因为具有不变性,它们作为全局变量的危害较小,但它们仍然会破坏函数封装并需要进行限制。
-
依赖于接口而不是具体类型
当你尝试最小化外部更改对程序的影响时,无论外来者是函数,包还是应用程序,都要使代码依赖于接口而不是具体类型。
命名规则
最佳的代码是自我解释的,良好的命名起着至关重要的作用。Go的命名约定与 Java 非常矛盾。尝试之后,我发现它是有效的,在创建简洁的代码同时并没有降低可读性。 Go是一种相对与更底层接近的语言,人们用它来编写网络,驱动程序和 docker 容器代码。在这些环境中,使用简洁的名称是合适的。
但是,在编写业务应用程序时,我们需要创建许多不同的类型或结构来处理相似的业务概念,简洁的命名便不再适用。例如,为了处理与“用户”相关概念,我们有“User”,“UserDataService”,“RegistrationUseCase”,“RegistrationUseCaseIterface”和“UserDataInterface”,它们都与“User”有关,但都完全不同。你确实需要一个相对较长的名字来区分它们。为了获得良好的可读性,我有意违反了Go的一些命名约定,我将逐一解释它们。
我遵循的一条规则是“变量声明(name declaration)与其使用之间的距离越大,名称应该越长” Andrew Gerrand ². 我从 Dave Cheney ³的一篇文章中学到了这一点。基于它,我创建了自己的命名规则:“为类型(结构,接口)或函数命名使用长名称使其清晰易读,为局部变量命名使用短名称”,因为局部变量声明和使用之间的距离较短。
给类型(types)命名:
当我看到一个名字时,重要的是要了解它是哪种类型,它处于哪个层。例如,“UserDataInterface”,告诉我它是域模型“User”,它提供数据服务(持久性),并且它是一个接口。
Model:
域模型层,是最容易提供名称的层。 例如,域模型用户的“User”。
Dataservice:
数据持久性服务层。 例如“UserDataMySql”作为用户持久性服务 MySQL 数据库的命名; “UserDataCouchdb”作为CouchDB数据库的用户持久性服务的命名。 用户数据服务的不同实现共享相同的前缀“UserData”,并且它们的接口是“UserDataInterface”。
“CourseDataInterface”是课程数据服务的接口,“CourseDataMySql”是具体课程数据服务MSql数据库实现的名称。 所有数据服务共享相同的前缀“[model]Data”。
Use Case:
用例层。 “RegistrationUseCase”是注册用例的具体类型,接口是“RegistrationUseCaseInterface”。 “ListCourseUseCase”是课程列表用例的具体类型。 所有用例共享相同的后缀“UseCase”
Interface:
在清晰架构(Clean Architecture)中,所有业务逻辑都是基于接口调用的。 在遇到类型时,重要的是要识别类型是接口还是具体实现,因此我在所有接口上添加后缀“Interface”,例如“UseCaseInterface”。 如果你认为它太长,你可以用“I”,“If”或“Intf”等缩略语替换“Interface”。 对我来说,打字不是一个问题,IDE在大多数时间里都已经把问题解决了。
Constants:
对于常量,重要的是将它们与变量区分开来,所以我使用全部大写,如果是多字段常量(multi-words constant),我使用蛇形命名法(Snake Case)而不是驼峰命名法(Camel Case)(我知道它与Go命名约定相左)。 例如,“QUERY_USER_BY_NAME”而不是“queryUserByName”,这使它易读性更好。
结论:
编码风格对于使编程效率至关重要。 良好的命名使代码自我解释。 对类型或函数使用长名称,对局部变量使用短名称。 将“interface”放在接口名称中是有帮助的。 用蛇形命名法(Snake Case)并且所有字母大写来命名常量,以便于识别。
源程序:
完整的源程序链接 github : https://github.com/jfeng45/se...
索引:
[1] Go Microservice with Clean Architecture: Application Layout
[3] Practical Go: Real world advice for writing maintainable Go programs
不堆砌术语,不罗列架构,不迷信权威,不盲从流行,坚持独立思考
以上所述就是小编给大家介绍的《清晰架构(Clean Architecture)的Go微服务: 编码风格》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 『互联网架构』软件架构-netty粘包分包编码解码(57)
- 普适注意力:用于机器翻译的2D卷积神经网络,显著优于编码器-解码器架构
- 编码、摘要和加密(一)——字节编码
- 新媒体编码时代的技术:编码与传输
- MySQL数据库字符编码总结--数据传输编码
- PHP 开发者学 Golang 之 URL 编码 (Urlencode)、解编码 (Urldecode)
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
React开发实战
[美] Cássio de Sousa Antonio / 杜伟、柴晓伟、涂曙光 / 清华大学出版社 / 2017-3-1 / 58.00 元
介绍如何成功构建日益复杂的前端应用程序与接口,深入分析 React库,并详述React生态系统中的其他工具与库,从而指导你创建完整的复杂应用程序。 你将全面学习React的用法以及React生态系统中的其他工具和库(如React Router和Flux 架构),并了解采用组合方式创建接口的佳实践。本书简明扼要地讲解每个主题,并呈现助你高效完成工作的细节。书中严谨深刻地讲述React中重要的功......一起来看看 《React开发实战》 这本书的介绍吧!