헝가리안 표기법의 장점..
1. 변수 이름만으로 그 변수나 무슨일을 하는지 알수 있다?!
왼쪽은 일반 사용자들이 변수이름으로 사용하는
방식이구요 오른쪽은 헝가리언 표기법 형태로
변수이름을 만든 형태 입니다.
active -> bActive Boolean 변수
size -> nSize 정수 변수
size -> fSize 실수 변수
name -> strName 문자열 변수
pi=3.14 -> PI=3.14... 상수값(변수를 대문자로)
size -> g_nSize 전역변수
snow -> ins_Snow 인스턴스 변수
어때요?
변수명만 보고도 그 변수가 무슨 타입인지를 바로 알수가 있죠?
이게 바로 변수이름 앞에 변수 타입을 나타내는
접두어를 붙여 변수명을 나타내는 것을
"헝가리언 표기법"
이라고 합니다.
이 헝가리언 표기법은 일반 프로그래밍 쪽에서는
많은 프로그래머들이 사용하고 있는 방식 입니다.
물론 대부분의 프로그래머들이 자신에 맞게 편한 방법으로
변형 되어서 사용하지만요.
참고로, 이 표기법은 Microsoft프로그래머인
Charles Simonyi를 기리는 뜻에서 사용되기
시작했다구 그러는데...
2. 함수이름에 대하여
함수 이름또한 변수 이름과 거의 같습니다.
일반적으로 함수 이름은
동사 + 목적어 또는 동사 + 보어 로 만들고 각 단어의 첫글자는
대문자로 나머지는 소문자로 씁니다.
예를 들어 볼까요.
CreateObject()
Init()..
이렇게요.
3. 컴포넌트의 맴버 변수에 대해서..
width -> m_nWidth;
height -> m_nHeight;
enabled -> m_bEnabled;
visible -> m_bVisible;
selected -> m_bSelected;
일반적인 방법과 다른점은 변수 이름 앞에 m_이 붙었다는 내용입니다.
이 뜻은 맴버(Member)변수라는걸 나타내는 뜻입니다.
4. 결론.
헝그리안 표기법 단점어떤것 같아요?
원문 : 야웅닷컴 http://yawoong.com/board/view.php?id=tutorial_component&page=1&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arrange=headnum&desc=asc&no=2
"모야~~ 귀찮게시리 이렇게 할 필요 있나!?" 라구
생각하실 분들도 있을꺼에요.
하지만,
코딩해서 자기만 본다면 변수나 함수이름을 어떻게
만들어서 사용하던지 상관 없겠지만 만약 코드가 다른
사람들도 봐야 한다면 변수에서부터 많은 시간이 투자될거 같네요.
특히 플래시가 아주 유동적이어서(플래시 6.0버젼까지) 변수 선언 없이 하나의 변수에
문자도 가능하고 숫자, 기타 모든 변수타입이 사용될수 있으니까요..
하지만 이건 치명적인 버그를 만들어 낼수 있는 하나의 미끼를 재공합니다.
그래서인지..
플래시 7.0에서는 좀더 변수선언및 함수선언이 엄격하게 변경된건지... ^^
일반 프로그래밍을 해 보셨던 분이라면 입문서의 모든 책들이
헝그리언 표기법을 따라서 예제들을 만듭니다. 그래서 자연히
이런 책을 보고 프로그래밍을 시작하시는 분들은 이런 변수이름
만드는 습관에 젓어 들게 됩니다. 하지만
플래시 액션 스크립터나 웹프로그래밍을 하시는 분들은
쉽게 접하실수 없을꺼에요.
그래두 지금이라두 이런 습관을 염두에 두고 코딩을 하신다면 보다
판독성과 문서화 가능한 코딩이 되지 않을까요?
오늘은 헝가리안 표기법에 대해서, 알아보려고 합니다.
헝가리안 표기법은 쉽게 말해서, 면수의 의미 앞에 변수의 성질(타입, 종류) 등을 명시한 것입니다.
예를 들어 다음과 같습니다.
- strName( CString형 이름 )
- dwhWnd( 윈도우의 DWORD형 핸들 )
이것이 헝가리안 표기법의 대표적인 장점입니다. 이 장점 때문에, 수많은 장점이 다시 생겨납니다.
지금은 쓰면.. "글쎄..." 라는 의견이 점점 증가하고 있습니다.
그 이유에 대해서 아래에서 한번 알아보겠습니다.
1. 가독성이 떨어진다.
strName ↔ name
dwhWnd ↔ wnd
오른쪽이 더 읽기 편합니다. 즉, 헝가리안 표기법을 쓴다면 가독성은 떨어집니다.
가독성이 떨어지면, 그만큼의 코드를 유지보수 하는 시간은 길어지고 이 문제는 프로젝트의 성공 여부를 결정하기도 합니다.
2. 개발 도구의 발전으로 타입의 확인이 쉬어졌다.
그래서 지금까지 가독성이 떨어짐에도 헝가리안 표기법을 사용하였습니다.
예를 들어서 마우스로 변수에 갖다대면 팝업창에 타입이 나타난다든가, 아래 윈도우에 타입이 나타납니다.
또는 특정 단축키를 누르면, 곧바로 특정 변수의 선언부로 이동해 타입을 확인할 수 있습니다.
실제로 확인하지는 않았지만, 이클립스와 Visual Assist에서 지원하는 기능일 것입니다.
3. 해당 변수의 타입이 바뀌 변수의 이름까지 바꾸어야 한다.
하지만, 어떠한 이유로 이 변수의 타입이 정수형에서 문자열로 바뀌었습니다.
평소와 같으면, 변수의 선언부로 가서 타입의 변수와 그 변수에 관한 알고리즘을 바꾸면 됩니다.
하지만, 헝가리안 표기법을 사용한다면, 그 변수의 이름까지도 변경을 해야 합니다. (strMoney로 변경)
요즘 개발 도구가 좋아서 이름 바꾸기는 뚝딱 이지만 이런 것까지 신경을 써야 한다는 이야기입니다.
4. 실제로 언어에 비추어보면..
이렇게 부자연스러운 표기법은 사용하지 않는 것이 더 좋습니다.
이렇게 대략 4가지 이유로 헝가리안 표기법의 단점을 적어보았습니다.
지금 적어보니, "헝가리안 표기법은 이제 쓰지 말자!"라고 이야기한 것 같습니다. 맞습니다. 저는 이런 의견으로 적었는데요..^^;;
하지만, 내가 안 쓴다고 해도 위에서 시키면 써야 합니다.
다시 말하면, 현재 내가 코딩하는 곳의 코딩규약이 헝가리안 표기법을 사용한다면 써야 하고요..
만약, 코딩규약이 없거나 코딩규약을 정해야 한다면 안 쓴다고 의견을 말씀하시면 됩니다.
혹시, 헝가리안 표기법의 또 다른 생각이거나 태클은 환영합니다.
저 또한 프로그래밍에서 초보이고.. 많은 것을 배우고 싶기 때문이죠.
그럼 저는 이만 글을 마칩니다.
정보 참고 : http://kldp.org/node/112442
원문 : http://babochi.tistory.com/13
'Programming Language > c언어' 카테고리의 다른 글
C언어 메모리 구조 (0) | 2011.03.02 |
---|---|
[스크랩] unistd.h execve함수 (0) | 2010.11.16 |
[스크랩]c 배열 초기화 (0) | 2010.08.26 |
[스크랩] xor ^ (0) | 2010.01.25 |
논리연산자 (0) | 2010.01.25 |