Embedded sharing collection 15

①、 Embedded engineer's 100 This professional book

001《 Big talk data structure 》

002《 Bird brother linux Private dishes 》

003《 insane android The notes 》

004《 First line of code 》

005《linux Kernel design and implementation 》

006《 Driving design and development 》

007《linux Kernel decryption 》

008《unix Environment advanced programming 》

009《linux Kernel design and implementation 》

010《essential C++》

011《 The embedded linux》

012《linux Device drivers 》

013《c Deep anatomy of language 》

014《linux Under the c Programming 》

015《C Primer Plus（ The fifth edition ）》

016《ARM Architecture and programming （ The second edition ）》

017《lINUX Detailed description of device driven development （ The third edition ）》

018《android Explore the development of art 》

019《c++plus》

020《Unix Environment advanced programming 》

021《 Walk with big data —— The future of learning and Education 》

022《 Elements of the user experience 》

023《 Programming and art 》

024《ARM Embedded architecture and interface technology 》

025《cortex-m0 Interface programming 》

026《C Language programming : Modern methods 》

027《C++ Primer》

028《 data structure 》( YanWeiMin )

029《 Introduction to algorithms 》

030《Linux Device driven development 》

031《 The code of 》

032《 Deep understanding of computer systems 》

033《UNIX Environment advanced programming 》

034《 Principles of computer security 》

035《UNIX Network programming 》

036《HeadFirst Design patterns 》

037《linux drive 》（ Song Baohua ）

038《C++ primer4》

039《qt5 Wonderful examples 》

040《ldd3》

041《C++ Advanced programming 》

042《C Language course 》

043《 actual combat linux The essence of programming 》

044《ARM course 》

045《JAVA Programming idea 》

046《HTML+CSS Web design and layout from introduction to mastery 》

047《C Deep anatomy of language 》

048《 Deep practice Linux System migration 》

049《unix Advanced programming 》

050《c Embedded one-stop teaching 》

051《 Compiler principle 》

052《 Deep practice Linux System migration 》

053《UNIX Environment advanced programming 》

054《linux Network programming 》

055《C Language programming 》

056《unix Environment advanced programming 》

057《 The embedded linuxc Basic course of language programming 》

058《Java Programming idea 》

059《TCP/IP Detailed explanation 》

060《linux Technical manual 》

061《C A deep analysis of language 》

062《Unix Advanced environment programming 》

063《C++primerplus》

064《QT》

065《C Programming 》

066《C And a pointer 》

067《C++primer》

068《C Programming language 》

069《ProgrammingC#》

070《thinking in C++》

071《Linux Device driver》

072《Linux kernel development》

073《 Software Engineering 》

074《C And a pointer 》

075《Android Core code 》

076《Android Technology insider 》

077《Android Bottom migration 》

078《Unix Programming manual （ Up and down ）》

079《Linux Drive Design Third Edition 》

080《ARM Practical development 》

081《unix Environment advanced programming 》

082《tcp/ip Programming details 》

083《Linux Network programming 》

084《Unix Programming art 》

085《 Construction and interpretation of computer program 》

086《C Primer plus》

087《LINUX Authoritative guide 》

088《LINUX Device driver 》

089《The C Programming Language》

090《ajax Advanced programming 》

091《angula js Authoritative course 》

092《ARM Architecture 》

093《Unix Environment advanced programming 》

094《Linux Device driver 》

095《 Modern operating system 》

096《TCP/IP protocol 》

097《 The embedded C Language design patterns 》

098《Struts In Action》

099《c Programming language （ The second edition ）》

100《 In depth understanding of Linux kernel （ The third edition ）》 

whaosoft aiot http://143ai.com

②、C Language coding specifications

No rules, no circles . Any team , Norms are topics that can't be bypassed . Especially when we are engaged in embedded C Developed , Code specification is the top priority of development . There are too many reasons to regulate , Because everyone has different preferences for coding , The code style is also very different . Every programmer has his own opinion on good code in his mind , The unified coding standard can be the same as Qin Shihuang unified the Warring States period , Avoid unnecessary debate and controversy .

     Sometimes I will help my classmates look at the code , I found that most of writing code is arbitrary . It looks very big at first , although C Language is very important , however C Language code specification is also very important . Today's share is anfulai C Language coding specifications , It is suggested that beginners go to the official website to see their code , Very standard ！

One 、 Files and directories

    1、 The available character set for the naming of files and directories is A-Z;a-z;0-9;._-.

    2、 The suffix of the source file name is lowercase .c and .h.

    3、 The naming of documents should accurately and clearly express their contents , At the same time, the file name should be concise , Prevent the file name from being too long and causing inconvenience . Abbreviations can be used appropriately in file names .

     The following two naming methods are provided for reference ：

    （1） The file name of each program module begins 2 Lowercase letters represent the functions of this module ： Such as ： The main control program is mpMain.c,mpDisp.c … 

    （2） Do not write module function identification ： Such as ： The main control program is Main.c,Disp.c …

    4、 It is recommended that all header files and source files of a software package or a logical component be placed in a separate directory , This is conducive to finding and using relevant files , It is conducive to simplifying the setting of some compilation tools .

    5、 For the public header file required by the whole project , It should be stored in a separate directory ( for example ：myProject/include) Next , It can avoid the problem of too scattered directories when referenced by other writers .

    6、 For the paragraph arrangement in the source file , We suggest the following order ：

• a. File header comments

• b. Settings to prevent repeated references to header files

• c. #include part

• d. #define part

• e. enum Constant declaration

• f. Type declaration and definition , Include struct、union、typedef etc.

• g. Global variable declaration

• h. File level variable declaration

• i. Global or file level function declarations

• j. Function implementation . In the order of function declarations

• k. End of file comments

    7、 When referencing header files , Do not use absolute paths . If absolute path is used , When you need to move directories , All relevant codes must be modified , Cumbersome and unsafe ; Using relative paths , When you need to move directories , Just modify an option of the compiler .

#include “/project/inc/hello.h” /*  Absolute paths should not be used  */#include “../inc/hello.h” /*  You can use relative paths  */

    8、 When referencing header files , Use <> To reference the header files of predefined or specific directories , Use “” To reference the header file of the current directory or path relative to the current directory .

#include <stdio.h> /*  Standard header file  */#include <projdefs.h> /*  Project specified directory header file  */#include “global.h” /*  Current directory header file  */#include “inc/config.h” /*  The path is relative to the header file of the current directory  */

    9、 To prevent the header file from being repeatedly referenced , Should use ifndef/define/endif Structure produces preprocessing blocks .

#ifndef __DISP_H /*  Add two underscores before the file name “__”, Back plus  “_H”#define __DISP_H......#endif

    10、 Only... Is stored in the header file “ Statement ” Instead of storing “ Definition ”, In this way, you can avoid repeated definitions .

/*  modular  1  The header file ：module1.h */extern int a = 5; /*  In the module  1  Of  .h  Declare variables in the file  */
/*  modular  1  Implementation file ：module1.c */uint8_t g_ucPara; /*  In the module  1  Of  .h  Global variables are defined in the file  g_ucPara */

    11、 If other modules need to reference global variables g_ucPara, Just include... At the beginning of the file module1.h

/*  modular  2  Implementation file ：module2.c */#include “module1.h” /*  In the module  2  Contains modules  1  Of  .h  file  */......g_ucPara = 0;......

    12、 There is no very strict requirement for the length of the file , However, try to avoid long files . Generally speaking , The length of the document should be kept at 1000 In line .

Two 、 Typesetting

    1、 Program blocks should be written in an indented style , The number of indented spaces is 4 individual .

    2、 Between relatively independent blocks 、 The variable description must be followed by a blank line .

void DemoFunc(void){
   
uint8_t i;
<----  There is a blank line between the local variable and the statement 
/*  Function block  1 */
for (i = 0; i < 10; i++)
{
   
...
}
<----  There is a blank line between different function blocks 
/*  Function block  2 */
for (i = 0; i < 20; i++)
{
   
...
}
}

    3、 Make a new line at the symbol , Put the operator at the beginning of the new line , New lines should be indented appropriately , Make the typesetting neat , Statements are readable .

if ((ucParam1 == 0) && (ucParam2 == 0) && (ucParam3 == 0)
|| (ucParam4 == 0)) <----  Long expressions need to be written on new lines 
{
   
......
}

    4、 It is not allowed to write multiple phrasal sentences in one line , That is, write only one sentence per line .

rect.length = 0; rect.width = 0; <----  Incorrect writing 
rect.length = 0; <----  Correct writing 
rect.width = 0;

    5、 Align use TAB key ,1 individual TAB Corresponding 4 Characters .

    6、 The beginning of a function or process 、 The definition and cycle of structure 、 The code in the judgment and other statements should be indented ,case The case processing statement under the statement should also comply with the statement indentation requirements .

    7、 The delimiter of the program block （ Such as braces ‘{’ and ‘}’ ） Should have one row and be in the same column , At the same time, it is left aligned with the statement that references them . At the beginning of the function body 、 The definition of a class 、 Definition of structure 、 The definition of enumeration and if、for、do、while、switch、case The program in the statement should be indented as above . For existing code that is inconsistent with the rules , Priority should be given to ensuring style consistency in the same module .

for (...) { <----  Irregular writing 
... /* program code */
}
for (...)
{ <----  A standard way of writing 
... /* program code */
}
if (...)
{ <----  Irregular writing 
... /* program code */
}
if (...)
{ <----  A standard way of writing 
... /* program code */
}

    8、 In more than two keywords 、 Variable 、 Constant for peer operation , Before the operators between them 、 After or before you want to add space ; When doing non peer operations , If it's a closely related immediate operator ( Such as －>), There should be no spaces after . explain ： The purpose of writing code in this loose way is to make the code clearer .

     The clarity caused by leaving spaces is relative , therefore , There's no need to leave a space in the already clear statement , If the statement is clear enough, the inside of the parentheses ( That is, after the left bracket and before the right bracket ) No spaces needed , There is no need to add space between multiple brackets , Because in C Parentheses are the clearest sign of the language .

     In long sentences , If you need to add a lot of spaces , Then we should keep the whole clear , And there is no space in the part . Don't leave more than two spaces in a row when you leave spaces for operators .

    （1） comma 、 Semicolons are followed only by spaces .

int_32 a, b, c;

    （2） Comparison operator , Assignment operator "="、 "+=", arithmetic operator "+"、"%", Logical operators "&&"、"&", Bitfield operators "<<"、"^" Space before and after the binocular operator .

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

    （3）"!"、"~"、"++"、"--"、"&"（ Address operators ） There is no space before and after the homonym operator .

*p = 'a'; /*  Content manipulation "*" And the content  */flag = !isEmpty; /*  Non operational "!" And the content  */p = &mem; /*  Address operation "&"  And the content  */i++; /* "++","--" And the content  */

    （4）"->"、"." No spaces before and after .

p->id = pid; /* "->" No spaces before and after the pointer  */

    （5）if、for、while、switch Space should be added between the brackets after and etc , send if And other keywords are more prominent 、 obvious , There is no space between the function name and the parentheses after it , Distinguish from reserved words .

if (a >= b && c > d)

3、 ... and 、 notes

    1、  In general , The effective annotation amount of the source program must be in 20％ above . explain ： The principle of annotation is to contribute to the reading and understanding of the program , Add where you should , Notes should not be too many or too few , The annotation language must be accurate 、 Understandability 、 concise .

    2、 At the beginning of the document , You should give information about document copyright 、 Content abstract 、 Modify the description of items such as history . Please refer to the following description for the specific format . When creating code and every time you update code , The version number must be marked in the history of the file 、 date 、 author 、 Change the description and other items . The format of the version number is two numeric characters and one English alphabetic character . Numeric characters indicate big changes , English characters indicate small modifications . If necessary , You should also make synchronous changes to other annotation contents . Be careful ： The asterisk in the first line of the note is required to be 76 individual , The ending planet number is 1 individual .

/******************************************************************
* Copyright (C), 2010-2011, wuhan xxx System Co., Ltd 
*  file name : main.c
*  Brief description of the content ：
**  Document history ：
*  Version number   date   author   explain 
* 01a 2020-07-29 xxx  Create the file 
* 01b 2020-08-20 xxx  Instead, carriage return can be sent in the string 
* 02a 2020-12-03 xxx  Add file header comments 
*/

    3、 For the function , Before the function is implemented , Sufficient and concise annotation information related to the implementation of the function should be given . The content includes the function introduction of this function , Called variables 、 Constant description , Parameter description , Especially the overall situation 、 Full or static variables （ Be careful with static variables ）, The initial value is required , The expected value after the call is described in detail . Please refer to the following examples for the specific writing format and contents .

     The comments of the following function are standard , Of course , Not limited to this format , However, the above information is recommended to be included .

/****************************************************************
*  Function name : SendToCard()
*  work   can :  Send a command to the card reader , If the card reader goes into sleep , Then wake it up first 
*  transport   Enter into :  Global variables  gaTxCard[] Store the data to be sent 
*  Global variables  gbTxCardLen  Storage length 
*  transport   Out :  nothing 
*/

    4、 Write code and comment , Modify the code and modify the corresponding comments , To ensure the consistency of comments and code . No longer useful comments to delete .

    5、 The content of the notes should be clear 、 clear , The meaning is accurate , Prevent the ambiguity of annotation . explain ： Wrong annotation is not only useless but also harmful . Comments mainly describe what the code does （What）, Or if necessary , Explain why you want to do this （Why）, The annotation is not used to explain how it implements the algorithm （How） Of .

    6、 Avoid using abbreviations... In comments , Especially very abbreviated . explain ： At or before the use of abbreviations , Abbreviations shall be explained as necessary .

    7、 Comments should be close to the code they describe , Comments on the code should be placed above or to the right ( Comment on a single statement ) Adjacent position , Don't put it under , If it is placed on the top, it needs to be separated from the code above by blank lines .

     example 1： Irregular writing

/*  Get replica subsystem index and network indicator  */
<----  Irregular writing , There should be no blank line here 
repssn_ind = ssn_data[index].repssn_index;
repssn_ni = ssn_data[index].ni;

     example 2： Irregular writing

repssn_ind = ssn_data[index].repssn_index;
repssn_ni = ssn_data[index].ni;
/*  Get replica subsystem index and network indicator  */ <----  Irregular writing , You should comment before the statement 

     example 3： A standard way of writing

/*  Get replica subsystem index and network indicator  */
repssn_ind = ssn_data[index].repssn_index;
repssn_ni = ssn_data[index].ni;

     example 4： Irregular writing , It seems that the code is too compact

/* code one comments */
program code one
/* code two comments */ <----  Irregular writing , You need to add a blank line between two pieces of code 
program code two

     example 5： A standard way of writing

/* code one comments */
program code one
/* code two comments */
program code two

    8、 The comments are indented in the same way as described . explain ： It can make the program layout neat , And facilitate the reading and understanding of notes .

     example 1： The following example , The layout is not neat , Reading is a little inconvenient .

void example_fun( void )
{
   
/* code one comments */ <----  Irregular writing , Comments and code should be indented the same 
CodeBlock One
/* code two comments */ <----  Irregular writing , Comments and code should be indented the same 
CodeBlock Two
}

     example 2： Correct layout .

void example_fun( void )
{
   
/* code one comments */
CodeBlock One
/* code two comments */
CodeBlock Two
}

    9、 Definition of variables and branching statements （ Conditional branch 、 Loop statement, etc ） Comments must be written . explain ： These statements are often the key to a specific function of the program , For maintenance personnel , Good comments help to better understand the program , Sometimes even better than looking at design documents .

    10、 about switch Under the sentence case sentence , If you need to deal with one... Because of special circumstances case Step back into the next case Handle , It's time to case Statement processing finished 、 next case Add a clear comment before the statement . explain ： In this way, the intention of the programmer is clear , Effectively prevent the omission of break sentence .

    11、 The annotation format shall be unified as far as possible , It is recommended to use “/* …… */”, because C++ notes “//” Not all C Compiler support .

    12、 The notes should take into account the readability and visual layout of the program , If the language used is middle 、 English has both , It is suggested to use more Chinese , Unless you can express in English fluently and accurately . explain ： The annotation language is not uniform , Affect program readability and appearance layout , For the sake of maintenance personnel , It is recommended to use Chinese .

    13、 The name of identifier should be clear 、 clear , Have a clear meaning , At the same time, use the complete words or abbreviations that you can understand , Avoid misleading .

     explain ： Shorter words can be removed by “ vowel ” Form abbreviations ; A longer word can be abbreviated by the first few letters of the word ; Some words have commonly accepted abbreviations . Example ： The abbreviations of the following words can be basically recognized by everyone .

temp  It can be abbreviated as  tmp;flag  It can be abbreviated as  flg;statistic  It can be abbreviated as  stat;increment  It can be abbreviated as  inc;message  It can be abbreviated as  msg;

    14、 If special conventions or abbreviations are used in naming , There should be notes . explain ： It should be at the beginning of the source file , Abbreviations or conventions used in the document , Especially special abbreviations , Make necessary notes to explain .

    15、 Own unique naming style , Be consistent from beginning to end , You can't change back and forth . explain ： Personal naming style , On the premise of conforming to the naming rules of the project group or product group , Just can use .( That is, only the places not specified in the naming rules can have personal naming style ).

    16、 For variable naming , Do not take a single character （ Such as i、j、k...）, It is suggested that in addition to having specific meaning , It can also indicate its variable type 、 Data type, etc , but i、j、k It is allowed to be a local loop variable . explain ： Variable , Especially local variables , If expressed in a single character , It's easy to type wrong （ Such as i It's written in j）, It doesn't check when compiling , It is possible to spend a lot of error checking time for this small error .

    17、 The naming convention must be consistent with the system style used , And unify in the same project , For example, using UNIX All lowercase underlined style or mixed case , Don't mix case and underline , Used as a special identifier, such as identifying member variables or global variables m_ and g_, It is allowed to add mixed case after it .

     Example ：Add_User Don't allow ,add_user、AddUser、m_AddUser allow .

    18、 Unless necessary , Don't use numbers or strange characters to define identifiers . Example ： Name it as follows , Make people confused .

uint8_t dat01;
void Set00(uint_8 c);
 It should be changed to a meaningful word .uint8_t ucWidth;
void SetParam(uint_8 _ucValue);

    19、 In the same software product , The interface part identifier shall be planned （ Variable 、 structure 、 Functions and constants ） The name of , Prevent compilation 、 There is a conflict when linking . explain ： There should be stricter restrictions on the identifier of the interface part , To prevent conflict . If you can specify the variables and constants of the interface part, add “ modular ” Identification, etc. .

    20、 In addition to compiling switches / Special applications such as header files , Use should be avoided _EXAMPLE_TEST_ The definition of the beginning and end of the underline .

Four 、 Variable 、 structure 、 Constant 、 macro

    1、 In order to facilitate writing and memory , The variable type is redefined as follows ：

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

    2、 Common types of prefixes

    （1） For some common types of variables , Its name shall be prefixed with a prefix indicating its type . Prefixes are in lowercase letters . Please refer to the following table for the use of prefix .

    （2） For several variable type combinations , Prefixes can be superimposed .

    3、 Prefix of variable scope

     In order to clearly identify the scope of variables , Reduce naming conflicts , The prefix indicating the scope of the variable should be added before the prefix of the variable type , And underline between the variable type prefix and the variable scope prefix - separate .

    （1） For global variables （global variable）, Add... Before its name g And variable type symbol prefix .

uint32_t g_ulParaWord;uint8_t g_ucByte;

    （2） For static variables （static variable）, Add... Before its name “s” And variable type symbol prefix .

static uint32_t s_ulParaWord;static uint8_t s_ucByte;

    （3） Local variables such as functions are not prefixed with the scope .

    （4） For constants , When scope and name conflicts may occur , The above rules also apply to constants . Be careful , Although the core part of the constant name is capitalized , But the prefix of the constant is still lowercase , To maintain prefix consistency .

    4、 For structure naming types , Indicates the name of the type , All names are in lowercase letters tag start , After that, the first letter of each English word is capitalized ( Include the first letter of the first word ), Other letters are lowercase , ending _T identification . Words are not separated by underscores , Structure variables are expressed in t start .

/*  Structure naming type name  */
typedef struct tagBillQuery_T
{
   
...
}BillQuery_T;
/*  Structure variable definition  */
BillQuery_T tBillQuery;
 All enumeration definitions are capitalized , ending _E identification .
typedef enum
{
   
KB_F1 = 0, /* F1  Key code  */
KB_F2, /* F2  Key code  */
KB_F3 /* F3  Key code  */
}KEY_CODE_E;

    5、 Constant 、 macro 、 The name of the template should be capitalized . If these names consist of more than one word , Words are separated by underscores . Macro refers to all names defined in macro form , Including constant classes and function classes ; Constants also include constant members in enumerations .

#define LOG_BUF_SIZE 8000

    6、 Bit fields are not recommended .

5、 ... and 、 function

    1、 Naming rules for functions . Each function name prefix must contain the module name , The module name is lowercase , Different from the function name . Such as ：uartReceive( A serial port to receive ) remarks ： For very simple programs , You can leave the module name blank .

    2、 The formal parameters of the function need to be opened on another line , Explain later , The formal parameters are underlined _ start , It has been shown to distinguish from ordinary variables , For functions without empty formal parameters (void) Parentheses follow the function .

/*****************************************************************
*  Function name ：uartConvUartBaud
*  work   can ： Baud rate conversion 
*  transport   Enter into ： _ulBaud :  Baud rate 
*  transport   Out ： nothing 
*  return   return ：uint32-  Baud rate value after conversion 
*/
uint32_t uartConvUartBaud(uint32_t _ulBaud)
{
   
uint32_t ulBaud;
ulBaud = ulBaud * 2; /*  Calculate baud rate  */
......
return ulBaud;
}

    3、 A function does only one function .

    4、 The function name should accurately describe the function of the function . Avoid using meaningless or ambiguous verbs to name functions . Use verb object phrases to name the function that performs an operation . explain ： Avoid using ambiguous verbs such as process、handle And so on , Because these verbs don't specify what to do . Example ： Name the function as follows .

void PrintRecord(uint32_t _RecInd);
int32 InputRecord(void);
uint8_t GetCurrentColor(void);

    5、 Check the validity of all parameter inputs of the function . explain ： If the Convention is for the caller to check the parameter input , You should use assert() And so on , To verify the validity of all parameter inputs .

    6、 Check the validity of all nonparametric inputs of the function , Such as data files 、 Public variables, etc . explain ： There are two main types of function inputs ： One is parameter input ; The other is the global variable 、 Data file input , That is, nonparametric input . Function before using input , Necessary inspections shall be carried out .

    7、 Prevent using function parameters as working variables . explain ： Take the parameters of the function as working variables , It is possible to change the parameter content by mistake , So it's dangerous . For parameters that must be changed , It's best to replace it with a local variable , Finally, assign the content of the local variable to the parameter .

    8、 Avoid designing functions with more than five parameters , Unused parameters are removed from the interface . explain ： Aim to reduce the complexity of interfaces between functions , Complex parameters can be passed using structures .

    9、 When calling a function to fill in parameters , Unnecessary default or forced data type conversions should be minimized . explain ： Because data type conversion is more or less dangerous .

    10、 Avoid using BOOL Parameters . explain ： There are two reasons , The first is BOOL The parameter value is meaningless ,TURE/FALSE The meaning of is very vague , It's hard to know what this parameter means when calling ; The second is BOOL Parameter values are not conducive to expansion . also NULL It's also a meaningless word .

    11、 The return value of the function should be clear 、 clear . Unless necessary , It's best not to use variables that are different from the return value type of a function , The default conversion mode or forced conversion mode of the compilation system is returned as the return value .

    12、 Prevent putting unrelated statements into a function . explain ： Prevent random cohesion within a function or procedure . Random cohesion refers to putting statements with no or weak correlation into the same function or procedure . Random cohesion gives the maintenance of functions or processes 、 Testing and subsequent upgrades are inconvenient , At the same time, it also makes the function or procedure unclear . Use random cohesion function , It is often easy to appear in an application where this function needs to be improved , This improvement is not allowed in another application , And get into trouble .

     In programming , We often encounter using the same code in different functions , Many developers are willing to put this code forward , And form a new function . If these codes are relatively large and complete a function , Then this structure is reasonable , Otherwise, this construction will produce randomly cohesive functions . Example ： The following function is a random cohesion .

void InitVar( void )
{
   
Rect.length = 0;
Rect.width = 0; /*  Initializes the length and width of the rectangle  */
Point.x = 10;
Point.y = 10; /*  initialization “ spot ” Coordinates of  */
}

     The length of the rectangle 、 The width has nothing to do with the coordinates of the point , So the above function is random cohesion . It should be divided into two functions as follows ：

void InitRect( void )
{
   
Rect.length = 0;
Rect.width = 0; /*  Initializes the length and width of the rectangle  */
}
void InitPoint( void )
{
   
Point.x = 10;
Point.y = 10; /*  initialization “ spot ” Coordinates of  */
}

    13、 Reduce recursive calls between functions or functions .

     explain ： Recursive calls, especially between functions （ Such as A->B->C->A）, Affect the comprehensibility of the program ; Recursive calls generally occupy more system resources （ Such as stack space ）; Recursive call has a certain impact on program testing . Therefore, unless it is convenient for the implementation of some algorithms or functions , Unnecessary recursive calls should be reduced . Yanqing Chuanbei community 45 Miss sun Collect and sell waste products and junk for stock speculation Waste sun Recycle

    14、 Improve the structure of functions in the module , Reduce the coupling between functions , And improve the independence of the function and the readability of the code 、 Efficiency and maintainability . When optimizing the function structure , Follow the following principles ：

• It can affect the realization of module functions .

• Carefully examine the module or function error handling and module performance requirements and improve them .

• Improve software structure by decomposing or merging functions .

• Examine the scale of the function , If it is too large, it should be decomposed .

• Reduce the complexity of interfaces between functions .

• Function calls at different levels should have more reasonable fan in 、 Fan out .

• The function function should be predictable .

• Improve function cohesion .（ A single function has the highest cohesion ）

     explain ： The function structure after preliminary division should be improved 、 Optimize , Make it more reasonable .