精华内容
下载资源
问答
  • c语言代码规范
    2021-07-22 16:58:58

    一、宏定义篇
    1、作者的目的是防止GPIO口赋值超过1。但是有明显自觉高人一等,瞧不起读者的感觉。

    uint8_t not_func(uint8_t sw)
    {
     return (sw?1:0);
    }
    
    #define LED1(sw)            PA12=not_func(sw)
    

    修改建议:

    #define LED1 PA12
    #define LED_ON 0
    #define LED_OFF 1
    
    ...
    
    LED1 = LED_ON;
    ...
    LED1 = LED_OFF;
    

    2、遇到新的就更新,不定时

    更多相关内容
  • C语言代码规范

    2021-03-31 16:02:32
    1 排版 1-1:程序块要采用缩进风格编写,缩进的空格数为4个。 1-2:相对独立的程序块之间、变量说明之后必须加空行。 1-3:较长的语句(>80字符)要分成多行书写,长表达式要在低优先级操作符处划分新行,操作...

    1 排版

    1-1:程序块要采用缩进风格编写,缩进的空格数为4个。

    1-2:相对独立的程序块之间、变量说明之后必须加空行。

    1-3:较长的语句(>80字符)要分成多行书写,长表达式要在低优先级操作符处划分新行,操作符放在新行之首,划分出的新行要进行适当的缩进,使排版整齐,语句可读。

    1-4:不允许把多个短语句写在一行中,即一行只写一条语句。

    1-5:if、for、do、while、case、switch、default等语句自占一行,且if、for、do、while等语句的执行语句部分无论多少都要加括号{}。

    1-6:对齐只使用空格键,不使用TAB键。

    1-7:函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格,case语句下的情况处理语句也要遵从语句缩进要求。

    1-8:程序块的分界符(如C/C++语言的大括号‘{’和‘}’)应各独占一行并且位于同一列,同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义以及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。

    1-9:一行程序以小于80字符为宜,不要写得过长。

    2 注释

    2-1:一般情况下,源程序有效注释量必须在20%以上。

    2-2:文件头部应进行注释,注释必须列出:版权说明、版本号、生成日期、作者、内容、功能、修改日志等。

    2-3:函数头部应进行注释,列出:函数的目的/功能、输入参数、输出参数、返回值、调用关系(函数、表)等。

    2-4:边写代码边注释,修改代码同时修改相应的注释,以保证注释与代码的一致性。不再有用的注释要删除。

    2-5:注释的内容要清楚、明了,含义准确,防止注释二义性。

    2-6:注释应与其描述的代码相近,对代码的注释应放在其上方或右方(对单条语句的注释)相邻位置,不可放在下面,如放于上方则需与其上面的代码用空行隔开。

    2-7:对于所有有物理含义的变量、常量,如果其命名不是充分自注释的,在声明时都必须加以注释,说明其物理含义。变量、常量、宏的注释应放在其上方相邻位置或右方。

    2-8:数据结构声明(包括数组、结构、类、枚举等),如果其命名不是充分自注释的,必须加以注释。对数据结构的注释应放在其上方相邻位置,不可放在下面;对结构中的每个域的注释放在此域的右方。

    2-9:全局变量要有较详细的注释,包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明。

    2-10:注释与所描述内容进行同样的缩排。

    说明:可使程序排版整齐,并方便注释的阅读与理解。

    2-11:避免在一行代码或表达式的中间插入注释。

    说明:除非必要,不应在代码或表达中间插入注释,否则容易使代码可理解性变差。

    2-12:通过对函数或过程、变量、结构等正确的命名以及合理地组织代码的结构,使代码成为自注释的。

    说明:清晰准确的函数、变量等的命名,可增加代码可读性,并减少不必要的注释。

    2-13:在代码的功能、意图层次上进行注释,提供有用、额外的信息。

    说明:注释的目的是解释代码的目的、功能和采用的方法,提供代码以外的信息,帮助读者理解代码,防止没必要的重复注释信息。

    2-14:在程序块的结束行右方加注释标记,以表明某程序块的结束。

    说明:当代码段较长,特别是多重嵌套时,这样做可以使代码更清晰,更便于阅读。

    2-15:注释格式尽量统一,建议使用“/* …… */”。

    2-16:注释应考虑程序易读及外观排版的因素,使用的语言若是中、英兼有的,建议多使用中文,除非能用非常流利准确的英文表达。

    说明:注释语言不统一,影响程序易读性和外观排版,出于对维护人员的考虑,建议使用中文。

    3 标识符命名

    3-1:标识符的命名要清晰、明了,有明确含义,同时使用完整的单词或大家基本可以理解的缩写,避免使人产生误解。

    说明:较短的单词可通过去掉“元音”形成缩写;较长的单词可取单词的头几个字母形成缩写;一些单词有大家公认的缩写。

    3-2:命名中若使用特殊约定或缩写,则要有注释说明。

    说明:应该在源文件的开始之处,对文件中所使用的缩写或约定,特别是特殊的缩写,进行必要的注释说明。

    3-3:自己特有的命名风格,要自始至终保持一致,不可来回变化。

    说明:个人的命名风格,在符合所在项目组或产品组的命名规则的前提下,才可使用。(即命名规则中没有规定到的地方才可有个人命名风格)。

    3-4:对于变量命名,禁止取单个字符(如i、j、k...),建议除了要有具体含义外,还能表明其变量类型、数据类型等,但i、j、k 作局部循环变量是允许的。

    说明:变量,尤其是局部变量,如果用单个字符表示,很容易敲错(如i 写成j),而编译时又检查不出来,有可能为了这个小小的错误而花费大量的查错时间。

    3-5:命名规范必须与所使用的系统风格保持一致,并在同一项目中统一,比如采用UNIX的全小写加下划线的风格或大小写混排的方式,不要使用大小写与下划线混排的方式,用作特殊标识如标识成员变量或全局变量的m_和g_,其后加上大小写混排的方式是允许的。

    3-6:除非必要,不要用数字或较奇怪的字符来定义标识符。

    3-7:在同一软件产品内,应规划好接口部分标识符(变量、结构、函数及常量)的命名,防止编译、链接时产生冲突。

    说明:对接口部分的标识符应该有更严格限制,防止冲突。如可规定接口部分的变量与常量之前加上“模块”标识等。

    3-8:用正确的反义词组命名具有互斥意义的变量或相反动作的函数等。

    3-9:除了编译开关/头文件等特殊应用,应避免使用_EXAMPLE_TEST_之类以下划线开始和结尾的定义。

    4 可读性

    4-1:注意运算符的优先级,并用括号明确表达式的操作顺序,避免使用默认优先级。

    说明:防止阅读程序时产生误解,防止因默认的优先级与设计思想不符而导致程序出错。

    4-2:避免使用不易理解的数字,用有意义的标识来替代。

    涉及物理状态或者含有物理意义的常量,不应直接使用数字,必须用有意义的枚举或宏来代替。

    4-3:源程序中关系较为紧密的代码应尽可能相邻。

    说明:便于程序阅读和查找。

    4-4:不要使用难懂的技巧性很高的语句,除非很有必要时。

    说明:高技巧语句不等于高效率的程序,实际上程序的效率关键在于算法。

    5 变量、结构

    5-1:去掉没必要的公共变量。

    说明:公共变量是增大模块间耦合的原因之一,故应减少没必要的公共变量以降低模块间的耦合度。

    5-2:仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系。

    说明:在对变量声明的同时,应对其含义、作用及取值范围进行注释说明,同时若有必要还应说明与其它变量的关系。

    5-3:明确公共变量与操作此公共变量的函数或过程的关系,如访问、修改及创建等。

    说明:明确过程操作变量的关系后,将有利于程序的进一步优化、单元测试、系统联调以及代码维护等。这种关系的说明可在注释或文档中描述。

    5-4:当向公共变量传递数据时,要十分小心,防止赋与不合理的值或越界等现象发生。

    说明:对公共变量赋值时,若有必要应进行合法性检查,以提高代码的可靠性、稳定性。

    5-5:防止局部变量与公共变量同名。

    说明:若使用了较好的命名规则,那么此问题可自动消除。

    5-6:严禁使用未经初始化的变量作为右值。

    说明:特别是在C/C++中引用未经赋值的指针,经常会引起系统崩溃。

    5-7:结构的功能要单一,是针对一种事务的抽象。

    说明:设计结构时应力争使结构代表一种现实事务的抽象,而不是同时代表多种。结构中的各元素应代表同一事务的不同侧面,而不应把描述没有关系或关系很弱的不同事务的元素放到同一结构中。

    5-8:不要设计面面俱到、非常灵活的数据结构。

    说明:面面俱到、灵活的数据结构反而容易引起误解和操作困难。

    5-9:不同结构间的关系不要过于复杂。

    说明:若两个结构间关系较复杂、密切,那么应合为一个结构。

    5-10:结构中元素的个数应适中。若结构中元素个数过多可考虑依据某种原则把元素组成不同的子结构,以减少原结构中元素的个数。

    说明:增加结构的可理解性、可操作性和可维护性。

    5-11:仔细设计结构中元素的布局与排列顺序,使结构容易理解、节省占用空间,并减少引起误用现象。

    说明:合理排列结构中元素顺序,可节省空间并增加可理解性。

    5-12:编程时,要注意数据类型的强制转换。

    说明:当进行数据类型强制转换时,其数据的意义、转换后的取值等都有可能发生变化,而这些细节若考虑不周,就很有可能留下隐患。

    5-13:对编译系统默认的数据类型转换,也要有充分的认识。

    5-14:尽量减少没有必要的数据类型默认转换与强制转换。

    5-15:合理地设计数据并使用自定义数据类型,避免数据间进行不必要的类型转换。

    5-16:对自定义数据类型进行恰当命名,使它成为自描述性的,以提高代码可读性。注意其命名方式在同一产品中的统一。

    说明:使用自定义类型,可以弥补编程语言提供类型少、信息量不足的缺点,并能使程序清晰、简洁。

    6 函数、过程

    6-1:对所调用函数的错误返回码要仔细、全面地处理。

    6-2:明确函数功能,精确(而不是近似)地实现函数设计。

    6-3:编写可重入函数时,应注意局部变量的使用(如编写C/C++语言的可重入函数时,应使用auto 即缺省态局部变量或寄存器变量)。

    说明:编写C/C++语言的可重入函数时,不应使用static 局部变量,否则必须经过特殊处理,才能使函数具有可重入性。

    6-4:编写可重入函数时,若使用全局变量,则应通过关中断、信号量(即P、V操作)等手段对其加以保护。

    说明:若对所使用的全局变量不加以保护,则此函数就不具有可重入性,即当多个进程调用此函数时,很有可能使有关全局变量变为不可知状态。

    6-5:在同一项目组应明确规定对接口函数参数的合法性检查应由函数的调用者负责还是由接口函数本身负责,缺省是由函数调用者负责。

    说明:对于模块间接口函数的参数的合法性检查这一问题,往往有两个极端现象,即:要么是调用者和被调用者对参数均不作合法性检查,结果就遗漏了合法性检查这一必要的处理过程,造成问题隐患;要么就是调用者和被调用者均对参数进行合法性检查,这种情况虽不会造成问题,但产生了冗余代码,降低了效率。

    6-6:函数的规模尽量限制在200行以内。

    说明:不包括注释和空格行。

    6-7:一个函数仅完成一件功能,不要设计多用途面面俱到的函数。

    说明:多功能集于一身的函数,很可能使函数的理解、测试、维护等变得困难。

    6-8:函数的功能应该是可以预测的,也就是只要输入数据相同就应产生同样的输出。

    说明:带有内部“存储器”的函数的功能可能是不可预测的,因为它的输出可能取决于内部存储器(如某标记)的状态。这样的函数既不易于理解又不利于测试和维护。在C/C++语言中,函数的static 局部变量是函数的内部存储器,有可能使函数的功能不可预测,然而,当某函数的返回值为指针类型时,则必须是STATIC的局部变量的地址作为返回值,若为AUTO类,则返回为错针。

    6-9:尽量不要编写依赖于其他函数内部实现的函数。

    说明:此条为函数独立性的基本要求。由于目前大部分高级语言都是结构化的,所以通过具体语言的语法要求与编译器功能,基本就可以防止这种情况发生。但在汇编语言中,由于其灵活性,很可能使函数出现这种情况。

    6-10:检查函数所有参数输入的有效性。

    6-11:检查函数所有非参数输入的有效性,如数据文件、公共变量等。

    说明:函数的输入主要有两种:一种是参数输入;另一种是全局变量、数据文件的输入,即非参数输入。函数在使用输入之前,应进行必要的检查。

    6-12:函数名应准确描述函数的功能。

    6-13:使用动宾词组为执行某操作的函数命名。如果是OOP方法,可以只有动词(名词是对象本身)。

    6-14:避免使用无意义或含义不清的动词为函数命名。

    说明:避免用含义不清的动词如process、handle 等为函数命名,因为这些动词并没有说明要具体做什么。

    6-15:函数的返回值要清楚、明了,让使用者不容易忽视错误情况。

    说明:函数的每种出错返回值的意义要清晰、明了、准确,防止使用者误用、理解错误或忽视错误返回码。

    6-16:除非必要,最好不要把与函数返回值类型不同的变量,以编译系统默认的转换方式或强制的转换方式作为返回值返回。

    6-17:让函数在调用点显得易懂、容易理解。

    6-18:在调用函数填写参数时,应尽量减少没有必要的默认数据类型转换或强制数据类型转换。

    说明:因为数据类型转换或多或少存在危险。

    6-19:避免函数中不必要语句,防止程序中的垃圾代码。

    说明:程序中的垃圾代码不仅占用额外的空间,而且还常常影响程序的功能与性能,很可能给程序的测试、维护等造成不必要的麻烦。

    6-20:防止把没有关联的语句放到一个函数中。

    说明:防止函数或过程内出现随机内聚。随机内聚是指将没有关联或关联很弱的语句放到同一个函数或过程中。随机内聚给函数或过程的维护、测试及以后的升级等造成了不便,同时也使函数或过程的功能不明确。使用随机内聚函数,常常容易出现在一种应用场合需要改进此函数,而另一种应用场合又不允许这种改进,从而陷入困境。在编程时,经常遇到在不同函数中使用相同的代码,许多开发人员都愿把这些代码提出来,并构成一个新函数。若这些代码关联较大并且是完成一个功能的,那么这种构造是合理的,否则这种构造将产生随机内聚的函数。

    6-21:如果多段代码重复做同一件事情,那么在函数的划分上可能存在问题。

    说明:若此段代码各语句之间有实质性关联并且是完成同一件功能的,那么可考虑把此段代码构造成一个新的函数。

    6-22:功能不明确较小的函数,特别是仅有一个上级函数调用它时,应考虑把它合并到上级函数中,而不必单独存在。

    说明:模块中函数划分的过多,一般会使函数间的接口变得复杂。所以过小的函数,特别是扇入很低的或功能不明确的函数,不值得单独存在。

    6-23:设计高扇入、合理扇出(小于7)的函数。

    说明:扇出是指一个函数直接调用(控制)其它函数的数目,而扇入是指有多少上级函数调用它。扇出过大,表明函数过分复杂,需要控制和协调过多的下级函数;而扇出过小,如总是1,表明函数的调用层次可能过多,这样不利程序阅读和函数结构的分析,并且程序运行时会对系统资源如堆栈空间等造成压力。函数较合理的扇出(调度函数除外)通常是3-5。扇出太大,一般是由于缺乏中间层次,可适当增加中间层次的函数。扇出太小,可把下级函数进一步分解多个函数,或合并到上级函数中。当然分解或合并函数时,不能改变要实现的功能,也不能违背函数间的独立性。

    扇入越大,表明使用此函数的上级函数越多,这样的函数使用效率高,但不能违背函数间的独立性而单纯地追求高扇入。公共模块中的函数及底层函数应该有较高的扇入。较良好的软件结构通常是顶层函数的扇出较高,中层函数的扇出较少,而底层函数则扇入到公共模块中。

    6-24:减少函数本身或函数间的递归调用。

    说明:递归调用特别是函数间的递归调用(如A->B->C->A),影响程序的可理解性;递归调用一般都占用较多的系统资源(如栈空间);递归调用对程序的测试有一定影响。故除非为某些算法或功能的实现方便,应减少没必要的递归调用。

    6-26:改进模块中函数的结构,降低函数间的耦合度,并提高函数的独立性以及代码可读性、效率和可维护性。优化函数结构时,要遵守以下原则:

    (1)不能影响模块功能的实现。

    (2)仔细考查模块或函数出错处理及模块的性能要求并进行完善。

    (3)通过分解或合并函数来改进软件结构。

    (4)考查函数的规模,过大的要进行分解。

    (5)降低函数间接口的复杂度。

    (6)不同层次的函数调用要有较合理的扇入、扇出。

    (7)函数功能应可预测。

    (8)提高函数内聚。(单一功能的函数内聚最高)

    说明:对初步划分后的函数结构应进行改进、优化,使之更为合理。

    6-27:在多任务操作系统的环境下编程,要注意函数可重入性的构造。

    说明:可重入性是指函数可以被多个任务进程调用。在多任务操作系统中,函数是否具有可重入性是非常重要的,因为这是多个进程可以共用此函数的必要条件。另外,编译器是否提供可重入函数库,与它所服务的操作系统有关,只有操作系统是多任务时,编译器才有可能提供可重入函数库。如DOS 下BC和MSC 等就不具备可重入函数库,因为DOS 是单用户单任务操作系统。

    6-28:避免使用BOOL参数。

    说明:原因有二,其一是BOOL参数值无意义,TURE/FALSE的含义是非常模糊的,在调用时很难知道该参数到底传达的是什么意思;其二是BOOL参数值不利于扩充。还有NULL也是一个无意义的单词。

    6-29:对于提供了返回值的函数,在引用时最好使用其返回值。

    6-30:当一个过程(函数)中对较长变量(一般是结构的成员)有较多引用时,可以用一个意义相当的宏代替。

    说明:这样可以增加编程效率和程序的可读性。

    7 程序效率

    7-1:编程时要经常注意代码的效率。

    说明:代码效率分为全局效率、局部效率、时间效率及空间效率。全局效率是站在整个系统的角度上的系统效率;局部效率是站在模块或函数角度上的效率;时间效率是程序处理输入任务所需的时间长短;空间效率是程序所需内存空间,如机器代码空间大小、数据空间大小、栈空间大小等。

    7-2:在保证软件系统的正确性、稳定性、可读性及可测性的前提下,提高代码效率。

    说明:不能一味地追求代码效率,而对软件的正确性、稳定性、可读性及可测性造成影响。

    7-3:局部效率应为全局效率服务,不能因为提高局部效率而对全局效率造成影响。

    7-4:通过对系统数据结构的划分与组织的改进,以及对程序算法的优化来提高空间效率。

    说明:这种方式是解决软件空间效率的根本办法。

    7-5:循环体内工作量最小化。

    说明:应仔细考虑循环体内的语句是否可以放在循环体之外,使循环体内工作量最小,从而提高程序的时间效率。

    7-6:仔细分析有关算法,并进行优化。仔细考查、分析系统及模块处理输入(如事务、消息等)的方式,并加以改进。

    7-7:对模块中函数的划分及组织方式进行分析、优化,改进模块中函数的组织结构,提高程序效率。

    说明:软件系统的效率主要与算法、处理任务方式、系统功能及函数结构有很大关系,仅在代码上下功夫一般不能解决根本问题。

    7-8:编程时,要随时留心代码效率;优化代码时,要考虑周全。

    7-9:不应花过多的时间拼命地提高调用不很频繁的函数代码效率。

    说明:对代码优化可提高效率,但若考虑不周很有可能引起严重后果。

    7-10:要仔细地构造或直接用汇编编写调用频繁或性能要求极高的函数。

    说明:只有对编译系统产生机器码的方式以及硬件系统较为熟悉时,才可使用汇编嵌入方式。嵌入汇编可提高时间及空间效率,但也存在一定风险。

    7-11:在保证程序质量的前提下,通过压缩代码量、去掉不必要代码以及减少不必要的局部和全局变量,来提高空间效率。

    说明:这种方式对提高空间效率可起到一定作用,但往往不能解决根本问题。

    7-12:在多重循环中,应将最忙的循环放在最内层。

    说明:减少CPU切入循环层的次数。

    7-13:尽量减少循环嵌套层次。

    7-14:避免循环体内含判断语句,应将循环语句置于判断语句的代码块之中。

    说明:目的是减少判断次数。循环体中的判断语句是否可以移到循环体外,要视程序的具体情况而言,一般情况,与循环变量无关的判断语句可以移到循环体外,而有关的则不可以。

    7-15:尽量用乘法或其它方法代替除法,特别是浮点运算中的除法。

    说明:浮点运算除法要占用较多CPU资源。

    7-16:不要一味追求紧凑的代码。

    说明:因为紧凑的代码并不代表高效的机器码。

    8.质量保证

    8-1:在软件设计过程中构筑软件质量。

    8-2:代码质量保证优先原则

    (1)正确性,指程序要实现设计要求的功能。

    (2)稳定性、安全性,指程序稳定、可靠、安全。

    (3)可测试性,指程序要具有良好的可测试性。

    (4)规范/可读性,指程序书写风格、命名规则等要符合规范。

    (5)全局效率,指软件系统的整体效率。

    (6)局部效率,指某个模块/子模块/函数的本身效率。

    (7)个人表达方式/个人方便性,指个人编程习惯。

    8-3:只引用属于自己的存贮空间。

    说明:若模块封装的较好,那么一般不会发生非法引用他人的空间。

    8-4:防止引用已经释放的内存空间。

    说明:在实际编程过程中,稍不留心就会出现在一个模块中释放了某个内存块(如C语言指针),而另一模块在随后的某个时刻又使用了它。要防止这种情况发生。

    8-5:过程/函数中分配的内存,在过程/函数退出之前要释放。

    8-6:过程/函数中申请的(为打开文件而使用的)文件句柄,在过程/函数退出之前要关闭。

    说明:分配的内存不释放以及文件句柄不关闭,是较常见的错误,而且稍不注意就有可能发生。这类错误往往会引起很严重后果,且难以定位。

    8-7:防止内存操作越界。

    说明:内存操作主要是指对数组、指针、内存地址等的操作。内存操作越界是软件系统主要错误之一,后果往往非常严重,所以当我们进行这些操作时一定要仔细小心。

    8-8:认真处理程序所能遇到的各种出错情况。

    8-9:系统运行之初,要初始化有关变量及运行环境,防止未经初始化的变量被引用。

    8-10:系统运行之初,要对加载到系统中的数据进行一致性检查。

    说明:使用不一致的数据,容易使系统进入混乱状态和不可知状态。

    8-11:严禁随意更改其它模块或系统的有关设置和配置。

    说明:编程时,不能随心所欲地更改不属于自己模块的有关设置如常量、数组的大小等。

    8-12:不能随意改变与其它模块的接口。

    8-13:充分了解系统的接口之后,再使用系统提供的功能。

    8-14:编程时,要防止差1错误。

    说明:此类错误一般是由于把“<=”误写成“<”或“>=”误写成“>”等造成的,由此引起的后果,很多情况下是很严重的,所以编程时,一定要在这些地方小心。当编完程序后,应对这些操作符进行彻底检查。

    8-15:要时刻注意易混淆的操作符。当编完程序后,应从头至尾检查一遍这些操作符,以防止拼写错误。

    说明:形式相近的操作符最容易引起误用,如C/C++中的“=”与“==”、“|”与“||”、“&”与“&&”等,若拼写错了,编译器不一定能够检查出来。

    8-16:有可能的话,if语句尽量加上else分支,对没有else分支的语句要小心对待;switch语句必须有default分支。

    8-17:Unix下,多线程的中的子线程退出必需采用主动退出方式,即子线程应return出口。

    8-18:不要滥用goto语句。

    说明:goto语句会破坏程序的结构性,所以除非确实需要,最好不使用goto语句。

    8-19:精心地构造、划分子模块,并按“接口”部分及“内核”部分合理地组织子模块,以提高“内核”部分的可移植性和可重用性。

    说明:对不同产品中的某个功能相同的模块,若能做到其内核部分完全或基本一致,那么无论对产品的测试、维护,还是对以后产品的升级都会有很大帮助。

    8-20:精心构造算法,并对其性能、效率进行测试。

    8-21:对较关键的算法最好使用其它算法来确认。

    8-22:时刻注意表达式是否会上溢、下溢。

    8-23:使用变量时要注意其边界值的情况。

    8-24:留心程序机器码大小(如指令空间大小、数据空间大小、堆栈空间大小等)是否超出系统有关限制。

    8-25:为用户提供良好的接口界面,使用户能较充分地了解系统内部运行状态及有关系统出错情况。

    8-26:系统应具有一定的容错能力,对一些错误事件(如用户误操作等)能进行自动补救。

    8-27:对一些具有危险性的操作代码(如写硬盘、删数据等)要仔细考虑,防止对数据、硬件等的安全构成危害,以提高系统的安全性。

    8-28:使用第三方提供的软件开发工具包或控件时,要注意以下几点:

    (1)充分了解应用接口、使用环境及使用时注意事项。

    (2)不能过分相信其正确性。

    (3)除非必要,不要使用不熟悉的第三方工具包与控件。

    说明:使用工具包与控件,可加快程序开发速度,节省时间,但使用之前一定对它有较充分的了解,同时第三方工具包与控件也有可能存在问题。

    8-29:资源文件(多语言版本支持),如果资源是对语言敏感的,应让该资源与源代码文件脱离,具体方法有下面几种:使用单独的资源文件、DLL 文件或其它单独的描述文件(如数据库格式)

    1.9 代码编辑、编译、审查

    9-1:打开编译器的所有告警开关对程序进行编译。

    9-2:在产品软件(项目组)中,要统一编译开关选项。

    9-3:通过代码走读及审查方式对代码进行检查。

    说明:代码走读主要是对程序的编程风格如注释、命名等以及编程时易出错的内容进行检查,可由开发人员自己或开发人员交叉的方式进行;代码审查主要是对程序实现的功能及程序的稳定性、安全性、可靠性等进行检查及评审,可通过自审、交叉审核或指定部门抽查等方式进行。

    9-4:测试部测试产品之前,应对代码进行抽查及评审。目组最好采用相同的智能语言编辑器,如Muiti Editor,Visual Editor 等,并设计、使用一套缩进宏及注释

    9-5:编写代码时要注意随时保存,并定期备份,防止由于断电、硬盘损坏等原因造成代码丢失。

    9-6:同产品软件(项目组)内,最好使用相同的编辑器,并使用相同的设置选项。

    说明:同一项宏等,将缩进等问题交由编辑器处理。

    9-7:合理地设计软件系统目录,方便开发人员使用。

    说明:方便、合理的软件系统目录,可提高工作效率。目录构造的原则是方便有关源程序的存储、查询、编译、链接等工作,同时目录中还应具有工作目录----所有的编译、链接等工作应在此目录中进行,工具目录----有关文件编辑器、文件查找等工具可存放在此目录中。

    9-8:某些语句经编译后产生告警,但如果你认为它是正确的,那么应通过某种手段去掉告警信息。

    说明:在BorlandC/C++中,可用“#pragma warn”来关掉或打开某些告警。

    9-9:使用代码检查工具(如C 语言用PC-Lint)对源程序检查。

    10 代码测试、维护

    10-1:单元测试要求至少达到语句覆盖。

    10-2:单元测试开始要跟踪每一条语句,并观察数据流及变量的变化。

    10-3:清理、整理或优化后的代码要经过审查及测试。

    10-4:代码版本升级要经过严格测试。

    10-5:使用工具软件对代码版本进行维护。

    10-6:正式版本上软件的任何修改都应有详细的文档记录。

    10-7:发现错误立即修改,并且要记录下来。

    10-8:关键的代码在汇编级跟踪。

    10-9:仔细设计并分析测试用例,使测试用例覆盖尽可能多的情况,以提高测试用例的效率。

    10-11:尽可能模拟出程序的各种出错情况,对出错处理代码进行充分的测试。

    10-12:仔细测试代码处理数据、变量的边界情况。

    10-13:保留测试信息,以便分析、总结经验及进行更充分的测试。

    10-14:不应通过“试”来解决问题,应寻找问题的根本原因。

    10-15:对自动消失的错误进行分析,搞清楚错误是如何消失的。

    10-16:修改错误不仅要治表,更要治本。

    10-17:测试时应设法使很少发生的事件经常发生。

    10-18:明确模块或函数处理哪些事件,并使它们经常发生。

    10-19:坚持在编码阶段就对代码进行彻底的单元测试,不要等以后的测试工作来发现问题。

    10-20:去除代码运行的随机性(如去掉无用的数据、代码及尽可能防止并注意函数中的“内部寄存器”等),让函数运行的结果可预测,并使出现的错误可再现。

    11 宏

    11-1:用宏定义表达式时,要使用完备的括号。

    11-2:将宏所定义的多条表达式放在大括号中。

    展开全文
  • 华为的代码规范C语言版,适合嵌入式行业的工程师
  • 平时用到的-----------嵌入式C语言易错点以及代码规范
  • C语言代码规范.pdf

    2021-09-30 16:38:51
    C语言代码规范.pdf
  • 在公司已有编码规范的指导下,审慎地编排代码以使代码尽可能清晰,是一项非常重要的技能。 如果重构/ / 修改其他风格的代码时,比较明智的做法是根据 现有 代码 的 现有风格继续编写代码,或者使用格式转换工具进行...
  • C语言代码规范[汇编].pdf
  • C语言代码规范_纯图版.pdf
  • c语言代码规范

    2014-05-24 14:27:09
    c语言 老师那拿到的,只想下几个资源罢了
  • 嵌入式C语言代码规范

    万次阅读 2019-12-17 16:26:27
    C语言代码规范 参考安富莱C语言编码规范 1.文件与目录 1、文件及目录的命名规定可用的字符集是[A-Z;a-z;0-9;._-]。 2、源文件名后缀用小写字母 .c 和.h。 3、文件的命名要准确清晰地表达其内容,同时文件名应该...

    C语言代码规范

    参考安富莱C语言编码规范

    1.文件与目录

    1、文件及目录的命名规定可用的字符集是[A-Z;a-z;0-9;._-]。

    2、源文件名后缀用小写字母 .c 和.h。

    3、文件的命名要准确清晰地表达其内容,同时文件名应该精练,防止文件名过长而造成使用不便。在文件名中可以适当地使用缩写。
    以下提供两种命名方式以供参考:

    (1)各程序模块的文件命名开头 2 个消协字母代表本模块的功能:
    如:主控程序为 mpMain.c,mpDisp.c …
    (2)不写模块功能标识:
    如:主控程序为 Main.c,Disp.c …
    

    4、一个软件包或一个逻辑组件的所有头文件和源文件建议放在一个单独的目录下,这样有利于查找并使用相关的文件,有利于简化一些编译工具的设置。

    5、对于整个项目需要的公共头文件,应存放在一个单独的目录下(例如:myProject/include)下,可避免其他编写人引用时目录太过分散的问题。

    6、对于源码文件中的段落安排,我们建议按如下的顺序排列:

    a. 文件头注释
    b. 防止重复引用头文件的设置
    c. #include 部分
    d. #define 部分
    e. enum 常量声明
    f. 类型声明和定义,包括 struct、union、typedef 等
    g. 全局变量声明
    h. 文件级变量声明
    i. 全局或文件级函数声明
    j. 函数实现。按函数声明的顺序排列
    k. 文件尾注释
    

    7、在引用头文件时,使用 <> 来引用预定义或者特定目录的头文件,使用 “” 来引用当前目录或者路径相对于当前目录的头文件。

    1 #include <file.h>
    执行这条指令时,它会在系统目录中去查找 file.h 文件。在此条码命令中,不会去当前路径和附加路径中查找文件。
    
    2 #include "file.h"
    执行这条指令时,它首先会搜索附加路径,如果没有则会搜索系统路径,如果还没有则会去搜索当前路径。
    

    8、为了防止头文件被重复引用,应当用 ifndef/define/endif 结构产生预处理块。

    #ifndef __DISP_H /* 文件名前名加两个下划线“__”,后面加 “_H”
    #define __DISP_H
    ...
    ...
    #endif /* disp.h*/
    

    9、头文件中只存放“声明”而不存放“定义”,通过这种方式可以避免重复定义。如果其它模块需要引用全局变量 g_temp, 只需要在文件开头包含 disp.h

    #ifndef __DISP_H /* 文件名前名加两个下划线“__”,后面加 “_H”
    #define __DISP_H
    /** 全局变量声明 */
    extern uint32_t g_temp;
    #endif /* disp.h*/
    
    #include "disp.h"
    /** 全局变量定义 */
    uint32_t g_temp = 0;
    

    2.排版

    1、程序块要采用缩进风格编写,缩进的空格数为 4 个。尽量用空格,在不同环境下Tab键代表的空格可能不同,导致排版混乱。
    在这里插入图片描述
    在这里插入图片描述

    2、相对独立的程序块之间、变量说明之后必须加空行增加可读性、变量最好在使用时在定义。

    3、当一行太长时,可以按操作符处划分新行,划分出的新行要进行适当的缩进,使排版整齐,语句可读。

    ANO_DT_send_int16((short)(sin(data1/180.0f * PI) * 100),
                      (short)(sin(data2/180.0f * PI) * 100),
                      (short)(sin(data3/180.0f * PI) * 100),
                      (short)(sin(data4/180.0f * PI) * 100), 
                      (short)(sin(data5/180.0f * PI) * 100), 
                       0, 
                       0,
                       0);  
    

    4、不允许把多个短语句写在一行中,即一行只写一条语句。

    5、程序块的分界符(如大括号‘{’和‘}’ )应各独占一行并且位于同一列,同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义以及 if、for、do、while、switch、case 语句中的程序都要采用如上的缩进方式。对于与规则不一致的现存代码,应优先保证同一模块中的风格一致性。

    for (...) { <---- 不规范的写法
    
    ... /* program code */
    
    }
    
    for (...)
    
    { <---- 规范的写法
    
    ... /* program code */
    
    }
    
    if (...)
    
    { <---- 不规范的写法
    
    ... /* program code */
    
    }
    
    if (...)
    
    { <---- 规范的写法
    
    ... /* program code */
    
    }
    

    6、在两个以上的关键字、变量、常量进行对等操作时,它们之间的操作符之前、之后或者前后要加空格;进行非对等操作时,如果是关系密切的立即操作符(如->),后不应加空格。
    说明:采用这种松散方式编写代码的目的是使代码更加清晰。
    由于留空格所产生的清晰性是相对的,所以,在已经非常清晰的语句中没有必要再留空格,如果语句已足够清晰则括号内侧(即左括号后面和右括号前面)不需要加空格,多重括号间不必加空格,因为在 C语言中括号已经是最清晰的标志了。
    在长语句中,如果需要加的空格非常多,那么应该保持整体清晰,而在局部不加空格。给操作符留空格时不要连续留两个以上空格。

    示例:
    (1)逗号、分号只在后面加空格。

    int_32 a, b, c;
    

    (2)比较操作符,赋值操作符"="、 “+=”,算术操作符"+"、"%",逻辑操作符"&&"、"&",位域操作符"<<"、"^"等双目操作符的前后加空格。

    if (current_time >= MAX_TIME_VALUE)
    
    a = b + c;
    
    a *= 2;
    
    a = b ^ 2;
    

    (3)"!"、"~"、"++"、"–"、"&"(地址运算符)等单目操作符前后不加空格。

    *p = 'a'; /* 内容操作"*"与内容之间 */
    
    flag = !isEmpty; /* 非操作"!"与内容之间 */
    
    p = &mem; /* 地址操作"&" 与内容之间 */
    
    i++; /* "++","--"与内容之间 */
    

    (4)"->"、"."前后不加空格。

    p->id = pid; /* "->"指针前后不加空格 */
    

    3.注释

    1、一般情况下,源程序有效注释量必须在 20%以上。
    说明:注释的原则是有助于对程序的阅读理解,在该加的地方都加,注释不宜太多也不能太少,注释语言必须准确、易懂、简洁。

    2、在文件的开始部分,应该给出关于文件版权、内容简介、修改历史等项目的说明。
    具体的格式请参见如下的说明。在创建代码和每次更新代码时,都必须在文件的历史记录中标注版本号、日期、作者、更改说明等项目。

    /*!
      * @file     LQ_ADC.c
      *
      * @brief    ADC驱动文件
      *
      * @company  北京龙邱智能科技
      *
      * @author   LQ-005
      *
      * @note     无
      *
      * @version  V1.1  2019/12/06 优化注释 Doxygen
      *
      * @par URL  http://shop36265907.taobao.com
      *           http://www.lqist.cn
      *
      * @date     2019/10/18 星期五
      */ 
    

    3、对于函数,在函数实现之前,应该给出和函数的实现相关的足够而精练的注释信息。内容包括本函数功能介绍,调用的变量、常量说明,形参说明,特别是全局、全程或静态变量(慎用静态变量),要求对其初值,调用后的预期值作详细的阐述。具体的书写格式和包含的各项内容请参见如下的例子。

    /*!
     * @brief    ADC通道初始化
     *
     * @param    channel   :  ADC通道 LQ_ADC.h中的一个枚举体  
     * @param    bit       :  ADC通道精度 LQ_ADC.h中的一个枚举体  
     *
     * @return   无
     *
     * @note     读取ADC之前一定要调用该函数对ADC通道进行初始化
     *
     * @see      ADC_InitConfig(ADC0CH0_P0_10, ADC_12bit);  //初始化ADC通道0 P0_10
     *
     * @date     2019/10/21 星期一
     */
    void ADC_InitConfig(ADCn_Ch channel, ADC_nbit bit)
    

    对于宏定

    /*! CTIMER 最大占空比 可自行修改 */
    #define  CMTER_PWM_MAX    10000
    

    结构体、枚举体注释

    /** 
      * @brief CTIMER模块 脉冲计数通道
      * @note  CTIMER 模块 脉冲捕获通道 
      * @note  CTIMER 模块的输入管脚并不是直接CTIMER连接的  而是通过INPUTMUX模块连接的
      * @note  CTIMER计数器 ---  INPUTMUX输入多路复用模块17路通道  ----  芯片外部管脚
      * @note  简单说 就是CTIMER的捕获通道每个都可以与 INPUTMUX模块的17路通道相链接
      * @note  INPUTMUX模块的17路通道相链接的管脚如下
      */ 
    typedef enum
    {
        CTInput0_P0_1  = 0x0000 + 1,  CTInput0_P0_13 = 0x0000 + 2,     /*!< INPUTMUX—CTIMER 输入通道0管脚  */  
        CTInput1_P0_14 = 0x0100 + 1,  CTInput1_P0_2  = 0x0100 + 2,     /*!< INPUTMUX—CTIMER 输入通道1管脚  */  
        CTInput2_P1_0  = 0x0200 + 1,  CTInput2_P1_28 = 0x0200 + 2,     /*!< INPUTMUX—CTIMER 输入通道2管脚  */  
        CTInput3_P1_1  = 0x0300 + 1,  CTInput3_P1_26 = 0x0300 + 2,     /*!< INPUTMUX—CTIMER 输入通道3管脚  */  
        CTInput4_P1_9  = 0x0400 + 1,  CTInput4_P0_16 = 0x0400 + 2,     /*!< INPUTMUX—CTIMER 输入通道4管脚  */  
        CTInput5_P1_11 = 0x0500 + 1,                                   /*!< INPUTMUX—CTIMER 输入通道5管脚  */  
        CTInput6_P1_13 = 0x0600 + 1,                                   /*!< INPUTMUX—CTIMER 输入通道6管脚  */  
        CTInput7_P1_15 = 0x0700 + 1,                                   /*!< INPUTMUX—CTIMER 输入通道7管脚  */  
        CTInput8_P0_24 = 0x0800 + 1,                                   /*!< INPUTMUX—CTIMER 输入通道8管脚  */  
        CTInput9_P0_25 = 0x0900 + 1,                                   /*!< INPUTMUX—CTIMER 输入通道9管脚  */  
        CTInput10_P0_10= 0x0A00 + 1,                                   /*!< INPUTMUX—CTIMER 输入通道10管脚  */  
        CTInput11_P0_28= 0x0B00 + 1,                                   /*!< INPUTMUX—CTIMER 输入通道11管脚  */  
        CTInput12_P0_4 = 0x0C00 + 1,                                   /*!< INPUTMUX—CTIMER 输入通道12管脚  */  
        CTInput13_P0_6 = 0x0D00 + 1,                                   /*!< INPUTMUX—CTIMER 输入通道13管脚  */  
        CTInput14_P1_20= 0x0E00 + 1,  CTInput14_P0_26= 0x0E00 + 2,     /*!< INPUTMUX—CTIMER 输入通道14管脚  */  
        CTInput15_P0_20= 0x0F00 + 1,  CTInput15_P0_22= 0x0F00 + 2,     /*!< INPUTMUX—CTIMER 输入通道15管脚  */  
        CTInput16_P0_15= 0x1000 + 1,                                   /*!< INPUTMUX—CTIMER 输入通道16管脚  */  
        
    } CTIMER_InputChannel_t;
    

    全局变量

    /** DMA link传输描述符 */
    extern dma_descriptor_t s_dma_descriptor_table0[];
    

    注释应严格按以上格式进行注释,方便日后使用Doxygen生成帮助API文档
    在这里插入图片描述

    4、边写代码边注释,修改代码同时修改相应的注释,以保证注释与代码的一致性。不再有用的注释要删除。

    5、注释的内容要清楚、明了,含义准确,防止注释二义性。
    说明:错误的注释不但无益反而有害。注释主要阐述代码做了什么(What),或者如果有必要的话,阐述为什么要这么做(Why),注释并不是用来阐述它究竟是如何实现算法(How)的。

    6、普通注释格式尽量统一,建议使用“/* …… */”注释在代码上方, C++注释“//”并不被所有 C 编译器支持。

    7、注释应考虑程序易读及外观排版的因素,使用的语言若是中、英兼有的,建议多使用中文,除非能非常流利准确的用英文表达。

    8、标识符的命名要清晰、明了,有明确含义,同时使用完整的单词或大家基本可以理解的缩写,避免使人产生误解。

    9、命名中若使用特殊约定或缩写,则要有注释说明。

    10、自己特有的命名风格,要自始至终保持一致,不可来回变化。

    11、 对于变量命名,禁止取单个字符(如 i、j、k…),建议除了要有具体含义外,还能表明其变量类型、数据类型等,但 i、j、k 作局部循环变量是允许的。

    12、 除了编译开关/头文件等特殊应用,应避免使用_EXAMPLE_TEST_之类以下划线开始和结尾的定义。

    13、除非必要,不要用数字或较奇怪的字符来定义标识符。

    4.可读性

    1、注意运算符的优先级,并用括号明确表达式的操作顺序,避免使用默认优先级。

    word = (high << 8) | low;
    if ((a | b) && (a & c))
    if ((a | b) < (c & d))
    

    2、避免使用不易理解的数字,用有意义的标识来替代。涉及物理状态或者含有物理意义的常量,不应直接使用数字,必须用有意义的枚举或宏来代替。

    if (Trunk[index].trunk_state == 0) <---- 不规范的写法,应使用有意义的标识
    {
    	Trunk[index].trunk_state = 1; <---- 不规范的写法,应使用有意义的标识
    ... /* program code */
    
    }
    
    enum trunk_state_e
    {
    	TRUNK_IDLE = 0,
    
    	TRUNK_BUSY = 1
    };
    
    if (Trunk[index].trunk_state == TRUNK_IDLE)
    {
    	Trunk[index].trunk_state = TRUNK_BUSY;
    ... /* program code */
    
    }
    

    3、不要使用难懂的技巧性很高的语句,除非证明改语句是性能瓶颈。

    4、为了方便书写及记忆,变量类型采用如下重定义:

    typedef unsigned char uint8_t;
    
    typedef unsigned short uint16_t;
    
    typedef unsigned long int uint32_t;
    
    typedef signed char int8_t;
    
    typedef signed short int16_t;
    
    typedef signed long int int32_t;
    
    #define __IO volatile
    

    5、对于一些常见类型的变量,应在其名字前标注表示其类型的前缀。前缀用小写字母表示。前缀的使用请参照下列表格中说明。
    在这里插入图片描述

    6、变量作用域的前缀
    为了清晰的标识变量的作用域,减少发生命名冲突,应该在变量类型前缀之前再加上表示变量作用域的前缀,并在变量类型前缀和变量作用域前缀之间用下划线‘-’隔开。
    具体的规则如下:
    (1)对于全局变量(global variable),在其名称前加“g”和变量类型符号前缀。

    /** 全局变量 */
    uint32_t g_ulParaWord;
    
    /** 全局变量 */
    uint8_t g_ucByte;
    

    (2)对于静态变量(static variable),在其名称前加“s”和变量类型符号前缀。

    /** 静态变量 */
    static uint32_t s_ulParaWord;
    
    /** 静态变量 */
    static uint8_t s_ucByte;
    

    (3)函数内部等局部变量前不加作用域前缀。

    (4)对于常量,当可能发生作用域和名字冲突问题时,以上几条规则对于常量同样适用。注意,虽然常量名的核心部分全部大写,但此时常量的前缀仍然用小写字母,以保持前缀的一致性。

    展开全文
  • 华为技术有限公司C语言编程规范,适合初学者以及求职者参考借鉴,提高自己的代码水平
  • 代码规范是一个程序员最基本的要求,所以从一开始学习编程的时候就应养成良好的习惯,符合代码规范的要求。下面具体说一下C语言的代码有哪些规范。一、命名规范1、匈牙利命名:基本原则:变量名=属性+类型 +对象...

    代码规范是一个程序员最基本的要求,所以从一开始学习编程的时候就应养成良好的习惯,符合代码规范的要求。下面具体说一下C语言的代码有哪些规范。

    一、命名规范

    1、匈牙利命名:基本原则:变量名=属性+类型 +对象,每一个对象的名称都要求有明确含义,可以取对象名字全称或名字的一部分。命名要基于容易记忆容易理解的原则。保证名字的连贯性是非常重要的。

    例子:

    属性部分:

    全局变量:g_

    常量: c_

    静态变量:s_

    类型部分:

    指针 p

    函数 fn

    无效 v

    句柄 h

    长整型 l

    布尔 b

    浮点型 f

    双字 dw

    字符串 s

    短整型 n

    双精度浮点 d

    计数 c(通常用 cnt)

    字符 ch(通常用 c)

    整型 i(通常用 n)

    字节 by

    字 w

    实型 r

    无符号 u

    描述部分:

    最大 Max

    最小 Min

    初始化 Init

    临时变量 T(或 Temp)

    源对象 Src

    目的对象 Dest

    例子:

    定义一个int类型局部变量:int nResult;

    定义一个int类型全局变量:int g_nResult;

    定义一个指针类型数组:char* pCResult[24];

    定义一个函数:fnAdd();

    ……

    2、驼峰式命名:第一个单词首字母小写,后面其他单词首字母大写(又称小驼峰式)。

    例子:

    定义一个int类型局部变量:int myAge;

    定义一个指针类型数组:char* myResult[24];

    定义一个函数:myAdd();

    ……

    3、帕斯卡命名:每个单词的第一个字母都大写(又称大驼峰式)。

    例子:

    定义一个int类型局部变量:int MyAge;

    定义一个指针类型数组:char* MyResult[24];

    定义一个函数:MyAdd();

    ……

    4、其他命名方式:比如下划线命名。

    例子:

    定义一个int类型局部变量:int My_Age;

    定义一个指针类型数组:char* My_Result[24];

    定义一个函数:My_Add();

    ……

    以上几种命名方式,读者朋友只需要使用一种就可以了,笔者这里推荐第一种匈牙利命名。

    二、代码编辑排列:

    1、变量的定义尽可能放在最开始处,功能相近的函数集中放在一起。

    2、声明变量时对齐变量名,并在定义时写上注释。

    3、函数间要使用空行分开,每个函数定义时写注释。

    4、某一段代码写上具体的注释,标注具体完成什么功能。

    5、函数或过程的开始、结构的定义及循环、判断等语句的代码都要采用缩进风格,case语句下的情况处理语句也要遵从缩进风格。

    6、程序块的分界符“{”与“}”应各占一行。

    7、工程项目中不起作用的文件、代码、变量等应删除。

    8、说明性文件(如头文件.h文件、.inc文件、.def文件等)头部应写上注释。

    9、程序要有作者信息、程序功能描述、版本信息、完成时间、修改日志等信息。

    10、建议将常用头文件全部放入stdafx.h中,而每个cpp开始处嵌入stdafx.h。避免不必要的错误。

    展开全文
  • C语言编码规范

    2022-07-14 17:39:12
    C语言编码
  • 华为C语言编程规范 高清PDF版 内容可复制
  • 华为C语言编程规范

    2018-10-23 17:31:45
    搜索了一下,发现论坛关于编程规范的内容非常少,在此分享一份华为的软件编程规范文档,有需要的拿去
  • C语言代码输入的规范

    2021-12-18 20:34:42
    代码规范代码规范有七大原则:分别表现在空行,空格,成对书写,缩进,对齐,代码行,注释七方面的规范上: 1)空行: 规则一:定义变量后面要空行 规则二:每个函数定义结束后都要空行 规则三:总之,...
  • 华为的C语言编程规范,本规范适用于公司内C语言编码
  • C语言代码规范(编程规范)

    千次阅读 多人点赞 2018-11-24 20:45:49
    C语言代码规范(编程规范) 什么叫规范?在C语言中不遵守编译器的规定,编译器在编译时就会报错,这个规定叫作规则。但是有一种规定,它是一种人为的、约定成俗的,即使不按照那种规定也不会出错,这种规定就叫作...
  • C语言代码规范(一)缩进与换行

    万次阅读 多人点赞 2018-08-20 12:14:47
    一、缩进的空格数为4个。... 不规范例子: for(i = 0; i &lt; student_num; i++); { if((score[i] &gt;= 0) &amp;&amp; (score[i]) &lt;= 100) total_score += score[i]; else prin...
  • 有关于C语言代码规范,函数,注释,循环,命名等
  • C语言编程规范X - GOOGLECODE第1章文件组织1.1文件命名1.文件名最长不得超过16字节(不包括扩展名);文件名和目录名只能使用小写字母、数字和下划线;2.文件名要遵照“模块名_功能名”的格式;1.2文件组织结构1.文件...
  • 对于刚学习c语言,不懂得c语言代码规范的人很有帮助

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 88,975
精华内容 35,590
关键字:

c语言代码规范