헝가리안 표기법은 안 쓰는 이뉴는 무엇일까요..

moonhalo의 이미지

윈도우로 공부를 시작해서 인지 헝가리안 표기법에 많이 익숙해져 있습니다.
안 쓰는 것 보다는 가독성도 높고, 형 변환으로 발생할 수 있는 문제점도
인식하게 해주는 게 장점이라고 생각합니다.
그래서 저는 쓰는게 좋다 쪽인데..

요즘 코딩 트렌드를 보면 안 쓰는 쪽으로 가는 것 같네요.
구글 코딩 가이드(http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml)에도
변수는 my_exciting_local_variable 이런식으로 써라..
저라면 nMyExcitingLocalVar 뭐 이렇게 되겠네요.

쓰면 안 좋은 이유가 뭘까요? 혹은 안쓰면 좋은 이유는 뭘까요..?

7339989b62a014c4ce6e31b3540bc7b5f06455024f22753f6235c935e8e5의 이미지

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

좀 길긴 하지만 읽어볼만 합니다. (번역서도 있을 듯...)

---8< 서명 -----------------
애니메이션 감상 기록 http://animeta.net/

winner의 이미지

우리가 쓰는 일상언어는 타입을 문맥과 문법을 통해서 유추합니다.
특별히 강조하고자 하는 경우를 제외하고는 각 단어나 형태소가
스스로 자신은 어떤 형식(혹은 클래스)이다라고 쓰지 않죠.

객체를 더이상 구체화할 수 없는 타입이라고 하죠.
거꾸로 이야기하면 객체는 유일무이한 타입이라고 할 수도 있습니다.
즉 동일한 인간이자 대통령이라는 타입을 가지고 있는
'노무현'과 '이명박'은 분명 다릅니다.
인간이라는 타입과 대통령이라는 타입을 통해 작성된 문장이 잘못된었다는 점을
찾을 수도 있겠지만 '노무현'과 '이명박'이라는 단어를 통해
잘못된 점이 더 잘 보일 가능성이 높을 겁니다.

물론 우리가 작성하는 source code라는 것은 이상적으로 추상화가 잘 된 형태를
지향하기 때문에 그런 경우 타입의 역할은 매우 중요합니다.
하지만 타입정의를 잘 하기 전에 각 객체의 이름을 먼저 신경쓰는게 좋겠죠.

ps. 제가 '노무현'과 '이명박'을 programming한다면 타입을 명세화하는 과정에서
상당히 동떨어진 곳에 둘겁니다.

ifree의 이미지

노무현과 이명박 은 Human 을 상속한 President 의 객체로 해야 하나요?
아니면 두 클라스를 다중상속하는 별개의 클라스를 따로 만들어야 합니까?

두 객체가 같은 타입을 가져서는 안돼겠죠?

drawhan의 이미지

성인의 범주에

그다음에 설치류 범주에...

lazycoder의 이미지

타입과 스코프를 왜 써줘야 하는지.. 특별한 이유가 있나요?
별로 중요하지 않다면 안써줘도 될겁니다.

보통 가독성은 타입이나 스코프가 어떻게 되는지보다 무엇에 쓰는 놈인지 직관적으로 알수 있게 하는 것이 더 중요하다고 봅니다.
그리고 네이밍으로 잘못된 캐스팅을 절대 막을 순 없다고 단언 할 수 있습니다.

moonhalo의 이미지

예 맞습니다. 절대 막을 수는 없지만
wLocalSize = dwRcvSize;
에서 DWORD가 WORD에 대입되니까 데이터 유실이 생길 수 있구나라고 짐작할 수 있습니다.
LocalSize = RcvSize 였다면 쉽게 보이지 않았겠죠.

그래서, 쓰나 안쓰나 상관 없으면 쓰는게 좋지 않을까 하는 생각에 질문을 드렸습니다.

unipro의 이미지

요즘에는 컴파일러가 워낙 좋아져서 옵션만 잘 사용하면 대부분의 실수를 잡을 수 있더라구요.
----
내 블로그: http://unipro.tistory.com

내 블로그: http://unipro.tistory.com

klyx의 이미지

데이터가 유실된다는 것은 매우 중요한 정보입니다.
이런 중요한 정보라면, 짐작을 통해서 알리기 보다는, 명시적인 형변환이나 주석을 통해서 확실히 전달하는게 좋지 않을까요?
사실 암묵적변환이냐 명시적변환이냐는 C VS C++과도 연관되며, 헝가리안 표기법은, 옛날 C처럼 지역변수도 전부 맨앞에 선언해서, 저~~앞에서 선언한걸 중간에 가져다 써야하거나, 전역변수가 난무하는 상황에서는 실수를 줄여줄수 있겠지만, C++처럼 대부분이 지역변수이고, 그것도 변수를 이용하기 직전에 선언하므로, 형이 무슨형인지 모를 일도 없습니다.
C도 이제는 중간에 변수 선언도 가능하고, 더불어 코드가 길어져도 요즘은 IDE의 도움덕에 형도 바로 알수 있지요.
다만 보이드 포인터나 typedef가 난무하는 상황이라면 헝가리안표기법이 유용할수도 있겠습니다...만, 보이드 포인터가 난무하는 상황을 만들지 않는게 좋겠지요.

freeuser의 이미지

옛날에 헝가리안안쓰면 마치 이상한놈 취급하던사람도 있더군요..

이런모든것이 다 자신만 옳고 다른사람은 틀렸다는 독선적인 생각아닐까합니다.

"내가 옳다 넌왜 하지 않느냐..니가 덜써봐서 잘모르는 것이다. 무조건 해봐라."

이런식의 고집을 내세우던 사람을 본적있었는데.. 마치 벽을 보는듯하더군요..

최소한 상대도 그것을 알고 있지만 쓰지않는것에 대해서도 인정할줄알아야 하지 않을까요..

moonhalo의 이미지

오해가 있었던 것 같네요.
뭐가 더 좋을까요 라고 물어본건데 독선적이라니요...

chadr의 이미지

요즘은 툴들이 좋아서 굳이 변수 이름에 타입과 같은 정보를 넣지 않아도 툴이 알아서 금방 찾아주기
때문에 그럴바에는 차라리 해당 변수가 무슨일을 하는지 한번에 알아보기 쉽도록 하기 위해서 안쓰기도 합니다.

저는 툴이 좋아지다 보니 점점 헝가리안은 안쓰는 경향으로 가고 있습니다.
툴이 열악한 환경에서는 그냥 헝가리안 쓰는게 낫겠죠.

그냥 그때그때 환경과 경우에 따라서 판단하시면 될것 같습니다.
정답은 없습니다.
-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.

-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.

moonhalo의 이미지

아.. 데이터 형보다는 하는 일에 집중해서 변수명을 정한다는 거군요.
감사합니다.

MovingSpotlight의 이미지

워낙 툴들이 좋아져서(가령, Visual Assist) 변수의 상태 및 정보를 확인하기가 정말 편해졌죠.
----
준비하세요. 당신 차례입니다.

----
준비하세요. 당신 차례입니다.

lagendia의 이미지

안 쓴다기 보다 Coding Convention에서 헝가리안 표기법을 채택하는 경우가 그렇지 않은 경우보다 적어서 그런 것 같아요. 좋고 나쁨을 따지는 것보다 일관성 있게 개발하는 게 프로젝트에는 통일성도 있고, 일치하여 두면 유지보수하기도 편해지고, 프로젝트 팀원 간 커뮤니케이션에도 더 도움이 되는 것 같아요.

moonhalo의 이미지

예. 좋은 의견 감사합니다. ^^
이 부분도 결정에 중요한 요소가 될 것 같네요.

whitelazy의 이미지

헝가리안 표기법 자체는 나쁘지 않습니다. 변수의 타입이나 스코프등을 명확하게 알 수 있으니까요...
근데 요즘 ide에서 논리 에러면 몰라도 변수명 몰라서 프로그램 잘못 짤 일은 적으니까 별로 필요성은 모르겠습니다...

윈도우 소스보면 자기네들 매크로로 재정의 해 놓은건 원래 타입이 아니라 매크로 명을 줄여서 붙여놓으니
저처럼 윈도 프로그래도 아니고 머리좋은것도 아닌 사람은 변수명앞에 왠 노이즈 낀것처럼 보일뿐이고....
해서 저는 헝가리안 표기법은 싫어합니다...;;;

차라리 버튼이면 btnOK나 OkButton, ButtonOK 이런식으로 변수의 의미를 기술하는 prefix나 postfix는 의미도 명확하게 해주고 변수가 이름 겹치는 일도 줄여주고....해서 많이 사용합니다만... m_nLen 이런식으로 멤버변수에 넘버타입에 Len이란 변수다 식으로는 잘 안씁니다. 아예 len이나 length라고 쓰지요... 알아보는데 지장없으니까요.. 명시적으로 멤버 변수라고 보이고 싶으면 this를 쓰면되고....

어쨌건 위와 같은 문제도 있고 오히려 가독성이 떨어지는 사태가 발생하고 해서 최근에는 헝가리안 표기법을 잘 안쓰는걸로 알고있습니다.
일례로 MS에서 만든 C#에서는 변수명에 헝가리안 표기법을 거의 사용하지 않죠...

http://www.pdfpro.co.kr/blog/jeong/archive/20080801
이런 블로그가 있군요 제 의견과 상당히 일치하는글이라 링크 겁니다.

moonhalo의 이미지

가독성이 떨어진다고 느끼는 분들도 계시는 군요.
그러면서 btn, g_ 같은 접두어는 좋다고 느끼는 부분도 새로웠습니다.
쓰자, 말자 보다는 필요하다면 쓰자라고 정리되는 느낌입니다.

whitelazy의 이미지

btn은 접두어이기도하지만 그냥 Button 약어입니다. OkBtn = OKButton btnOK = ButtonOK 등등...
타이핑 줄이기위해서 쓰는 internationalization을 i18n로 자주 표기하는것과 같이 말이죠 ....
함수라면 GetUserInfomationCount 라고 좀 말도안되지만 긴 이름을 가진 함수를 만들수도있고 GetUserInfoCnt 라고 좀더 줄여서 쓸수 있습니다. 이런의미입니다.

자주쓰고 의미가 명확한 단어를 표기하는 경우... 즉 누구나 봐도 알수 있을법한 단어 중에 정말 많이 써서 손아픈경우... Button -> btn 이나 뭐... Label -> lbl 등등은 구분을 해주기 위해 쓰는경우가 있습니다. 전 이것도 잘 안하고 캐멀케이스나 유닉스 스타일로 풀어쓰는편인데... 같이 작업하시는분들이 이거라도 붙이자 하셔서 ㅎㅎㅎ

CString name: 사람의 이름을 저장하는 변수일껍니다...
CLabel lblName: 화면에 사람 이름을 출력해주는 컨트롤이겠죠... 특히 name 이라는 문자열 변수를 화면에 출력해주는 놈일껍니다...
이런식으로 자료형과 같은 이름을 가지게끔 하고싶은 컨트롤들이 있습니다.... 세트로 가게하고싶을때 prefix를 사용합니다. 즉 이름짓기 귀찮은거죠.

lblName을 NameLabel, label_name name_label 식으로도 이름지을 수도 있겠지만... 저는 사용하는 언어와 툴을 따라갑니다.
java나 C#등이겠지요... 이렇게 맞춰주면 나중에 언어에서 제공해주는 api가져다 쓸때 함수이름들이랑 어울려보여서 제 경우는 읽기 좀더 났더군요.

중요한건 이와 같은경우는 제 경우입니다 ^^;; 편하신대로 선택하시면 되겠죠...
네이밍 룰이 팀 프로젝트라면 팀에서 정해진 네이밍 룰대로 가시면될테구요. 없다면 강력한 리더쉽을 발휘하는척 하며 내편한대로 만들어버리셔도되고...

코딩 컨벤션 이라는건 개인이던 여러명이던 개발시 개발 효율성과 상호 가독성 나중에 그 코드를 읽어야하는사람의 코드 가독성을 확보하기 위해서입니다. 너무 복잡해서 못하겠다 하지 않는한 그 코드를 개발하는 사람 혹은 개발팀이 편한게 장땡인거죠.... 규칙만 일관적이면 됩니다. 이 변수는 캐멀케이스로 xmlData 식으로 해두고 다음 변수는 xml_parse_result 식으로 왔다갔다만 안하신다면요...

tj의 이미지

안 예쁘고 치뤄야하는 비용에 비해서 얻어지는 게 별로 없으니까요. 사람 머리의 문맥과 일반적인 사용 관례를 적용하는 능력은 고려하지 않고 오히려 그걸 방해하는 방향으로 표기를 하는거니 효율이 좋을 수가 없을 거 같아요. 딱딱한 코딩 규칙들도 비슷한데 머리가 주된 원칙들 + 자잘한 예외상황을 처리하는 데 탁월하니 거기에 맞춰서 주된 줄거리들을 세우고 나머지는 유연하게 가는게 효율적인데 전체를 다 규칙으로 정해버리려고 하면 규칙을 세우고 따르는 즐거움 외엔 별로 얻을게 없는 것 같습니다. 누가 주절주절 적어놓은 규칙들보단 대자연의 기나긴 엔지니어링 결과물인 머리를 믿으세요.

김동수의 이미지

무언가 나온지 오래되었고 대세가 될거 같았던게 잘 안쓰이는 이유는 간단합니다.

"어딘가 구리기 때문이죠."

...

-------------------------------------
김동수 - Prototype for Evolution

김동수 - Prototype for Evolution

imyejin의 이미지

http://mindprod.com/jgloss/unmainnaming.html

이거 유명한 고전인데요, 너무 오래된데다 요즘은 헝가리안 표기법을 MS도 버리고 있으니 아무래도 이 유머를 알고 있는 사람이 줄어드는 것 같군요. 실제 프로젝트에서 벌어진 일을 예로 든 헝가리안 표기법의 강력함:

Quote:
Insist on carrying outright orthogonal information in your Hungarian warts. Consider this real world example: "a_crszkvc30LastNameCol". It took a team of maintenance engineers nearly 3 days to figure out that this whopper variable name described a const, reference, function argument that was holding information from a database column of type Varchar[30] named "LastName" which was part of the table’s primary key. When properly combined with the principle that "all variables should be public" this technique has the power to render thousands of lines of source code obsolete instantly!

이거 말고도 저 페이지에 보면 여러가지 이유가 있습니다. 제가 생각하는 가장 큰 문제점은 하나는 변수 이름에다 타입을 적어 놓음으로써 API 버전업을 한다거나 하는 등의 이유로 타입을 바꾸는 일이 생기는 경우에는 변수를 일일이 다 찾아가며 고쳐야 한다는 점입니다. 실수로 안고치고 놔두면 변수 이름만 보고 엉뚱한 타입으로 오해할 수 있죠. 이게 많이 쓰는 라이브러리 API일 경우에는 정말 골때려지게 됩니다. MS도 아마 이것 때문에 버리려고 하는 걸거에요.

헝가리안 표기법이 나온 이유 자체가 C의 타입 시스템이 가지는 한계 때문에 typedef와 타입 캐스팅을 너무 많이 하다 보니 타입이 추적이 되질 않아서 나온 궁여지책일 뿐입니다. C#만 해도 VS에서 변수 위에 커서 올려놓으면 타입이 뭔지 다 보여주니 변수에다 타입을 굳이 적을 필요성이 이제는 거의 없겠죠.

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

winner의 이미지

적당히 쓰면 괜찮을 겁니다.
Type은 사실 syntax에 의해서만 점검되는게 아니라 semantic을 가지는 경우가 있으니까요.
Singleton이 그런 경우가 많고요. g 접두사는 허용을 하자는 것도 그런 경우가 많습니다.

체스맨의 이미지

1. 표기법을 정하다보면, 접두사들이 넘쳐나게 되고

2. 넘쳐나다보니 같은 타입의 변수에도 개인마다 불일치의 가능성도 발생하고,

3. 유지 보수 과정에서 어떤 경우는 변수 타입을 바꾸게 되는 경우도 생기는데 헝가리 표기를 엄격히 따르자면 그 때마다 해당 타입이 사용된 소스를 전부 고쳐야된다는 것입니다. 하나의 예로 윈도우즈의 윈도우 콜백 함수 3번째 인자가 WPARAM 인데, 16비트 윈도우즈에서 이것은 WORD PARAM 즉 2바이트 정수였으나, Win32 에서는 4바이트 정수로 변경되었습니다. 하지만, 여전히 이 파라미터의 이름은 WPARAM 이죠. ( 아... 위에도 이게 언급이 됐네요.. -_-; 죄송합니다. )

반면 타입 체크가 비교적 느슨한 C 언어라해도 선(미리) 선언 구조에 의해, 변수의 타입이 확정되어있고, 개체 지향 프로그래밍이 대세를 타기 시작하며 언어의 타입 체크가 강화되는 것이 대세이기 때문에 굳이 그 타입을 변수 이름에 표기할 필요는 없다고 봅니다.

Orion Project : http://orionids.org

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.