Shulou(Shulou.com)06/01 Report--

Today, the editor will share with you the relevant knowledge of what the scope coding specification is in the C language. The content is detailed and the logic is clear. I believe most people still know too much about this knowledge, so share this article for your reference. I hope you can get something after reading this article, let's take a look at it.

The specification itself should be a stipulation, but there is no such stipulation in coding. The code that conforms to the syntax is qualified, but the code that conforms to the syntax is not necessarily good code. Some bad behaviors should be stipulated, for example, locally used variables should not be used as global variables. This is one of them. Second, the code itself may also be co-developed or later maintained, so a code that expresses a unified structure and is clear is necessary. The coding specification is produced from these two points, so the coding specification is a rule and convention for the coding of the company or group.

For the second point, although the value of its existence is necessary, but the applicable occasions are different, and it is difficult to tune, lack of scientific basis. For example, the familiar Hungarian nomenclature contains type information in the variable name, and its advantages are self-evident. It is very convenient in the process of code implementation, but there are also many disadvantages, such as the variable itself has a type. Again, the name contains type information, which is a serious redundancy. To modify the variable type, it is necessary to modify the variable name. More importantly, there is no way to ensure their consistency. In short, the name should be a description of the function and should not contain type information.

So even if it is better than the Hungarian nomenclature, it will no longer exist in the coding specification of M$. Because the second point is not universally applicable, I will talk about the * point in this short article, which is easy to accept if there is a scientific basis, but I would like to emphasize that this point is only part of the reason for the existence of the coding specification. Not all, the second reason is also very important, and the resulting specifications are indispensable.

There are a lot of points to pay attention to if you want to write an excellent Cmax code, which can not be described clearly in a short passage. I only talk about the scope and lifetime of variables here. The coding specifications generated according to these rules will contradict some of the coding specifications you have seen before, which is not surprising. For example, many coding specifications specify the number of lines of the function body. In most cases, the excessive number of lines is because the function is not structured, which is not good for reading, but this is not necessarily the case. if there is a conflict between this provision and the purpose of this provision, then it should be abandoned at this time. so I think it's better to call it a coding recommendation than a coding specification.

This is the end of the explanation of the meaning of the coding specification, and let's get to the point. for a process-oriented language, the function process is its basic unit, the function is a fully functional implementation process, and so is the object-oriented. it's just that the class replaces part of the function process.

Why separate a procedure into a function? This is because the function of this process is complete and clear, and it also has the ability of reuse after being independent into a function.

Why not separate a procedure into a function? This is because this process is too coupled with other parts, there is no clear functional meaning, even if independent, there is no reusable occasion.

Scope is the scope that works, and an object that should work in many places should not be limited to a small space, and vice versa. Functions, objects, namespaces, etc., can be used here. If none of the above matches, then the "{}" ignored by some people should be used.

The following is a demonstration of the scope and lifetime of a variable / procedure:

A function or type () {} that may be used in many places; a function or type () {a subfunction or subtype () / C++ that is only used in this function or type and used many times does not have a subfunction, you can use function objects (mock functions) instead of {}; variables that need to be used in the next section / / Note the semicolon {temporary variables used only in this {}; function segments} functions or other parts of the type that are only used and used only once in this function or type;}

In this way, variables and processes are limited to their due space, which avoids the pollution of variables and processes to future variables and processes, especially in programs with a large amount of code, and because {} distinguishes different functional codes, makes the program more readable. Of course, everything is still readable, look at the following situation:

The * line of a function code; the second line of a function code; the third line of a function code; {A line that is implemented only once for this function and is not logically related to this function; the second line;. ; line n; the fourth line of a function code; the fifth line of a function code; the sixth line of a function code The implementation may be logical, but it takes a lot of trouble to scroll up and down the page in the code editor to see the continuous functional code, and the code in {} is too long, like an ugly patch, so it is more appropriate to move the code in {} to an independent subfunction, which becomes the third line of a functional code; {call subfunction (parameter s) / / the {} above and below may not} the fourth line of a function code.

Of course, it was also mentioned earlier that if the coupling between this subfunction and this functional code segment is too strong, it will need to pass a lot of parameters, which is not a good way, because after all, this is a compromise for readability.

Local classes (such as those defined inside functions) have some unpleasant functional limitations, such as not being able to serve as template parameters. I don't know why there is such a restriction in C++, but this is really unpleasant.

These are all the contents of the article "what is the scope coding specification in C language?" Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.