“面试造火箭,进厂拧螺丝”是我们常为之感叹的,日常的开发工作大多是编写简单的业务代码。事实上,编写良好的业务代码也有技术上的困难,并非人人都能编写可读性更高的业务代码。
高可读性代码减少了后续维护成本,提高了后续开发的效率。
下面将与您分享我的经验,它们可以在一定程度上提高代码的可读性。
名称。
有两件事情很难做到,一是缓存失效,二是命名。”
同一性。
大型项目都是分工合作,不同的领域由不同的团队负责,同样的领域可以由多个人共同开发,所以即使对同一个事物命名,不同的人也会有不同的理解,所以要统一关键业务名称的命名,以保证整个链的一致性。
这一职责最好由项目PM负责,当编写技术方案时,要统一关键业务的名称。
health有意义而且简短。
第一,必须确保命名是有意义的,只要命名合理,不必担心方法名太长,但是方法名太长通常意味着方法做得太多,那么就需要考虑是否可以拆分,这也反映了"责任单一化"的设计原则。
在保证命名有意义的前提下,尽量保证命名的简短,删除一些不影响表达的词,或采用缩写。下面是一些例子:
由于RepositoryRuleRepository.findActivityRuleById(上下文已对此查询活动规则进行了说明)可以简化为ActivityRuleRepository.findById()()。
将voidupdateRuleRevision(StringruleString)简化为voidupdateRule4Revision(StringruleStr)
活动规则2活动规则(StringruleStr)借鉴toString的简写方式,将其简化为活动规则Ruleto活动规则(StringruleStr)
符号符合命名规范。
JavaScript的命名规范参考了阿里巴巴开发规范,下面摘录几个命名规范供大家参考:
任何与编程相关的名称都不能以下划线或美元符号开头,也不能以下划线或美元符号结尾。
严禁以任何程序命名时使用拼音与英文混用的方式,更不得直接使用中文。
在编码和注释中应避免(任何人语的)与性别、种族、地域、特定群体等有关的歧视性词语。
类名称使用了UpperCamelCo风格,例外的情况是:DO/BO/DTO/VO/AO/UID等等。
方法名称,参数名称,成员变量,本地变量都使用lowerCamelCycle风格。
常数命名应全部大写,字间用下划线分隔,力求语义表达完整清晰,不嫌名字长。
在POJO类中,不要将任何类型的变量加is前缀,否则部分框架解析将导致序列化错误。
等级区别作用范围
可将作用范围划分为应用、包、类、方法、代码块,在较大的作用域范围内应尽可能使用完全有意义的命名,但可考虑在方法和代码块中使用短名称,因为变量的作用范围有限,上下文一目了然,变量的意义也不一定非要写为high。
仍然使用长命名的小作用域将导致列宽很容易超出,甚至难以读取。方法中使用了简短的名称,如下所示。