日本人的企业呆着最大的感受就是—规范,想象不到的规范
日本人的规范用到硬件上,做出了高质量的产品。但是软件上,日本人做的并不怎么好。
日式代码的风格
文档式代码—风格一:
日本人很爱写文档,应该是酷爱写文档。代码设计思维跟他们写文档一个样。不怎么讲究灵活巧妙的设计思路。写文档时,是什么功能一条一条地列出来实现。
写代码也是这,讲究复杂的功能就应该分解,分解成一块一块的,然后一条一条的罗列出来实现(也许整个民族就是这样思维的)。整个代码风格说好了是规范,说的不好有点僵化,但是我们还有值得学习的地方。
文档式代码,里面设计架构很简单,就是分解功能。同时设计过程中遇到新问题,不是巧妙的复用以前的功能,而是再制造出一个新的功能。
文档式代码,阅读多了,会发现怎么这么多的功能实现,而且之间都是并列关系,也没巧妙的组合到一块。
这种代码新手一上来可能没好的应对思路。好的应对思路就是跟日本人要SD文档,看代码的时候,最好结合着他们的设计文档看,这样你就会感觉到阅读不困难了,比以前有点轻松了。
文档式代码还有个应对思路,就是以后疏通测试时,看他们那详尽的log信息输出。一看到log信息,代码整个工作思路都明白了。
爱用宏—风格二:
代码中宏的运用的好处:
使代码清晰可读,规范:
如:pjsd_bean.h文件中宏的运用,
#define BEAN_FREE_FAIL -31
#define BEAN_FREE_OK 0
运用在 资源释放函数中;
#define BEAN_CHK_FAIL -42
#define BEAN_CHK_OK 5
运用在资源检查函数中;
以上宏的第二个字段仔细区分了应用在哪个函数。
#define BEAN_SCHED_CUT -5
#define BEAN_MAXTIME -4
#define BEAN_ALCNOW_OK 0
#define BEAN_ALCRSV_OK 1
对于函数返回值宏,小于0代表函数分配资源失败,大于等于0代表分配成功;通过返回值宏定义来区分错误失败,对接下来的函数分支处理很有帮助。
spec_write_log函数中宏的应用,具体反映了文件格式出错的细致原因,到底是哪种错误,见此函数和check_code_t枚举结构体的应用;反映了日式代码的清晰可读;
还有这个语法的运用:
switch(alloc_type) {
case ALC_AB_PACK:
case …………
get_spec_resc等其分支函数中的怎么检查出各种文件格式出错的代码处理,反映出日式代码的高可靠质量(能检查出各种指定文件格式错误),同时也是把宏成功应用到代码错误检测处理中的典范,这个错误检查如果不用这个宏来处理的话,还真想不出其他的办法。
代码片段为:
/* set flag bit */
#define SET_DEFINE 0000000001
#define SET_NODE 0000000002
#define SET_CORE 0000000004
*set_flag |= SET_NODE;
if (*set_flag & SET_DEFINE){ // 这种与语句也很重要的。
统一的编码规范—风格三(这一点值得学习的)
代码是写给人看的,顺带在机器上执行。
所以要给变量,函数起个好听的规范的名字,便于以后阅读。写出的代码,就等于在用规范清晰的思想和别人交流。
pcc_rscgrp_cpu_t rscgrp; t 用来声明结构体
pcc_timemap_t *new_tmap_p = NULL; 变量后面的p是为了指出这是个指针变量;
全局变量起名如:g_allocable 在最前方带个g字,表明为全局变量;
所有的宏用大写字母表示
int delay_njobs,forcealloc_njobs; 中的n表示多少个JOB;
枚举结构体来清晰的表示:
struct {
int cnt;
int *interval_p;
}cause[PJS_COUNT_DLINE+1];
typedef enum {
PJS_COUNT_GAP_OVER = 0,
PJS_COUNT_CHG_RESOURCE,
………
}pjsd_count_opp_t;
………………………..
resched_ctl.cause[PJS_COUNT_GAP_OVER].interval_p = 1;
resched_ctl.cause[PJS_COUNT_CHG_RESOURCE].interval_p = 2;
有待完善啊
PS:以后还要加强这方面的训练,让自己的程序词语优美些。
详细的log信息输出—风格四
之前在PT组呆着就感受了性能测试过程中log信息的重要性。
完备的LOG信息输出有助于你对代码工作流程的了解,也方便以后排错。
例如PCC软件开发时,代码各个地方统一输出log信息的好处:可以根据log信息提示来理解代码的工作行为,多线程调试时这是个比较好的办法。根据log信息级别的轻重缓急,及各级别log信息提取,有利于理解整个代码的工作行为。
怎么做各个级别LOG信息提取的,怎么分清log信息级别的轻重缓急都是值得我们学习的。
PS: 感受着日式代码,不一样的风格,取其精华,忍受其糟粕吧。