Good source program, good software

Good source program, good software

Some may think: as long as the program runs well, no matter what the original program is compiled. But this is definitely not the case. The software is not completed in one time. It is necessary to manage the changes and extensions. Therefore, the original program should be easy to understand and manage.

In this way, the first is for the convenience of software developers, and the second will also affect the performance of the software. Management of inconvenient programs will not make good software.

I hope I can learn good programming habits through this article. To understand the content of this article, you must understand at least one development tool language. The examples here illustrate the C language, but you do not need to worry about the C language. The principle rather than the specific language is described here.

1. The statement should end completely --- (semicolon ;)

One of the common mistakes of programmers is that they forget to add a semicolon after the statement ends. Such problems are hard to find, and sometimes programmers are overwhelmed. When programming, always pay attention to whether each statement ends with a semicolon, although not all languages end with a semicolon. The following is an example of forgetting to click a semicolon.

Int main (void)
{
/* No semicolon, resulting in a problem */
Printf ("Hello world! /N ")
Return (0 );
}

Many people make such mistakes. It is not difficult to find such a problem in less than a few programs, but what about more than 1000 programs? It is not easy to find the statements that forget to write a semicolon. Remember, to end a statement, you must write a semicolon, just as if you had ended an article and ended it.

Another mistake about the semicolon is that the semicolon should not be written when it is written. Experienced programmers may find the following example funny, but I have seen many such mistakes.

/* Do not write a semicolon after main */
Int main (INT argc, char * argv []);
{
Printf ("Hello World ");
Return (0 );
}

The function or method should not be followed by a semicolon.

2. Suitable for spaces and Tab keys

The C language does not distinguish spaces, so the program can be written without spaces, but such a program will be a "very difficult" program that no one can understand. See the following example:

If (x = 0) {a = B = c = d = max; X ++ ;}

Writing in this way may save space, but not only others, but programming will be hard to understand. The program should be easy to understand!

If (x = 0)
{
A = B = c = d = max;
X ++;
}

Isn't it clear to write like this? The program can be easily understood only by spaces.

3. Use braces and cutting methods

Every programmer has his or her own habit of using braces ({}) and modifying rows. In this way, chaos occurs when the program is handed over to others for further work. For example:

Int main ()
{
Int x = 1;
Int y = 10;
While (x <Y ){
Printf ("value of X is % d/N", X );
X ++;
}
}

Some programmers write braces like this:

Int main ()
{
Int x = 1;
Int y = 10;
While (x <Y)
{
Printf ("value of X is % d/N", X );
X ++;
}
}

I like the second method. Because the beginning and end of a statement are obvious. We cannot require every programmer to use a certain method for programming, but a program must be unified. Also, the habit of thinking about others' programming may be different from yours when you look at others' programming.
4. Do not use the if statement in disorder

Some people like to use the "if" statement as follows:

If (A = 0)
{
A ++;
Return ();
}

If (A = 1)
{
A + = 5;
Return ();
}

If (A = 2)
{
A + = 10;
Return ();
}

If (A = 3)
{
A + = 20;
Return ();
}

If (A = 4)
Exit (1 );

Is there any better way than this? Else if statement? No. A good way is to use the "Switch-case" statement to write a simple program:

Switch ()
{
Case 0: A ++;
Return ();

Case 1: A + = 5;
Return ();

Case 2: A + = 10;
Return ();

Case 3: A + = 20;
Return ();

Default: exit (1 );
}

If there is no value consistent with A, the job defined in default will be executed, and the above example is to end the execution.

5. Use a program to cut the block)

Many people often use programs to cut it out. Using more than three programs is hard to understand. See the following example:

Int A = 10;
Int B = 20;
Int c = 30;
Int d = 40;

If (A = 10)
{
A = a + D;
If (B = 20)
{
B = B +;
If (C! = B)
{
C = C + 1;
If (D> (a + B ))
Printf ("made it all the way to the bottom! /N ");
}
}
}

This may be an exaggeration, but many people do. So how to write better? One way is to use a function to separate the write:

Void next (int A, int B, int C, int D)
{
If (C! = B)
{
C = C + 1;
If (D> (a + B ))
Printf ("made it all the way to the bottom! /N ");
}
}

Int main ()
{
Int A = 10;
Int B = 20;
Int c = 30;
Int d = 40;

If (A = 10)
{
A = a + D;
If (B = 20)
{
B = B +;
Next (A, B, C, D );
}
}
Return (0 );
}

Writing in this way may increase the workload, but the program is structured and easy to understand. If the function is better done, it can be used elsewhere.

6. write comments

Develop the habit of writing comments. In particular, programs or variables that are hard to understand must be commented out. A month later, you may need to read the comment yourself.

Int x = 100;
Int y= 1000;

If (x <Y)
A = 0;
Else
A = 1;

What does the above program mean? It is hard to understand what the variables X, Y, and a are. Let's mark a comment for it:

/*
* Programs for profit and loss detection
*/

Int x = 100;
/* X indicates the total amount of books sold */
Int y= 1000
/* Y is the cost of books */
Int;
/* Confirm profit */

/* Compare X and Y :*/
If (x <Y)
/* 1 indicates the loss */
A = 1;
Else
/* 0 indicates profit */
A = 0;

In this way, people who do not understand the C language can understand what each statement means and what each variable refers. It is a good habit to write comments, but do not comment everything. Annotations are for better understanding, not for long-edited articles.

Int profit = 1;
/* Profit equals 1 ?? */
Int loss = 0;
/* The loss is equal to 0 ?? */

/* If the profit is equal to 1 */
If (profit = 1)
/* Print out "profitable "?? */
Printf ("We made a profit! /N ");
/* If not */
Else
/* Print "we are losing money "*/
Printf ("We made a loss! /N ");

This annotation is a waste of time. It is usually a variable or variable value that needs to be commented out, as well as the purpose of the program. It is also required when a function or procedule is used.
7. Naming should be reasonable

Programs, variables, procedure, and structure names must be associated with their content. Do not name variables like "X", "Y", "Z"

Maybe you will say that I used X, Y, and so on in the above example, but the reason why I did this is that he did not involve other programs. When developing software, of course, I will use meaningful variable names. See the following example:

Void X (int A, int B)
{
Int Z;
Z = A + B;
Printf ("Z is % d/N", Z );
}

Here, we can know what X does, but what it means. The same is true for a, B, and Z. Let's take a look at it later:

Void sum_of_ages (INT jacks_age, int jills_age)
{
Int total_age;
Total_age = jacks_age + jills_age;
Print ("total_age is % d/N", total_age );
}

Although there is no comment, it is easy to see what to do. You can also name it without comments.

8. Confirm Buffer

Always check the size of the specified arrangement or variable to avoid data confusion or system problems. See the following example of user input data: Char City [10];
/* Lists the city names */

Printf ("enter a city name :");
Scanf ("% s", city );
Printf ("city is % s/n", city );

Here, the city name is set to 10 characters (English text. What if you enter a city name with more than 10 words? It can be said that the program fails or overwrites the data in the buffer. In any case, do not take risks. Check the length of the text:

Char City [10];
/* Lists the city names */

Printf ("enter a city name :");
Fgets (city, sizeof (city), stdin );
Printf ("city is % s/n", city );

The above modified program is: if the user enters a city name with more than 10 words, only accept the length acceptable to the buffer, otherwise it will not accept.

9. Never trust users

This is an important rule. Do not trust the people who will use your software, do not think that the users will operate as you want, but think of them as people who specifically discover program problems. For example, the above program confirms the text length for those users who enter a longer city name.

Developers who need explicit data formats like C must remember to confirm whether the input data format is consistent with the program data format. Otherwise, problems may occur.

Sharpen the knife without mistake

The above programming habits are for your convenience. Make more preparations (Analysis and Design) before programming ). Although it is a little troublesome, but in order to compile a program that is easy to understand and tidy up, do not be reluctant to take the time to prepare, otherwise it will take more time to modify and expand your program.