17. Style

Q 17.1

C 언어 코딩을 할 때, 가장 좋은 스타일은 무엇일까요?

Answer

K&R은 다음과 같은 단점을 가지고 있음에도, 가장 널리 쓰이는 스타일입니다:

대부분 사람들이 굳은 믿음을 가지고 있음에도, 중괄호의 ({}) 위치는 중요하지 않습니다. 그래서 우리는 인기있는 스타일 중 하나를 선택했습니다. 여러분에게 맞는 스타일을 찾은 다음, 그것을 일관성있게 사용하시기 바랍니다.

완전한 스타일을 찾는 것보다는, 하나의 스타일을 일관성있게 사용하는 것이 더 중요합니다. 만약 여러분이 처한 환경이 (예를 들어, 어떤 지역적인 관습이나, 회사 정책 등) 이러한 스타일을 정의하지 않았고, 또, 여러분이 새 스타일을 만들려는 마음이 없다면, 그냥 K&R을 쓰시기 바랍니다. (물론 중괄호의 위치나 들여쓰기의 간격에 대한 많은 논쟁이 있을 수 있지만, 여기에서 그런 논쟁을 하지는 않겠습니다. Indian Hill Style Guide를 참고하기 바랍니다.)

`좋은 스타일'이란 (good style) 단순하게 코드를 어디에 배치하느냐보다 훨씬 많은 것을 내포하고 있습니다; don't spend time on formatting to the exclusion of more substantive code quality issues.

덧붙여 질문 10.6도 참고하시기 바랍니다.

References

[K&R1] § 1.2 p. 10
[K&R2] § 1.2 p. 10

Q 17.3

두 문자열이 같은지 비교하기 위해 다음과 같은 코드를 썼습니다:

  if(!strcmp(s1, s2))

이것이 좋은 스타일일까요?

Answer

흔히들 그런 식으로 코드를 작성하기는 하지만 특별히 좋은 스타일이라고 말하기는 어렵습니다. 위의 코드는 두 문자열이 같은 경우를 검사한다는 점에서는 전혀 문제가 될 것이 없지만, ! 연산자는 대개 `not'을 의미하는 곳에 쓰이므로 혼동을 가져올 수 있기 때문입니다.

다음과 같은 매크로를 쓰는 것이 도움이 될 경우도 있습니다:

  #define Streq(s1, s2) (strcmp((s1), (s2)) == 0)

덧붙여 질문 17.10도 참고하시기 바랍니다.

Q 17.4

어떤 사람들은 if (x == 0)을 쓰지 않고 if (0 == x)와 같은 코드를 쓰는 데, 그 이유는 무엇인가요?

Answer

다음과 같은 실수를 하는 것을 막기 위함입니다:

  if (x = 0)

상수를 == 연산자의 왼쪽에 쓰는 습관을 들이면, 다음과 같은 실수를 했을 때, 컴파일러가 에러를 발생합니다:

  if (0 = x)

어떤 사람들은 이런 방식을 쓰는 것을 외우는 것보다 두 개의 =를 쓰는 것을 외우는 것이 쉽기 때문에, 이런 방식을 좋아하지 않습니다. (물론, 이러한 스타일은 한 오퍼랜드(operand)가 상수일 경우에만 도움을 줄 수 있습니다.)

References

[H&S] § 7.6.5 pp. 209-10

Q 17.5

제가 본 코드에는 printf()를 부를 때, 항상 (void)로 캐스팅하고 있는데요, 왜 그럴까요?

Answer

printf()는 어떤 수치를 리턴하지만, 대개의 경우 쓰이지 않습니다. 어떤 컴파일러는 (특히 lint와 같은 프로그램도) 함수가 어떤 값을 리턴하는데, 이 값을 쓰지 않으면, 경고를 출력합니다. 따라서 (void)로 캐스팅해줌으로써, 이 리턴 값을 무시한다는 것을 컴파일러에게 알려, 경고를 출력하지 않게 할 수 있습니다.

strcpy()나 strcat()의 경우에도 같은 이유로 캐스팅이 사용되곤 합니다.

References

[K&R2] § A6.7 p. 199
[ANSI Rationale] § 3.3.4
[H&S] § 6.2.9 p. 172, § 7.13 pp. 229-30

Q 17.8

“헝가리안 표기법”이란 (Hungarian Notation) 무엇인가요? 그리고 그것이 쓸만한 가치가 있나요?

Answer

헝가리안 표기법은 Charles Simonyi씨가 만든 (변수의 이름에 변수의 타입에 대한 정보를 포함하는) 이름 짓는 방법입니다. 어떤 사람들에게는 매우 사랑받는 표기법이며, 어떤 사람들에게는 매우 배척받는 표기법입니다. 이 표기법의 가장 큰 장점은 변수의 이름만 보고도, 변수의 타입과, 쓰임새를 알 수 있는 것입니다; 가장 큰 단점은 이름을 짓는 데 타입에 관한 정보가 별로 중요하지 않다는 것입니다.

References

Simonyi and Heller, "The Hungarian Revolution".

Note

헝가리안 표기법은 특히 Microsoft사의 Win32 API를 쓰는 프로그래머들에게 사랑받고 있습니다. (API 자체도 이 표기법을 사용하고 있습니다.) 대개의 UNIX 프로그래머들은 이를 배척하고 있습니다.

Q 17.9

“Indian Hill Style Guide”나 이와 유사한 코딩 스타일에 관한 표준을 얻을 수 있는 곳이 있나요?

Answer

Anonymous FTP를 써서 여러 곳에서 얻을 수 있습니다.

Site:	File or directory
ftp.cs.washington.edu	pub/cstyle.tar.Z (최신의 Indian Hill Guide)
ftp.cs.toronto.edu	doc/programming (Henry Spencer씨의 “10 Commandments for C Programmers” 포함)
ftp.cs.umd.edu	pub/style-guide

“The Elements of Programming Style”, “Plum Hall Programming Guidelines”, “C Style: Standards and Guidelines”라는 책이 도움이 될 수 있습니다: `참고문헌'란을 보기 바랍니다.

덧붙여 질문 18.9도 참고하시기 바랍니다.

Q 17.10

어떤 사람들은 goto가 악마와도 같다고 말하면서 절대로 쓰지 말라고 하는데, 너무 과장된 말이 아닐까요?

Answer

프로그래밍 스타일이란, 글을 쓰는 스타일과 같이 예술과도 같은 것이기에, 어떠한 강경한 규칙으로 제정될 수 없는 것입니다, although discussions about style often seem to center exclusively around such rules.

goto 문장은 남용되면 유지/보수/관리하기 힘들 정도의 복잡한, 이른바 스파게티 코드를 (spaghetti code) 만들어 낼 수 있습니다. 그렇다고, 아무런 생각없이 goto 문장을 무조건 금지하는 것이 즉각 좋은 코드를 만들어 내는 것도 아닙니다: 물론 goto를 전혀 쓰지 않고도 (이상해 보이는 중첩된 루프나, 불리언 제어 변수를 써서) 코드를 만들어 낼 수도 있습니다.

대부분 프로그래밍 스타일에 관한 “규칙(rule)”은 규칙이란 단어보다는 “안내지침(guideline)”이란 단어로 보는 게 더 바람직합니다. 또한 이러한 규칙들이 왜 만들어졌는 가를 이해하는 것이 더 중요합니다. 이러한 규칙에 대한 이해없이, 무조건 어떤 구조를 배척하는 것은 원래 규칙이 의미하고자 한 것과 오히려 반대되는 결과를 만들어낼 수 있습니다.

게다가 프로그래밍 스타일에 대한 많은 의견은 단지 의견일 뿐입니다. 따라서 이러한 “스타일 전쟁”에 참여하는 것은 쓸데없는 짓입니다. (질문 9.2, 5.3, 5.9, 10.7에 이러한 내용이 있습니다.) 여러분의 의견에 반대하는 사람은 결코 여러분의 의견에 동의하지 않을 것이며, 여러분의 의견에 동조하는 사람은 결코 반대하지 않을 것이므로, 이런 논쟁을 할 필요가 없습니다.