The way of coding: the Great power of small functions

A screen of land, sweeping! That's right! Want is short and concise!

Open the project code, everywhere visible hundreds of lines of functions, function body inside switch-case, if, for and other staggered together, a look not to the end of the feeling. Some perverted functions, the length of which may have to be calculated by kilometer. God, give me the courage to look down! First of all, regardless of logic, the length of the first is to frighten the person directly. How do these extra-large functions come about?

More information: http://game-lab.org/archive.html

• Copy a piece of code directly from elsewhere, change it casually, and create a lot of duplicate code.
• The lack of encapsulation, or even the absence of encapsulation, is completely random and arbitrary, resulting in various levels of abstraction of the code mixed together, chaotic.
• The core logic of the exception-handling and special handling of an article is perhaps the beginning, the middle, or the end of a function body.

These extra-long functions have caused us a lot of trouble: Reading code to find bugs is almost impossible, no debugger estimates that the heart of the wall has been, duplication of code caused by the difficulty of modification, missing any place sooner or later is going to be a problem; All levels of code mixed together, reading the code is very laborious, the temporary memory of people is limited , constantly switching between the levels, and a moment to get around the halo.

The most important thing to solve these problems is to keep the function short, the short function reads much better, and the short function implies a better encapsulation. Here are some of the principles that you should follow about functions:

1. Principle: Take a descriptive name

• It's important to take a look at the name of the function intent.
• Long and descriptive names are better than short and confusing (moderate in length, not too long)
• Use a verb or verb + noun phrase

In the code of the Tao: Take a good name has been introduced, the importance of good name, no longer repeat.

2. Principle: Keep the list of parameters concise

• No parameter is best, second one yuan, again two yuan, ternary try to avoid
• Try to avoid identifying parameters
• Working with Parameter objects
• Parameter list
• Avoid mixed output and input, cannot be avoided, output is left, input is in right

BOOLISBOSSNPC ();voidSUMMONNPC (int ID);voidSUMMONNPC (int ID,intType);voidSUMMONNPC (int ID,intStateintType);//Can you remember the order of the parameters? voidShowcurrenteffect (intStateBOOLShow);//Bad!!!voidShowcurrenteffect (intState);//good!!voidHidecurrenteffect (intState);//New Add a function is not too difficult? BOOLNeedweapon (DWORD skillid, byte& failtype);//Bad!!!

3. Principle: Keep function short

• The first rule: to be short
• Second rule: even shorter
• To achieve "one screen of land, sweeping" better

4. Principle: Do only one thing

• function should do only one thing, do it well
• And only do this thing

5. Principle: Each function is at the same level of abstraction

• To make sure that the function does only one thing, the statements in the function are at the same level of abstraction
• Read code from top down

6. Principle: No side effects

• A lie, often a misnomer

7. Principle: operation and inspection to be separated

• Either do something or answer something, but not both.
• Mixed use-the perpetrators of side effects

8. Principle: Use exceptions instead of return error codes

• Operation function return error code minor violation of the principle of isolation of operation and inspection
• It's better to use exceptions in some cases.
• Pull away from Try-cacth
• Error handling is also something that should be encapsulated as a function

BOOLRedisclient::connect (Const STD::string& Host, uint16_t Port) { This->host = host; This->port = port; This->close ();Try{REDIS_CLI =NewRedis::client (host, Port);return true; }Catch(redis::redis_error& e) {redis_cli = NULL;STD::Cerr<<"Error:"<< e.what () <<STD:: Endl;return false; }return false;}

9. Principle: Reduce duplication of code "

Repetition is the root of some evil!!!

10. Principle: Avoid ugly switch-case

• I was born to do n things.
• Multi-State reconstruction is considered when multiple occurrences are necessary

Bad:

bool saveBinary(type, data) {   switch (type) {     case TYPE_OBJECT:           ....          break;     case TYPE_SKILL:           ...          break;     ....   }}bool needSaveBinary(type) {   switch (type) {     case TYPE_OBJECT:          return true;     case TYPE_SKILL:           ...          break;     ....   }}

Class binarymember{Binarymember*Createbytype (type) {switch (type) { CaseType_object:return NewObjectbinarymember; CaseType_skill:return NewSkillbinarymember;....} virtual BOOL Save (Data); virtual BOOL Needsave (Data);}; Class Objectbinarymember: Publicbinarymember{BOOL Save (Data){....} bool Needsave (Data){....}};")))

At last

The above mentioned principles, to understand more deeply, suggest to read the code clean Road, there are many detailed examples, for people who have written for several years of code, will always find some of their own projects often committed problems.

Knowing these principles, we should do this:

When adding a new function:

• It's okay to violate the rules and principles when you start.
• Gradually polished during the development process
• Ensure that the code after submission is neat and tidy

To refactor an existing function, see one that destroys one of the following conditions:

• Lengthy and complex
• There are too many indentation and nesting loops
• Parameter list too long
• The name is free to take
• Repeated more than three times

The way of coding: the Great power of small functions