안녕하세요. 몇일동안 헝가리안 표기법에 대해 질문을 해왔네요.
인터넷을 찾아보기도 하고 하면서 정리해봤습니다.
이것을 하는 이유는 C++만 평균 7년경력을 가지고있는 팀원이 프로젝트가 끝나고난 뒤,
C#으로 하는 프로젝트를 처음 시작했기에 그들에게 C#에서는 헝가리안표기법을 쓰지말아야한다고 주장하려는 내용입니다.
팀원전체가 헝가리안을 쓰기때문에 당연히 따라야하지만 팀장님이 PT를 허락해주셨기에 준비하고있습니다.
자신이 C++로 헝가리안표기법을 10년간 사용해왔다는 설정으로 몰입해서 봐 주시면감사하겠습니다.
또한 잘못된 점이나, 생각이 다르신분들의 비판을 댓글로 달아주시면 정말 감사하겠습니다.
1. 표기법이 존재하는 이유
표기법은 특정한 규격을 말하는것이 아니다. 작업자의 성향일 수도 있고, 팀, 회사의 내규일 수도있다. 하지만 어느 표기법을 따르던 규칙적이여야하며 효율적이고 타당해야한다.
아래는
-가독성 : 잘 읽어져야함
-접근성 : 주변 프로젝트랑 어울려야함?
-명확성 : 잘보여야함?
-통일성 : 명세가 간략하며 모두가 따를 수 있어야한다.
-지속성 : 시간이 지난 뒤 코드를 보았을 때도 이해가 잘 되야 한다
-간편성 : 작성하는데 불편함이 없어야한다
-효율성 : 표기법 자체에서 논리적 오류를 발생할 여지가 적어야한다.
2. 헝가리안 표기법이란?
헝가리안 표기법은 BCPL(Before C Programing Language)에서 계승된 표기법이라고 할 수 있다.
BCL 시절엔 타입시스템이 없어 변수명으로 타입을 명시하여 사용했다. 이것은 70년대에 등장한 언어를 더불어 타입이 존재하는 언어에서도 변수명에 타입이 함께 기입되어 사용됐다.
그것은 에디터나 컴파일러가 고도화되지 않은 환경에서는 변수명만으로 타입을 확정지을 수 잇는 방식이므로 여러모로 유용했던 것이다.
당시 유럽에서는 타입을 변수명 뒤에 붙여서 사용했다. 그것은 성이 뒤에 오는 유럽에서는 관례적인 일이었다고한다. 하지만 유럽에서도 특이하게 성이 이름 앞에 오는 관습을 지닌 헝가리아에서 온 청년 'Charles Simonyi'는 타입을 앞에붙여 사용하게된다.
80년대 마이크로스프트의 아키텍트가 된 Charles Simonyi의 프로그래밍방식이 빌게이츠의 눈에들어 MS표준으로 지정되었다. 그것을 '헝가리안 표기법'이라고 한다.
하지만 표기법은 '정의'가 아닌 '트렌드'다. 이것을 옳다 그르다 라고 말하는것은 종교나 정치에 대해 논쟁하는 것과 같이 무의미한 일이다.
3. 시대적인 변화
1966 : (BCPL) 타입시스템이 없기에 이름에 명시한 타입으로 실제 타입을 추측하는 '고대'언어
1972 : (SmallTalk) 타입시스템은 있지만, 이름에 Postfix로 타입을 추가로 명시하여 사용한 언어
1981 : (MS Coding Convention) 이름에 Prefix로 파입을 명시하여 사용하는 Hungarian Notation 권장
1999 : (MS Coding Convention) 여전히 Hungarian Notation 권장
2005 : (Jeol On Software) System Hungarian을 부정하고, Apps Notation 권장
2008 : (MS Coding Convention) Hungarian Notation을 사용하지 말라고 권장
2009 : (StackOverflow) Hungarian Notation에 대한 부정적인 의견 수렴
절대적이었던 헝가리안 표기법이 근례에는 "글쎄..."로 바뀜
4. System Hunagrian VS Apps Hungarian
System : Type을 붙여 사용. 일반적으로 int는 i,n을 접두어로 붙이는것.
Apps : 의미를 접두어로 붙이는 것.
헝가리안 표기법은 크게 두가지로 나뉜다고 할 수 있다. 헝가리안 표기법을 사용했던 Microsoft는 Apps Hungarian을 사용하였지만, 대부분이 이걸 오인하여 System Hungarian을 사용함으로서 문제가 발생했다고 말함.
Excel, Word 팀에서 사용하는 헝가리안 표기법에 대해 소개하자면. Excel 소스에는 rw, col과 같은 접두어를 가진 변수들이 많다고 한다. 모두 정수형이지만 행과 열을 나타나게 된다. 그리고 rw와 col은 서로 절대로 값이 섞일 수 없는 것입니다.
워드에서는 xl, xw라는 접두사가 있는데 xl의 경우 현재 페이지를 기준으로 한 가로 좌표이고 xw는 현재 윈도우를 기준으로 하는 좌표라고 합니다.
이렇게 "모든 변수는 변수가 담고 있는 내용에 따라 종류(Kind)를 구분할 수 있도록 소문자로 된 식별자를 접두어로 붙여서"사용하는 것이 찰스 시모니(Charles Simonyi)가 원하는 바였다고 합니다.
5. 헝가리안 표기법을 쓰는 이유
1) 변수 이름만으로 많은 정보를 한 눈에 알아볼 수 있어 오류를 획기적으로 줄일 수 있다.
+ 변수 이름으로 알 수 있는걸 '마우스, F12'를 통해 볼 필요가 없다
+ 어느 IDE, 출력을 해도 코드분석을 쉽게 할 수 있다.
+ 유추성이 높다( 변수가 수백개가 넘어가는 경우, 오래된 코드를 분석할때 유용하다 )
2) 네이밍은 코드 발생에 직접 개입하지 않지만 소스 관리, 작성에 중요한 역할을 한다.
+ 변수명 고민을 줄여준다 (하나의 의미를 가진 여러개의 변수를 관리할 때 유용하다)
3) Scope별로 변수 관리가 가능하다 (g_, m_, a_)
4) 타입선언 및 사용이 자유로운 언어이기에 컴파일러가 형을 검사하기 힘들고, 그걸 프로그래머가 해야하기에 적합하다.
+ IDE가 없거나, 손코딩과 같은 환경에서 헌가리안 표기법은 최고의 기법
5) Com, WinAPI의 Document가 헝가리안 표기법을 사용했고, MS에서 표준으로 사용했기 떄문에
6. 헝가리안 표기법을 버려야하는 이유
1) 시대적 이유
- MS : 헝가리안 표기법을 공식적으로 폐기하겠다고 발표. Doc이 어렵고 못생겼기 때문에.
- MS에 대한 유저견해 : "쓰다보니 별로네", "이거 안좋아졌네" 수준이 아니라. 앞으로의 환경,방향,방법,목표들이 헝가리안 표기법에 맞지 않았을 것.
- 헝가리안 표기법은 과거 툴이 좋지 않았을때 쓰던 것이며, 근례에는 변수, 함수 이름은 인간이 이해하기 쉽게 작명하고 뭔가 보려면 툴에서 알려준다. 과거에는 인간을 기계화 해서 오류를 줄였다면 근례에는 기계를 인간화 해서 오류를 줄이는 경향
2) 언어적 특성
- OOP 언어는 변수타입, 로우레벨한 것 보다 변수의 기능과 역할에 초점을 두기 때문에, 가독성은 변수타입보다 중요하다.
- 전역변수가 없기에 m_, g_의 구분이 필요없어졌다.
- 기본데이터를 섞어가며 써야하는 경우가 없기때문에 bool, int, float, string만으로 모든걸 할 수 있기 때문에.
- a_를 사용하지 않는 이유. Method Optional Argument의 별개 호출시의 코드 길이가 길어지는 것을 방지하기 위함.
3) 외부적 측면
- .NET FrameWork, Unity Docs에서 Hungarian Notation을 사용하지 않는다.
- AssetStore 및 C#라이브러리의 대부분은 Hungarian Notation을 사용하지 않는다.
- UnityLearn, Stackoverflow 등에서 Hungarian Notation을 사용하지 않는다.
- 유니티는 단순 라이브러리가 아닌, 에닌 위에 입혀야 하는 것이기에, 유니티 라이브러리들과 혼합되어 사용하게된다.
- 신입으로 들어올 후임, Unity전문 개발자는 대부분 Hugarian Notation을 사용하지 않을것으로 예상.
4) 도구의 발전
- 개발 도구의 발전으로 타입 확인이 쉬워졌다. (마우스를 갖다댄다거나 F12, Ctrl -를 이용하여 변수를 확인할 수 있다)
- 만약 헝가리안표기법이 보편적으로 타당하다면 fortran처럼 컴파일러가 n으로 시작하는 변수명을 정수형으로 강제하고, m_을 붙이면 멤버로 해석하는 기능이 있을 것이다.
5) 헝가리안 표기법의 한계
- 코드가 길어진다.
- 취지에 안맞게 보기 흉하고 가독성이 저하된다.
- 굳이 쓸 이유가 없는데 쓰는게 에러를 유발할 수 있다.
- 규모가 커질수록 타입을 바꿀일이 빈번하게 일어나고, 귀찮거나 실수로 prefix를 바꾸지 않는다면 의미가없어진다.
- 모든 프로그래머가 천재, 부지런하다는 생각을 버려야한다. 위의 경우는 빈번하게 일어나며, 그것은 코드리뷰의 횟수가 늘어나며 강제하게되어 효율이 떨어진다.
- 헝가리안 표기법을 보증해줄 수단이 없다. 타입은 컴파일러가 기계적 검증을 하지만, 변수명은 강제할 수단이 사람의 눈밖에 없다. 사람이 조금 편하기 위해, 표기법 자체를 관리하는것 자체가 모순적이다.
- OOP에서 클래스 명도 일종의 타입, 수많은 클래스의 약어를 모두 만들고, 기억할 수 없다면 System Hungarian Notation은 의미가 없어진다.
- 각 언어마다 관습이 있고, 타인과 협업을 위해서라면 각 언어의 표기법을 따르는게 좋다.
6) 인터넷의 비판
- 아래 문장은 헝가리안 표기법 조롱에 제법 유명세를 탔다.
"vUsing adjHungarian nNotation vMakes nReading nCode adjDifficult."
(헝가리안 표기법에 따라 동사, 부사, 명사 등을 나타내는 prefix를 붙인 것)
- 소스코드 판독을 어렵게 하는 핵폭탄급 기법중 하나.
- 70년대 감성을 갖고 있는 구닥다리 프로그래머
- 읽기 힘든 코드를 끊임없이 양산해내는 두뇌파괴자
- Type-Safe하지 않은 언어에서나 필요하다
- 변수이름만 잘 짓고, 모듈을 잘 나눠 놓기만 해도 변칙적인 표기법은 필요없다고 본다.
- 헝가리안 표기법을 고수하는 것은 이미 이에 익숙한 기존 개발자들의 횡포, 이는 새로운 후배 개발자들이 느끼는 높은 진입장벽이다.
- 조금 편해보고자 만든 얘기였을뿐이다. 이제는 더 불편해 지고 있다.
