Writing Clean Code

Recently spent some time reading this book, the title istheWriting Clean Code–Microsoft Techniques for developing bug-free C Programs"
here is the main summary of some of the programming ideas inside.
add NULL to an empty statement
When you need to use an empty statement, it is best to write null, such as:

 
   
  

  
    
   
if (music_on())
  
    
   
 NULL;
  
    
   
else
  
    
   
 turn_it_on();
 
   
  

problem with the same parameter type
If the type of two arguments in the function is the same, the problem occurs if the error replaces the order of the arguments when the user calls the function.
Like what

 
   
  

  
    
   
bool are_you_that_guy(int id, int year)
 
   
  

If you can modify one of the types here (for example, to change int to short), the compiler warns you when you write the inverse argument, which avoids the problem.
Code Error Checking
Do not rely on testers to help you identify problems in the code, when writing code to do as much as possible unit speed, to ensure that every unit is not a problem, it seems to be a lot of effort, and will delay progress, but for the last is a great benefit, you know programmers generally spend most of the time to solve the bug, It's a good thing to let Bugs get strangled in the cradle. But it's not the same for programmers who maintain a bunch of huge code.
When you write the code, use Assert, do a debug switch, when release to the customer, the assert is removed. The role of assert is to expose a real error (such as passing a null pointer to a function), asserting that the actual usage is incorrect, rather than a generic error (such as memory allocation failure, which returns null).
Using tools such as lint can also help you analyze problems in your code. (I didn't use it, try it in the back). In fact, using the wall switch of GCC can get a lot of warning, and then remove some problems.
You can write two different versions of the code to check for errors, one is less efficient, the code for validation, and the other is the code that needs to be release.
It may not be possible for a lot of people to keep track of the code and unit test every situation.
Code Style
Do not let the function return the result and return the error code. The most expressive of all is

 
   
  

  
    
   
int getchar ( void );
 
   
  

Returns an int when it is correct. GetChar why an int is returned instead of a char, which is incredibly true, the int value is actually prepared for the wrong situation, which is the EOF
definition of EOF:It is a macro definition of typeintthat expands into a negative integral constant expression (generally,-1).

here it can be thought of as -1.so it's easy to go wrong. It's good practice to pass data into the parentheses of the function, and assign the function call to the return value, such as:

 
   
  

  
    
   
int getchar(char *char_val);
 
   
  

don't write weird code.
Good code should be maintainable, because there will always be newbies to maintain your code. When you squeeze all the code into one line, such as this type:

 
   
  

  
    
   
plan = planA ? (planB ? planC : planX) : (planD ? planE : planY)
 
   
  

This can be confusing to people. They should be split into if and else statements, and if and else nested too deep, then it's your own design problem. Instead of using names like variables such as Plana and PLANB, it's easy to confuse.

don't change people's code .
This clause seems unreasonable, and sometimes it can be a problem, unless you have done a thorough test.
such as the

 
   
  

  
    
   
int identity;
  
    
   
identity = whois(tanhangbo);
  
    
   
TELL(identity );
 
   
  

Change into

 
   
  

  
    
   
TELL(whois(tanhangbo))
 
   
  

if the definition of Tell is

 
   
  

  
    
   
#define TELL(x) (x + x*2)
 
   
  

then Whois will be called two times.



knowing and wrong can change
Of course, the most important criterion, the same mistake do not commit two times.


--------------------need to pay attention to a lot of things, this is just a part of the mention. Write code when you want to think more, how to write good code, easy to maintain, fewer bugs. This book is still good, recommend to have a look.


To know the contents of the note to the blog Park is still a bit of a problem, where the code is formatted well and then sent up, the format is gone. But it's good to be able to easily send it.





From for notes (Wiz)

Writing Clean Code