헝가리안 표기법을 버려라.

헝가리안표기법은
마치 처음 배우는사람이 화장실에 앉아서 10분만에 만들어낸듯한..
ㅡ,.ㅡ;;

저도 헝가리언 표기법을 좋아하지 않아서 잘 쓰지
않습니다. 하지만 취향에 따라서 사용하는 건 괜찮겠지요..
제 경우에는 헝가리언 표기법 대신 모듈 등 성격에 따른
접두사를 붙여 사용하는 것이 더 효율적이더라구요.
변수 타입은 개발환경의 도움을 받아 맞추는 추세로 가는
것이 맞지 않을지요..
어쨌든 헝가리언 표기법 자체가 문제가 있다기 보다는
취향 문제라고 하겠네요..

혹시나 도움이 될까 하여 관련 내용의 링크를 추가합니다. :D

The Coad Letter: Test-driven Development, Issue 106, Intentional Coding, by Dave Astels - http://bdn.borland.com/article/0,1410,29608,00.html

헝가리안 표기법 .

제가 윈도우 프로그래밍에 겁을 먹게 만들어준 아주 멋진 프로그램입니다.

MFC나 winAPI등을 쓸때 쏟아져 나오는 의미를 알수 없는 변수명 클래스 명들은
비슷한 뜻으로 단어로만 조합한 낙타모양보다 훨씬 읽기 어려웠고
심지어 그냥 변수명 만드는대도 가끔 사전을 찾곤 하는 제 머리론 사전에다가 헝가리안 표기법 레퍼런스까지 보게 만드는 이상한 사태까지 가지고 왔습니다.

게다가 단어로 조합된 낙타 모양 변수보다 복잡해서인지 더 짧아 보이지도 않더군요-_-

없어진다면 두손 두발들고 환영입니다.

한때 헝가리 사람을 그냥 미워한 적이 있었죠. ^^

http://www.joelonsoftware.com/articles/Wrong.html

변수명등을 통해 에러를 원천봉쇄하자는 글인데 중간부터 헝가리언 표기법에 대한 얘기가 본격적으로 나옵니다.

원조(?) 헝가리언 표기법은 변수형이 아니라 변수의 특징을 변수나 함수 명 앞에 붙이는 것이였다고 합니다. 저는 프로그래밍을 못해서 과연 원조/사이비 헝가리언 표기법이 얼마나 불편한지는 모르겠지만, 이 글을 쓴 사람도 사이비 헝가리언 표기법은 싫어하나 봅니다.

---

http://bbs.kldp.org/viewtopic.php?t=22034

저기 내용과 여기 내용을 보니 원조 헝가리언 표기법의 "취지"를 싫어하실 분은 얼마 없어 보입니다.

저도 개인적으로 헝가리안 표기법을 좋아하지는 않습니다.
학부/대학원 시절에는 헝가리안 표기법을 절대로!! 따르지 않았죠...
지금도 내부 알고리즘 쪽 코드나, 다른사람이 같이 읽어야 하는 코드가 아닌, 혼자서 관리해야 하는 코드 부분에는 헝가리안 표기법을 사용하지 않고, 개인적인 표기법을 사용합니다만.

제 회사 경험상으로는 헝가리안 표기법이 나쁜것만은 아닌것 같습니다.
머 MFC로 user interface쪽의 프로그램을 하다보면,
하나의 의미를 가지는 객체를 여러개의 변수로 나누어 관리해야 하는 경우가 발생합니다.
예를들어... (단지 예입니다. 좋은예는 아니지만..)
CComboBox m_ctlComboX;
int m_iComboX;
와 같이 하나의 객체를 가리키기 위해 두가지 이상의 변수를 이용하는 경우에는 (헝가리안 표기법이 아니고는) 마땅히 이름을 붙이기가 쉽지 않죠.. 이름을 정하는데 고민을 시작해야 하거든요..
머 이런쪽에서는 헝가리안 표기법이 나쁘지 않다고 생각하고 있습니다...
하지만, 역시나 헝가리안... 짜증나죠.. ^^;;

PS:
혹시나 저렇게 쓸 필요 없다.
CComboBox m_ctlComboX;
만으로도 된다고 얘기하실만한 분이 충분히 있을거 같은데..
저건 단지 예입니다. 충분한 예는 아니지만요.. ^^;

지역 변수 아니면 거의 다 멤버 변수 아닌가요? 혹은 전역 변수거나. 전역 변수는 OOP에서 거의 안 쓰이니만큼 제외하고 본다면 지역 변수인지 아닌지는 금방 알 수 있잖아요. 그러면 멤버 변수인지 아닌지도 금방 알 수 있을 꺼라고 보는데요. 지역 변수, 멤버 변수를 구분할 수 없을 정도로 메쏘드가 길어졌다면 적절히 extract method를 하는 것이 좋겠죠.

덧붙여, 자바의 경우는 이클립스 등의 IDE에서 멤버 변수를 다른 색으로 표시할 수 있습니다. C++도 그 정도 기능이 있는 IDE는 있을 꺼라고 생각되는데 제가 C++ IDE는 많이 알지 못해 뭐라 말을 못하겠군요.

아..그리고 파이썬에서는 self.이 의무입니다. this->을 쓰는 게 그리 불편한 것 같진 않습니다. 어차피 content assist로 다 입력할 수 있으니까요.

그렇죠. 그렇게 무작정 긴 메쏘드를 만들어내는 프로그래머라면 헝가리안 표기법인들 제대로 지킨다는 보장이 어디 있겠습니까. 지역 변수로 만들었다가 멤버 변수로 바꾸면서 m_ 추가하는 걸 잊는다면? 반대로 멤버 변수를 지역 변수로 바꾸면서 m_ 빼는 거 잊는다면? 대책 없죠. 그런 프로그래머에게 헝가리안 표기법을 교육시키느니 checkstyle 같은 툴로 30라인 넘어가는 메쏘드 못 만들게 한다든지 하는 게 더 나을지도 모릅니다. 그리고, 앞서도 말했듯 이런 건 IDE에서 해결하는 게 더 바람직하겠죠.

그리고 모든사람들에게 부정확한 명찰을 달아놓는것보다
꼭필요한사람에게 정확한명찰을 달아주는게 정확하고 훨씬 쉽고 좋습니다.

저도 저 블로그 읽어보았습니다.
블로거인 Adam Abrams라는 사람은 닷넷의 스타일리스트 같은 사람이더군요.
내공과 수준을 겸비한 사람이라는 거겠지요.

자바와 같이 닷넷에서는 C++에 비해 좀 더 완전한 객체지향 언어인 C#으로 프로젝트를
개발할 수 있으니 그에 좀 더 맞는(제 개인적인 견해로는 C#을 밀기위한 정책이라고 여겨집니다만)
Convention Rule이 효율적이라 생각하기 때문에 그 생각을 블로그를 통해 피력을 한 것일테고,
개발자는 자기의 스타일과 맞으면 수용하고 생각이 좀 다르면 자기와 맞는 편한방법을 선택하면 그만이라 여겨집니다.

아무리 주위에서 "넌 파란색이 잘 어울려" 이래도 노란색 옷이 좋으면 노란색을 좀 더 많이 사고 입게 되듯이...

헝가리언 Notation도 사상은 팀프로젝트에서 가장 효율적인 코드이해방법이 어떤것일까를 고민한 결과의
산출물이기 때문에 기본적인 사상은 같다고 보입니다.
저도 습관이 붙어서 헝가리언으로 많이 치우치긴 하지만, m_ 이건 this이건 가독성을 높이기 위한 방법이지
코딩을 편하게 하자는 생각은 아닌것 같은데요...(아닌가...?)

Object Oriected 입장에서 생각하면 this-> 형태의 코딩이 좀더 직관적이라 생각할 수 있을것 같습니다.
(개인적으로도 그게 더 명확해 보이긴 하네요.)
Convention이라고 하는 굴레을 씌우면 코딩의 자유도는 당연스레 낮아지는게 아닐까 합니다.
대신 작은걸 버리고 보다 큰 목표인 가독성 및 일관성을 유지하자는 취지이겠지요.

어찌됐건 내 취향에 맞는 스타일은 대부분 가지고 가실테고, 팀프로젝트를 진행할때는 내스타일보다는
공동의 작업을 위한 절충된 방법을 협의하여 약간의 불편을 감수하더라도 코드의 가독성을 높이는 쪽으로 우선순위를
두고 작업하는 것이 효율적이라고 생각하실테이니 굳이 방법론에 얽매여서 본질을 흐리는것은 별로 좋지 않아 보이는군요.

오랜만에 재미있는 주제 잘 보았습니다. 많은 개발자분들의 높으신 고견을 공유 & 공감하고 갑니다.
덧붙여 낙서도 하고 가게 되는군요. ^^;

아담스 아자씨가 recommend하면서 "헝가리언을 버려라"라고 하는 충격요법을 쓰면서 파장이 우려되는지 이런 문구도 덧붙였네요.
(버렸다기보다는 확장이라는 표현으로 완화하고자 하는... ^^;)
미천한 실력으로 해석하다가 아담스 아자씨의 의도를 훼손할것 같아 원문 그대로 옮겨봅니다.

"The reasons to extend the public rules (no Hungarian, no prefix for member variables, etc.) is to produce a consistent source code appearance. In addition a goal is to have clean readable source. Code legibility should be a primary goal."

모두들 화이팅 하시고 멋잇는 코딩들 하시기 바랍니다~~~~