The element of programming style - 요약본 번역

http://planetmars.tistory.com/entry/The-element-of-programming-style-%EC%9A%94%EC%95%BD%EB%B3%B8-%EB%B2%88%EC%97%AD

The elements of programming style 요약본을 번역해 보았습니다.

오역을 대비해서 아래에 원문 주소와 원문을 실었습니다만,

오역을 알려주시면 더욱 감사하겠습니다.

================================================================================================

1. 명료하게 써라. - 너무 똑똑해지지 말것


2. 무엇을 원하는지를 간단하고 직접적으로 말하라. (돌려서 얘기하지 마라는 뜻인듯 함)
3. 언제나 사용할 수 있을 라이브러리를 사용하라. (플렛폼에 종속적인 라이브러리를 사용하지 말라는 뜻인듯 함)
4. 임시 변수를 너무 많이 사용하지 말라.
5. 명료하게 코딩하라. - 효율을 위해서 명료성을 희생시키지 말라.
6. 기계가 어려운 일을 하도록 하라. (사람이 어려울 일을 하게 하지 말라는 뜻인듯 함)
7. 반복적인 표현을 공통 함수를 호출하도록 수정하라. (동일한 표현-코드-를 함수로 정리하라는 뜻인듯 함)
8. 모호성을 피하기 위해서 삽입해라 (원문 : Parenthesize to avoid ambiguity, 정확한 의미를 모르겠음)
9. 헷갈리지 않는 변수명을 사용하라.
10. 불필요한 분기를 피하라.
11. 이해하기 힘든 논리적 표현이 사용되었다면, 그 표현 자체를 쉽게 만들라.
    (어려운 문제를 간략화시켜서 쉬운 문제로 변형하라는 뜻인듯 함)


12. 프로그램을 간단하게 만들수 있는 데이타 표현을 사용하라.(정확한 뜻을 모르겠음)
13. 이해하기 쉬운 의사(pseudo) 언어로 먼저 쓴 후, 실제 사용하는 언어로 바꾸어라.
14. 모듈에 맞게 정리해라. 함수를 사용하라. (함수를 그룹하해서 파일에 배치하라는 뜻인듯 함)
15. 프로그램 가독성을 지킬 수 있다면, 되도록 goto문을 사용하지 말아라.
16. 나쁜 코드는 수정하지 말라. - 다시 작성하라.
17. 큰 프로그램은 작은 단위로 작성하고 테스트하라.
18. 재귀적 형태의 데이타 구조에는 재귀 함수를 사용하라.


19. 그럴싸하고 정상적인 데이타로 테스트하라. (말도 안되는 값으로 테스트하지 말라는 뜻인듯 함)
20. 입력이 프로그램의 한계를 침범하지 않게 하라. (입력에 의해서 프로그램이 깨지지 않게 하라는 뜻인듯 함)
21. 개수(count)가 아닌 EOF 표시로 입력을 종료하라.
22. 잘못된 입력을 검출하고, 가능하다면 복구하라.
    (제 생각과는 완전히 반대네요.)
23. 입력은 쉽게 작성할 수 있는 형태로 하고, 출력은 쉽게 이해할 수 있는 형태로 하라.
24. 도일한 입력 포맷을 사용하라.
25. 입력을 교정하기 쉽게 만들라.
26. 스스로 확인할 수 있는 입력을 사용하라. default를 허용하라. 입력/default입력을 output에 표시하라.

27. 모든 변수는 사용하기 전에 초기화되었는지 확인한다.
28. 큰 버그를 만났다고 그 곳에서만 멈추지 말라.
29. 디버깅이 가능한 컴파일러를 사용하라.
30. off-by-one 에러를 조심하라.
31. 동일한 상황에서 정상적으로 분기되는지 확인하라.
32. loop문 중간에서 종료되는 경우와 정상적으로 loop문이 종료되는 경우
    loop문의 종료후 실행되는 코드가 같은지 확인하라.
33. 코드가 우아하지 "못한지" 확인하라.
34. 경계의 값으로 프로그램을 테스트하라.
35. 가끔은 손으로 직접 값을 계산해보라.
36. 10.0의 0.1배는 1.0이 아닌 경우가 많다.
37. 7/8은 0(zero)이지만, 7.0/8.0은 0(zero)이 아니다.
38. 부동소수점 숫자 비교를 조심하라.


39. 코드를 빠르게 만들기 전에 제대로 돌아가도록 만들라.
40. 크드를 빠르게 만들기 전에 에러에 안전하도록 만들라.
41. 코드를 빠르게 만들기 전에 명료하게 만들라.
42. "작은 성능"을 위해서 명료성을 위해를 가하지 말라.
43. 간단한 최적화는 컴파일러가 하도록 하라.
44. 코드를 재사용하기 위해서 무리하지 말라; 대신 재구성하라.
45. 특별한 경우가 정말 특별한지 확인해라.
46. 코드를 빠르게 만들기 위해서 간단하게 만들라.
47. 코드를 빠르게 만들기 위해서 사기치지 마라. - 좀 더 좋은 알고리즘을 찾아라.
48. 프로그램을 측정하라. "효율적인" 코드 작성을 시도하지 전에 측정하라. (정확한 번역이 아닌듯 함)


49. 주석는 코드와 동일해야 한다. (코드가 수정되면 주석도 수정되야 한다.)
50. 코드와 동일한 주석을 만들지 말라. - 의미있는 주석을 작성하라.
51. 나쁜 코드에 주석을 달지 말라. - 코드를 다시 작성하라.
52. 의미있는 변수명을 사용하라.
53. 의미있는 분기명을 사용하라.
54. 프로그램을 읽기 쉽도록 작성하라.
55. 데이타 구조에 대한 설명을 추가하라.
56. 너무 많은 주석을 달지 말라.

================================================================================================

원문 주소 : http://cs.boisestate.edu/~amit/teaching/handouts/style.pdf

The Elements of Programming Style
The following rules of programming style are excerpted from the book "The Elements of
Programming Style" by Kernighan and Plauger, published by McGraw Hill. Here is quote
from the book: "To paraphrase an observation in The Elements of Style by Strunk and
White, the rules of programming style, like those of English, are sometimes broken, even by
the best writers. When a rule is broken, however, you will usually find in the program some
compensating merit, attained at the cost of the violation. Unless you are certain of doing as
well, you will probably do best to follow the rules."

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't sacrifice clarity for "efficiency."
6. Let the machine do the dirty work.
7. Replace repetitive expressions 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 in easy-to-understand pseudo language; then translate into whatever language you have to use.
14. Modularize. Use procedures and functions.
15. Avoid 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-defined data structures.


19. Test input for plausibility and validity.
20. Make sure input doesn't violate the limits of the program.
21. Terminate input by end-of-file marker, not by count.
22. Identify bad input; recover if 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 defaults. Echo both on output.


27. Make sure all variable are initialized before use.
28. Don't stop at one bug.
29. Use debugging compilers.
30. watch out for 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 fail-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 optimizations.
44. Don't strain to re-use code; reorganize instead.
45. Make sure special cases are truly special.
46. Keep it simple to make it faster.
47. Don't diddle code to make it faster - find a better algorithm.
48. Instrument your programs. Measure before making "efficiency" changes.


49. Make sure comments and code agree.
50. Don't just echo the code with comments - make every comment count.
51. Don't comment bad code - rewrite it.
52. Use variable names that mean something.
53. Use statement labels that mean something.
54. Format a program to help the reader understand it.
55. Document your data layouts.
56. Don't over-comment.