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 to use and easy to master these two concepts 5 Productivity Can Be Measured in the number of keystrokes 5 productivity can be measured by clicking the number of 6 if You 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 use C / C to express 6.1 Do The Comments First 6.1 to write Note 7 Read Code 7 Read Code 7.1 There's no room for prima donnas in 8 complex issues a contemporary programming shop 8 decompose complex problems into smaller tasks into multiple smaller tasks 9 Use the whole language (Use the appropriate tool for the job) 10 a problem must be thought through before it can be before solved 10 to solve the problem should be well thought out 11 computer programming is a service industry 11 computer programming services industry 12 Involve users in the development process 12 development process should be user participation 13 the customer is always right 13 customer is always right 14 Small is Beautiful (BIG == SLOW) 14 small is US (large == slow) general development problem 15 first, do no harm 15 first, don't harm 16 Edit your code 16 Edit your code 17 a Program Must Be Written At Least TWICE 17 A program should wait for at least twice 18 You can't Measure Productivity by Volume 18 Cannot measure productivity 19 You Can't Program in ISOLATION 19 Programming Cannot isolate 20 GoOF Off 20 Programming too serious 21 Write Code With maintenance Programmer is you 21 When writing code, you should always think about maintaining, assuming yourself is the maintenance person 21.1 Efficiency Is offen a Bugaboo 21.1 pursuit of efficiency often results in formatting other issues And Document 22 Uncommeted Code Has No Value 22 No Note No Code No Value 23 Put The Code and The Documentation in The Same Place 23 Place the code and document 24 Comments Should Be Sentences 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 'by spelling
t restate the obvious 26 do not comment the obvious thing 27 A comment should provide only information needed for maintenance 27 comments should only be helpful to maintain content 28 Comments should be in blocks 28 using block comments 29 Comments should align vertically 29 Comments should Vertical alignment 30 Use neat columns 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 Do not write between function name and first curly brackets 32 mark THE ENDS OF long Compound Statements with Something Reasonable 32 Makes Marking Note 33 Put Only One Statement Per Line 33 Put Argument Names In Function Prototypes 34 Function Prototype Show parameters Name 35 USE A damage red acidate? Form to split up long expressions36 a Subroutine SHOULD FIT ON A Screen 36 One Subfounded length should be in one screen 37 All code sales be Printable 37 All code should be printed 38 USE Lines Of Dashes for Visual Secly, Between Subroutines 38 Using a Metal Coned Springs 39 White Space Is One of the Most Effective Comments 39 Blank is the best annotation One 40 Use Four-space Indents 40 Use four spaces to make shrinkage Tour 41 Indent Statements Associated WITH A FLOW-Control Statement 41 Net into all statements related to a process control statement 41.1.comMents Should B e at the same indent level as the surrounding code 41.1 Notes code should be retracted together with the corresponding 42 Align braces vertically at the outer level 42 than one line is present under a flow-control in the vertically aligned outer braces 43 Use braces when more STATEMENT 43 In the process control statement, if there is more statements, you should use the margin name and identifier 44 name 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 should be ENTIRELY_CAPITALIZED 45 macro name should be of the form: ENTIRELY_CAPITALIZED 45.1 Do not capitalize members of an enum 45.1 Do not enumerated type member capitalized 45.2 Do not capitalize type names created with a typedef 45.2 do not use typedef to define the type of capital 46 avoid the ANSI C name space 46 to avoid ANSI C namespace 47 avoid the Microsoft name space 47 to avoid Microsoft namespace 48 avoid unnecessary symbols 48 to avoid unnecessary symbols 49 symbolic constants for Boolean values are rarely necessary 49 symbolic boolean constants is substantially free Using general programming principles 50 don't confuse hardiarity with readability 50 Be familiar with code with code readability is two things 51 A Function Should Do Only One 51 A function should only complete one thing 52 Too Many Levels of Abstract or Encapsulation Are AS Bad as Too Few 52 too much or too little abstract or package hierarchy 53 A Function SHOULD BE CALED More Than ONCE, But? Br> 53 A function should be called 53.1 Code Used More Than Once Should Be Put INTO A FUNCTION 53.1 Codes in more than one point should become a function 54 a Function SHOULD HAVE ONE ONE EXIT POINT 54 A function should have only one exit point 54.1 Always Put a return at The Outer Level 54.1 Always put one in the outer layer Return 55 Avoid Duplication of Effort 55 Avoiding Between Ten Things 56 Don't Corrupt The G lobal name space 56 do not pollute the global namespace 56.1 Avoid global symbols 56.1 avoid global symbol 56.2 Never require initialization of a global variable to call a function 56.2 call to the function should not depend on whether the 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 normal function, if a variable is independent of the measurement, it should be a local static variable 56.3 Use instance counts in place of initialization functions 56.3 In the initialization function Counting Example 56.4 if An if Ends in return, Don't Use else 56.4 If there is Return in the IF statement,
