1.在代码中不要使用非id的字符串来判断逻辑，如：判断一个用户是否有某个小组角色，错误的使用方法：
$user_group_roles = og_get_user_roles('node', $gid, $user->uid);
if (in_array('小组管理员', $user_group_roles)) {}
正确的使用方法：
$user_group_roles = og_get_user_roles('node', $gid, $user->uid);
if (array_key_exists(RESOURCE_GROUP_EXPERT_RID, $user_group_roles)) { }
2.不要直接使用arg()，先定义一个有语义的变量，将arg()赋值，再使用该变量。
3.如果对比的两个变量类型不同，那么不能用 !== 去判断， ===及!==都要慎用！
if ($node->field_course_visibility['und'][0]['value'] != COURSE_VIEW_PRIORITY_PRIVATE
if ($node->field_course_visibility['und'][0]['value'] !== COURSE_VIEW_PRIORITY_PRIVATE
4.编写可重用的代码，建立项目API文档供团队成员查询使用
5.文件，目录组织及命令要遵守drupal的规范
6.变量名，函数名有语义，SQL语句关键字大写，缩进两个空格，运算符、控制语句内，该空格空格，该折行折行。如：if else之间是折行的。
7.代码注重效率，简洁，可读性好（分解代码），注释要详细。
8.成员之间可相互做code review，有利于了解项目的其它功能，提升代码编写能力。
9.ajax调用时的url路径值，要写成非简洁url的格式，以保证支持各种不同的服务器环境
$.ajax({
type: "POST",
url: '?q='+$( "#slider-range-max" ).attr('url'),
data: "progress="+progress,
success: function(){
}
});
10.在读取添加编辑删除entity相关内容时，如节点，分类，用户，评论等，都可以使用entity_metadata_wrapper()来实现，避免因字段结构不明产生的问题。
11.不要直接查询核心或第三方模块提供的表，要以API的方式调用，自己的功能模块写的表也是，模块都要提供相应的API封装。
12.若是自定义显示用户自行输入保存到数据库的内容，显示时要加输入格式过滤函数：check_markup, 或check_url, check_plain
12.尽量使用：Drupal.behaviors.*** 来代替jquery的页面载入事件：$(document).ready
14.尽量将.module中的API函数分散放到不同的inc文件中，按需加载（module_load_include()），减少.module的代码加载量
15.输出特定的日期格式时，要使用format_date函数，以使用系统内定义好日期格式，方便统一管理。
如：format_date($comment->created, 'short'); 而不要自己写：date('Y-m-d', $comment->created);
16.不在代码中设置特殊的变量值，如ip地址，帐号信息等。也不用常量，这些都放在variable中，提供一个变量设置界面，别忘了赋好权限。就像google分析模块，phpmailer模块等一样。
好处：1.有利于权限控制，只有相应管理员角色才能在正式站点配置这些敏感信息。 2.防止同一个系统，多个项目并存的开发模式下，代码之间有太多敏感的不同之处，不能方便的覆盖，改一个还得去再改另一个。
17.非在文件字段中上传的文件，例如是直接放在文件目录里被引用的文件，文件名尽量不要是中文，否则有些服务器的系统环境里，svn无法checkout
18.给模板增加变量时，可以先判断哪些页面需要这个变量，再去处理，比如在 _preprocess_page 里，每个页面加载时都会通过这个预处理函数去处理变量，
如果有变量的生成比较麻烦，花时间长，那么对每个页面都会有性能损失，所以可以只针对某些页面路径去定义。
19.hook_init里的代码是不会进入缓存中的，慎用！
20.非全局性css和js，在模块中使用 drupal_add_css, drupal_add_js 来加载，并尽量使用文件形式，而非在模块代码里加载。
21.如果在上线维护阶段，且是多人协作，那么做一个任务时，如果增加了新模块，且代码中有依赖此模块（如：调用了此模块的API），一定要在代码中判断新模块是否已经存在，如果不存在，也不会报错，影响其他成员的开发环境。
22.如果因为不得已的原因修改了第三方模块，应该把该模块从contrib文件夹转移到contrib_custom文件夹。已表明是修改了第三方模块。
23.词汇表使用时，尽量不使用vid，要使用machine_name。如：menu中有分类的参 数，$items['admin/structure/taxonomy/%taxonomy_vocabulary_machine_name'] ，SQL中有条件是某个词汇表时，使用词汇表的machine name，而不是vid。views中如果要使用词汇表作为动态参数，也要注意尽量使用词汇表的machine name。
分类导出再导入到另一个系统里后，vid可能会变化，但是machine name只要没有重复的就会保持，所以通过machine name调用词汇表的功能还可正常使用。
24.如果修改了第三方模块的代码，应该将其转移到custom目录中，以表明此模块被修改了，不要再直接覆盖升级。