Java教程

优雅的变量命名

本文主要是介绍优雅的变量命名,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

前言

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

一、通用规则

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 设置

小结

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

这篇关于优雅的变量命名的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!