代码的规范化—高质量程序的结构(一)

PS:均总结自前辈经验和自己的个性化心得

1、程序是让人看的,是要分享给队友或者领导,甚至是任何陌生的人共享交流,还有记得大学的时候一次全院大会,院长说,“写代码就和写毛笔字一样,要有书法的规矩,要有美感才可以,这也是区分到底是科班还是非科班的出身,到底这个人平时是严谨的还是大意的,这个人有没有对美的追求,有没有真实团队开发经验的一个考察点”

2、学校里很少有讲这些,只能自己总结和加以注意。

一、程序整体结构排版

1、使用空格分割程序的不同逻辑块或者代码块,比如类的声明之后

1 class A
2 {
3
4 };
5 //空

函数定义之后

void print()
{

}
//空

同一个类or函数体内,逻辑块or功能快要空格区分

if (xxx)
{
    xxx;
    //空
    for ()
    {
        xxx;
    }
    //空
    xxx;
}
else
{
    xx;
}
//空

2、做到一行代码只做一个事

//int a, b, c;//不推荐
//a = b = c;
//a = b + 1; a = a + b;

//推荐,容易阅读,方便注释
int a;//a
int b;//b
int c;//c

a = b + c;
a = b - c;

3、任何循环体,判断体等执行语句都使用{}

if ()
  xxxx;//这看着就不爽,还容易让人误判

//推荐
if ()
{
}
//空

4、循环的for,while,do,开关switch,判断语句if等,不要独占一行

//while(){xx;};//不推荐

//推荐
while ()
{
}

5、养成变量定义就初始化的好习惯(尽可能的),防止疏忽而忘记,比如有时候程序很大,前面的变量没有初始化,那么后面忘记了,使用就会出错!

c++可以随用随定义,现在标准C99以后的C也可以这样了。

6、关键字后面留一个空格(突出关键字,识别关键字)

if ()
{
}

//constint a = 10;
const int a = 10;

7、函数名之后紧跟()区别于关键字

//void print ();
void print();

8、列表里的分号(比如for循环等),列表的逗号(比如函数参数列表等),都要空格分开,不要挤到一起

赋值,比较,移位,算数,逻辑等二元运算符,前后加空格分开
但是,比如圆点. -> [] 运算符 前后不用加空格,只适用具有比较和传递关系的

//for (int i=0;i<100;i++)//丑陋 时间长了还眼疼
for (int i = 0; i < 100 || i > 0; i++)//++是一元的,一元就一个操作数,不空就挺好的了
{
}

//int x=a<b?a:b;//丑陋不堪
int x = a < b ? a : b;

/*空格太多了
int * p = & a;
p -> function();
(*p) . function();*/
int *p = &a;
p->function();
(*p).function();

//int arr [100];//不觉得很别扭么?
int arr[100];

9、程序应该左对齐,包括括号等标记,如果有嵌套,使用缩进!

/*接触过java,貌似都是这么写,包括自动生成的代码,也是习惯问题吧,c和c++里一般不这样写
if (){
    xxxx;
}*/

if ()
{//全部左对齐
}

do
{
} while ();//末尾的while不另起一行!空一个格,然后沿着本行写while ();

//嵌套的要缩进!
if ()
{
if ()
{
if ()
{
xxxx;
}
}
}

10、记得看林锐博士的书说,一行代码建议保持在70-80左右个字符,太长不容易看,也不容易打印,长了要拆分,拆分的新行要适当缩进,排版整齐。

/*这样显然看着很不舒适!
if ((long_long_long_long < very_big_high) || (a > b) && (short_short) <= 100000)
{
//
}*/
//拆分长语句,同时如果有运算符,那么要注意突出运算符的存在!一起拆分到下一行开头,类似的还有for语句()里
if ((long_long_long_long < very_big_high)
     || (a > b)
     && (short_short) <= 100000)
{
    //
}

//函数参数也是如此
//void sum(int long_variable, int so_long_variable);
virtual int sum(int long_variable,
                int so_long_variable);

11、* 和 & 到底应该靠近谁(数据类型 or 变量)的问题,查阅了很多相关资料,我认为应该紧跟变量名!

//int* a;//直观表达了指针是int类型的,但是弊端是
//int* a, b;//虽然a b可以分行,但是不一定每个人都这样做!不注意会认为b也是指针!

int *x, y;
char *name;

二、注释和版权,头文件和定义文件的结构
一般情况下,把类、函数、常量的声明写到头文件,定义写到.c or cpp文件

头文件:
1、程序通过头文件来调用标准库的功能,因为有时候源代码不方便公布(绝大多数),那么只需提供头文件和二进制库即可,用户调用接口声明就可以使用这些功能,不用看到和关心具体的实现,编译器自动查找提取。
2、头文件可以使得程序具备良好的层次性和结构性,提高阅读性,加强类型检查!
3、类似于java,如果软件的头文件很多很多(比如类似java里的dao,action,servlet等),可以分目录存放,便于维护。比如头文件保存到include目录,定义文件保存到source目录等等。如果某个头文件也需要保密,那么可以和定义文件放到一起!

在头文件和定义文件开头,要写清楚版权信息和作者信息,文件功能简介等(依据团队或者公司要求)

/*
*    Copyright (c) 2014, xxxxxxxx
*    All rights reserved
*
*    文件名称:
*    主要功能:
*
*    当前版本:
*    作    者:
*    完成时间:
*
*    //如果有以前版本的话,后面依次写上取代版本,完成时间,作者
*/

头文件结构

1、版权,文件信息说明
2、预处理操作
3、常量,类,函数,结构,联合,枚举等的声明
4、为防止头文件被重复引用,应该用#ifndef #define…… #endif结构产生预处理块
5、头文件只存放声明,不写任何定义!
6、c++的类内成员函数,如果声明的同时就定义,自动inline,不论是效率还是风格都无法保证!不推荐(除非函数特别小的时候)。
7、常量用大写字母标识!区分变量

//如下一个头文件myHeader.h
#ifndef MYHEADER_H //防止本头文件被重复引用
#define MYHEADER_H //编译器检测指定的预处理器变量,是否定义?如果没定义,则其后的全部指示都被处理,直到遇见#endif。若定义,则后面被忽略
//空行
#include <iostream>
#include <string>
#include "zijdingyi.h"//先引用标准库头文件,再引用自定义头文件
const double PI = 3.141592653;//注释常量意义且常量名大写,c里的宏定义 #define PI 3.14
……

//注释
void function();// 全局函数声明
……

//注释
class A
{
    //类声明
};
//空行
#endif //一般放到程序末尾

定义文件的结构

1、也要开头写好版权信息和作者程序信息等
2、头文件引用
3、定义代码

//如下一个定义文件 implementation.cpp
#include "myHeader.h"

//注释
void function()
{
    //……
}

//注释 类成员函数实现
void A::print()
{
    //……
}

c和c++的注释为
单行注释 // 标准c新增
块注释 /* */

注释一般用于:
1、函数接口声明的意义解释
2、头文件和定义文件里,版权,作者,功能等信息说明
3、个人认为重要的代码行,块的提示信息
4、注释如果是为了学习使用,可以当作笔记(个人认为),如果是正式的软件产品,那么不能过多!

int arr[NUM];//声明一个数组 其实这就没有必要注释,是个人都能看懂看出!

不能反客为主,且花样要少,整洁干净!

5、代码一旦修改,相应的注释必须及时更新!
6、注释要负责任,不能瞎写或者想当然,不能模棱两可,要写清楚,写明白,不使用缩略词!不然,不如不写,以免误导别人或者以后自己看了都看不懂,或者以后自己看到这些注释,可能会怀疑自己的知识是不是学错了……
7、注释的位置不能随心所欲!要和被解释的代码靠近,代码的上面,或者后面都行(下面不行)
8、当代码有很多嵌套,那么要在一些嵌套结尾处加上注释,便于阅读,一目了然!

if ()
{
    //……

    while ()
    {
        //……

        for ()
        {
            //……
        }//end of for

        //……
    }//end of while

    //……
}//end of if

……

13、类的结构版式

class A
{
private://个人习惯,把private属性的成员写在最前面,不过有人推荐public接口写在最前面,这样的话重点是关心接口。具体看团队开发的规定了
    int a;
public:    xxxxx;
};

三、变量的命名习惯
推荐匈牙利法或者驼峰命名法(具体还是要服从团队的规定)
匈牙利法:变量或者函数名加入前缀词,提醒用户如何理解。命名比较麻烦,但是直观,易于阅读(微软推荐)

char *chName;//字符变量加ch前缀,下一字母大写。
int iNum;//int i
float fVar;//float f

驼峰命名法:变量名或函式名是由一或多单字连一起而构成唯一识别字,则第一个单词小写,后面的每一个单词的首字母都大写

String myFirstName;
String myLastName;//这样的变量名看上去就像骆驼峰一样此起彼伏

几个共性问题

1、变量名和函数名,类名等要有意义,望文知意!最好是英文单词(可见确实英语很重要,不止体现在此)组合,不能用汉语拼音!!!!!
2、现在的标准C不再具体规定变量名字的长度,但是不是越长越好(不过也不一定,因为比如OC,苹果就是希望方法名越长越好),一般局部变量使用短的,最好是单个字符,比如i,j,k,p,q等
3、不要把不同风格的命名规则使用在一个程序里,要么用驼峰,要么用匈牙利,要么用其他的
4、不要依靠大小写区分变量(虽然他们不一样)

int sum(int x, int X);//x和X很容易混淆
double SUM(double x, double y);//函数名也是一样

5、对于全局变量和局部变量,虽然可以重名(作用域不同),但是还是避免比较好

6、针对变量名,应该使用名词,或 形容词 + 名词

double preCode;
double nextCode;
int oldNum;
int newNum;
char *redCar;
char *blueCar;

7、全局函数的名字应该用 动词 or 动词 + 名,类成员函数名只用 动词,而类的对象充当名词的角色。

Point point;
point.draw();//类成员函数
drawPoint();//全局函数

8、对于有互斥含义的,使用反义词命名

int minValue;
int maxValue;
void setAge(int age);
int getAge();

9、不论什么名称,都不能混入数字!

int a1;//不推荐,这是偷懒的行为,说明程序员不动脑子,造成无意义的命名
int a2;//除非程序本身需要编号,则在使用编号命名

10、常量名使用大写,且用下划线分割

const int MAX_NUM;
#define MIN_VALUE 10;

11、静态变量声明使用前缀 s_

static int s_minValue;//s_    static

12、全局变量之前,使用前缀 g_

double g_money;//g_     global

13、类的数据成员前,使用前缀 m_

void Point::setAge(int age)
{
    m_age = age;//m_      member     避免类数据成员和成员函数或者参数同名or不好区分
}
时间: 2024-10-15 07:03:01

代码的规范化—高质量程序的结构(一)的相关文章

4年前的随笔---写出高质量程序的要点

从1990年開始敲代码.到如今已经快20年了.总结出写出高质量程序的几个要点: - 1.開始写之前思路越清晰完整越好. - 2.写的过程中代码一定要规范一致,这种代码便于维护和改动.这个规范一致性包括名称.格式.算法等.- 3.发现一处错误,马上回忆有没有可能其他地方具有相同的错误(假设你遵循第2条.就能非常快找到). - 4.多用ASSERT,在我的代码里面,这条语句至少占领了程序总量的1/10. - 5.每写完一段后至少重复看3遍.非常多BUG是非常难用调试器找出来的. - 通过遵循以上规则

Python编程实战:运用设计模式、并发和程序库创建高质量程序 阅读笔记

Python编程实战:运用设计模式.并发和程序库创建高质量程序 目录 1 创建型设计模式 2 结构型设计模式 3 行为型设计模式 4 高级并发 5 扩充Python 6 高级网络编程 7 Tkinter 8 OpenGL 创建型设计模式 抽象工厂 @classmethod def make_xxx(Class, ...) Builder with open(filename, "w", encoding='utf-8') as f: f.write(x) 多一层映射封装好吗? 序列与m

python经典书籍:Python编程实战 运用设计模式、并发和程序库创建高质量程序

Python编程实战主要关注了四个方面 即:优雅编码设计模式.通过并发和编译后的Python(Cython)使处理速度更快.高层联网和图像.书中展示了在Python中已经过验证有用的设计模式,用专家级的代码阐释了这些设计模式,并解释了为什么一些与面向对象设计相关的模式和Python均有关联. 书中通过大量实用的范例代码和三个完整的案例研究,全面而系统地讲解 了如何运用设计模式来规划代码结构,如何通过 并发与Cython等技术提升代码执行速度,以及如 何利用各科IPython程序库来快速开发具体的

开始慢慢学习这本书了。。Python编程实战:运用设计模式、并发和程序库创建高质量程序

没办法,不到设计模式,算法组合这些,在写大一点程序的时候,总是力不从心...:( 一开始可能要花很多时间来慢慢理解吧,,这毕竟和<大话设计模式>用的C#语言有点不太一样... 书上代码是3版本的,有些库的用法不一样,还要改回2.7的才可以测试..:( #!/usr/bin/env python3 # Copyright 漏 2012-13 Qtrac Ltd. All rights reserved. # This program or module is free software: you

高质量C++/C编程指南

http://man.chinaunix.net/develop/c&c++/c/c.htm#_Toc520634042 文件状态 [  ] 草稿文件 [√] 正式文件 [  ] 更改正式文件 文件标识: 当前版本: 1.0 作    者: 林锐 博士 完成日期: 2001年7月24日 版 本 历 史 版本/状态 作者 参与者 起止日期 备注 V 0.9 草稿文件 林锐 2001-7-1至 2001-7-18 林锐起草 V 1.0 正式文件 林锐 2001-7-18至 2001-7-24 朱洪海

[ 转 ]编写高质量代码:改善Java程序的151个建议

记得3年前刚到公司,同桌同事见我无事可做就借我看<编写高质量代码:改善Java程序的151个建议>这本书,当时看了几页没上心就没研究了.到上个月在公司偶然看到,于是乎又找来看看,我的天,真是非常多的干货,对于我这种静不下心的人真是帮助莫大呀. 看完整本书,也记了不少笔记,我就分享一部分个人觉得有意义的内容,也为了方便以后自己温习. --警惕自增陷阱 i++表示先赋值后自增,而++i表示先自增后赋值.下面的代码返回结果为0,因为lastAdd++有返回值,而返回值是自增前的值(在自增前变量的原始

编写高质量代码改善C#程序的157个建议——建议13: 为类型输出格式化字符串

建议13: 为类型输出格式化字符串 有两种方法可以为类型提供格式化的字符串输出.一种是意识到类型会产生格式化字符串输出,于是让类型继承接口IFormattable.这对类型来 说,是一种主动实现的方式,要求开发者可以预见类型在格式化方面的要求.更多的时候,类型的使用者需为类型自定义格式化器,这就是第二种方法,也是最灵活 多变的方法,可以根据需求的变化为类型提供多个格式化器.下面就来详细介绍这两种方法. 最简单的字符串输出是为类型重写ToString方法,如果没有为类型重写该方法,默认会调用Obj

转载-------编写高质量代码:改善Java程序的151个建议(第1章:JAVA开发中通用的方法和准则___建议1~5)

阅读目录 建议1:不要在常量和变量中出现易混淆的字母 建议2:莫让常量蜕变成变量 建议3:三元操作符的类型务必一致 建议4:避免带有变长参数的方法重载 建议5:别让null值和空值威胁到变长方法              The reasonable man adapts himself to the world; The unreasonable one persists in trying to adapt the world himself. 明白事理的人使自己适应世界:不明事理的人想让世

编写高质量代码改善java程序的151个建议——[110-117]异常及Web项目中异常处理

原创地址:http://www.cnblogs.com/Alandre/(泥沙砖瓦浆木匠),需要转载的,保留下! 文章宗旨:Talk is cheap show me the code. 大成若缺,其用不弊.大盈若冲,其用不穷.  <道德经-老子>最完满的东西,好似有残缺一样,但它的作用永远不会衰竭:最充盈的东西,好似是空虚一样,但是它的作用是不会穷尽的 Written In The Font 摘要: 异常处理概述 学习内容: 建议110: 提倡异常封装 建议111: 采用异常链传递异常 建议