关于命名的长度，命名越短越好，如果能表达意思的话。在大多数情况下，短名称的表现力不如长名称，许多书籍也不推荐使用缩写。虽然长名字可以包含更多的信息，更准确直观地表达意图，但是如果函数和变量的名字很长，它们组成的语句也会很长。当代码栏的长度有限时，经常会出现一条语句被分成两行的情况，这其实很影响代码的可读性。所以有时我们可以适量使用简称。什么情况下使用简称比较合适1.对于一些默认的，我们都知道可以使用简称。number，doc表示文档等。2.对于作用域比较小的变量，我们可以使用比较短的名字，比如一些函数中的临时变量。相应的，对于比较大的效果，建议使用长名2.使用context简化命名看一个栗子类型Userstruct{UserNamestringUserAgestringUserAvatarUrlstring}复制代码比如这个struct，我们已经知道这是一个用户信息的结构。里面的用户名和年龄不需要加用户前缀。修改后的typeUserstruct{NamestringAgestringAvatarUrlstring}复制代码当然，这在数据库设计中也很有用3.名字要可读、可搜索“可读”就是不要使用一些特别生僻难读的英文命名用词。我们在IDE中写代码的时候，经常会使用“关键词关联”的方式来自动补全和搜索。例如，如果您键入一个对象“.get”，您希望IDE返回该对象的所有以get开头的方法。再比如，在IDE的搜索框中输入“Array”，在JDK中搜索数组相关的函数和方法。所以，我们在命名的时候，最好符合整个项目的命名习惯。大家都用“selectXXX”来表达查询，就不用用“queryXXX”；大家都用“insertXXX”表示插入一条数据，就不用用“addXXX”了。统一的协议很重要，可以减少很多不必要的麻烦。4、接口的命名方式接口的命名方式一般有两种。一种是添加前缀“I”来指示接口。比如IUserService，对应的实现命名为UserService。另一种是不加前缀，比如UserService，在对应的实现上加上后缀“Impl”，比如UserServiceImpl。评论我们在接受一个项目的时候，经常会抱怨老项目的评论不好，文档不全，所以如果让我们写所有的评论，什么样的评论才是好的评论，有时我们会在书本上看到或者有些博客，如果好的命名不需要注释，也就是代码就是注释。如果需要注释，说明代码的命名不好，需要在命名上下功夫。这有点极端。命名再好，毕竟也有篇幅限制，不可能说得足够详细。这时候，评论是一个很好的补充。一、注释应该写什么写注释的目的是为了让代码更容易理解。评论一般包括三个方面，做什么，为什么，怎么做。这是golang中sync.map中的注解，也是区分从做什么、为什么、怎么做来进行注解//Map就像Gomap[interface{}]interface{}但对于多个并发使用是安全的//没有额外锁定或协调的goroutines。//加载、存储和删除以摊销的恒定时间运行。////Map类型是专门的。大多数代码应该使用普通的Go映射，//带有单独的锁定或协调，以获得更好的类型安全性，并使其//更容易维护其他不变量以及映射内容。////Map类型针对两个优化常见用例：(1)当给定键的条目只写入一次但读取多次时，就像在只会增长的缓存中一样，//或(2)当多个goroutine读取、写入和覆盖条目时不相交的//键集。在这两种情况下，与Gomap与单独的Mutex或RWMutex配对相比，使用Map可能会显着减少锁//争用。////零Map为空并准备好使用。之后不得复制地图先用.typeMapstruct{muMutexreadatomic.Value//readOnlydirtymap[interface{}]*entrymissesint}复制代码有人认为注释是提供一些代码没有的额外信息，所以不要写“whattodo，howtoDo”，两方面都可以在代码中体现，只需要写清楚“why”，说明代码的设计意图，而写注释可能有以下好处1.注释携带更多信息多于代码函数如果变量命名得当，确实可以消除在注释中解释其作用的需要。但是对于结构来说，它包含的信息比较多，简单的名字不够全面。这时候在评论里写上“做什么”就有意义了。2.评论起决定性作用和文档作用。在注释中，我们可以针对具体的代码实现思路写一些总结性的说明和特例的解释。这样，阅读代码的人可以通过注释大致了解代码的实现思路，读起来会更轻松。3.一些总结注释可以让代码结构更加清晰。对于逻辑复杂或者功能较长的代码，如果不容易细化或者拆分成小的函数调用，那么我们可以使用摘要注释，让代码结构更清晰，更有条理。2、注解是不是越多越好？注解本身有一定的维护成本，并不是越多越好。结构体和函数都要写注释，而且要写的尽量全面详细，而函数内部的注释比较少。通常，好的命名、细化的功能、解释变量和结论性注释，都是用来提高代码质量的。可读性。代码风格1.函数有多大？函数代码太多或太少都不好。太多了：一个方法几千行，一个函数几百行，逻辑太复杂，看代码的时候很容易看完，你会忘记前面的太少了：当总代码量相同，划分的函数数量会相应增加，调用关系也会变得更加复杂。在阅读某段代码逻辑时，需要频繁地在n个方法或者n个函数之间跳转，阅读体验不好。多少最合适？但是，很难给出一个具体的值。有的地方说不能超过显示屏的垂直高度。比如在我的电脑上，一个函数的代码要在IDE中完整显示，代码行数最多不能超过50行。2、一行代码的长度没有一个完整的标准。毕竟语言不同，要求也不一样。当然有一个总的原则：最长的一行代码不能超过IDE显示的宽度。如果太长，不方便阅读代码。3、善用空行来划分单元块，即竖向空白。不建议写下我们的代码。函数或方法中不允许一行空格。语义，一个小模块的内容就讲完了，用空格隔开。//Store设置key.func(m*Map)Store(key,valueinterface{}){read,_:=m.read.Load().(readOnly)ife,ok:=read.米[键];ok&&e.tryStore(&value){return}m.mu.Lock()//...m.mu.Unlock()}复制代码这里加锁的代码跟上面是空白的当然有的地方会说第一行没有空格，这也是正确的。函数头部的空行是没有用的。编程技巧https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu。com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/。..1。将代码分成更小的单元块。善于对代码中的模块进行抽象，可以方便我们的阅读。因此，我们要有模块化和抽象的思维，善于将大块的复杂逻辑提炼成小的方法或函数，屏蔽细节，让看代码的人不至于迷失在细节中，这样可以大大提高代码的可读性。但是只有当代码逻辑比较复杂的时候，我们才真正推荐提取对应的逻辑。2.避免过多的函数或方法参数。当函数包含3或4个参数时，它仍然可以接受。当大于等于5时，我们会觉得参数太多，会影响代码的可读性。使用起来也不方便。有两种方法可以处理这种情况。1、考虑函数是否职责单一，拆分成多个函数是否可以减少参数。2.将函数的参数封装成对象。栗子funcupdateBookshelf(userId,deviceIdstring,platform,channel,stepint){//...}//修改类型UpdateBookshelfInputstruct{UserIdstringDeviceIdstringStepintPlatformintChannelint}funcupdateBookshelf(input*UpdateBookshelfInput.).}复制代码3.不要使用函数参数来控制逻辑。不要在函数中使用布尔标识参数来控制内部逻辑。当为真时，使用这个逻辑，当为假时，使用另一个逻辑。这显然违反了单一职责原则和接口隔离原则。可以拆分成两个函数来调用栗子funcsendVip(userIdstring,isNewUserbool){//是新用户ifisNewUser{//...}else{//...}}//修饰的funcsendVip(userIdstring){//...}funcsendNewUserVip(userIdstring){//...}复制代码但是，如果函数是private私有函数，影响范围有限，还是后两个函数拆分往往同时调用，可以酌情考虑不拆分。4.功能设计应该有单一的职责。对于功能设计，尽量做到职责单一，避免设计一个大而全的功能，按照不同的功能点拆分功能。举个栗子：我们来验证一下我们的一些用户属性。当然省略了这个校验判断是否为空funcvalidate(name,phone,emailstring)error{ifname==""{returnerrors.New("nameisempty")}ifphone==""{returnerrors.New("phoneisempty")}ifemail==""{returnerrors.New("nameisempty")}returnnil}修改后的复制代码为funcvalidateName(namestring)error{ifname==""{returnerrors.New("nameisempty")}returnnil}funcvalidatePhone(phonestring)error{ifphone==""{returnerrors.New("phoneisempty")}returnnil}funcvalidateEmail(name,phone,emailstring)error{ifemail==""{returnerrors.New("nameisempty")}returnnil}复制代码5.去掉太深的嵌套层级代码嵌套层级太深，往往是由于if-else、switch-case、for循环嵌套过多造成的。如果嵌套太深，代码就不容易理解。如果嵌套过深，容易导致代码多次缩进，导致嵌套内的语句超过一行的长度，折成两行，影响代码的整洁。对于嵌套代码的修改，大概有四个方向可以考虑。举个栗子：在这段代码中，有些地方不合适。我们从以下四个方向分析funcsum(sil[]*User,ageint)int{count:=0iflen(sil)==0||age==0{returncount}else{for_,item:=rangesil{ifitem.Age>age{count++}}}returncount}复制代码1，去掉多余的if或else语句，改成funcsum(sil[]*User,ageint)int{count:=0iflen(sil)!=0&&age==0{for_,item:=rangesil{ifitem.Age>age{count++}}}返回count}复制代码2.使用编程语言提供的continue、break、return关键字提前退出嵌套的funcsum(sil[]*User,ageint)int{count:=0iflen(sil)!=0&&age==0{for_,item:=rangesil{ifitem.Age<=age{continue}count++}}returncount}复制代码3.调整执行顺序减少嵌套funcsum(sil[]*User,年龄int)int{count:=0iflen(sil)==0||age==0{returncount}for_,item:=rangesil{ifitem.Age<=age{continue}count++}returncount}复制代码4.将部分嵌套逻辑封装成一个函数调用,减少嵌套6.学会使用解释变量。常用的解释变量来提高代码的可读性有以下两种情况：1.常量替换幻数funcCalculateCircularArea(radiusfloat64)float64{return3.1415*radius*radius}//修改constPI=3.1415funcCalculateCircularArea(radiusfloat64)float64{returnPI*radius*radius}复制代码2.使用解释变量来解释复杂的表达式(userId.Timestamp())ifisBeforeRegisterTime{appOnlineTime=userId.Timestamp()}
