阅读 773

优雅的命名 🧊🧊

本文已参与「掘力星计划」,赢取创作大礼包,挑战创作激励金。

优雅,永不过时。

前言

优秀的代码往往是最通俗易懂的代码,在于它的易于维护。在开发过程中,变量/方法优秀的命名往往有助于理解该变量/方法的用途,起到命名即注释的作用。而糟糕的命名往往会让人摸不着头脑。为了提高代码的可维护性,我们需要更优雅的命名方式。

一、通用规则

1. 有意义

起一个有意义的变量名这条相信绝大多数开发者都能做到,即变量名有实际的指代意义,在此不再赘述。

2. 指代具体

命名时需要使其更加具体详尽,可以具体到所在的模块,或者能表达出其逻辑/功能。

/* bad */
.title {}
/* good */
.head-title {}
复制代码
// bad
const info;
// good
const userInfo;
复制代码

3. 遵循传统

无论是CSS、JavaScript、还是文件的命名,都有一些约定俗成的惯例和规范,我们只需遵循即可。

4. 约定规范

命名的规则有很多种,没有高低之分,只有相对合适,没有绝对完美的规则。通常为了维持项目的风格统一,通常在一个项目中,相同种类的规则只选取一种。毕竟规范也只是一种工具,运用规范的根本目的是为了更好的开发和维护,太过复杂的规范反而会阻碍正常开发。因之,在项目启动前,在技术栈选取后就应当进行规范的约定,这个过程是团队意见的整合,毕竟规范是要靠团队成员的相互配合。

二、CSS 中的命名

1. 划分原则

CSS中的类名根据其职责可以分为公共类名和自定义类名。其中公共类名又可以分为常见类名(一般是约定俗成)和工具类名。

2. 常见类名

下面整理了一些常见的 css类名 供大家参考:

CSS类名说明
布局
layout布局容器
wrapper/wrap控制布局宽度的外围容器
header/head/hd头部/顶部
main/bd主体部分
footer/foot/ft底部
sidebar侧边栏
容器
banner广告栏
content内容部分
copyright版权
list列表
menu/submenu菜单/二级菜单
nav/subnav导航栏/二级导航
组件/细节
arrow箭头
btn按钮
download下载
logo徽标
message/msg信息
news新闻
product产品
search搜索
status状态
summary摘要
tab标签页
tag标签
text/txt文本
tip提示
title/subtitle标题/二级标题
尺寸
large
middle中等
small
mini迷你
位置
top/right/bottom/left上/右/下/左
关系
first第一个
last最后一个
prev上一个
current当前项
next下一个
forward向前
back向后
状态
primary主要
info提示信息
success成功
warning一般警告
danger/error严重警告/错误警告
link文字链接
plain/ghost按钮是否镂空
light亮模式
dark暗模式
disabled禁用
active激活
checked选中
loading加载中

3. 自定义类名

自定义类名一般以短横线“-”或者下划线“_”中的一种作为单词间分割,通常不使用驼峰命名,以此区别于变量。在项目中通常使用 scssless 来进行样式书写,大大降低了类名重复引发的样式问题。因此我们只需要关注一个模块的外层容器类名。通常采用 模块名称-修饰名称 的命名方式。

三、JavaScript 中的命名

1. 命名规则

1.1 小驼峰式命名(lower camel case)

第一个单词以小写字母开始,第二个单词的首字母大写。例如:firstName、lastName。一般的变量、函数均采用小驼峰式命名。

1.2 大驼峰式命名(upper camel case)

每一个单词的首字母都采用大写字母,例如:FirstName、LastName,也被称为 Pascal 命名法。一般类采用大驼峰式命名。

1.3 全大写式命名

常量通常采用全大写式命名,单词间以下划线“_”分割。

1.4 以下划线开头式命名

一般情况下,局部变量或者私有变量采用下划线开头,后跟驼峰式命名。

2. 命名单词选择

一般情况下,变量/函数的命名采用动词前缀+名词修饰。

前缀说明
变量
can是否可以执行某操作
is是否xxx
has是否有xxx
函数
calc计算
change改变
fetch/get获取(数据)
handle操作
judge判断
set设置

结语

任何的 代码规范 都是利于我们 开发维护 的,它存在的意义就是让我们的代码可读性更高/协作更方便的。对于多种不同的 规范 ,没有绝对意义上的谁好谁坏,只有适合与不适合。 代码规范 本身是为(协作)开发提供便利的,要避免本末倒置,还是要将更多的精力投入到项目的核心业务逻辑而非代码规范的条条框框的束缚,因为任何规范的代码都不是一朝一夕能运用自如的,要持之以恒才能力透纸背。循序渐进的在优化代码的漫漫长路上上下求索!

文章分类
前端