当人们一开始接触各种Web开发语言时,总会发现彻底搞懂不同语言的命名约定是一件很要命的事情。而且当开发者在争论什么才是最佳实践时,事情会变得更加让人困惑。为了让初学者更容易地在不同语言中过渡,这篇文章列出了一些常见的约定。
1. 类属性名前加下划线
如果你看到一个变量或者方法是以_开头的,其实这并不代表其幕后有什么猫腻。这仅仅是为了提醒开发者这个变量/属性/方法是私有的(private
)或是受保护的(protected
),它们不能从类的外部访问到。
PHP方式
1
2
3
4
5
6
7
>1
2
3
4
5
6
7
>1
2
3
4
5
6
7
8
9
10
11
12
13
>1
define('TAXRATE', .0825);
3. 单字母前缀
你一定在某些场合见过变量名是以一个单独字母开头的,例如“s”或者“i”。
$sName = 'Captain Jack Sparrow'; //译注:Jack Sparrow《加勒比海盗》中的船长角色
这被称作“匈牙利命名法”,事实上在近几年并不流行。不过在许多公司内这仍是一条约定。
匈牙利命名法能够提醒开发者它正在使用的变量是什么类型的:string
,integer
等。
尤其在JavaScript中,这种方法是不可取的,因为JavaScript是弱类型的语言。弱类型语言不需要在使用变量前声明它的类型。如果我们给一个字符串以“s”开头命名,但是后来我们把一个整数赋值给它,这种命名法还有什么意义呢?事实上,这种形式的命名法会妨碍我们的工作,而不是对工作有益。
var sName = "Lieutenant Commander Geordi La Forge"; // 译注:Geordi La Forge 少校是《星际迷航:下一代》中的角色,天生眼盲,佩戴高科技护目镜
typeof(sName); // string
....
sName = undefined;
typeof(sName) // undefined
美元符号
致jQuery使用者:当你使用工厂函数生成对象并且心里暗喜没有受到匈牙利命名法的束缚时,你是否会在变量名前加一个美元符号?如果是这样,那么这也是匈牙利命名法的一种形式。这个符号的唯一目的是提醒你这个变量的类型。
// 这个美元符号提醒我可它可以使用jQuery的各种方法
var $container = $('#container');
应当这么使用吗?
这完全取决于你自己。事实上许多jQuery团队的成员也使用这种美元符号前缀。使用它的最终目的是能够适应你的工作。以我而言,几年前我就不使用这种美元符号了??这仅仅是因为我个人觉得这没有必要。你可以自己决定如何对待它。
4. 首字母大写
下面这个首字母大写的变量名看上去如何?
$response = $SomeClass->doSomething();
在上面的代码中,$SomeClass写成了单词首字母大写的形式是因为它是一个类的对象而不是普通的变量名。通常这是绝大多数开发者使用的方法。当我们一年后再回过头来看这些代码时,这个简单的形式就能准确地告诉我们这是一个对象,可以调用其方法。
// 注意类名中大写的M
class MyClass {
function __construct() {}
}
JavaScript方式
在JavaScript中,没有真正的类,但是有构造(constructor
)函数。
var Jeff = new Person();
我们将构造器(Person
)的首字母大写的原因是我们有时候很容易忘记new关键词。在这种情况下,JavaScript往往不会抛出任何警告,但是这个小错误却非常难调试到。首字母大写能够给开发者在debug时一个有效的提示。Douglas Crockford是这个约定最大的提倡者。(译注:Douglas Crockford是Javascript社区的大神级人物,是JSON、JSLint、JSMin和ADSafe之父,是《JavaScript:The Good Parts》的作者。)
另一种可选方案是,如果你生怕自己的健忘,你可以在执行前首先确保构造器存在并且正确。
function Person(name) {
// 如果遗漏了new关键词,将会执行下面的构造函数并返回一个新的实例
if ( this.constructor !== Person ) {
return new Person(name);
}
this.name = name;
}
// 故意不用“new”关键词
var Joey = Person('Joey');
Joey.name; // Joey
5. 驼峰式和下划线式
为什么有些变量使用驼峰式大小写模式,而有些是使用下划线分割单词呢?哪一种是正确的方法?答案是:没有绝对正确的用法。这完全去取决于你的语言,或者你公司的代码约定。这两种都是非常好的方式。
// camelCase
var preacherOfSockChanging = 'Lieutenant Dan'; // 译注:Dan中尉,电影《阿甘正传》中的人物
// under_score
var preacher_of_sock_changing = 'Lieutenant Dan';
正如大家所说,跟随你使用的语言的通常约定是一项最佳实践。例如,大量JavaScript开发者使用驼峰式的语法,而像PHP则更倾向于使用下划线分割。需要重申的是,这不是板上钉钉的规矩。Zend框架就是驼峰式大小写的推动者。
比你使用什么更重要的是确保你一直去使用它!
6. 目录结构
通常在团队中工作时,你必须和你的协同开发者一起接受一个合适的目录结构。最基本的显然是不要把所有的样式表、脚本都放到项目的根目录下,这显得非常无组织无纪律。许多开发者愿意将它们的图像、脚本和样式表放到一个Assets
目录下。
/ Project Root
/Assets
/ js
/ min
script_min.js
script.js
/ css
/ min
style_min.css
style.css
/ img
img1.jpg
index.html
otherFile.html
此外,记住一项创建min
目录的约定规则。这里面动态地存放着压缩后的脚本和样式表文件。
7. 语义
当使用标记语言时,需要明白你选择的id
和class
需要能够描述你的内容,而不是仅仅代表形式。例如:
最悲剧的
<div id="middle-left-and-then-a-little-lower"> Justin Bieber is my homeboy section. </div>
稍好一些
<div class="section"> Justin Bieber is my homeboy section. </div>
最佳做法
<section> Justin Bieber is my homeboy section. </section>
怎么样?如果在六个月以后,你决定把Justin Bieber粉丝的内容放到中间偏右并稍低一些(middle-RIGHT-and-then-a-little-lower)的位置呢?这样,你的iid
就完全失去了意义。
我们正在向HTML5的世界过渡,你应当在元素中使用尽量少的标识。id
显得很不灵活,而且很多情况下并不需要。
8. 写两遍Header
和Footer
当做一个居中的网站时,需要将多重背景扩展到整个窗口的宽度(通常是header
和footer
),是非常令人讨厌的。你通常需要包裹你的内容,这样外层元素扩展后,内层元素还能继续保持居中。
这是一个一般性的问题,在创建必需的标记语言内容时接受这样的约定规则是很重要的。
<div id="footer-wrap">
<footer>
My footer content goes here.
</footer>
</div>
难以决定的是,假设你在使用HTML5中的新元素,你需要决定将footer
标签放在里面还是外面。这个还有待讨论。然而我个人觉得将footer
放在内层更加语义化。
div
只限下面的情况时才使用:
- 没有更好的元素来使用了
- 你需要一个单纯的表示布局结构的元素
9. 简写
现在就决定是否允许在你的代码中使用简写。书写精确且整洁的代码总是一场可读性和代码长度的斗争。这也正是开发团队内使用相同代码风格是首要考虑规则的原因。来看两个简单的例子:
三目运算符合适吗?
var name = 'Joe';
// regular
if ( name === 'Jeff' ) {
alert("That's me");
} else {
alert("Nope");
}
// ternary
alert(name === "Jeff" ? "That's me" : "Nope"); // Nope
使用逻辑&&
来写简短的条件判断句?
var getTweets = true;
// regular
if ( getTweets ) {
alert('getting them now');
}
// 逻辑 AND
// 除非左边是“true”否则右边不会运行
getTweets && alert('Getting them now');
许多开发者都对如此使用AND感到不爽,坚持认为这影响了可读性。尽管这的确是是一个有力的观点,但是连流行的框架类库例如jQuery也大量使用了这种方法。
结论
再次重申,你在开发时坚持使用某种方式比选择什么样的的约定来的更加重要。事实上,许多开发团队都有自己专门的代码风格指导给新开发者参考。感谢阅读!
译注:关于变量命名更详细的约定规则介绍,大家可以阅读《代码大全》(第2版)的第11章。
原文:9 Confusing Naming Conventions for Beginners
作者:Jeffrey Way