The following programming style rules are extracted from the classic book "The Elements of Programming Style"
(published by McGraw Hill) by Brian Kernighan and PJ Plauger . Since the original book was published early and mainly aimed at the Fortran language, this article only refines the style elements applicable to today's mainstream programming languages.
——Clive Studio
1. Write clearly-don't be too clever. To
write clearly, don't be smart
2. Say what you mean, simply and directly.
Simple and straightforward to express your meaning
3.
Use library functions whenever feasible. function
4.Avoid too many temporary variables.
Do not use too many temporary variables
5.Write clearly - ". efficiency" don''t sacrifice clarity for
write clearly - not the so-called "efficiency" sacrifice clarity
6.Let the machine do the dirty work.
let the machine do the troublesome thing
7.Replace repetitive expressions by calls to a common function.
the code duplication replaced by a generic function calls
8.Parenthesize to avoid ambiguity.
use parentheses to avoid ambiguity
9.Choose variable names that won't be confused.
Choose the unambiguous variable name
10. Avoid unnecessary branches.
Avoid unnecessary branches
11.If a logical expression is hard to understand, try transforming it.
If the logical expression is not easy to understand, try to do the transformation
. 12.Choose a data representation that makes the program simple
use of the program to more concise data representation form
13.Write first in easy-to-understand pseudo language;. Then translate into whatever language you have to use
the first pseudo understandable Write code; then translate into your language
14. Modularize. Use procedures and functions.
Modularize. Use procedures and functions
15. Avoid gotos completely if you can keep the program readable.
As long as you can guarantee the readability of the program, you can do not goto do not use
16.Don''t patch bad code -. rewrite it
do not patch the bad code - rewrite it wants
17.Write and test a big program in small pieces.
write and test a large program when, chunking
18.Use recursive procedures for recursively-defined data structures.
using a recursive process to handle the data structure defined recursively
19.Test input for plausibility and validity.
Always test input correctness and validity of
20.Make sure input doesn''t violate the limits of the program.
Be sure to enter the program does not exceed the limit
21.Terminate input by end- of-file marker, not by count.
Terminate input by end- of-file character instead of counting
22. Identify bad input; recover if possible.
Identify bad input; and repair as much as possible
23. Make input easy to prepare and output self -explanatory.
Make input easy to construct; make output statement clear
24. Use uniform input formats.
Use uniform input format
25. Make input easy to proofread.
Make input easy to proof
26. Use self-identifying input. Allow defaults. Echo both on output.
Use the input prompt. Accept the default value and display it
27.Make sure all variable are initialized before use .
Make sure that all the variables are initialized before use
28.Don''t stop at one bug.
Do not stop because of a bug before
29.Use debugging compilers.
Open compiler debug options
30.watch out for off-by-one errors.
carefully off-by-one error (http://en.wikipedia.org/wiki/Off-by-one_error)
31.Take Care Branch at the right to Way on equality.
Note branched equivalent comparison
32.Be careful if a loop exits to the same place from the middle and the bottom.
when the cycle out of a plurality of points to be careful
33.Make sure your code does "nothing" gracefully .
If you do nothing, you have to gracefully express the idea
34.Test programs at their boundary values.
boundary value testing procedures
35.Check some answers by hand.
Hand checking some answers
36.10.0 times 0.1 is hardly ever 1.0 .
10.0 times 0.1 is difficult to guarantee that it will always be 1.0
37.7 / 8 is zero while 7.0 / 8.0 is not zero.
7/8 is equal to 0, and 7.0 / 8.0 is not equal to 0
38. Don''t compare floating point numbers solely for equality.
Don't simply judge whether two floating point numbers are equal
39.Make it right before you make it faster .
Do first right, do it fast
40.Make it fail-safe before you make it faster.
First it reliable, faster and let it
41.Make it clear before you make it faster.
Clean the code first, and then make it faster.
42.
Don't sacrifice clarity for small gains in "efficiency." Don't sacrifice a bit of "performance" to neatness
.
Simple optimization allows the compiler to do
44.
Don't strain to re-use code; reorganize instead. Don't over -purchase to reuse the code; reorganize it when you use it next time
.
ensure that special circumstances are indeed special
46.Keep it simple to make it faster.
Keep it simple in order to make it faster
47.Don''t diddle code to make it faster - . find a better algorithm
not Sike code to speed up -Find a better algorithm
48.Instrument your programs. Measure before making “efficiency” changes.
Use tools to analyze your programs. Evaluate before making “performance” improvements
. 49.Make sure comments and code agree
to ensure consistency and code comments
50.Don''t just echo the code with comments - . Make every comment count
not only repeated the comment in the code - so that each of the comments have value
51.Don '' t comment bad code -. rewrite it
do not make comments to the bad code - rewrite it should
52.Use variable names that mean something.
use meaningful variable names
53.Use statement labels that mean something.
use meaningful statement label
54.Format a program to help the reader understand it.
formatting program allows people to read the code easier to understand
55.Document your data layouts.
Write document data layout
56.Don''t over-comment.
Do not overdo comment
————————————————
Copyright Statement: This article is an original article by CSDN blogger "Lindsay", following the CC 4.0 BY-SA copyright agreement, please attach the original source link and this statement for reprint .
Original link: https://blog.csdn.net/xuying123456/article/details/7275703
