좋은 코딩 습관은 무엇일까요? 그것이 무엇인지 잘 모르겠지만 아마 이런 것을 만족할 것 같습니다.<br><ul><li>적절한 수준에서 적확한 동작을 보증한다</li> <li>같은 결과를 낸다면 작성자의 의도를 잘 드러낸다</li></ul><br>일반적으로 C 언어의 구조체를 선언할 때 자료형의 크기로 몰아서 위쪽으로 배치하는 것이 좋은 습관입니다. 대부분의 C 언어 구현에서 컴파일러가 가장 쉽고 빠르게 구조체의 멤버들에 접근할 수 있도록 크기가 큰 멤버를 기준으로 삼습니다. 이것을 C 언어 컴파일러와 프로그래머 사이의 일종의 "계약"이라고 생각해볼 수도 있습니다. 이러한 계약을 실행할 때 자료형의 크기가 제각각인 멤버들이 흩어져있으면 메모리의 낭비가 생깁니다. 또, 특별히 압축하라고 지정하지 않은 구조체에서는 각각의 멤버 사이에 낭비되는 공간이 있을 수도 있습니다. 이러한 "계약조건"은 프로그래머가 반드시 이해하고 있어야 합니다.<br><br>특별히 압축하라고 지정하지 않은 구조체에서 각각의 멤버가 낭비되는 메모리 공간 없이 연속되어 있을것이라는 "추측" 또는 "기대"로 프로그래머가 메모리에 접근한다면, 컴파일러의 관점에서 프로그래머가 "계약을 위반"하는 것입니다. 컴파일러는 프로그래머의 의도를 추측해서 동작하지 않습니다. 구조체가 차지하는 메모리의 낭비를 없애거나 줄이려면, 프로그래머는 구조체를 압축하라고 특별히 지시하거나 또는 메모리 낭비를 줄이도록 수동으로 멤버들의 위치를 지정해야 합니다. 따라서, 자료형의 크기로 몰아서 위쪽으로 배치하는 것은 일반적으로 좋은 프로그래밍 습관입니다.<br><br>이 습관은 언제나 좋은 것일까요? C 언어의 구조체 멤버들은 단 한개의 예외를 제외하고 모든 자료형의 크기가 고정되어 있습니다. (그 단 한개의 예외도 비교적 최신 규약에서야 포함된 것입니다.) 그 예외를 사용하지 않는 일반적인 C 언어의 구조체 크기는 고정되어 있습니다. C++ 의 클래스는 C 언어의 구조체에 해당합니다. 그것도, 크기를 쉽게 알 수 없는 다른 클래스들이 중첩되어 포함된 구조체라고 생각해도 됩니다. 상속으로 물려받은 메모리 공간을 생각하지 않더라도, 그 내부에서 접근성이 다른 여러 멤버가 있습니다. 메모리 낭비를 줄여보겠다고 프라이빗 멤버들과 퍼블릭 멤버들을 뒤섞어서 배치하면 이해하기 어려운 코드가 될 수도 있습니다. 메모리 낭비를 많이 줄일 수 있는 것도 아니고요. C 언어의 좋은 습관이 C++ 에서는 크게 유용하지 않습니다.<br><br>좋은 습관에 대한 평가는 상황에 따라 바뀝니다. 대단히 오래동안 저는 변수의 사용을 억제하는 것이 좋은 습관이라고 믿어왔습니다. 적절히 이름을 붙이는 것, 즉 변수를 사용하면 코드를 쉽게 읽을 수 있습니다. 그러나 컴퓨터는 한정된 레지스터만을 가지고 있고 메모리의 내용을 레지스터에 적재하고 필요할 때 레지스터를 교체하는 것, 즉 변수를 사용하는 것에 비용이 듭니다. 성능을 생각한다면 변수의 사용을 억제하는 것이 좋은 습관인 것 같습니다. 그렇지 않습니다!! 컴파일러가 최적화 과정을 거치면서 불필요한 레지스터 사용을 스스로 조절합니다. 또한, 프로그램은 대개 최적화 컴파일 과정을 거친 다음 실행됩니다. 최적화 컴파일을 일부러 하지 않는 경우가 아니라면 프로그래머가 변수의 사용에 제약을 받을 이유가 없습니다. 프로그래머의 의도를 잘 드러내는 이름을 주는 것이 더 좋은 습관입니다.<br><br>함수의 사용은 어떨가요? 일반적으로 함수 호출은 변수 사용보다 더 큰 비용이 듭니다. 따라서, 함수 호출을 억제하고 지역 변수로 복사해서 쓰는 것이 더 좋은 습관인 것 같습니다. 여기에 미묘한 점이 있습니다. 복사본의 값이 계속 유효한 것이라면 지역 변수를 쓰는 것이 이득입니다. 그런데, 복사본의 값이 언제까지 유효한 것인지에 대한 고려가 필요합니다. 복사본의 값이 유효하지 않는 일이 생기지 않는다는, 즉 "기대"가 어긋나거나 "계약"에 위배되는 상황이 없을 것이란 "확신" 또는 "확인"이 필요합니다. 이것을 확인하려고 다시 그 함수를 호출해야한다면 배보다 배꼽이 큰 일입니다. 누군가 믿을만한 존재가 그것을 보증해주는 것이 좋겠습니다.<br><br>보증을 하려해도 확인이 필요합니다. 어떤 것을 변경하지 않았다는 보증을 하려면 그 전의 상태와 지금의 상태가 같다는 것을 확인해야합니다. 변경할 능력이 없는 경우는 어떨까요? 확인할 필요도 없을 것입니다.<br><br>예를 들어...<br><code>int const SIZE = 10;</code><br>로 선언된 SIZE 라는 변수는 일반적으로 그 함수 내부에서 변경할 능력이 없습니다. <code>SIZE = 20</code> 란 구문은 에러를 냅니다. 포인터의 경우는 어떨까요?<br><code>int size1 = 10;</code><br><code>int size2 = 20;</code><br><code>int* const SIZE_PTR = &size1;</code><br>로 선언된 변수들 사이에서 <code>SIZE_PTR = &size2</code> 는 에러를 냅니다. 그런데, <code>*SIZE_PTR = size2</code> 는 허용되는 구문입니다. SIZE_PTR 이 size1 을 가르켜야 된다는 것은 const 로 한정했지만, 그 내용을 바꾸는 것을 한정하지는 않았습니다. 가르키고있는 size1 도 변경이 가능한, 즉 const 로 한정되지 않은 변수입니다.<br><br>조금 다른 예 입니다.<br><code>int const SIZE1 = 10;</code><br><code>int const SIZE2 = 20;</code><br><code>const int* size_ptr = &SIZE1;</code><br>이 경우 <code>size_ptr = &SIZE2</code> 는 허용되지만, <code>*size_ptr = SIZE2</code> 는 에러를 냅니다. 한정사 const 가 int* 를 한정하고 있지만 포인터 변수 자체의 변경을 제한하고 있지는 않기 때문입니다. 만일, <code>const int* const SIZE_PTR = &SIZE1</code> 이었다면 모두 금지되었을 것입니다. 이렇게 지역 변수들을 한정하는 것은 의도를 명백하게해서 실수를 방지하는 효과가 있습니다. 조금 관점을 달리하죠.<br><br><code>size_t getSize (struct MY* const THIS) { THIS->size = 10; return THIS->size; }</code><br>라는 함수는 THIS 의 size 라는 멤버를 변경하고 그 값을 돌려줍니다. 그런데,<br><code>size_t getSize (const struct MY* const THIS) { THIS->size = 10; return THIS->size; }</code><br>는 허용되지 않습니다. 오직,<br><code>size_t getSize (const struct MY* const THIS) { return THIS->size; }</code><br>만 허용됩니다. (const 를 주의해서 보세요.) 따라서, 이런 종류의 함수만 사용한다면 THIS 의 멤버들이 변경되지 않는다는 것을 확신할 수 있습니다. 물론, 예외는 있습니다. 내부적으로 캐스트 연산을 해서 const 한정을 벗어난다거나...<br><br>다시 말하지만 C++ 의 클래스는 C 의 구조체에 해당합니다. 만일 MY 가 구조체가 아니라 클래스였다면 getSize() 매소드가 이런 식으로 쓰였을 것입니다. (같은 기능을 하는 함수가 어떻게 표현되는지 const 의 위치를 비교해보세요.)<br><code>size_t MY::getSize (void) const { return this->size; }</code><br><br>이런 종류의 다른 const 함수를 사용하는 동안은 지역 변수로 복사한 값은 확인할 필요도 없이 계속 유효합니다. 함수 호출을 하지 않는만큼 이득이겠죠. 그런데, 또... 만일 getSize() 함수가 인라인 된다면 그리 큰 이득을 볼 수는 없습니다. 그게 그거니까요 :)<br><br>어쨌든, 실수를 방지하고 확신을 줄 수 있다는 점에서 const 한정자를 적극적으로 쓰는 것은 분명히 좋은 코딩 습관입니다.