3.5 规范化命名,提升可读性

我们开始进一步了解业务逻辑、阅读项目的代码和函数。于是,我们又进一步将注意力放到命名上。

命名,对于程序员来说是一件相当头疼的事,对于英语不是母语的开发人员来说更是如此。为了取一个变量名,我们需要打开翻译软件、网站,输入对应的中文名,以获取可能的英语单词。再按自己的经验来决定使用哪个单词。即便如此,一个英文单词又可能拥有多个中文含义,我们又需要进一步翻译成中文。即便最后我们决定使用这个单词,在和其他程序员讨论代码的时候,可能还会对这些代码有一定的争议。

这个头疼的问题不是我们使用规范能解决的,但是我们可以通过制定命名规则来统一命名方法。

3.5.1 命名法

对于阅读代码来说,一个简单有效的函数名、变量名,远远比冗长的注释来得更加有用。而这些函数名、变量名本身应该也是容易阅读的,比如gettypebyid这种全小写的方式,对于开发人员来说相当不友好。如果读者也接触过不同的语言就会发现,语言间的差距不仅体现在使用上,还会体现在函数、变量的命名上。下面是几种常用的命名规则:

◎ 驼峰命名法,译自CamelCase,类似于骆驼的后背形状一样高低起伏。这个命名法来源于Perl语言,其展现形式是在单字之间通过首字母大写来展现,如“getTypeById”。在前端开发中,这种命名规则较为常见。

◎ 下画线命名法,即通过下画线来分割单词,如“get_type_by_id”就是采用这种命名方法。下画线(_)的分割方式非常显眼,它也更容易让开发人员区别单词。在Python语言中,这种命名方式特别流行。

◎ 匈牙利命名法,最初是由一个匈牙利程序员Charles Simonyi发明的,其命名规则是:属性+类型+对象描述。如“strFirstName”便是这样的形式,变量中的“str”表示这个变量的类型是string,再比如“iAge”中的“i”表示这个变量的类型是int。

上述几种方式都是为了提升代码的可读性而出现的,并不存在哪种命名方式更好,都是随习惯而来的。

不同语言之间存在一些不同的文化,在使用其他语言的时候,这些文化会体现出来。比如在JavaScript里,通常会使用that = this来解决this作用域的问题,而对于一些程序员(如Ruby语言的使用者)来说,他们会将它写成self = this——这种方式对他们来说更好理解。

对于前端团队来说,我们需要统一项目的命名规则,以降低项目的成本。

3.5.2 CSS及其预处理器命名规则

除了代码,CSS的命名规则也是值得进行规范的。它存在于HTML文件和JavaScript代码中,以及自身的CSS文件中。

在前端技术快速发展的今天,我们已经不再直接编写CSS文件,而是通过CSS预处理器将LESS、SCSS等新增了很多编程特性的语言转换为CSS。对CSS进行命名规范的主要原因是,如果不同页面、组件中定义的样式发生冲突,就会导致页面UI受到影响。而在诸如Angular这样的Web Components框架里,它会将一个组件内的CSS代码进行编译,使它只在自己的组件里生效。

同样,在规模比较大、技术栈统一的前端团队里,会开发一套统一的编码规范。比如“Airbnb CSS/Sass指南”https://github.com/airbnb/css,它里面会定义一些常见风格的写法,并且会编写CSS Lint工具。

下面是在上述的指南中提到的CSS命名示例:

        .ListingCard { }
        .ListingCard--featured { }
        .ListingCard__title { }
        .ListingCard__content { }

下面是一些对应的解释:

◎ .ListingCard是一个块(Block),表示高层次的组件。

◎ .ListingCard__title是一个元素(Element),它属于.ListingCard的一部分,因此块是由元素组成的。

◎ .ListingCard--featured是一个修饰符(Modifier),表示这个块与.ListingCard有着不同的状态。

需要注意的是,原版的Airbnb写法中,“ListingCard”采用全小写的形式,“listing-card”在使用React的JSX语法的时候,变成了驼峰式写法。

3.5.3 组件命名规则

同样,对于团队而言,组件的命名规则也需要规范,特别是对于使用组件化框架的项目而言,有如下几种不同的命名方式:

◎ 按照功能来命名,比如SideBar就是一个侧边栏功能的组件。

◎ 按页面来切分组件,比如NewsItem就是用于展示新闻的组件,它既用于列表页,又用于相关新闻页。

◎ 按上下文来命名组件,如NewsChildItem就是按需要将上一个组件的某个共用元素拆分出来。

不过这些命名方式并不是对立的,它们可能同时存在于一个项目中。