신념, 이념, 종교, 그리고 스타일
by 신영진(YoungJin Shin), codewiz at gmail.com, @codemaru, http://www.jiniya.net
인지부조화 이론이라는 것이 있다. 사람은 태도와 행동간의 불일치를 줄이는 방향으로 행동한다는 것이다. 즉, 대부분의 사람들은 언행일치 내지는 신념과 행동간의 불일치를 줄이는 방향으로 자신을 조절해 나간다는 이야기다. 이걸 활용한 것 중에 하나가 다짐을 받는 방법이 있다. 즉, 사소한 일이라도 부탁을 해서 다짐을 받아두면 그 사람은 다짐을 했기 때문에 그 일을 하기 싫어도 할 확률이 높아진다는 것이다. 그럴 것 같기도 하고, 아닐것 같기도 한 이 이론에 대한 심오한 경험을 오늘 하게 되었다.
문제의 발단은 리팩토링 작업을 하면서 만난 다음과 같은 코드였다.
class XSCPacket1 : public ISCPacket
{
private: char Key[PACKET_KEY_SIZE];
public: virtual LPCSTR Key() const;
}
코드가 이렇게 된 배경에는 다음과 같은 이유가 있었다.
하지만 결국 저 코드는 쓸 수 없는 코드다. 왜냐하면 동일한 네임스페이스에 Key라는 동일한 이름을 가진 존재가 두 개가 있기 때문이다. 결국 한 놈은 다른 이름으로 바뀌어야 하는 상황이다. 정말 아무것도 아닌 상황일 수 있다. 아무 곳에나 아무 글자나 덧붙이면 되기 때문이다. 그런데 나는 이 사소한 문제를 가지고 2시간을 고민했다.
처음으로 이러한 문제를 겪은 다른 사람들의 글을 찾아보려는 시도를 했다. 보통 파라미터와의 이름 충돌 문제는 this->를 사용해서 해결을 하지만 이러한 함수 이름 충돌을 겪는 것에 관한 이야기는 잘 없었다. 비슷한 문제를 해결하기 위해서 멤버 변수 뒤에 _ 스코어를 붙이는 걸 좋아한다는 사람의 글을 하나 찾았을 뿐이었다.
결국 그렇다면 둘 중에 하나를 고쳐야 한다면 무엇을 고칠지에 대해서 생각해 보았다. 함수 이름을 고치면 코드 전체에 고칠 부분이 너무 많았다. 또한 다른 코드의 Get/Set 함수와의 일관성도 잃게 되는 부작용도 있었다. 결국 멤버 변수 이름을 바꾸기로 결정했다.
변수 이름을 어떻게 바꿀지 고민을 시작했다. 앞에 m이나 m_를 붙이는 게 좋을지, 뒤에 _를 붙이는 것이 좋을지를 두고 고민한다. mKey, m_Key, Key_ 흠. 사실 셋 다 마음에 들지 않는다. 결국 mKey를 하겠다고 결정을 했다.
변수 이름 세 개 중에 충돌이 나는 두 개를 mKey, mData로 변경했다. 이러니 나머지 한 변수가 좀 이상해 보인다. 둘만 붙이고 하나를 안 붙이는 것이 찜찜한 것이었다. 결국 나머지 하나는 충돌도 없지만 붙였다. 이러고 나자 헝가리언 표기법을 사용하지 않으려는 나의 신념에 위배되는 코드를 만든 것 같아 찜찜한 기분이 든다. 한참을 코드를 본다. 그리고는 결국 m을 다 지우고, Data와 Key 뒤에 Buffer라는 엄청난 단어를 붙였다. DataBuffer, KeyBuffer가 된 것이다. 결국은 그 놈들은 버퍼인 셈이기도 하니 머 잘못된 결정은 아니라는 안도의 한숨을 쉰다. 머 변수 중에 버퍼가 아닌 변수가 뭐가 있겠냐마는 말이다.
종종 사람들은 자신의 신념, 이념, 믿음, 종교 등을 증명하기 위해서 정말 어처구니 없는 일들을 하곤 한다. 왠지 그런 사람들을 이해할 수 있을 것 같은 오늘이었다. 그리고 또 한번 느꼈다. 신념, 이념, 사상, 종교 등이 얼마나 대단한 것인지를 말이다. 그런 것들을 점령 했을 때 얼마나 엄청난 일을 할 수 있을지에 대해서 말이다.
덧0) 글을 쓰고 다시 읽어 보니 제가 원하는 스타일이 굉장히 충돌이 잘 발생할 수 밖에 없을 것 같다는 생각이 드네요. 저도 원래는 대부분의 윈도우 프로그래머들이 그러하듯 타입 기반 헝가리언 표기법을, 그러다 범위 기반 표기법을, 그러다 이제는 의미론을 제외한 일에는 헝가리언 표기법을 사용하지 않습니다. 변수명에 대한 표기법도 첫글자를 소문자로 하는 방식을 쓰다가, 멤버 변수는 뒤에 언더스코어를 쓰는 방식을 쓰다가 결국은 그런 제한이 다 없는 상태로 쓰기로 했습니다. Get/Set 함수는 이 페이지에 소개된 것과 같은 생각으로 붙이지 않습니다. 제가 버린 순서가 Get/Set, 헝가리언, 소문자 표기가 되다 보니 이런 일이 벌어진 것 같습니다. 비극이군요. ㅎㅎ~^^;;
덧1) 저희 큰 누나는 28살에 결혼한다고 이야기 하고는 28살에 시집을 갔습니다. 작은 누나는 32에 한다고 하고는 그 나이에 가더군요. 인지부조화 이론은 참 그럴듯하죠. 그런데 재미난 사실은 팀원들이 하는 일정 관련 이야기는 인지부조화 이론이 통하지 않는다는 사실입니다. 물론 저도 그렇지요. 매번 일정을 너무 살인적으로 잡아서 그런것 같다는 생각도 드는군요.
나도
1. 개인적으로 Get/Set 계열 함수에 해당 동사를 붙이는 것을 좋아하지 않는다.
2. 타입이나 범위(scope)에 기반한 헝가리언 표기법을 사용하지 않는다.
이건 똑같은데
변수 소문자시작, 함수 대문자 시작규칙은 써서
위의 경우
변수는 그냥 key, 함수는 Key() 써 하하
인지부조화가 “자신의 생각”을 밖으로 표출한 것을 지키는 건데
자신의 생각에 부합되지 않는건 밖으로 표출해도 속으론 “이건 아니잖아” 해서 안지키지 않겠어
그래서 살인적인 일정같은건 이미 마음속으로 말이 안되잖아! 싶어서 일지도 ㅋ
그리고 불일치를 줄일려고 해도 불가능을 가능으로 바꿀 순 없으니
알고보면 인지부조화에 맞춰서 일정을 지킬려고 피나게 노력하는데도
안되고 있는걸지도? ㅎㅎ
kuaaan // 네 어려운 부분이지만 그런 부분들이 자신을 남과 구분지어주는 요소 중에 하나라고 저는 생각합니다. 그래서 스타일은 잘 강요하지 않는 부분이기도 하구요.
황선우 // 네. 저도 key, Key 이렇게 썼는데 커틀러 아저씨 소스를 보면서 생각을 바꾸게 되었습니다. 그냥 다 대문자로 써도 별 상관 없지 않을까, 했는데 상관이 많이 있드라고요. ㅋㅋㅋ~
네. 불일치를 줄이려해도 불가능을 가능으로 바꿀 수 없다는 부분이 심히 공감이 가네요. 그런 점에서 좀 더 비관적인 일정을 잡을 필요가 있을 것 같아요. 저희 팀은~ ㅎㅎ
저는 만사 귀찮아서 요즘은 99% 구글 코딩 컨벤션을 따릅니다. 헝그리안은 쓰지 않는데 적어도 멤버 변수는 무조건 구별을 해야 편하더군요.
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#General_Naming_Rules
사실 저는 당분간 윈도우에 종속된, 적어도 Win32 API를 쓸 일이 별로 없어서 괜찮긴한데 MFC나 Win32 API많이 쓰면 구글 코딩 가이드라인은 좀 거시기하기는 합니다. 그런데 한번 정독해볼 필요는 있습니다.
미친듯이 헝가리안을 쓰던적이 있었는데….
저도 object 님하고 비슷하게…. 스코프에 관한 것만 사용합니다. (멤버변수앞에는 m_ 글로벌앞에는 g_ )
그리고 그 이외의 것은… ㅎㅎㅎ
X 꼴리는대로.. ㅋㅎㅎㅎㅎ
m_key 일때도 있고… m_keyBuf 일때도 있고.. m_keybuf, m_keyBuffer, m_key_buffer
m_aKeyBuffer 뭐 이런경우도 있고. ^^
대신 대분자로 시작하는 경우는 거의 없는데…
이유는 안 이쁘기 때문이예요.. 눈에 거슬려서.. ㅋㅋㅋㅋ
저도 m_ 는 절때 붙이지 않았었습니다.
이유는… 보기 흉해서 -_-ㅋ 매번 치기 귀찮아서….
원래는 변수가 변수의 이름 그대로를 가지고 있는데, 이상한게 붙어 있어서….
그런데, 말씀하신 것 같은 상황이 여러모로 너무 일어나구요.
특히, m_ 좀 덜치겠다고 this-> 같은걸 쳐대는건 정말 더더욱 이상하더군요.
결국 m_ 를 붙이는걸로 타협을 봤는데 막상 써보니 굉장히 좋더군요. ㅡ0ㅡ;
깊이 공감가는 내용이군요.
변수명과 함수명 네이밍하느라 고민하다 보내는 시간들… 저도 꽤 많았던 것 같습니다. ^^
함수명이나 변수명 네이밍해주는 프로그램이라도 있었으면 싶습니다.