相信大家对样式命名都多少感到困难,特别是想起一个有意义的名,更难。回顾了一下之前写的《 样式命名规则 》(不知道大家使用后有什么感想)结合这段时间使用上发现的一些问题,重新整理了样式的命名规则,希望能更实用些。
要避免当状态改变时名称失去意义,最常见的就是用于布局的类名,如“left”、“right”,当左边栏不再是左边栏的时候,“left”这个名就没有实际意义了。这与我们所推荐的“命名要有意义”就相违背了,使用序号就更加有问题了。好像没错,不过有好长一段时间都有个问题让我很烦恼,如果一个页面中同个模块出现一次以上,而且细节还不一样,那后面出现的名称应该叫什么呢?难道“one”、“two”就不是序号?其实我们要避免遇到的情况就是当状态(表现)改变时,对应定义的类名不会失去意义。
所谓的状态(表现)改变,有几种情况:
而实际情况并不是单纯的某一种情况,更多的时候是混杂着出现的。有点远了,回主题。
[ 模块前缀 ] _ 类型 _ ( 作用 | 状态 ) n _ [ 位置 n ]
图例说明:
名词说明:
例:
模块前缀:
类型:
作用:
状态:
位置:
中文解释 | 命名 | 中文解释 | 命名 |
---|---|---|---|
文本输入框 | .input_tx | 段落文本颜色 | .tx_c_p |
密码输入框 | .input_pw | 相册弹出的设置层 | .pop_set_photo |
登录密码输入框 | .input_pw_login | 日志设置成功提示 | .hint_suc_blogset |
文本颜色 | .tx_c | 公共提示 | .hint_gb |
问几个简单的问题,可以帮助我们完成命名:
可能无法覆盖到所有的情况,但相信能解决70%~80%的命名问题。如果结合“模块化”相关的方法去定义,其实所需要定义的名称并不需要很多。如:“hint_tx”表示提示模块的文字定义,“hit_tx_hint”表示提示里文字强调的定义,至于是改变颜色还是加粗,这个就看不同提示模块的需要了。