跳转到主要内容
Carol 提交于 16 July 2014

标准的写代码

原文: http://www.blinkreaction.com/blog/drupal-coding-standards

Drupal 标准代码

2014年7月8日撰文Matt Korostoff

我们和Blink Reaction公司合作很多。不只是内部的,有和客户开发团队,还有我们的合作伙伴,当然还有Drupal 社区。

最近,一个同事在开发员聊天室问了个问题是关于标准的写代码到底有什么价值。很明显他自己很清楚价值在哪里,然而,之前跟他合作的一个客户的那个具体项目的Git库代码不是用Drupal标准代码写的。实际上我这个同事问的问题应该是“我应该怎么告知我的客户标准规则代码的价值?”

每个程序员都有自己处理空白字符,换行符,下划线还有其他一些的偏好。有一些开发员喜欢用-下-划-线-来-分-割-字-体。其他的又喜欢每个首字母大写(PreferCamelCase)。这些习惯在个人项目中都还没有什么,但是如果是很多不同的程序员要把根据各自习惯写的代码加到一个项目中就麻烦了,结果就是一团乱。幸好的是,Drupal社区已经用Drupal 标注代码 来最大化的解决了这个问题。可能对于一个Drupal新人来说为什么要准守这么多的代码撰写规则,其实任何一个曾经给较大型的项目写过代码的人都知道,如果你不会使用标注代码来写,等于一无是处。准守Drupal标注代码有很多策略和功能上的原因的,下面都讲一下。与你所见一样,准守这个标准规则非常有用,即使你不承认也没关系。

 

策略上遵守Drupal标准代码的原因:

遵守代码标准使团队工作更容易了。很多团队都会在Drupal标准代码的核心设置上作一些小的个性化修改。但是,拥有固定的标准其实很重要,否则的话其他人都要费尽心思来解析你的代码。当你在一个已有的代码库花了很多时间你开始寻思这些应该看起来是怎么样的

当你快速的浏览完一个文件,找一个,就说是功能定义吧。你在找相似的形状和模式来停留或者近距离的检查。

这个为什么所有的“停止前进”标志是八边形的原因一个道理--不是因为八边形的标志和其他形状的相比就一定是“停止前进”,只是因为八边形的标志可以让驾驶员在行驶时或高速状态中也可以很快的识别出这个交通标志的意思。如果有些镇把“停止前进”标志弄成月牙形状的,我们可能也会识别出来,只是需要更多的时间来辨别出这个标志。

许多国家都是用标准的红色八边形标志写着“STOP”,包括一些不适用拉丁语字母的国家也是用这个标志。上面这幅图就是希腊的STOP标志。证据: http://www.ilankelman.org/stopsigns.html

 

通常来说,代码都被阅读大约两到三次比写的时候花的时间更多。每次你写代码时就决定了以后每次被阅读时所要的时间。有一个很好的视频来解释这一点:video URL:Video

一个简单的举例:

这里有个简单例子是基于这个规则操作的。Drupal标准代码在函数调用时在参数前后都不需要空格,一般看起来都是没有问题的,但是如果一旦在函数调用中声明数组时,将会导致以下的槽糕情况:

return l('Log in', 'user/login', array('attributes' => array('target' => '_blank')));

个人的看法,我没办法忍受这个,而且我认为这个是没办法阅读的。我的习惯是,目前为止,有空格字符的比如:

eturn  l(  'Log in', 'user/login', array(  'attributes' => array(  'target' => '_blank'  )  )  );

当我写的代码是只给自己用的,我总是在我嵌套的函数调用里面留空格。但是现在想像一下这个脚本:我们在某个自定义模板里面发现了一个漏洞当每次在l() function中声明一个嵌套的数组时都会造成一个致命的错误。所以我们又在l() function生成一连串的正则表达方式来寻找所有声明数组的实例,其实也很简单,只要大家都遵守标准:"l\(array\(.*array\("。但是如果每个人都按照自己的偏好来写,那么要写一个符合所有不同偏好的正则表达方式几乎等于不可能。所以我遵守这个规则,即使我认为它是错的。因为我知道别人会处理我写的代码。

然后,顺便说一句,在实际的情况中,我宁愿将以上的重构为以下这种:

//settings for use in the l() function to make links open in new tab

$open_in_new_tab = array(

 'attributes' => array(

   'target' => '_blank'

 )

);

 

//Create a link to the user login page

return l('Log in', 'user/login', $open_in_new_tab);

功能上遵守Drupal标准代码的原因:

可以有一个可预测的,标准的代码格式和一个有预测结构的工具来搭建网站。我相信这个优点对于有经验的程序员来讲已经是很显著的了。但是这里也允许我给出一些Drupal的具体案例:

标准的评论可以被API模块解析来自动生成文件https://drupal.org/node/1354 :

“API模块解析文件和PHP文件里面的代码,并且他要求用一个和其他代码/文件解析系统相同的文件格式例如PHPDoc,JavaDoc,等等。 他最初是基于Doxygen系统的。但是后来渐渐演化出有自己的标签和许多的Drupal具体功能”

https://drupal.org/node/1354

标准功能和类的定义可以被IDEs解析和文字编辑器来实现一个像PHPStorm的ctrl+click跳转到功能定义这样的功能。

http://i.imgur.com/BFInJqq.gif

 

在文件区块中的@标签是十分有用的,可以在广义的相关文本中被用来生成自动列表,例如:

http://i.imgur.com/aLjgmeK.jpg

Drush可以通过分析文本区块在部署时来展现有用的输出。Drush中很多高级的功能之所以能实现也是得益于Drupal的标准代码的原因。例如以下 安装文件:

http://i.imgur.com/iPoYarg.jpg

给你这个drush 输出:

http://i.imgur.com/DRlxRG9.gif

自动格式化像Sublime’s PHP整洁可以移除出所有的代码方式思维-但是如果两个人在同一个项目上使用不同的代码格式来自动格式化,他们只会立马重组对方的代码,造成Git历史记录里面最大的混乱。

 

总的说来:

 

当然,你的团队可能会认为Drupal标准代码的某些方面不适合你-但那不是世界末日。最重要的是你的团队最终还是会找到一个标准然后坚持这个标准,因为最后:

Drupal 版本