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

sangheon의 이미지

닷넷에 와서 헝가리안 표기법을 포기했다고 하는데 좀 더 자세한 내용이 나온 것을 발견했습니다.

Quote:

2.6 Naming
Follow all .NET Framework Design Guidelines for both internal and external members. Highlights of these include:

Do not use Hungarian notation
Do not use a prefix for member variables (_, m_, s_, etc.). If you want to distinguish between local and member variables you should use “this.” in C# and “Me.” in VB.NET.
Do use camelCasing for member variables
Do use camelCasing for parameters
Do use camelCasing for local variables
Do use PascalCasing for function, property, event, and class names
Do prefix interfaces names with “I”
Do not prefix enums, classes, or delegates with any letter
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.

http://blogs.msdn.com/brada/articles/361363.aspx

뭐하는 사람인가 궁금해서 살펴보았습니다.

http://blogs.msdn.com/brada/archive/2003/09/26/50384.aspx

doldori의 이미지

말 많은 헝가리안 표기법을 공식적으로 폐기하는군요.
(블로그에 실린 글이긴 하지만 공식적인 입장이라고 봐도 되겠죠?)
저야 헝가리안 표기법이 이상해 보여서 쓰지는 않았습니다만.
답글에 눈에 띄는 게 있네요.

Quote:
Back on the days of c/c++ on MFC, we used Hungarian notation, and
m_ and it was very encourged by MS docs although being ugly and
hard for developers, now it is discouraged I am happy, but I have
learned to ask why?
익명 사용자의 이미지

char a[30];

for(int i=0; a<30; ++i) {
cout << a[i];
}

이렇게 짜는 것은 두가지 문제점이 있을 것입니다. 30이라는 매직넘버가 존재한다는 것 하나와 배열을 선언했을때 30과 루프에서 30이 별개의 수치 처럼 취급되고 있기 때문입니다. 하나를 바꾸기 위해 둘을 바꾸어야 하는 것은 매우 바보같은 행위라고 생각합니다.

헝가리언 표기법에 대한 생각도 동일합니다. 사람이 조금 더 편리해지기 위해서 표기법을 유지하기 위해 표기법 자체를 사람이 집중하고 관리해야 한다는 것 그 자체가 모순이라고 생각합니다. 그렇게 해서라도 뭔가 남았다면 다행일텐데 소스 코드의 용량이 클 수록 잘못된 헝가리언 표기법을 발견할 가능성이 높았습니다. 자료형과 자료명의 성격이 동일하게 보장해줄 어떠한 문법적인 장치도 도구적인 도움도 없기 때문일 것입니다.

죠커의 이미지

로그인이 튕겨버렸네요 -_-

덧붙여 소스가 미학과는 멀어집니다. 낙타 혹을 붙이는 언더바를 붙이든 리드미컬한데 헝가리언 표기법은 엇박으로 시작한 아마추어의 노래같습니다.

ㅡ,.ㅡ;;의 이미지

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


----------------------------------------------------------------------------

jedi의 이미지

이거 유행인가요? 한때는 너도 나도 권장했던 기억이 나는데...

+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년

shji의 이미지

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

atie의 이미지

요즘 C# 프로젝트가 진행되는 것이 있어, 가이드 정한 것을 보니
camelCase (첫번째 글자는 소문자, 중간의 다른 워드는 대문자로 시작: customerName)는 Private Field, Constant 그리고 Static Field는 _c 이런식으로 _를 붙여쓰고, Inline Variable 그리고 Parameter에는 _없이 씁니다.
나머지, Public, Protected 그리고 Internal의 모든 경우는 PascalCase(첫번째 글자는 대문자, 중간의 다른 워드는 대문자로 시작: CustomerName)를 쓰는군요.

----
I paint objects as I think them, not as I see them.
atie's minipage

kcando의 이미지

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

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

khris의 이미지

흠 헝가리안 표기법이라...
프로그래밍 입문할때 지겹게 들었던 소리지요.
헝가리안 표기법을 준수해라... -_-a;
하지만 전 그냥 제 방식대로 씁니다.
저는 훌륭한 코딩은 보기좋은 코딩이라고 생각하거든요...
제가 하는쪽은 최적화보다는 가독성을 생각해도 될만한 정도라서요.
변수명이나 함수명 대부분을 언더바를 삽입해서 길게 쓰게 되더라도 단어들을 그대로 쓰는것을 선호합니다.(물론 영어 약어를 풀어쓰진 않습니다)
이러면 굳이 "통일된" 헝가리안 표기법을 쓰지 않아도 알아 볼 수 있으니까요.

P.S. 비주얼 어시스트의 도움으로 함수명이나 변수명이 조금 길어도 OK입니다 :)

───────────────────────
yaourt -S gothick elegant
khris'log

카二리의 이미지

헝가리안 표기법 .

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

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

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

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

새 생각 :)

idealismoo의 이미지

헝가리안//

취지에 안맞게 보기 흉하긴 하죠.

theone3의 이미지

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

당신은 사랑받기 위해 태어난 사람.

소리의 이미지

MS에서 헝가리안 노테이션 및 낙타을 폐기하다니...
왠지 모르게 이렇게 웃게 되네요. :oops:

"푸하하" :twisted:

Prentice의 이미지

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

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

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

---

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

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

jj의 이미지

타입시스템과 같은 컴파일러 기술의 발달과, IDE의 발달로 인한 결과겠지요. 헝가리안표기법이 나올 당시엔 그만한 이유가 있었으리라 생각됩니다.

--
Life is short. damn short...

htna의 이미지

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

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

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

WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra

익명 사용자의 이미지

헝가리언 표기법이 너무 복잡해서 쓰지 말자고 하는 것은 이해가 갑니다만 꼭 나쁜 것만은 아니라고 봅니다. 멤버변수에 "m_"대신에 this->를 쓴다는 것이 타이핑하기도 힘들고 더 복잡하게 보이게 합니다. 그리고 this->를 안쓰는 것으로만 문제가 해결 되진 않습니다. 멤버 함수만 하나 놓고 보았을때 이 변수가 멤버변수인지 아닌지를 한번에 알아볼수 있다면 가독성이 많이 증가됩니다. 해더만 한번 훑어보고 멤버 함수에서 이게 멤버변수 인지 아닌지를 정확히 기억해 낸다면 천재지요. 아마 저 블로그를 쓰는분은 한번에 다 기억할수 있는 엄청난 기억력에 소유자일 겁니다. 멤버함수가 피치 못하게 길어질 경우 "a_"접두사도 상당히 가독성에 도움이 됩니다. 저런 편파적인 시각으로 해라 마라를 강조하는 사람이 팀의 리더라면 참 피곤하겠네요.

creativeidler의 이미지

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

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

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

오호라의 이미지

하하.. 이글을 보니까 얼마전에 제가 다니는 학교 컴공카페에서 몇몇 사람과 실갱이를 버렸던 일이 떠오르는군요.

어떤 후배가 코딩은 프리스타일이라고 하더군요. FreeSytle 좋죠!!~
컴파일러를 무시하는 프리스타일까지도...ㅋㅋㅋ.

저도 그랬지만. 어떤 Notation을 쓰던지 잘 만들어진 표기법 가이드라인을 보는 일은 본인에게 많은 도움을 줍니다.

MS, Sun, Samsung, NASA, 헝가리안, 접미두사, posix, ansi...

암튼 M$가 헝가리안 표기법을 버린다면, 그건 앞으로의 환경, 방향, 방법, 목표....단지 여러가지 상황이 헝가리안 표기법과 맞지 않아서 일겁니다.

'쓰다보니 후졌네~', '어 이거 좋았다 안좋아지네...' 이런 수준이 아니란거죠.

가이드라인이란게 가이드가 바뀌면 라인도 바뀌겠죠...
세상에서 유일한건 M$사장이 왕부자란 것밖에 없습니다. ㅋㅋㅋ
몇십년후에 다시 헝가리안 표기법의 시대가 도래할수도...
아님, 코리안 표기법이라던지...ㅋㅋㅋ

PS. 이건 요즘들어 갑자기 생각난건데. M$ windows는 빈번한 부팅을 하게 하는데 이유가... On/Off를 자주하게 해서 Hardware부품들을 금방 소모되게 해서 교체시기를 앞당기게 하는 엄청난 음모가 아닐까요?! MS+Intel+수많은 업체들..

Hello World.

익명 사용자의 이미지

상당히 신기한게 모든 프로그래머가 다 똑똑한건 아니거든요. 가끔 보면 상당히 긴 메쏘드를 만드는 황당한 프로그래머가 존재하고 지역변수로 충분한데 꼭 멤버변수 선언하는 황당한 경우도 많습니다. 그런 프로그래머 한테는 "m_", "a_" 를 쓰도록 교육시키는게 나을 때가 많습니다. 그래야 멍청한 남의 코드를 code review할때 편하거든요. 지역변수로 충분한 변수를 멤버변수로 선언해서 짜는 프로그래머를 만나보시면, 무지 황당하게 긴 메쏘드를 꼭 만들어내는 프로그래머를 만나보시면, 생각이 달라지실 겁니다. 모든 프로그래머가 자기처럼 천재라고 생각하지 마세요.

crimsoncream의 이미지

그 황당한 프로그래머가 헝가리언표기법을 지켰는지는 어떻게 보장이 되나요? m_ 썼다가 전역으로 옮긴다음 변수명 안바꾸면 어떡하죠? 무조건 믿던가 결국은 선언부를 일일이 확인해야 하는 거 아닌가요? 헝가리언 표기법의 가장 큰문제는 룰이지만 직관적이지도 않고 검증하거나 강제할 수단이 없다는 거 아닐까요?

flurino wrote:
상당히 신기한게 모든 프로그래머가 다 똑똑한건 아니거든요. 가끔 보면 상당히 긴 메쏘드를 만드는 황당한 프로그래머가 존재하고 지역변수로 충분한데 꼭 멤버변수 선언하는 황당한 경우도 많습니다. 그런 프로그래머 한테는 "m_", "a_" 를 쓰도록 교육시키는게 나을 때가 많습니다. 그래야 멍청한 남의 코드를 code review할때 편하거든요. 지역변수로 충분한 변수를 멤버변수로 선언해서 짜는 프로그래머를 만나보시면, 무지 황당하게 긴 메쏘드를 꼭 만들어내는 프로그래머를 만나보시면, 생각이 달라지실 겁니다. 모든 프로그래머가 자기처럼 천재라고 생각하지 마세요.

오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.

creativeidler의 이미지

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

익명 사용자의 이미지

C를 숭배하던 저로서는...
처음 위도즈 플그밍 시작할 때, 미치는 줄 알았습니다...
도저히.. 도무지... 비효율적인 코딩방식... 이라고 생각했죠.
비효율적인거 확실합니다.
하지만, 그 나름대로의 이유가 있었습니다.
꼭 헝가리안 방식을 따라야 하는 것은 아니었지만, M$의 예제 코드들부터
시작해서 MFC/ATL/COM 코드들 보십시오.
당신이라면 아니 따를 수 있겠습니까?
게다가, 정말이지 C 언어처럼 자유로운 언어에 푹 빠져있는 저같은 프로그래머들은 각자의 코딩 스타일도 있을 뿐더러, 솔직히 C 언어의 자유로움은 코드 공유를 어렵게 만드는 것도 확실합니다. 즉, 가독성이 떨어지죠.
작은 프로젝트야 문제없지만, 큰 프로젝트는?? 나 혼자 끝나는 것이 아니라 누군가 이어받고 이어받고 이어받아야 하는 소스 코드라면?
만약 내가 마지막에 바톤을 이어받는다면... 끔찍할겁니다...
아마 거의 새로 재작성을 해버릴 겁니다.
(우리나라 프로그래머들.. 주석 제대로 쓰는 사람 보기 드뭅니다.. 정말... )
코드 자체나 프로그램의 효율성은 확실히 떨어뜨리지만, 업무의 효율성을 위해서 Windows API/MFC에서는 헝가리언 표기법이 탁월한 선택이였을지도 모릅니다. 아니 적어도 C++에서는 말입니다. 많지 않은 경험상 C와 OOP의 중간에 있는 C++에서는 더 이상의 표기법이 무엇인지 모르겠습니다.
이제는, m_ 이런 프리픽스가 없으면 불안합니다. 이놈이 어디서 온 놈인지..
strVar 이렇게 선언되지 않으면, 이놈이 뭘하는 놈인지 불안합니다.
nVar 이렇게 안되어있으면 어떤 값을 넣어도 되는 것인지 헤더를 찾느라, 고생해야 되겠죠... 그나마, 주석이라도 잘 되어있으면 행운이겠죠...
적어도, 협업 프로세싱에서는 헝가리안 중독성 심각합니다.
적어도, C++처럼 헤더를 왔다 갖다 해야하는 불편한 언어에서는 헝가리안 표기법처럼 맘편하게 해주는 것 못봤습니다.
뭐... 손가락 고생하는건 여전하지만요...

C#은 아직 공부하지 않았습니다만 C#에서는 헝가리안 표기법을 안써도되는 그만큼의 이유가 있겠지요. 시간나는데로 공부해야 되겟습니다...
하기사, JAVA에서 m_ 이렇게 변수 선언하면 좀 웃기던데...
같은 맥락 아닐까요?? C#에 와서야 (JAVA를 베껴서) 완전한 OOP언어에 접근하였다는 것인지...

꼭 헝가리안이 아니더라도, 저같이 실용주의 예술을 하는 프로그래머에게는 표기법이 상당히 중요합니다. 서로 같은 말을 써야 알아듣는법 아니겟습니까?
하여간, 헝가리안 중독성 꽤 됩니다... 적어도 윈도즈 기반 C++에서는...

M$의 이미지

VS

wafe의 이미지

헝가리안 표기법을 강제할만한 방법이 없기 때문에 문제라고 하셨는데, 그게 헝가리안 표기법에만 있는 문제라고 생각되지는 않습니다. 헝가리안 아니라 다른 코딩 규칙을 쓰더라도 peer review 같은 걸 하지 않는한 규칙을 제대로 지키고 있는지는 알기 어렵지 않나요?

Heejoon Lee

ㅡ,.ㅡ;;의 이미지

wafe wrote:
헝가리안 표기법을 강제할만한 방법이 없기 때문에 문제라고 하셨는데, 그게 헝가리안 표기법에만 있는 문제라고 생각되지는 않습니다. 헝가리안 아니라 다른 코딩 규칙을 쓰더라도 peer review 같은 걸 하지 않는한 규칙을 제대로 지키고 있는지는 알기 어렵지 않나요?

없으면되죠..

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


----------------------------------------------------------------------------

crimsoncream의 이미지

헝가리언만 나쁘고 다른 건 좋다는 말씀을 드린게 아닙니다.
만약 변수명에 변수의 자료형이나 스토리지 타입 혹은 스코프를 포함시켜 네이밍을 해야 한다고 주장하는 다른 코딩규칙이 있다면 그 규칙 또한 좋은 규칙은 아니라고 생각합니다. 만약에 그런 규칙이 보편적으로 타당하다면 fortran 에서 그랬었던 것 처럼 컴파일러 자체가 i로 시작하는 변수명은 몽딴 정수형으로 강제하도록 해야하는거 아닐까요. m_을 붙이면 무조건 멤버로 해석하고요.

저는 변수명을 자유롭게 만들수 있게 한 이유가 구현의 세세한 측면에 구애되지 않고 로직에 집중할 수 있도록 의도된 추상화라고 생각합니다. 만약에 그게 틀렸다면 컴파일러 구현자체에서 강제해야지 프로그래머 개개인의 의지 혹은 습관에 강제해서는 안된다는 거죠.

오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.

ㅡ,.ㅡ;;의 이미지

crimsoncream wrote:
헝가리언만 나쁘고 다른 건 좋다는 말씀을 드린게 아닙니다.
만약 변수명에 변수의 자료형이나 스토리지 타입 혹은 스코프를 포함시켜 네이밍을 해야 한다고 주장하는 다른 코딩규칙이 있다면 그 규칙 또한 좋은 규칙은 아니라고 생각합니다. 만약에 그런 규칙이 보편적으로 타당하다면 fortran 에서 그랬었던 것 처럼 컴파일러 자체가 i로 시작하는 변수명은 몽딴 정수형으로 강제하도록 해야하는거 아닐까요. m_을 붙이면 무조건 멤버로 해석하고요.

저는 변수명을 자유롭게 만들수 있게 한 이유가 구현의 세세한 측면에 구애되지 않고 로직에 집중할 수 있도록 의도된 추상화라고 생각합니다. 만약에 그게 틀렸다면 컴파일러 구현자체에서 강제해야지 프로그래머 개개인의 의지 혹은 습관에 강제해서는 안된다는 거죠.


제생각과 같으시군요.. 나이쑤..ㅎㅎ


----------------------------------------------------------------------------

지리즈의 이미지

crimsoncream wrote:
헝가리언만 나쁘고 다른 건 좋다는 말씀을 드린게 아닙니다.
만약 변수명에 변수의 자료형이나 스토리지 타입 혹은 스코프를 포함시켜 네이밍을 해야 한다고 주장하는 다른 코딩규칙이 있다면 그 규칙 또한 좋은 규칙은 아니라고 생각합니다. 만약에 그런 규칙이 보편적으로 타당하다면 fortran 에서 그랬었던 것 처럼 컴파일러 자체가 i로 시작하는 변수명은 몽딴 정수형으로 강제하도록 해야하는거 아닐까요. m_을 붙이면 무조건 멤버로 해석하고요.

저는 변수명을 자유롭게 만들수 있게 한 이유가 구현의 세세한 측면에 구애되지 않고 로직에 집중할 수 있도록 의도된 추상화라고 생각합니다. 만약에 그게 틀렸다면 컴파일러 구현자체에서 강제해야지 프로그래머 개개인의 의지 혹은 습관에 강제해서는 안된다는 거죠.

변수명 표기법은 관례와 같은 것이지요.

개인이 혼자 작업하는 것이면 변수명 명명법이 무슨 의미가 있겠습니까?

하지만, 여러 프로그래밍 기술의 발달로 인해서,
코드의 재사용성이 중요해지고,
라이브러리의 배포가 빈번히 일어나면,
이런 것들이 매우 큰 의미를 가지지요.

적어도 두사람만 작업해도,
변수명 명명법에 최소한의 규약이 필요해지는데,
수십명 아니 수만명이 이상이 이 코드를 사용하게 된다면,
이러한 표기법은 더욱 큰 의미를 가지는 것은 분명합니다.

변수명은 수학의 정의와 달리 트렌드에 가까운 범주이지요.
그 바닥에서 그렇게 쓰자면 따르는 수 밖에 없습니다.

물론 그 바닥에 속하지 않는다면, 별로 의미가 없는 말일뿐이구요.

There is no spoon. Neo from the Matrix 1999.

깜장물꼬기의 이미지

저도 저 블로그 읽어보았습니다.
블로거인 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."

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

김현민의 이미지

얼마전에 M$ 미국 현지에 있는 모바일 팀에서 일하시는 분의

이야기를 들은적이 있습니다.

그때 잠시 나왔던 이야기가 그분이 이전에 오피스 팀에 있을 때가

있었는데 오피스 하나 개발하는데 개발자가 무려 2000명 이상 이랍니다.

컴파일 하는데 6~12시간 정도 걸리고요.

그렇게 큰 프로젝트를 진행함에 있어서 노테이션의 일관성을

유지하는 것은 굉장히 중요한 일이라고 합니다.

다른 노테이션 많지만 M$에서는 헝가리언 노테이션이 적어도 C/C++

개발에 있어서는 최선의 선택이라 생각 했을 겁니다.

그리고 그것을 철저하게 지킴으로서 누가 봐도 알아 볼 수 있는

코드를 만든다고 합니다. 그리고 재미난 것이 개발자 들이 서로서로

상대방의 코드를 리뷰를 한다고 합니다. 그래서 헝가리언 노테이션을

조금이라도 지키지 않았다거나 혹은 M$에서 정한 규약에 조금이라도

어긋나는 부분이 있다면 다시 작업을 시킨답니다.

.NET 프레임 워크에서 버렸을 지는 몰라도 그 내부가 C/C++로 되어 있다면

헝가리안 노테이션으로 만들어져 있을 겁니다.

헝가리언 노테이션이 물론 비효율 적인 부분도 있겠지만 M$개발에 익숙해 지면

헝가리언 노테이션 중독에서 빠져나오기 힘든게 사실입니다.

API나 MFC 쓰다보면 헝가리언 노테이션 안쓰고 썩어서 쓰면 제가 짜증이

나서 보기가 싫을 정도니깐요.

익명 사용자의 이미지

저 개인적으로는 헝가리안 표기법의 적절한 사용에 한표를 던집니다.

구시대의 유물이니 쓰지 말아야 한다"라는 주장과 "대규모 프로젝트, 다수작업시 코드파악이 잘된다."등의 논란은 많지만 사용을 잘 하면 코드 분석 및 작성에 매우 도움이 되는 코딩 방법론입니다.

참고로 제가 다닌 대부분의 회사와 잘만들어진 소스(하프라이프 등)들은 대부분 헝가리안 표기법을 준수하더군요...

bookgekgom의 이미지

다들 헝가리안 노태이션에 대해서 많은 얘기를 하시는데 제가 궁금한건말이죠....

헝가리안 노테이션을 안쓰면 무엇으로 대신할수있느냐는 겁니다.

회사마다 다른 노테이션을 쓰나요?

이것을 좀 가르쳐주세요.

------------------------------------------------------------------------------

허접한 페도라 가이드 http://oniichan.shii.org

---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.

http://jihwankim.co.nr

여러 프로그램 소스들이 있습니다.

필요하신분은 받아가세요.

hongminhee의 이미지

헝가리안 노테이션은 보통 윈도 GUI 프로그래밍에서 쓰지 않나요? 최근의 윈도 GUI 프로그래밍은 VS라는 훌륭한 IDE를 가지고 있고(물론 상용이지만), 이것이 각 식별자가 어떤 타입이며 어느 클래스의 멤버인지 쉽게 알 수 있어서, 그것으로 대체할 수 있지 않나 생각합니다. 사실 그 정도가 아니라 리팩토링 툴 같은 것도 지원하죠. 특정 코드를 선택해서 extract method하는 것 등을 반자동으로 할 수 있더군요.

ppdha82의 이미지

헝가리안 노테이션에 대한 공부를 프로그래밍하면서 20년만에 처음 찾아봤네요... 사실 듣기는 많이 들었는데 대강 prefix 에 data type 을 붙여준다는 것만 알았어요. 그리고 제가 카멜 노테이션을 자주 써왔는데 이름이 카멜인줄 첨 알았네요... 게다가 카멜 노테이션을 헝가리안 노테이션으로 잘못 이해한 점도 있고요... 헝가리안 노테이션을 검색하다가 더 놀란 건 굉장히 많은 논쟁들이 있었다는 건데 이제 알게 되었다는 거네요... 예전 글이지만 역사 기록의 중요함을 알게 되었습니다. 고맙습니다. 선배님들...