Basic C language programming specifications for microcontroller development

灞波儿奔

Basic C language programming specifications for microcontroller development [Copy link]

This specification is mainly aimed at the single-chip microcomputer programming language and the 08 compiler, including typesetting, comments, naming, variable usage, code testability, program efficiency, quality assurance and other contents. 1. Basic rules Clear format, concise comments, easy-to-understand naming conventions, modular functions, easy-to-read and easy-to-maintain programs, accurate implementation of functions, high code space efficiency and time efficiency, moderate scalability, single-chip microcomputer programming specifications - identifier naming 2. Identifier naming 2.1 Basic naming principles (1) The naming is clear and concise, with clear meanings, and uses complete words or commonly accepted abbreviations. Generally, shorter words can be abbreviated by removing vowels; longer words can be abbreviated by taking the first few letters of the word. That is, "see the name and know the meaning". (2) The naming style should be consistent from beginning to end. (3) If special conventions or abbreviations are used in naming, there should be comments to explain. (4) The module identifier is added before the name of the interface part between modules in the same software product. 2.2 Naming macros and constants Macros and constants are named with all uppercase letters, and words are separated by underscores. All numbers used in the program should be replaced by meaningful enumerations or macros. 2.3 Naming variables Variable names are named with lowercase letters, and the first letter of each word is uppercase. Type prefix (u8\s8 etc.) Global variables are prefixed with g_. Local variables should be concise. Local loop control variables should preferably use i, j, k, etc.; local length variables should preferably use len, num, etc.; temporary intermediate variables should preferably use temp, tmp, etc. 2.4 Function Naming Function names should be named in lowercase letters, with the first letter of each word capitalized, and the module identifier should be added at the front. 2.5 File Naming A file contains all functions of a class of functions or a module, and the file name should clearly indicate its function or nature. Each .c file should have a .h file with the same name as a header file. 3. Comments 3.1 Basic Principles of Comments It helps to understand the program, explain what the program is doing, and explain the purpose, function and method of the code. Generally, the effective comment volume of the source program is about 30%. The comment language must be accurate, easy to understand and concise. Write the code while commenting, modify the corresponding comments while modifying the code, and delete the comments that are no longer useful. Use "//" in both assembly and C, cancel ";" Do not use segment comments " /* */ " (available during debugging) 3.2 File comments File comments must state the file name, function, creator, creation date, version information and other related information. When modifying file code, the modification date and modifier should be recorded in the file comment, and the purpose of the modification should be briefly stated. All modification records must be kept complete. File comments are placed at the top of the file and included in the "/*……*/" format. The comment text is indented 4 spaces per line; the name of each comment text item should be aligned. /*************************************************************** File name: Author: Version: Description: Modification record: ***************************************************************/ 3.3 Function comments 3.3.1 Function header comments Function header comments should include function name, function function, input parameters, output parameters, etc. If necessary, you can also add author, creation date, modification record (remarks) and other related items. Function header comments are placed at the top of each function, using the format of "/*……*/". The function name should be abbreviated as Name(), and no information such as output parameters should be added. /*************************************************************** Function name: Function function: Entry parameter: Exit parameter: Remarks: ***********************************************************/ 3.3.2 Code comments (信、盈、达'腾讯：以一一起罩罩吧久零久要') Code comments should be placed adjacent to the commented code, above or to the right, not below. If placed above, they must be separated from the code above by a blank line. Generally, a small number of comments should be added at the end of the line 2 of the commented statement, and multiple comments in a function should be left-aligned; more comments should be added above and the comment line should be left-aligned with the commented statement. Function code comments use the format of "//…//". Generally, branch statements (conditional branches, loop statements, etc.) must be commented. The mark "end of ……" indicating the end of the program block should be added to the right of the program block end line "}", especially when multiple nesting. 3.4 Comments on variables, constants, and macros Identifiers of the same type should be defined together, and their common features should be uniformly commented on the line before the definition. Comments on individual identifiers are added to the end of the definition statement. Global variables must have detailed comments, including their functions, value ranges, which functions or procedures access them, and precautions when accessing them. Comments use the format of "//…//". 4. Function 4.1 Function design principles Basic requirements for functions: 1) Encapsulation 1) Correctness: The program must implement the functions required by the design. 2) Stability and security: The program runs stably, reliably and safely. 3) Testability: The program is easy to test and evaluate. 4) Standardization/readability: The program writing style, naming rules, etc. meet the standards. 5) Extensibility: The code leaves space and interfaces for the next upgrade and expansion. 6) Global efficiency: The overall efficiency of the software system is high. 7) Local efficiency: The efficiency of a module/submodule/function itself is high. Basic principles for compiling functions: 1) The size of a single function should be limited to 200 lines (excluding comments and blank lines). A function only completes one function. 2) The number of local variables in a function generally does not exceed 5 to 10. 3) There is a blank line between the local variable definition area and the function implementation area (including variable initialization) in the function. 4) The function name should accurately describe the function's function. Usually, a verb-object phrase is used to name a function that performs a certain operation. 5) The return value of the function should be clear, especially the meaning of the error return value should be accurate. 6) Do not return a variable of a different type from the function return value as a return value using the default conversion method or forced conversion method of the compilation system. 7) Reduce recursive calls within a function or between functions. 8) Try not to use function parameters as working variables. 4.2 Function Definition 1) If a function has no input or output parameters, it should be explicitly declared as void. 2) There should be one and only one space between the function name and the output parameter type definition. 3) There is no space between the function name and the parentheses (). 4) Function parameters must be given an explicit type definition. 5) For functions with multiple parameters, add a space between the latter parameter and the comma separator of the previous parameter. 6) The front and back curly braces "{}" of the function body should each occupy a separate line. 4.3 Local Variable Definition 1) Do not define too many variables on the same line. 2) Variables of the same type are defined in the same line, or in adjacent lines. 3) Define data type variables first, then define idtata type variables, and then define xdata type variables. (?) 4) The definition of complex types such as arrays and pointers is placed at the end of the definition area. 5) Do not make more complex variable assignments in the variable definition area. 4.4 Function Implementation Area Specifications 1) Write only one statement per line. 2) Pay attention to the priority of operators, and use parentheses to clarify the order of operations in expressions, and avoid using default priorities. 3) Use a blank line to separate each program segment, and add necessary comments. A program segment refers to one or more lines of code that can complete a more specific function. The lines of code in a program segment are highly interdependent. (1, 2, 3 methods) 4) Do not use difficult and technical statements. 5) The closely related codes in the source program should be as close as possible. 6) One or several statements that complete simple functions and are very closely related can be written as functions or defined as macros. 5. Microcontroller Programming Specifications - Formatting