规范_C#编码
c标准是多少
c标准是多少自从1972年开发出来以后，C语言就一直是程序开发领域的一门重要的、流行的编程语言。
C语言在计算机科学中的贡献，不仅仅体现在其广泛的应用方面，更在于它建立了一套“C语言标准”，该标准是当今主流编程语言的基础。
那么，C标准又是多少？C标准，又叫C99标准、ANSI C标准或ISO C标准，是一套定义了C语言的技术文件规范。
它既包括了C语言的语法结构、内置数据结构，也包括C语言标准库以及一些编程技术。
C标准是C语言在程序开发中最重要的规范文件，它指导着C语言的编写和使用。
C标准的发展可以追溯到上世纪70年代初，1972年Brian Kernighan和Dennis Ritchie最初发布了C语言，当时它只有50多页，只包含有限的内容。
随着C语言的推广应用，从而进一步发展出C语言的标准。
1979年，第一个全面的C标准标准C出现了。
它代表着C语言的发展从半原始状态发展到一种强大的、可移植性的编程语言。
1989年，第二个C标准ANSI C标准出现了，它是继1978年的标准C之后的一个完善的版本，它包括比标准C更全面的内容，比如：函数重载、宏变形、数据类型更宽松的允许，还有可变参数列表等。
1999年，ANSI C标准得到了ISO的支持，并获得了ISO/IEC 9899-1999的标准认证，这就是今天所熟知的C99标准，是继1978年的标准C和1989年的ANSI C标准之后的又一个版本，它的具体内容大致和ANSI C标准一致，但也有一些小小的改动和改善，例如：在ISO C中引入了新的头文件<assert.h>，用于调试程序；定义参数获取环境变量等。
从发展史上来看，C标准的发展经历了三个阶段：标准C、ANSI C 和ISO C，其中ISO C是最新的标准，也是当今C语言编程中所采用的主流标准。
C标准是C语言发展的基础，它定义了C语言的语法结构、内置数据结构，以及C语言标准库等，是程序开发领域的重要规范文件。
C语言编程规范LDRA_MISRA_2004_Standard_v2[1].5.3_Web
![C语言编程规范LDRA_MISRA_2004_Standard_v2[1].5.3_Web](https://img.taocdn.com/s3/m/3b9c010cc4da50e2524de518964bcf84b9d52d8d.png)
C语⾔编程规范LDRA_MISRA_2004_Standard_v2[1].5.3_WebRules Definition Required AdvisoryTotal Implemented byLDRA 10317120Partially implemented byLDRA 617Not deemed to be statically analysable by atool12214NOTE: Of the 14 rules deemed 'Not statically analysable", a number of them are checkable to some extent with facilities available in the LDRA tool suite. This may be through the application of a related programming standard, or some other technique such as dynamic analysis.Total12120141This information has been compiled using version 7.7.1 of the LDRA tool suite and is correct as of July 2008.MISRA-C:2004 Coding StandardThe LDRA tool suite is developed and certified to BS EN ISO 9001:2000. This comparison has used the revised MISRA standard, MISRA-C:2004 "Guidelines for the use of the C language in critical systems" was published in October 2004.LDRA Ltd. reserves the right to change anyMISRA-C:2004Rule Required / Advisory LDRA Rule NumberMISRA Description LDRA Rule Description1.1Required293 S All code shall conform to ISO 9899:1990“Programming languages – C”, amended andcorrected by ISO/IEC 9899/COR1:1995, ISO/IEC 9899/AMD1:1995, and ISO/IEC 9899/COR2:1996.Non Ansi construct used.1.2Required412 SNo reliance shall be placed on undefined orunspecified behaviour.Undefined behaviour, \ before E-O-F.1.3Required N/AMultiple compilers and/or languages shall only be used if there is a common defined interfacestandard for object code to which thelanguages/compilers/assemblers conform.N/A1.4, 5.1Required 17 D The compiler/linker shall be checked to ensurethat 31 character significance and case sensitivityare supported for external identifiers.Identifier not unique within 31 characters. 1.5Advisory N/AFloating-point implementations should complywith a defined floating-point standard.N/A2.1Required 88 SAssembly language shall be encapsulated andisolated.Procedure is not pure assembler. 2.2Required 110 SSource code shall only use /* … */ stylecomments.Use of single line comment(s) //. 2.3Required 119 SThe character sequence /* shall not be usedwithin a comment.Nested comment found2.4Advisory 302 S Sections of code should not be “commented out”. Comment possibly contains code3.1Required N/AAll usage of implementation-defined behaviour shall be documented.N/A 3.2Required N/AThe character set and the correspondingencoding shall be documented.N/A3.3Advisory 373 S The implementation of integer division in thechosen compiler should be determined,documented and taken into account.Use of integer division 3.4Required69 SAll uses of the #pragma directive shall bedocumented and explained.#pragma used.LDRA Ltd. reserves the right to change anyMISRA-C:2004Rule Required / Advisory LDRA Rule Number MISRA Description LDRA Rule Description316 SBit field is not unsigned integral. 328 S Non bit field member in bitfield struct. 42 S Use of bit field in structure declaration. 226 S Bit field is not octal, hex or suffix u;3.6RequiredN/A All libraries used in production code shall be written to comply with the provisions of this document, and shall have been subject to appropriate validation.N/A4.1, 7.1Required 176 S Only those escape sequences that are defined inthe ISO C standard shall be used.Non standard escape sequence in source.4.2Required 81 S Trigraphs shall not be used.Use of trigraphs.384 S Identifier matches macro name in 31 chars.61 X Identifier match in *** chars. 5.2 - 5.5Required 131 S Identifiers in an inner scope shall not use the same name as an identifier in an outer scope,and therefore hide that identifier.Name reused in inner scope. 5.3, 5.6Required 112 STypedef name redeclared. 374 S Name conflict with typedef 16 X - 24 XIdentifier resuse: typedef vs …325 SInconsistent use of tag.4 X - 15 XIdentifier resuse: tag vs …18 D Identifier name reused 25 X - 39 XIdentifier reuse: ...91 S Name redeclared in another namespace (MR).40 X - 48 X Identifier reuse: ...5.6, 5.7Advisory383 S Identifier name matches macro name.Identifiers (internal and external) shall not rely on the significance of more than 31 characters.Required5.1Required 5.3 A tag name shall be a unique identifier.No identifier in one name space should have the same spelling as an identifier in another namespace, with the exception of structure and unionmember names.Advisory 5.63.5RequiredRequired 5.4Advisory 5.5If it is being relied upon, the implementationdefined behaviour and packing of bitfields shallbe documented.A typedef name shall be a unique identifier.No object or function identifier with static storage duration should be reused.LDRA Ltd. reserves the right to change anyMISRA-C:2004Required / Advisory LDRA Rule NumberMISRA Description LDRA Rule Description327 SReuse of struct member name. 49 X - 60 XIdentifier reuse: ...6.1Required 329 SThe plain char type shall be used only for thestorage and use of character values.Operation not appropriate to plain char. 93 S Value is not of appropriate type. 96 S Use of mixed mode arithmetic. 90 S Basic type declaration used. 495 S Typedef has no size indication6.4Required 73 SBit fields shall only be defined to be of typeunsigned int or signed int.Bit field not signed or unsigned int.6.5Required 72 S Bit fields of type signed int shall be at least 2 bitslong.Signed bit field less than 2 bits wide.7.1Required83 S Octal constants (other than zero) and octalescape sequences shall not be used.Octal number found.24 DProcedure definition has no associated prototype 8.2Required326 SWhenever an object or function is declared ordefined, its type shall be explicitly stated.Declaration is missing type.102 SFunction and prototype return inconsistent 103 SFunction and prototype param inconsistent 62 XFunction prototype/defn return type mismatch.63 XFunction prototype/defn parameter type mismatch.1 X Declaration types do not match across a system.360 S Incompatible type8.3RequiredFunction call with no prior declaration 496 S8.1Required8.4Required6.2, 12.1, 12.6RequiredAdvisory 6.35.7Advisory Functions shall have prototype declarations and the prototype shall be visible at both the function definitionIf objects or functions are declared more than once their types shall be compatible.Signed and unsigned char type shall be used only for the storage and use of numeric values.Typedefs that indicate size and signedness should be used in place of the basic types.No identifier name should be reused.For each function parameter the type given in the declaration and definition shall be identical, and the return types shall also be identical.LDRA Ltd. reserves the right to change anyMISRA-C:2004RuleRequired / Advisory LDRA Rule NumberMISRA Description LDRA Rule Description286 S Functions defined in header file. 287 SVariable definitions in header file. 8.6Required 296 S Functions shall be declared at file scope.Function declared at block scope. 8.7Required 25 DObjects shall be defined at block scope if theyare only accessed from within a single function.Scope of variable could be reduced26 D Variable should be defined once in only one file 60 DExternal object should be declared only once.172 S Variable declared multiply. 33 DNo real declaration for external variable.27 D Variable should be declared static61 D Procedure should be declared static 461 SIdentifier with ambiguous linkage.27 D Variable should be declared static 61 DProcedure should be declared static 8.12Required 127 S When an array is declared with external linkage,its size shall be stated explicitly or defined implicitly by initialisation.Array has no bounds specified.9.1Required 5 D All automatic variables shall have been assigneda value before being used.Procedure contains UR data flow anomalies.9.2Required105 S Braces shall be used to indicate and match thestructure in the non-zero initialisation of arrays and structures.Struct field initialisation brace fault.The static storage class specifier shall be used indefinitions and declarations of objects andfunctions that have internal linkage.RequiredAn external object or function shall be declared inone and only one file.Required 8.88.5Required There shall be no definitions of objects orfunctions in a header file.An identifier with external linkage shall haveexactly one external definition.Required 8.98.108.11RequiredAll declarations and definitions of objects or functions at file scope shall have internal linkage unless external linkage is required. LDRA Ltd. reserves the right to change anyMISRA-C:2004Rule Required / Advisory LDRA Rule NumberMISRA Description LDRA Rule Description9.3Required85 S In an enumerator list, the “=” construct shall notbe used to explicitly initialise members other than the first, unless all items are explicitly initialised.Incomplete initialisation of enumerator.93 S Value is not of appropriate type. 96 SUse of mixed mode arithmetic. 433 SType conversion without cast.(a) 434 S Signed/unsigned conversion without cast.(a) 435 S Float/integer conversion without cast.(a) 446 S Narrower int conversion without cast.(a) 488 SValue outside range of underlying type.(b) 452 SNo cast for widening complex int expression.(c) 458 SImplicit conversion: actual to formal param.(c) 491 S No cast for widening int parameter.(d) 101 S Function return type inconsistent.(d) 457 SImplicit int widening for function return. 93 S Value is not of appropriate type. 96 S Use of mixed mode arithmetic. 433 S Type conversion without cast.(a) 435 S Float/integer conversion without cast. (a) 445 S Narrower float conversion without cast.(b) 451 SNo cast for widening complex float expression.(c) 458 SImplicit conversion: actual to formal param.(c) 490 S No cast for widening float parameter.(d) 101 S Function return type inconsistent.(d) 456 S Implicit float widening for function return.Required10.2The value of an expression of floating type shall not be implicitly converted to a different type if:a) it is not a conversion to a wider floating type, orb) the expression is complex, or c) the expression is a function argument, or d) the expression is a return expression10.1RequiredThe value of an expression of integer type shallnot be implicitly converted to a differentunderlying type if:a) it is not a conversion to a wider integer type of the same signedness, orb) the expression is complex, or c) the expression is not constant and is a function argument, ord) the expression is not constant and is a returnexpression LDRA Ltd. reserves the right to change anyMISRA-C:2004Rule Required / AdvisoryLDRA RuleNumberMISRA DescriptionLDRA Rule Description93 S Value is not of appropriate type. 433 S Type conversion without cast.332 S Widening cast on complex integer expression. 442 SSigned integral type cast to unsigned.443 S Unsigned integral type cast to signed.444 SIntegral type cast to non-integral.93 S Value is not of appropriate type. 433 SType conversion without cast.333 S Widening cast on complex float expression. 441 SFloat cast to non-float.10.5Required334 SIf the bitwise operators ~ and << are applied to an operand of underlying type unsigned char orunsigned short, the result shall be immediately cast to the underlying type of the operand. No cast when ~ or << applied to small types.10.6Required 331 SA “U” suffix shall be applied to all constants ofunsigned type.Literal value requires a U suffix. 11.1Required94 S & 95 S Conversions shall not be performed between apointer to a function and any type other than anintegral type.Conversions shall not be performed between a pointer to a function and any type other than an integral type.11.2Required94 SConversions shall not be performed between a pointer to object and any type other than anintegral type, another pointer to object type or a pointer to void.Casting operation on a pointer.439 SCast from pointer to integral type.440 SCast from integral type to pointer.11.4Advisory95 S A cast should not be performed between apointer to object type and a different pointer toobject type.Casting operation to a pointer.11.3AdvisoryA cast should not be performed between a pointer type and an integral type.10.4RequiredThe value of a complex expression of integer type may only be cast to a type that is narrower and of the same signedness as the underlyingtype of the expression.Required10.3The value of a complex expression of floatingtype may only be cast to a narrower floating type.LDRA Ltd. reserves the right to change any MISRA-C:2004RuleRequired / Advisory LDRA Rule Number MISRA Description LDRA Rule Description203 SCast on a constant value.344 S Cast on volatile value. 96 SSee 6.2 above361 SExpression needs brackets.9 SAssignment operation in expression. 134 SVolatile variable in complex expression. 12.2, 12.3Required 35 D Expression has side effects.12.2, 12.4Required 1 Q Call has execution order dependant side effects.12.2, 12.13 Required 30 S Deprecated usage of ++ or -- operators found.12.3Required54 SThe sizeof operator shall not be used on expressions that contain side effects.Sizeof operator with side effects.406 S Use of ++ or -- on RHS of && or || operator. 408 SVolatile variable accessed on RHS of && or ||.12.5Required49 SThe operands of a logical && or || shall beprimary-expressions. The oparands of a logical && or || shall be primary-expressions .12.6, 13.2Advisory 114 SThe operands of logical operators (&&, || and !) should be effectively Boolean. Expressions thatare effectively Boolean should not be used as operands to operators other than (&&, || and !).Expression is not Boolean.50 SUse of shift operator on signed type.Bitwise operators shall not be applied to operands whose underlying type is signed.12.4Required 12.7Required11.5Required12.1AdvisoryA cast shall not be performed that removes any const or volatile qualification from the typeaddressed by a pointer.Limited dependence should be placed on C’s operator precedence rules in expressions.The value of an expression shall be the sameunder any order of evaluation that the standardpermits.The right hand operand of a logical && or ||operator shall not contain side effects.12.2Required LDRA Ltd. reserves the right to change anyMISRA-C:2004Rule Required / Advisory LDRA Rule NumberMISRA Description LDRA Rule Description120 S Use of bit operator on signed type. 12.8Required51 SThe right hand operand of a shift operator shall lie between zero and one less than the width inbits of the underlying type of the left hand operand.Shifting value too far.12.9Required 52 SThe unary minus operator shall not be applied toan expression whose underlying type is unsigned.Unsigned expression negated.12.10Required 53 S The comma operator shall not be /doc/9781b2552b160b4e767fcff3.html e of comma operator. 493 S Numeric overflow.494 SNumeric underflow.12.12Required 345 S The underlying bit representations of floating-point values shall not be used.Bit operator with floating point operand.12.13Advisory 30 S The increment (++) and decrement (--) operatorsshould not be mixed with other operators in anexpression.See 12.213.1Required 132 S Assignment operators shall not be used inexpressions that yield a Boolean value.Assignment operator in boolean expression.13.2Advisory 114 S Tests of a value against zero should be madeexplicit, unless the operand is effectively Boolean.See 12.613.3Required 56 S Floating-point expressions shall not be tested forequality or inequality.Equality comparison of floating point.13.4Required39 SThe controlling expression of a for statementshall not contain any objects of floating type.Unsuitable type for loop variable.429 SEmpty middle expression in for loop. 430 SInconsistent usage of loop control variable. 270 S For loop initialisation is not simple. 271 SFor loop incrementation is not simple.12.11Advisory Evaluation of constant unsigned integer expressions should not lead to wrap-around. operands whose underlying type is signed.The three expressions of a for statement shall be concerned only with loop control.13.512.7RequiredRequiredLDRA Ltd. reserves the right to change anyMISRA-C:2004RuleRequired / Advisory LDRA Rule NumberMISRA Description LDRA Rule Description13.6Required 55 D Numeric variables being used within a for loop foriteration counting shall not be modified in thebody of the loop.Modification of loop counter in loop body. 139 S Construct leads to infeasible code. 140 S Infeasible loop condition found.14.1Required1 J There shall be no unreachable code.Unreachable Code found.14.2Required57 S All non-null statements shall either :a) have at least one side-effect howeverexecuted, orb) cause control flow to change.Statement with no side effect.14.3Required 58 SBefore preprocessing, a null statement shall only occur on a line by itself; it may be followed by a comment provided that the first character following the null statement is a white space character.Null statement found.14.4Required 13 S The goto statement shall not be used.goto detected. 14.5Required 32 S The continue statement shall not be used.Use of continue statement. 31 SUse of break statement in loop. 409 SMore than one break statement in loop. 14.7Required 7 CA function shall have a single point of exit at theend of the function.Procedure has more than one exit point. 11 SNo brackets to loop body. 428 S No {} for switch. 14.9Required12 SAn if (expression) construct shall be followed by a compound statement. The else keyword shall befollowed by either a compound statement, or another if statement.No brackets to then/else.The statement forming the body of a switch, while, do ... while or for statement shall be acompound statement.For any iteration statement there shall be at most one break statement used for loop termination.Boolean operations whose results are invariantshall not be permitted.14.8Required14.613.7Required RequiredLDRA Ltd. reserves the right to change anyMISRA-C:2004RuleRequired / Advisory LDRA Rule NumberMISRA Description LDRA Rule Description59 S Else alternative missing in if.477 S Empty else clause following else if.60 SEmpty switch statement.385 S MISRA switch statement syntax violation.15.1, 15.5Required 245 S A switch label shall only be used when the mostclosely-enclosing compound statement is the body of a switch statement.Case statement in nested block.15.2Required62 S An unconditional break statement shall terminateevery non ?empty switch clause.Switch Case not terminated with break.48 SNo default case in switch statement.322 S Default is not last case of switch. 410 SSwitch empty default has no comment.15.4Required 121 SA switch expression shall not represent a valuethat is effectively /doc/9781b2552b160b4e767fcff3.html e of boolean expression in switch. 61 S Switch contains default only. 245 SCase statement in nested block.16.1Required 41 SFunctions shall not be defined with a variablenumber of arguments.Ellipsis used in procedure parameter list. 1 U Inter-file recursion found. 6 DRecursion in procedure calls found. 16.3Required 37 SIdentifiers shall be given for all of the parametersin a function prototype declaration.Procedure Parameter has a type but no identifier. 16.4Required 36 DThe identifiers used in the declaration anddefinition of a function shall be identical.Prototype and Definition name mismatch. 16.5Required 63 SFunctions with no parameters shall be declaredwith parameter type void.Empty parameter list to procedure/function. 21 S Number of parameters does not match.Every switch statement shall have at least onecase clause.Functions shall not call themselves, either directlyor indirectly.The number of arguments passed to a functionshall match the number of parameters.All if … else if constructs shall be terminated with an else clause.N/A15.5Required 16.2Required 14.10Required15.3Required16.6Required15N/AThe final clause of a switch statement shall bethe default clause.LDRA Ltd. reserves the right to change anyMISRA-C:2004RuleRequired / Advisory LDRA RuleNumberMISRA DescriptionLDRA Rule Description98 SActual and formal parameters inconsistent (MR).59 DParameter should be declared const.62 DPointer parameter should be declared const.2 DFunction does not return a value on all paths.36 S Function has no return statement. 66 S Function with empty return expression.16.9Required 99 S A function identifier shall only be used with eithera preceding &, or with a parenthesised parameter list, which may be empty.Function use is not a call.16.10RequiredDataflow anomalies If a function returns error information, then thaterror information shall be tested.N/A87 S Use of pointer arithmetic. 436 S Declaration does not specify an array.17.2Required438 SPointer subtraction shall only be applied topointers that address elements of the same array.Pointer subtraction not addressing one array.17.3Required 437 S >, >=, <, <= shall not be applied to pointer types except where they point to the same array.< > <= >= used on different object pointers.17.4Required 87 SArray indexing shall be the only allowed form of pointer arithmetic.See 17.117.5Advisory80 SThe declaration of objects should contain nomore than 2 levels of pointer indirection.Pointer indirection exceeds 2 levels.17.6Required 71 S The address of an object with automatic storage shall not be assigned to another object that may persist after the first object has ceased to exist.Pointer assignment to wider scope.465 S Struct/union not completely specified.481 SArray with no bounds in struct.17.1, 17.4RequiredAll exit paths from a function with non-void return type shall have an explicit return statement withan expression.Pointer arithmetic shall only be applied topointers that address an array or array element.A pointer parameter in a function prototype should be declared as pointer to const if the All structure and union types shall be complete at the end of a translation unit.Required16.8Required18.1Advisory16.7LDRA Ltd. reserves the right to change anyMISRA-C:2004Rule Required / Advisory LDRA Rule Number MISRA DescriptionLDRA Rule Description482 S Incomplete structure referenced.497 S Type is incomplete in translation unit.18.2Required 480 SAn object shall not be assigned to an overlappingobject.memcpy params access same variable.18.3Required N/A An area of memory shall not be reused forunrelated purposes.N/A18.4Required74 S Unions shall not be used. Union declared.75 S Executable code before an included file. 78 S Macro parameter not in brackets.338 S#include preceded by non preproc directives.19.2Advisory 100 SNon-standard characters should not occur inheader file names in #include directives.#include filename is non conformant. 292 SNo space between #include and filename. 339 S #include directive with illegal items. 427 SFilename in #include not in < > or " ". 19.4Required79 SC macros shall only expand to a braced initialiser, a constant, a parenthesisedexpression, a type qualifier, a storage class specifier, or a do-while-zero construct.Macro contains unacceptable items67 S #Define used in a block. 426 S #undef used in a block.19.6Required 342 SExtra chars after preprocessor directive. 19.6, 20.0Required 68 S#undef used. 19.7Advisory 340 SA function should be used in preference to afunction-like macro.Use of function like macro. 19.8Required 324 SA function-like macro shall not be invoked withoutall of its arguments.Macro call has wrong number of parameters. 19.9Required341 S Arguments to a function-like macro shall notcontain tokens that look like preprocessingdirectives.Preprocessor construct as macro parameter.Macros shall not be #define’d or #undef’d within ablock.#undef shall not be used.#include statements in a file should only bepreceded by other preprocessor directives orcomments.The #include directive shall be followed by eithera or "filename" sequence.the end of a translation unit.19.3Required19.5Required 19.1AdvisoryRequired18.1LDRA Ltd. reserves the right to change anyMISRA-C:2004RuleRequired / Advisory LDRA Rule NumberMISRA Description LDRA Rule Description19.10Required78 SIn the definition of a function-like macro each instance of a parameter shall be enclosed inparentheses unless it is used as the operand of # or ##.In the definition of a function-like macro the whole definition, and each instance of a parameter, shall be enclosed in parentheses or braces.19.11Required337 SAll macro identifiers in preprocessor directives shall be defined before use, except in #ifdef and#ifndef preprocessor directives and the defined() operator.Undefined macro variable in #if.19.12Required 76 SThere shall be at most one occurrence of the # or## operators in a single macro definition.More than one of # or ## in a macro. 19.13Advisory 125 S The # and ## operators should not be/doc/9781b2552b160b4e767fcff3.html e of ## or # in a macro 335 S operator defined contains illegal items. 336 S #if expansion contains define operator.19.15Required243 S Precautions shall be taken in order to prevent thecontents of a header file being included twice.Included file not protected with #define.19.16Required147 S Preprocessing directives shall be syntacticallymeaningful even when excluded by thepreprocessor.Spurious characters after preprocessor directive126 S A #if has no #endif in the same file.343 S #else has no #if, etc in the same file. 86 S Attempt to define reserved word. 156 S Use of 'defined' keyword in macro body. 478 S Misra special prefix banned name.20.2Required 218 SThe names of standard library macros, objectsand functions shall not be /doc/9781b2552b160b4e767fcff3.html is used in standard libraries. 20.3RequiredUnit TestingThe validity of values passed to library functions shall be checked.TBrun may be used to perform the necessary checks.Reserved identifiers, macros and functions in thestandard library, shall not be defined, redefinedor undefined.The defined preprocessor operator shall only beused in one of the two standard forms.All #else, #elif and #endif preprocessor directivesshall reside in the same file as the #if or #ifdef directive to which they are related.19.17Required19.14RequiredRequired20.1LDRA Ltd. reserves the right to change anyMISRA-C:2004。
C语言代码规范(编程规范)
什么叫规范？在C语言中不遵守编译器的规定，编译器在编译时就会报错，这个规定叫作规则。
但是有一种规定，它是一种人为的、约定成俗的，即使不按照那种规定也不会出错，这种规定就叫作规范。
虽然我们不按照规范也不会出错，但是那样代码写得就会很乱。
大家刚开始学习C语言的时候，第一步不是说要把程序写正确，而是要写规范。
因为如果你养成一种非常不好的写代码的习惯，代码就会写得乱七八糟，等到将来工作面试的时候，这样的习惯可能会让你失去机会。
代码如何写才能规范那么代码如何写才能写得很规范呢？代码的规范化不是说看完本节内容后就能实现的。
它里面细节很多，而且需要不停地写代码练习，不停地领悟，慢慢地才能掌握的一种编程习惯。
所以大家不要想着一下子就能把代码规范化的所有知识全部掌握，也不要想着一下子就能把代码写规范，这是不太可能的。
有很多知识，比如为什么代码要这样写，为什么不能那样写，作为一个初学者你是很难弄明白的。
有很多规范是为了在程序代码量很大的时候，便于自己阅读，也便于别人阅读。
所以刚开始的时候有很多规范你不知道为什么要那样规定，你就单纯地模仿就行了。
等将来敲代码敲得时间长了，你就会感觉到那样写是很有好处的。
代码规范化的好处代码规范化的第一个好处就是看着很整齐、很舒服。
假如你现在用不规范的方式写了一万行代码，现在能看得懂，但等过了三个月你再回头看时就很吃力了，更不要说给别人看了。
所以代码要写规范，比如加注释就是代码规范化的一个思想。
在一般情况下，根据软件工程的思想，我们的注释要占整个文档的20%以上。
所以注释要写得很详细，而且格式要写得很规范。
第二个好处是，把代码写规范则程序不容易出错。
如果按照不规范的格式输入代码的话，很容易出错。
而代码写规范的话即使出错了查错也会很方便。
格式虽然不会影响程序的功能，但会影响可读性。
程序的格式追求清晰、美观，是程序风格的重要构成元素。
代码规范化的七大原则代码规范化基本上有七大原则，体现在空行、空格、成对书写、缩进、对齐、代码行、注释七方面的书写规范上。
USB Type-C 规范1.2(中文版)
知识产权声明
THIS SPECIFICATION IS PROVIDED TO YOU “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE. THE AUTHORS OF THIS SPECIFICATION DISCLAIM ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PROPRIETARY RIGHTS, RELATING TO USE OR IMPLEMENTATION OF INFORMATION IN THIS SPECIFICATION. THE PROVISION OF THIS SPECIFICATION TO YOU DOES NOT PROVIDE YOU WITH ANY LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS.
预发行行业审查公司提供反馈
Revision History.......................................................................................................................14
LIMITED COPYRIGHT LICENSE: The USB 3.0 Promoters grant a conditional copyright license under the copyrights embodied in the USB Type-C Cable and Connector Specification to use and reproduce the Specification for the sole purpose of, and solely to the extent necessary for, evaluating whether to implement the Specification in products that would comply with the specification.
MISRA--C编程规范
MISRA--作为工业标准的C编程规范(嵌入式c开发者必读)MISRA--作为工业标准的C编程规范MISRA (The Motor Industry Software Reliability Association 汽车工业软件可靠性联会) 是位于英国的一个跨国汽车工业协会，其成员包括了大部分欧美汽车生产商。
其核心使命是为汽车工业提供服务和协助，帮助厂方开发安全的、高可靠性的嵌入式软件。
这个组织最出名的成果是所谓的MISRA C Coding Standard，这一标准中包括了127条C语言编码标准，通常认为，如果能够完全遵守这些标准，则你的C代码是易读、可靠、可移植和易于维护的。
最近很多嵌入式开发者都以MISRA C来衡量自己的编码风格，比如著名的uC/OS-II就得意地宣称自己99％遵守MISRA标准。
而《嵌入式开发杂志》也专门载文号召大家学习。
编码规范通常是一个公司自定的“土政策”，居然有人去做标准，而且还得到广泛的认可，这不禁引起我强烈的兴趣。
可惜这份标准的文本需要花钱去买，而且短短几十页，要价非常昂贵。
MISRA 在网上公布了一些文档，其中有关于MISRA C Coding Standard的Clarification报告，从中间你可以大致猜到MISRA标准本身是什么。
我仔细阅读了这些文档，并且通过阅读其他一些介绍性文档，大致了解了MISRA标准的主要内容。
这些条款确有过人之处，对于C/C++语言工程项目的代码质量管理能够起到良好的指导性作用，对于大部分软件开发企业来说，在MISRA的基础上适当修改就可以形成自己的规范。
当然其中也有一些过于严苛的东西，这就需要各个开发部门灵活处理了。
我个人的体会，编码规范虽然很简单，但是要完全执行，不折不扣，需要开发部门有很高的组织性和纪律性，并且有很好的代码评审机制。
因此，如果能够严格地遵守编码规范，本身就是一个开发部门实力的证明。
这里不可能将所有规则一一列出（事实上正式文本我一条也没看到），只列出一些比较有意思的条款，让大家有机会了解MISRA的风格。
标准C语言规范
* 编程时间 : 94.9.29
* 修改时间 :
*/
#include <curses.h>
#include <signal.h>
#include <fcntl.h>
#include "Tr_mac.h"
#include "Tr_str.h"
return(Err);
}
}
/******* added by yang yijun 95.7.25 *****/
else
{
_disp_nm(bgdc.cur); /* yyj 94.11.17.*/
return(Err);
}
}
return(Ok);
}
void_disp_nm( _sName)
char *_sName;
p------pointer
字符串数组也使用p标志
静态变量名前用s标志
数组变量名前用stru标志
全局变量使用前缀g_标志
如：dBalance，fInterest，pName,sCustomer，struPersonWang,g_iOperNo
3．书写规范
⑴对齐原则
同一层次的语句必须左对齐。“{”和“}”必须独占一行。
⑵缩进原则
不同层次的语句必须遵从缩进原则，一般缩进四个字符为宜,TAB值设为4。
Case后的语句（简短注释语句除外）应另起一行，且须与“：”相接。
⑶分行书写原则
当行超过屏幕上的行时，应分行书写。
⑷注释符要求
单行注释符使用“//”，多行注释符使用“/*……*/”，注释符必须遵从前面3条原则，
c类防火窗规范最新标准
c类防火窗规范最新标准C类防火窗规范最新标准。
随着城市建设的不断发展，建筑安全已经成为人们关注的焦点之一。
而在建筑安全中，防火安全更是至关重要的一环。
作为建筑中的重要防火设施，防火窗在建筑设计和施工中扮演着重要的角色。
因此，C类防火窗的规范和标准也备受关注。
本文将就C类防火窗的最新标准进行介绍和分析，以期为相关从业人员提供参考。
首先，C类防火窗的材质和结构应符合国家相关建筑防火标准的要求。
在材质选择上，应选用符合防火要求的金属材料或其他耐火材料，以确保在火灾发生时能够有效地隔离火灾蔓延。
同时，在结构设计上，应考虑到防火窗的密封性和稳定性，以确保其在火灾发生时能够有效地起到隔离和阻挡火灾的作用。
其次，C类防火窗的安装和使用也需要符合一定的规范。
在安装过程中，应严格按照相关标准和要求进行，确保防火窗的安装位置和方式符合要求，不得出现任何安装缺陷或不合理之处。
同时，在使用过程中，相关人员也应按照规定正确地使用和维护防火窗，确保其在平时能够保持良好的状态，一旦发生火灾能够正常使用。
另外，C类防火窗的检测和维护也是至关重要的。
定期的检测和维护能够及时发现防火窗存在的问题，并进行及时修复和处理，以确保其在火灾发生时能够正常使用。
因此，相关单位和个人应严格按照规定进行防火窗的定期检测和维护，确保其在平时能够处于良好的状态。
总之，C类防火窗的规范和标准对于建筑安全具有重要的意义。
相关从业人员应严格按照相关标准和要求进行设计、安装、使用、检测和维护，确保C类防火窗能够在火灾发生时发挥应有的作用，保障建筑及其中人员的安全。
希望本文能够为大家对C类防火窗的规范和标准有所了解，并能够引起大家对建筑防火安全的重视和关注。
c命名规范
c命名规范C命名规范是指在编程中为变量、函数、类、常量等标识符取名的一套规则。
遵循良好的命名规范可以增加代码的可读性和可维护性，方便他人理解和使用代码。
一、命名原则1. 可读性原则：命名要具有可读性，方便其他人理解代码的含义。
避免使用缩写、不清晰的变量名或拼音命名，尽量使用有意义的单词或词组。
2. 一致性原则：命名应保持统一，遵循团队或项目的约定。
相同类型的标识符命名应统一，不同类型的标识符命名应区分开。
3. 易于搜索原则：命名要便于搜索和定位。
避免使用过长的命名，但也要避免使用过短的命名，使得标识符在项目中易于搜索和找到。
二、标识符的命名规范1. 变量和函数命名：使用小写字母和下划线，多个单词之间用下划线分隔。
例如：user_name, calculate_price。
2. 类的命名：使用驼峰命名法，即首字母大写，不使用下划线。
例如：UserInfo, CarFactory。
3. 常量的命名：使用大写字母和下划线，多个单词之间用下划线分隔。
例如：MAX_NUMBER, PI_VALUE。
4. 包名的命名：使用小写字母，多个单词之间使用点"."分隔。
例如：com.example.project。
5. 枚举类型的命名：使用大写字母和下划线，多个单词之间用下划线分隔。
例如：Color.RED, Season.SUMMER。
三、命名的约定1. 命名要有意义，尽量反映标识符的用途和含义，避免使用无意义的命名。
2. 避免使用保留字和关键字作为标识符，例如：int, float, if, else等。
3. 避免使用单个字母或数字作为标识符，除非是临时变量或索引变量。
4. 当命名较长时，可以使用缩写，但要确保缩写被广泛接受并易于理解。
5. 避免使用拼音命名，特别是在英文环境下，可能导致理解困难。
6. 命名要避免歧义和混淆，尽量不要使用相似的标识符，容易造成误解。
四、常见命名错误1. 不符合命名规范：命名不清晰、不规范，缺乏可读性和可维护性。
软件编程规范(MISRA_C)
软件编程规范目录一环境二语言扩展三文档四字符集五标识符六类型七常量八声明与定义九初始化十数值类型转换十一指针类型转换十二表达式十三控制语句表达式十四控制流十五 switch语句十六函数十七指针和数组十八结构与联合十九预处理指令二十标准库二十一运行时错误一环境规则1.1（强制）：所有代码都必须遵照ISO 9899:1990 “Programming languages - C”，由ISO/IEC 9899/COR1:1995，ISO/IEC 9899/AMD1:1995，和ISO/IEC9899/COR2:1996 修订。
规则1.2（强制）：不能有对未定义行为或未指定行为的依赖性。
这项规则要求任何对未定义行为或未指定行为的依赖，除非在其他规则中做了特殊说明，都应该避免。
如果其他某项规则中声明了某个特殊行为，那么就只有这项特定规则在其需要时给出背离性。
规则1.3（强制）：多个编译器和/或语言只能在为语言/编译器/汇编器所适合的目标代码定义了通用接口标准时使用。
如果一个模块是以非C 语言实现的或是以不同的C 编译器编译的，那么必须要保证该模块能够正确地同其他模块集成。
C 语言行为的某些特征依赖于编译器，于是这些行为必须能够为使用的编译器所理解。
例如：栈的使用、参数的传递和数据值的存储方式（长度、排列、别名、覆盖，等等）。
规则1.4（强制）：编译器/链接器要确保31 个有效字符和大小写敏感能被外部标识符支持。
ISO 标准要求外部标识符的头6 个字符是截然不同的。
然而由于大多数编译器/链接器允许至少31 个有效字符（如同内部标识符），因此对这样严格而并不具有帮助性的限制的适应性被认为是不必要的。
必须检查编译器/链接器具有这种特性，如果编译器/链接器不能满足这种限制，就使用编译器本身的约束。
规则1.5（建议）：浮点应用应该适应于已定义的浮点标准浮点运算会带来许多问题，一些问题（而不是全部）可以通过适应已定义的标准来克服。
c语言命名规范
c语言命名规范C语言命名规范是为了提高代码的可读性和维护性，使不同人员编写的代码在风格上保持一致。
以下是一些常见的C语言命名规范：1. 变量和函数名应使用有意义的描述性词汇，尽量使用英文单词或缩写，避免使用无意义的单词或缩写。
2. 变量名应使用小写字母，使用下划线作为单词之间的分隔符，例如：num_students。
3. 函数名应使用小写字母，每个单词的首字母大写，使用驼峰命名法，例如：calculateAverage。
4. 宏定义应使用大写字母，并用下划线分隔单词，例如：MAX_NUM。
5. 常量名应使用大写字母，并用下划线分隔单词，例如：PI。
6. 结构体名应使用大写字母开头，每个单词首字母大写，使用驼峰命名法，例如：StudentInfo。
7. 指针名应以“p_”开头，后面跟上指向的变量名，例如：p_student。
8. 数组名应采用单数形式，例如：student。
9. 枚举类型应使用大写字母命名，并用下划线分隔单词，例如：ColorType。
10. 文件名应全部小写，并用下划线分隔单词，例如：calculator.c。
11. 函数参数名应使用小写字母，使用下划线作为单词之间的分隔符，例如：num_students。
12. 类型定义名应使用大写字母开头，每个单词首字母大写，使用驼峰命名法，例如：StudentInfo。
13. 行内函数或变量的命名应使用小写字母，用下划线分隔单词，例如：get_average。
总之，C语言命名规范应尽量清晰、简洁和有意义。
使用规范的命名方法可以提高代码的可读性和可维护性，从而更好地理解和修改代码。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
版本历史
目录
1目的 (4)
2范围 (4)
3规范内容 (4)
代码格式 (4)
注释（C OMMENT）规范 (5)
变量（V ARIABLE）命名规范 (7)
常量命名规范 (9)
类（C LASS）命名规范 (9)
类的实例命名规范 (10)
接口（I NTERFACE）命名规范 (10)
方法（M ETHOD）、属性（A TRIBUTE）命名规范 (10)
命名空间（N AME S PACE）命名规范 (11)
窗口(F ORM)命名规范 (11)
4编码实践经验 (11)
C#编码规范
1目的
为了保证所每个项目组编写出的程序都符合相同的规范，便于理解和维护，便于检查、减少出错概率，有助于成员间交流，保证一致性、统一性而建立的C#程序编码规范。
2范围
该规范适用于所有基于C#开发的.Net平台项目。
3规范内容
代码格式
◆所有的缩进为4个空格，使用的默认设置。
◆在代码中垂直对齐左括号和右括号。
◆为了防止在阅读代码时滚动源代码编辑器，每行代码或注释在1024*768的分辨率下尽量不超过一
显示屏。
◆当一行被分为几行时，将串联运算符放在每一行的末尾而不是开头，清楚地表示没有后面的行是不
完整的。
缩进方式采用默认格式。
◆每一行上放置的语句避免超过一条。
◆在大多数运算符之前和之后使用空格，这样做时不会改变代码的意图却可以使代码容易阅读。
例：
◆将大的复杂代码节分为较小的、易于理解的模块。
◆编写SQL 语句时，建议（不强求）对于关键字使用全部大写，对于数据库元素（如表、列和视图）
使用大小写混合。
◆将每个主要的SQL 子句放在不同的行上，这样更容易阅读和编辑语句，例如：
◆使用括号的目的必须是在表达上不但能够标明优先顺序，而且有助于使表达更简单明了。
另外，如
果某一段代码有可能产生歧义，也需加括号。
注释（Comment）规范
注释规范包括：模块（类）注释规范、类属性注释规范、方法注释规范、代码间注释规范。
3.1.1模块（类）注释规范
模块开始尽量以以下形式书写模块注释：
当模块有重大修改或修改他人代码时，必须添加以下注释：
修改时根据需要保留程序员第一次和最近一次修改的代码。
具体办法是将原有代码注释。
(保留第一次的代码可以反映此部分代码最初要实现的功能及其初始编程思想，保留最新的代码可以反映此代码最近变化要实现的最新功能)
3.1.2类属性注释规范
在类的属性必须以以下格式编写属性注释：
3.1.3方法注释规范
在Visual Studio环境中，在方法中上一行中输入“///”，开发环境会自动生成注释模板。
3.1.4代码间注释规范
代码间注释分为单行注释和多行注释。
3.1.
4.1单行注释：
//<单行注释>（不提倡使用，尽量都使用/**/）
3.1.
4.2多行注释：
/*多行注释1
多行注释2
多行注释3*/
代码中遇到语句块（if，case……）或实现一个逻辑功能时，必须添加注释。
添加的注释应该能够说明此语句块的作用和实现手段（所用算法等等）。
注释应添加在所说明语句同一级别的缩进里。
变量（Variable）命名规范
3.1.5程序文件(*.cs)中的变量命名规范
程序中变量名称=变量的前缀+代表变量含意的英文单词或单词缩写。
1．
2．过程级的变量不使用前缀, 第一个字母小写，其他单词的首字母大写。
3．过程的参数使用“p_”作为参数, 第一个字母小写，其他单词的首字母大写。
如果捕获异常不需要作任何处理，则不需要定义Exception实例。
例：
4．
单词外，每个单词的第一个字母都是大写。
例如：oracleConnection。
5．即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用有意义的名称。
仅对于短循环索引使用单字母变量名，如i 或j。
6．在变量名中使用互补对，如min/max、start/end 和open/close。
7．不要使用原义数字或原义字符串，如for (int i = 0;i < 7;i++)。
而是使用命名常数，如for ( int i = 0;i < DAYS_IN_WEEK;i++)，以便于维护和理解。
8．类成员变量声明时，应放在类的顶部。
3.1.6控件命名规则
控件命名=控件缩写前缀+变量具体释义。
常量命名规范
常量名也应当有一定的意义，格式为NOUN 或NOUN_VERB。
常量名均为大写，单词之间用下划线分隔。
例：
注：
变量名和常量名最多可以包含255 个字符，但是，超过25个字符的名称比较笨拙。
并且，要想取一个有实际意义的名称，清楚地表达变量或常量的用途，25个字符应当足够了。
类（Class）命名规范
1．名字应该能够标识事物的特性。
2．首字母大写，缩略语可以全部字母大写。
3．名字可以有两个或三个单词组成，但通常不应多于三个。
4．在名字中，每个单词的第一个字母大写。
例如：IsSuperUser；包含ID的，ID全部大写，如CustomerID。
5．使用名词或名词短语命名类。
4．少用缩写，除非是被广泛使用的。
5．不要使用下划线字符(_)。
6．自定义异常类以Exception结尾。
例：
类的实例命名规范
类的实例第一个字母小写，其他单词的第一个字母大写。
例：
接口（Interface）命名规范
和类命名规范相同，唯一区别是接口在名字前加上“I”前缀。
方法（Method）、属性（Atribute）命名规范
1．方法命名应采用首字母大写的方式。
2．返回值是Bool值的方法和属性以Is开头。
3．使用返回值是Bool值的方法（属性）的时候，不要将bool值方法（属性）与if语句放在同一行，如应该这样写：
4 其他和类命名规范相同。
5 同名方法参数少的在前，多的在后(多态)。
6 类构造函数方法在类方法描述的最前。
7 按访问作用域和访问权限，权限低的（private）在前，高的（public）在后。
/IT PAGE 11 OF 11 命名空间（NameSpace ）命名规范
和类命名规范相同。
窗口(Form)命名规范
frm+模块名称+子模块名称，其中子模块名称在模块不能细分的情况下可以省略。
主界面统一命名为：frmMain
例：
● frmMain
● frmDatasource
●
frmDataSetSelect
4 编码实践经验
◆ 不要混合使用递增运算符和递减运算符。
原因：在方法调用或是数学运算中混合使用递增运算符（或递减运算符）会造成欠经验的程序员阅读困难。
◆ Switch 语句必须有default 语句。
◆ 避免在一个语句中给多个变量赋相同的值。
◆ 避免在同一个文件中放置多个类。
◆ 避免在同一个文件中使用多个命名空间。
◆ 避免写超过5个参数的方法。
如果传递多个参数，应使用结构。
◆ 尽量使用以零为基数的数组。
◆ 使用长字符串时，使用StringBuilder 代替string 。
◆ 使用String.Empty 取代””。
◆ 注意不要将随发布环境变化而变化的变量写死，例如数据库连接字符串。
◆ 变量声明后应立即赋初值。
◆ 调试语句应及时注释掉。