Code specification extended by C/C ++ Scope

Coding standards are very important, not only because they do not understand each other's code in group cooperation, but also because they may need to maintain their own code in the future, the more readability, the more difficult it is to make some common mistakes.

The specification itself should be a provision, but C/C ++ does not have such a provision in coding. Any code that complies with the C/C ++ syntax is qualified, but the code that complies with the C/C ++ syntax is not necessarily good code. We need to make conventions on some bad behaviors. For example, we should not use local variables as global variables; second, the Code itself may also undergo cooperative development or post-maintenance, so it is necessary for a code that expresses a unified structure clearly. These two points produce code specifications. Therefore, the code specification is a provision and Convention of the company or group for coding.

For the second point, although the value of its existence is necessary, it is applicable in different scenarios and difficult to adjust the public, and there is no scientific basis beyond this. For example, if you are familiar with the Hungary naming method, the variable name contains the type information. Its advantages are self-evident and convenient in the code implementation process, but there are also many disadvantages, for example, the variable itself has a type, and the name contains the type information again. This is a serious redundancy. to modify the variable type, you must modify the variable name, what's more, there is no way to ensure their consistency. In short, the name should be a description of the function, rather than containing type information. Therefore, even if it is better than the Hungarian naming method, the M $ encoding specification will no longer exist. Because the second point cannot be universally applied, I will describe the first point in this essay. It is easy to accept it if there is a scientific basis, but I would like to emphasize that, this is only part of the reason for the existence of the code specification, not all. The second reason is also very important, and the extended specification is indispensable.

There are a lot of notes for writing excellent C/C ++ Code. It is not a short article that can be clearly described. Here I will only talk about the scope and survival of variables, the encoding rules produced based on these rules will conflict with some of the encoding rules you have seen. This is not surprising. For example, many encoding rules specify the maximum number of rows in the function body, the excessive number of rows is mostly due to unclear functional structure, which is not conducive to reading, but is not necessarily the case. If there is a conflict between this provision and the purpose of this provision, in this case, we should discard this rule, so I think it is better to call it a code specification than to call it a code specification.

At this point, the explanation of the meaning of the coding specification is over. To answer the question, for a process-oriented language, the function process is the basic unit, and the function is a complete function implementation process, the same applies to object-oriented systems, but classes represent part of the function process.

Why do we need to separate a process into a function? This is because the functions of this process are complete and clear. After being independent into a function, it also has the ability to reuse it.

Why not separate a process into a function? This is because this process is too coupled with other parts and has no clear functional meaning. Even if it is independent, there is no reusable scenario.

Scope is the scope of action. An object that should take effect in multiple places should not be limited to a small space, and vice versa. Functions, objects, namespaces, and so on can be used here. If none of the above are met, the "{}" should be used for some people's neglect.

The following is a demo of the scope and lifetime of the variable/process:

Functions or types that may be used in many places ()

{};

A function or type ()

{You can use a function object (like a function) to describe the sub-function that is used only in this function or type and has no sub-function for multiple times) replace {};

Variables also need to be used in the following sections; // note that this semicolon {only temporary variables used in this; function segments used only in this function or type and used only once} functions or other types ;};

In this way, the variables and processes are limited to the space they should have. This avoids variable and process contamination in future variables and processes, especially in programs with a large amount of code, in addition, the program's readability is enhanced because different functional codes are differentiated. Of course everything is still readable. Check the following situation:

The first line of a function code; the second line of a function code; the third line of a function code; {only implemented once for this function, the first line of code with no logic relationship with this function; the second line ;...... ; Row n;} The fourth line of a function code; the fifth line of a function code; the sixth line of a function code;

This implementation may be logically clear, but in the code editor, you need to flip pages to see continuous functional code, and the code in {} is too long, like an ugly patch, at this time, it is more appropriate to move the code in {} to an independent sub-function.

The third line of a function code; {call sub-function (parameter s); // up/down {} can not} The fourth line of a function code;

Of course, we also mentioned that if this subfunction is too coupled with this functional code segment, a lot of parameters need to be passed. There is no good way to do this, after all, this is a compromise for readability.

Partial classes (such as classes defined inside functions) have some unpleasant functional limitations. For example, they cannot be used as template parameters. I still don't know why such restrictions exist in c ++, but this is indeed unpleasant.

The short text is complete, and there are many coding specifications. I hope this short text will play the role of turning the text into tokens. Thank you!