Terms 32: Delay the definition of variables as much as possible
Yes, we agree that the variables in the C language should be placed in the module head definition; but in C , there is no need to cancel this practice, it is not necessary, unnatural, and expensive.
do you remember? If a variable with a type of constructor and a destructuring function is defined, when the program is running to the variable definition, it is necessary to face the overhead of the structure; when the variable leaves its life space, it is necessary to undertake the overhead of the designer. This means that the definition of useless variables will inevitably accompany unnecessary overhead, so as long as it is possible, it is necessary to avoid this.
As I know, your programming method is elegant without losing sophistication. So you may think that you will never define a useless variable, so the recommendations of this Terms are not applicable to your rigorous and compact programming style. But don't worry, look at the following function: When the password is long enough, it returns the encryption version of the password; when the password is too short, the function throws the abnormality of the Logic_Error type (the logic_error type is defined in the C standard library, see Terms 49) :
// This function defines the variable "Encrypted" string encryptpassword (const string & password) {string encrypted;
IF (Password.Length () Perform the necessary operations, put the encryption version of the password into Encrypted; Return encrypted;} Object Encrypted is not completely useless in the function, but if there is an abnormality, it is useless. However, even if ENCRYPASSWORD throws an exception (see Terms M15), the program also assumes the overhead of Encrypted constructors and destructors. So, it is best to define encrypted to define it when you really need it: // This function delays the definition of Encrypted, // until you really need to define String EncryptPassword (Password.Length () {throw logic_error ("password is too short");} String encrypted; Perform the necessary operations, put the encryption version of the password into Encrypted; Return encrypted;} This code is not so strict, because there is no initialization parameter when Encrypted is defined. This will result in its default constructor being called. In most cases, one thing to do to an object is what value gives it, which usually uses assignments. Terms 12 illustrate why "Default constructing an object then assigns it" to initialize this object than "The value of the truly wants" is much lower. This argument applies here. For example, suppose the most difficult part of EncryptPassword is performed in this function: Void Encrypt (String & S); // S is encrypted here So EncryptPassword can be implemented like this (of course, it is not the best implementation): // This function delays encrypted definition, // is defined until it is needed, but it is also very low-efficiency string encryptpassword (const string & password) {... //, check the length string encrypted; // default constructed encrypted encrypted = Password; // Assign Encrypt (Encrypted) to Encrypted; Return Encrypted;} A better way is to initialize Encrypted with password, which bypasses unnecessary calls for default constructor: // Define and initialize the best way to encrypted String Encryptpassword (const string & password) {... // check the length String Encrypted (Password); // Defines and initialized by copy constructor Encrypt (Encrypted); Return Encrypted;} This code expounds the true meaning of "as possible" in the title of this Territor. You should not only post the definition of the variable to the time you have to use it, but you should be delayed as possible to provide an initialization parameter. In this way, not only avoid the unnecessary objects to construct and sect, but also avoid meaningless calls to the default constructor. Moreover, in the case where the variable is initialized, the use of the variable itself is self-cleaned, so the variables here are beneficial to indicate the meaning of the variable. Remember the practice in the C language? It is best to have a short comment next to each variable to indicate what this variable will use. Now, a suitable name (see Terms 28), combine meaningful initialization parameters, you can implement each programmer's dream: eliminate unnecessary annotations itself through a reliable variable itself. Delaying variable definitions can improve the efficiency of the program, enhance the process of the program, and reduce the annotation of variable meanings. It seems that the definition of the variables of the open module is noted.
