Hungarian Notation(헝가리안 표기법)에 대해서 어떻게 생각하시
글쓴이: aero / 작성시간: 수, 2003/07/16 - 10:43오전
소스코드 작성할때 특히 MS계열쪽에서는 Hungarian Notation(헝가리안 표기법)을 많이 사용했고.. 하죠.
예) szName, iNumber 등등
MS계열에서 프로그램 하던사람들이나 좋다니깐 생각없이 그런가보다 하고 그걸 쓰던 사람들은
딴 플랫폼에나 언어에서도 그걸 굳이 쓰려고 하는거 같더군요.
MS에서도 .NET C# 등으로 넘어가면서 헝가리안 표기법을 포기한걸로 알고 있는데.
개인적인 생각으로는 요즘같이 타입채킹이 잘되는 컴파일러환경과 그리고 의미론상으로
충분히 변수 naming으로 나타낼수 있는걸 굳이 제각각인 방식으로 notation을 붙여서 오히려
코드의 가독성을 떨어뜨린다고 생각되거든요
여러분들은 이에 대해 어떻게 생각하시나요?
Forums:
Re: Hungarian Notation(헝가리안 표기법)에 대해서 어떻게 생각
혼자서 프로그램 하는게 아니라면, 팀의 회의를 거쳐서 어느 정도의 표기법 스타일은 있는게 좋다고 생각합니다. 뭐, 회사 차원에서 있으면 좋겠죠. 단순히
헝가리언 표기법 뿐 만이 아니라, 주석의 사용, 브레이스의 사용 이런것들도
전부 규칙을 정해두는게 좋을것 같습니다.
=========================
CharSyam ^^ --- 고운 하루
=========================
.........
전 옛날부터 유닉스환경에서 프로그래밍을 해서인지 몰라도
헝가리안 표기만 봐도 경기를 일으킵니다.
물론 사람 나름이겟지만...대문자랑 소문자가 한데 엮여서 한 10글자가
되면 이게 무슨뜻을가진 변수인지 한참 보고 있어야 하더군요...ㅜ.ㅜ
리눅스나 유닉스용의 공개 소스들을 보면 이렇게 되어 있는 경우도 있으나
조금은 유연하게 사용을 하더군요.
이런식으로요...저는 이런식이 훨 보기 좋다고 생각합니다. 그냥 쭉
szMemberName 써 버리면 변수 보기가 넘 힘들어요.물론 키보드 치기도
만만찮고요.
저같은 경우는 sz_member_name 이런식으로요
물론 sz같은 넘은 안쓰지만요. 이게 일아보기가 쉽더군요.
즉, '_' 가 있어야 보기가 편하더군요...
가독성 문제에서 저는 좀 반댑니다.
그럼..
서명.....음, 서명이라...
아싸!!! Three Go!
헝가리안 표기법..
저는 변수와 함수는 소문자와 언더바, 상수는 대문자 식의 간단한 표기법을 씁니다. 하지만 이 것도 쓰는 언어나 환경 나름인 것 같습니다. 자바는 객체마다 대문자화(캐피털라이즈) 되있길래 좀 적응이 안 됐었습니다. 근데 지금은 그게 더 자연스러워 보이더군요 (그 쪽에 한해서)
"no error was found with his codes"
가만히 보면 정작 마이크로소프트에서 일하는 개발자들도 헷갈려서 DWORD
가만히 보면 정작 마이크로소프트에서 일하는 개발자들도 헷갈려서 DWORD와 ULONG, SIZE_T, UINT를 마구 섞어 쓰는 걸 볼 수 있습니다(똑같은 플래그를 flOptions이라고 했다가 dwFlags라고 했다가 uFlags라고 했다가...). 문자열 앞에 sz 접두사도 붙였다 안붙였다 마음대로죠. 아예 커널쪽에는 헝가리안을 안쓰고요. 이렇다 보니 가독성과 이해도가 오히려 낮아집니다.
반면 개인적으로 윈도 스타일로 변수 이름을 가능한한 길게 쓰는 것은 코드 가독성이 훨씬 높아지는 걸 경험하고 있습니다. 유닉스 스타일은 며칠 지나면 왜 이름을 그렇게 만들었는지 제자신도 잊어 버리기가 일쑤고, 남이 만든 변수명의 의미를 유추하느라(특히 주석이 없을 경우) 시간이 소비될 때가 자주 있습니다.
[quote="방준영"]반면 개인적으로 윈도 스타일로 변수 이름을 가능한
절대적인 찬성입니다.
변수 이름은 최소한 핵심 단어는 줄여쓰지 않는것이 좋다는 생각입니다.
여담으로
저는 보통 자동변수는 Stack을 이용하므로 s_ 을 붙이고
전역 변수는 global에서 g_ 을 사용하고
typedef으로 한번 다시 정의된것은 t_ 을 붙이며
#define으로 정의된것은 DEF_ 을 붙이고
enum으로 순차적으로 선언된것이라면 e_ 을 붙입니다.
typedef struct 로 선언된 첫 선언은 ts_ 로 붙이고
const 의 경우는 c_
내부적으로 static인 경우 맘대로 정합니다. 하지만 대부분 __xxxx__ 이렇게
사용합니다.
완전히 헝가리표기법은 무시한 저만의 표기법입니다.
좋은 습관은 아니지만 저 자신의 생각으로는 이게 가독성이 높습니다.
다른 사람은 아니더라도.....
반드시 헝가리안 표기가 아니더라도, 표기법을 따르는 것이 결국은 시간을
반드시 헝가리안 표기가 아니더라도, 표기법을 따르는 것이 결국은 시간을 줄이는 길이라 믿고 있습니다.
개인적으로는, 반드시는 아니지만, 헝가리안 표기법을 종종 사용하고 있습니다. 그리고 이로 인한 득을 많이 보고 있습니다.
berise@nowhere.comes.out
어느정도 찬성
전에 윈도에서 헝가리안 표기법을 썼는데..
리눅스에서 프로그램에서.. 변수명을 적어야 할때...
헝가리안 표기법을 씁니다.
nSonOfGod 이런식으로 하면.
좀 햇갈리는 면이 있지만..
전 헝가리안 표기법..+ '_' 표기법이 좋던데..
nSon_of_god로 쓰고 싶더군요..
아직 정립이 안돼서..
일단.. 헝가리안 표기법을 쓰고 있습니다..
다만.. char [] 형을 쓸때 햇갈리더군요..
lps, lpsz, sz, p 중 무엇을 쓰면 좋을까?
char buff[1024]; 이런 경우
char lpBuff[1024]; ?
char pBuff[1024];?
char lpsBuff[1024]; ?
char arrBuff[1024]; ?
어느것이 낳을까요?
고작 블로킹 하나, 고작 25점 중에 1점, 고작 부활동
"만약 그 순간이 온다면 그때가 네가 배구에 빠지는 순간이야"
저는 함수명은 소문자와 언더바 '_',매크로와 typedef된 것은
저는 함수명은 소문자와 언더바 '_',
매크로와 typedef된 것은 대문자와 언더바 '_',
변수명은 type을 나타내는 접두어는 소문자.. 변수의 의미를 나타내는 단어는
언더바 없이 헝가리안 표기법을 사용합니다.
일단 이렇게 함으로서 매크로와 type, 변수를 이름만으로 구분할 수 있고
제가 모듈화한 서브모듈이나 라이브러리를 동료가 사용할 때는 함수
인터페이스나 매크로 외에는 자세히 알 필요가 없기 때문에 가장 가독성이
좋다고 생각되는(타이핑때문에 좀 귀찮긴 하지만..) '소문자 + _ ' 형태를
사용하고 있습니다.
자신만의 스타일은 확실히 존재하는 것 같습니다.
물론 자신에게 익숙하다고 해도 같이 일하는 동료들이 보기 어렵다고 하면
팀이나 회사 단위로 표기법을 일치시키는 것도 좋겠죠 ^^
s(˘∼˘*)z,·´″"`°³о$ √(´∀｀√)... (˘ヘ˘ㆀ)a
Re: 어느정도 찬성
그 경우에는 어떤 식으로 그 데이터가 사용될 것인지가 명확하면 문제가
없을 텐데요? 만약 단순하게 문자열의 배열이라면 rchBuff[] 일 것이고,
NULL terminated string 이면 lpszBuff 또는 pszBuff(어차피 FAR 이런
것은 의미 없으니... :-) 그냥 string이면 lpsBuff, psBuff 가 되겠지요.
헝가리언의 목적은 변수의 의미를 명확히 하는데 있습니다. psBuff 이거나
rchBuff이라면 여기다 대고 strlen 이런 함수를 부르면 뭔가 문제가 있다는
말이 되겠지요. 타입 체킹만을 위해서 쓴다면 좀 그렇네요... 그리고 _를 좋아
하시는 분들은 아마 _가 다른 의미로 쓰이는 언어가 있다는 사실도 모르시고
또 aVariableName이 그 언어에서 시작이 되었다는 것도 모르시는 분들이겠
지요? 그 언어는 뭘까요? 아마 객체 지향 교육울 재대로 받으신 분들은 한번
쯤 사용하셨을 언어입니다.
전 객체지향 교육을 제대로 못받아서 그런지 모르겠군요.무슨 퀴즈퀴즈
전 객체지향 교육을 제대로 못받아서 그런지 모르겠군요.
무슨 퀴즈퀴즈 게시판도 아니고 아시다면 제대로 설명을 해주시면 좋으셨을 텐데요.
헝가리안의 가장 큰 문제는 그걸 주장하는 사람들이 대개의 경우 빠릿하게 못쓴다는 겁니다. 코드를 바꿀시에 type은 바꾸면서 변수명은 안바꾸는 경우도 꽤있고. 말씀하신 것처럼 부적절한 이름을 사용하는 경우도 있고 소소한 인덱스 변수에 거창하게 타입부터 의미 설명까지 죽 해대서 사람 피곤하게 하고.. 위에서도 말씀하신 내용이지만 개인차로 인해 같은 의미에 다른 유형을 적용해서 이름을 만들고 뭐 그런 일들이 다 반사라는 거지요. 이런 고로 지키기 어렵고 지켰을 때의 이익이라는 것이 별로 크게 느껴지지가 않는군요.
또 경험에 비추어서도 헝가리안으로 된 소스를 받았을 때 변수 이름만으로 그 변수의 type이나 의미를 추정하는 경우는 거의 없었습니다. ctag를 쓰든가 안되면 grep을 해서라도 찾아보지.. 제 생각엔 변수명 작명같은 극히 인적인 요인들에 의존해서 convention을 구성하는 것보단 ctag나 indent 같은 툴을 공용으로 도입해 소스를 구조화해서 누가 뭔 생각으로 만들었든 파보기 쉽게 만드는게 파보지도 않고 알 수 있게 하려는 시도보다 현실 적이라는 겁니다.
저도 oo 툴을 쓸때는 aVariableName 스타일을 쓰지만 헝가리안은 거추장 스러운 반면 특별한 이익은 없던거 같은데.
오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.
Re: 어느정도 찬성
"그 언어"에도 타입이란 게 존재합니까? 8) 타입이 없다면 헝가리안 표기법이 필요할 리도 당연히 없겠지요...
[quote="minzkn"]저는 보통 자동변수는 Stack을 이용하므로
스택대신 레지스터에 저장되는 경우도 많으므로 지역 변수를 뜻하는 l_을 쓰는 것이 더 좋지 않을까요. l_ (local) <-> g_ (global) s_는 정적 변수를 뜻할 때 쓰는 것이 좋을 듯 합니다.
또 한가지 방법은 아무것도 안붙이면 지역변수로 취급하는 것입니다.
저의 경우에는....
그 플랫폼의 소스들을 그냥 흉내냅니다... -0-
자바에서는 자바 스타일대로...
VC++에서는 헝가리안 비스무리하게....
유닉스에서는 또 그 나름대로...
뭐 정확히 똑같이 흉내내는 것은 아니지만요...
local 변수는 가능한 한 짧게 약어로, global/static 변수는 가능한 한 길게,
변수이름 붙이는 데에는 뭐 이정도 규칙만 갖고 하는 것 같네요....
Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24
공동작업일 경우는 회의를 거쳐서 표기법결정.개인 작업일 경우는 내맘대
공동작업일 경우는 회의를 거쳐서 표기법결정.
개인 작업일 경우는 내맘대로 기분대로...
공통적으론 헝가리안은 결사반대...
변수에 타입을 표기한다는 자체가 웃긴발상인것 같습니다.
첨에 윈도 프로그래밍 할때는 이렇게 해야하나부다 하고 생각했었는데...
그게 아니더군요.
짜증만 나고 타수만 늘리고... 실제로 요즘의 자동완성 기능이 있는 IDE에선 헝가리안 노테이션의 경우 특히(!) 별 이득을 못봅니다. 타입이 같은 놈들이 다 줄을 서잖아요.... -_-;;
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
저는 특별한 방식이 없고 그때그때 쓰고는 하는데... 보통 유닉스 코드
저는 특별한 방식이 없고 그때그때 쓰고는 하는데... 보통 유닉스 코드 보면
나오는 그런 식으로 씁니다. 타입 구분 없이 소문자 1-4문자 정도...
가끔 전역변수 등은 다른 분 말씀대로 g_같은것 붙이기도 하고요.
변수 명을 길고 명확하게 한다고 해 봐야 긴 소스 볼때는 사실 별로 도움이
안되는 것 같아서.. 가령 유닉스 소스 보면 i,j,k (아마 포트란 영향이지만)
를 for루프 변수로 많이 쓰는걸 볼 수 있는데 이런걸 굳이 복잡하고 길게
표현할 필요는 없을 것 같고요. 소스 볼 때/나중에 관리할 때 필요한 것은
잘 된 주석문이나 소스에 대한 안내서이지 변수 이름 잘 지었다고 그다지
가독성이 높아질 것 같지는 않습니다.
ruby같은 언어는 변수 이름만 보면 전역인지 로컬인지 클래스 변수인지,
타입이 해시인지 배열인지 쉽게 구분이 가니까 그런 식의 언어 구성도 좋을것
같습니다.
--
익스펙토 페트로눔
[quote="crimsoncream"]헝가리안의 가장 큰 문제는 그걸
개인적으로는 _ 를 선호합니다만, 헝가리안 스타일에 대한 부분은 동감합니
다. 저 역시 헝가리안 스타일의 경우 유지 보수에 추가적인 비용을 요구하
기에 사용을 피하고 있습니다. 변수명에 type 을 표기한다는 사실 자체가
변수명과 type 을 program text 상에서 정적으로 묶어 버리는 결과를 낳고,
후에 변수의 type 이 변할 때 변수명을 일관되게 고쳐주지 못하면, 프로그
램 수정 과정에서 틀린 내용으로 남아있는 주석과 다를 바 없는 결과를 낳
더군요 - 유사한 이유로 주석을 많이 다는 것 보다는 프로그램 자체를 이해
하기 쉽게 작성하려고 노력하고 있습니다. 그래서, 프로그램 전체에서 유의
미하게 사용되는 type 의 경우 typedef name 으로 추상화하고, 덜 빈번하게
사용되는 (global) 변수일수록 자세한 의미를 변수명에 담는 것을 원칙으로
하고 있습니다.
--
Jun, Woong (woong at gmail.com)
http://www.woong.org
농담으로 한 말인데... :-) Smalltalk이 그렇습니다. _ 가
농담으로 한 말인데... :-) Smalltalk이 그렇습니다. _ 가 <- 식의 화살표로
나오고 C라면 =와 같은 의미로 사용됩니다. 위에서 방준영씨가 말씀하신
것 처럼 ST는 Type이 없습니다. 전부 객체이고 동적인 언어라 파벌에 따라
좋다 나쁘다가 확실히 갈라지죠.(저는 당연히 동적인 것이 좋다는 파입니다 :-)
헝가리안을 쓰든 안쓰든 그건 말씀 하신 것 처럼 빠릿하게 쓸 수 있다면,
도움이 될 수 있다면 좋은 것이고 빠릿하게 쓸 수 없다면, 단지 형 검사를
위해서만이라면 별로죠. 고생만 늘릴 뿐.
변수의 이름이라든가 인덴테이션 등은 개인의 기호에 해당하는 문제인 것
같습니다. 물론 기호를 떠나서 좋지 않은 습관을 가진 사람들도 많습니다만.
공통의 규칙이 있고 그 규칙이 도움이 된다면 좋은 것이겠지요.
Re: 어느정도 찬성
underscore (_) 가 다른 언어에서 어떻게 쓰이는지는 C/C++ (혹은 명칭으로
underscore 를 허락하는 언어) 과 그 언어가 (mixed programming 등의 목적
으로) 외부로 export 되는 명칭을 공유하지 않는 이상 아무런 현실적인 문
제를 낳지 않을 것입니다.
C/C++ 은 명백하게 underscore 를 명칭을 구성하는 문자 중 하나로 정의하
고 있고, underscore 를 명칭 구성시에 space 의 의미로 사용한 것은 현대
프로그래머의 무지가 아닌 매우 오래된 관례입니다 (표준이 언어나 라이브
러리를 통해 정의하고 있는 많은 명칭들도 그와 같은 관례를 따라
underscore 를 사용하고 있습니다). 더구나, C 에서 명칭에 사용되는
underscore 는 단순히 명칭을 구성하는 문자 이상의 의미를 가져, 그 위치
에 따라 매우 중요한 의미를 부여하기도 합니다.
--
Jun, Woong (woong at gmail.com)
http://www.woong.org