Quotation from the book “The elements of programming style” of Kernighan and Plauger

  1. Write clearly – don’t be too clever

  2. Say what you mean, simply and directly

  3. Use library functions whenever feasible

  4. Avoid too many temporary variables

  5. Write clearly – don’ sacrifice clarity for “efficiency”

  6. Let the machine do the dirty work

  7. Replace repetitive expression by calls to common functions

  8. Parenthesize to avoid ambiguity.

  9. Choose variable names that won’t be confused

  10. Avoid unnecessary branches

  11. If a logical expression is hard to understand, try transforming it

  12. Choose a data representation that makes the program simple

  13. Write first and easy-to-understand pseudo language; then translate into whatever language you have to use.

  14. Modularize. Use procedures and functions

  15. Avois gotos completely if you can keep the program readable

  16. DOn’t patch bad code – rewrite it

  17. Write and test a big program in small pieces

  18. Use recursive procedures for recursively-defines data structures

  19. Test input for plausibility and validity

  20. Make sure input doesn’t violate the limits of the programs

  21. Terminate input by end-of-file marker, not by count

  22. Identify bad input; recover of possible

  23. Make input easy to prepare and output self-explanatory

  24. Use uniform input formats

  25. Make input easy to proofread

  26. Use self-identifying input. Allow defautlt. Echo both on output

  27. Make sure all variables are initialized before use

  28. Don’t stop at one bug

  29. Use debugging compiler

  30. Watch out of off-by-one errors

  31. Take care to branch the right way on equality

  32. Be careful if a loop exits to the same place from the middle and the bottom

  33. Make sure your code does “nothing” gracefully

  34. Test programs at their boundary values

  35. Check some answers by hand

  36. 10.0 times 0.1 is hardly ever 1.0

  37. 7/8 is zero while 7.0/8.0 is not zero

  38. Don’t compare floating point numbers solely for equality

  39. Make it right before you make it faster

  40. Make it false-safe before you make it faster

  41. Make it clear before you make it faster

  42. Don’t sacrifice clarity for small gains in “efficiency”

  43. Let your compiler do the simple optimization

  44. Don’t strain to re-use code; reorganize instead

  45. Make sure special cases are truly special

  46. Keep it simple to mak eit faster

  47. Don’t diddle code to make it faster – find a better algorithm

  48. Instrument your programs. Measure before make “efficiency” changes

  49. Make sure comments and code agree

  50. Don’t just echo the code with coments – make every comment count

  51. Don’t comment bad code, rewrite it

To this advice, I decide to continue my work instead of retype this.

Good luck with coding!



Reply in English if you want

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Tag Cloud

%d bloggers like this: