Design Process 1 The essence of programming is: no accident, minimize coupling, maximizing internal gathering
2 Eliminate complexity This devil (Part 1)
2.1 Do not resolve problems that do not exist 2.2 Solve a problem without solving a type of problem
3 a User Interface Should Not Look Like a Computer Program (The Transparency Princi)
3 User interface does not seem to be like a computer program (transparent principle) 4 don't confuse ease of learning with ease of use
4 Do not confuse easy use and easy to master these two concepts 5 Productivity Can Be Measured in the number of keystrokes
5 productivity can be measured by hitting the number of 6 if can't Say IT IN ENGLISH, You CAN't Say IT IN C / C
6 If you can't express it in natural language, you can't express 6.1 do the comments first by C / C .
6.1 write a message 1 Read Code
7 Read the code
7.1 There's no room for primma donnas in a contemporary programming shop
8 Decompose Complex Problems Into Smaller Tasks
8 Decompose complex problems into multiple small tasks 9 Use the appropriate Tool for the Job
10 Resolve problems should be thoughtwated 11 Computer Programming IS a Service INDUSTRY
11 Computer programming is the service industry 12 Involve Users in the development process Process
12 Development process should have users to participate in 13 The Customer Is Always Right
13 The customer is always the correct 14 small is beautiful. (Big == Slow)
14 small is beautiful (big == slow)
General development problem 15 first, do no harm
15 first, don't be harmful 16 Edit Your Code
16 Edit Your Code 17 a Program Must Be Written At Least TWICE
17 A program should write at least twice 18 You can't Measure Producture by Volume
18 Cannot use code measurement productivity 19 You can't Program in isolation
19 Programming can't be isolated with the world 20 goof off
20 Don't put the program too serious 21 Write Code with maintenance in Mind 梩 HE Maintenance Programmer is you
21 When writing code, you should always think about maintaining, assume you who yourself is the maintor.
21.1 Efficiency Is Offen A Bugaboo
21.1 Pursuit of efficiency often leads to other problems
Formatting and Document 22 Uncommented Code Has No Value
22 No Note Code No Value 23 Put The Code and The Documentation in The Same Place
23 Place the code and document 24 Comments shop besences
24 Note Should be a complete sentence 25 Run Your Code Through a spelling checker
25 Your code should be able to check 26 a comment shopn't restate the obvious26 Do not comment Obvious things 27 A Comment Should PROVIDE INFORMATION NEEDED for Maintenance
27 Note You should only provide helpful content for maintenance 28 Comments SHOULD BE in Blocks
28 Using Blocks 29 Comments Should Align Vertically
29 Note Should be aligned vertically 30 Use Neat Column As Much as Possible
30 code should be as close as possible 31 don't put comments between the function name and the open brace
31 Don't write a comment between function name and first curly bracket 32 Mark the ends of long compound statements with something realment
32 Making marker Note 33 Put Only One Statement Per Line after longer code block
33 Each row only writes a statement 34 Put Argument Names in Function Prototypes
34 Function prototype should be written on parameter name 35 USE A damage red acidate? Form to split up long expibilitys36 a subroutine shop Fit on a screen
36 One child function should be within one screen 37 All Code Should Be Printable
37 All code should be printed 38 Use Lines of Dashes for Visual Separation Between Subroutines
38 Using a Metal Connector to Isolation Sub Function Code 39 White Space Is One of the Most Effective Comments
39 Blank is one of the best comments 40 Use Four-Space Indents
40 Use four spaces to make indentation 41 indent Statements Associated with a flow-control statin
41 indent all statements related to a process control statement
41.1.com in the Same Indent Level As The Surrounding Code
41.1 Note Should be indented with its corresponding code
42 Align Braces Vertically At the Outer Level
42 In Outer Vertical Algebra Brand 43 Use Braces WHEN More Than Line Is Present Under A Flow-Control Statement
43 In the process control statement, if there are more statements, it should be used
Name and Identifies 44 Names SHOULD BE Common English Words, Descriptive of What The Function, Argument, ORVARIABLE DOES
44 names should be ordinary English words, used to describe this function, parameter or variable
44.1.do Not CLUTTER NAMES with GIBBERISH
44.1 Don't let the name (meaningless, deeper, not appropriate)
45 macro names shop be entirely_capitalized
45 macro names should be shaped like: entirely_capitalized
45.1 Do Not Capitalize MEMBERS OF An ENUM
45.1 Do not write an enumerated type member capital 45.2 Do Not Capitalize Type Names created with a typedef45.2 Do not write types defined by typedef
46 Avoid The Ansi C Name Space
46 Avoid ANSI C Name Space 47 Avoid The Microsoft Name Space
47 Avoid Microsoft Name Space 48 Avoid Unnecessary Symbols
48 Avoid unnecessary symbols 49 Symbolic Constants for Boolean Values Are Rarely Necessary
49 Boolean symbol constant basically useless
General Programming Principle 50 Don't Confuse Familiarity with Readability
50 Be familiar with code and code is good, two things 51 A Function SHOULD Do IONE Thing
51 A function should only complete one thing 52 Too Many Levels of Abstract Or Encapsulation Are As Bad as Too Few
52 Excessive or too little abstract or package hierarchy 53 a Function SHOULD BE CALED More Tan Once, But? Br>
53 A function should be called multiple
53.1 Code Used More Than Once Should Be Put Into A Function
53.1 The code used in more than one place should become a function
54 a Function Should Have ONLY One Exit Point
54 A function should only have one exit point
54.1 Always Put A Return At The Outer Level
54.1 Always put a Return in the outer layer
55 Avoid Duplication of Effort
55 Avoiding Two Courses 56 Don't Corrupt The Global Name Space
56 Do not pollute the global name space
56.1 Avoid Global Symbols
56.1 Avoid global symbols 56.2 Never Require Initialization of A Global Variable To Call A Function
56.2 The call to the function should not depend on whether global variable is initialized
56.2.1 Make Locals Static in Recursive Functions If The Value Doesn't Span A Recursive Call
56.2.1 In the final return function, if a variable is independent of the timing, it should be a local static variable.
56.3 Use Instance Counts in Place of Initization functions
56.3 Using an example in the initialization function 56.4 if an esturn, don't use else
56.4 If there is Return in the IF statement, don't write ELSE
57 Put The Shortest Clause of an IF / Else On Top
57 shortest IF / Else clause in the top 58 try to move ire ire time Time Time
58 Try to make an error in the run to compile time 59 USE C Function Pointers As SELECTORS
59 Using C Function Pointer as a selector 60 Avoid Do / While LOOPS
60 Avoid Do / While Cycle
60.1 Never USE A Do / While for a Forever Loop
60.1 Do not use DO / While to achieve an infinite loop
61 counting loops shop count Down if Possible61 cyclic counting should be from big to small 62 don't do the same thing in Two Ways At the Same Time
62 Don't use different methods at the same time 63 Use for if any two of an initialization, test, or increment ispent
63 If you initialize, test, the increment is two, you should use for statement 64 if it doesn't Appear in the test, IT Shouldn't Appear in Other Parts of for Statement
64 There is no variable that appears in the test portion of the for statement, nor should it appear in other two parts 65 Assume That Things Will Go Wrong
65 Always assume things to have an error 66 Computers Do Not Know Mathematics
66 computer does not understand mathematics
66.1 EXPECT The IMPOSSIBLE
66.1 Always impossible 66.2 Always Check Error-Return Codes
66.2 Checking the error Returns code
67 Avoid Explicit Temporary Variables
67 Avoid explicit temporary variables 68 NO MAGIC NUMBERS
68 Do not appear pure numbers 69 make no assumptions about sizes
69 Don't make a assumption 70 BEWARE of CASTS (C Issues)
70 pairs of type conversion to be careful (C language problem) 71 Handle Special Cases Directly
71 Treatment of special circumstances 72 don't try to make lint happy
72 Don't try to make Lint Do not report a problem 73 Put Memory Allocation and DEACATION CODE IN THE SAME PLACE
73 Allocate memory and release memory should be together 74 Heap Memory IS Expensive
74 Pile of memory is expensive 75 Test Routines SHOULD NOT BE Intective
75 Test Process should not be interactive 76 An Error Message SHOULD TELL TELL TELL TELL TELL TELL TELL TELL TELL
76 Error message should tell the user what is the correct 77 Don't Print Error Messages if An error is Recoverable
77 If a mistake is recoverable, do not print an error message 78 don't use system-dependent functions for error messages
78 Do not use system-related functions in error messages
