타입스크립트에서 interface 정의시 I- prefix를 권장하지 않는 이유 (헝가리안)

타입스크립트에서 interface를 정의할때 I-prefix를 붙이는 것은 권장되지 않는다.

인터넷을 뒤져보면서 다양한 헝가리안 표기법을 지양하는 이유에 대해서 모아보았다.

 

1. 헝가리안 표기법의 시대는 끝났다.

원래 I-prefix를 사용한 이유는 네이밍만 보고 그 구문의 역할을 바로 알아챌 수 있었다는 점이다.

 

예를 들어서, 

I는 interface 

C는 클래스 

A는 추상 클래스

S는 문자열

c는 const 변수

i는 정수형 변수

에 해당하는 의미를 가지고 있다.

 

즉, 마우스를 hover안하고 이름만 보고도 타입의 정보를 알아챌 수 있는 것이다!

 

하지만 변수나 함수인자의 이름을 기억하기가 힘들어지고,

데이터 타입이 바뀌면 이름도 바꿔주어야 한다.

그 외에도 여기서 언급되지 않은 장/단점이 매우 많이 존재한다. 

 

https://en.wikipedia.org/wiki/Hungarian_notation#Advantages

 

근데 시대가 지나서 더이상 사용하지 않게 되었다. (C#은 아키텍쳐적인(?)이유로 계속 쓰고 있는듯 하다.)

왜냐하면, 사실 마우스를 hover하여 데이터 타입을 찾아내는게 크게 어려운 일도 아니고, 화면도 커쳐서 코드를 한눈에 볼 수 있는 양이 많아져서 헝가리안을 사용했을 때의 이점이 거의 없고, 평소에 지키던 네이밍 규칙에 오히려 위배될 수 있다.

즉, 헝가리안 표기법 자체가 80년대에 IDE가 엄청 부실할 때 나온것이라서, 지금 써도 크게 효과를 볼 수 없다.

 

 

2. I-prefix가 캡슐화 원칙에 위배된다.

외부에서는 사용되어지는 타입을 알필요가 없다. 

근데 사용하는 입장에서는 해당 타입을 읽는 즉시 알게된다.

그러니까 이름으로부터 타입을 유추가능하므로 그 자체가 원칙에 위배가 된다..!

 

3. bad naming

(이 이유는 뭐지 ㅋㅋ)

I prefix를 제거함으로써 개발자들이 더욱 적절한 이름을 생각하기위해 노력할 수 있다.

I prefix가 강제로 붙고 안붙고에는 그런 차이가 있다. 코드를 작성하는 사람에게 어느 정도 정보를 전달했다고 보고 변수명을 대충 짓게 만들 수 있다고 한다.

 

4. 변수의 가독성이 떨어지고, 변수명이 쓸데없이 길어진다.

쓸데없이 길어지는 건 인정한다.

하지만, 타입스크립트에서는 interface에서 밖에 안써봐서 딱히 공감되진 않는다.

 

5. 헝가리안 표기법을 썼던 마이크로소프트 조차도 이제는 헝가리안 표기법을 쓰지말라고 한다.

 

 

다양한 이유를 수집해봤는데 (누락된 이유들도 있겠지만..)

 

우아한 테크코스 3기 프론트엔드 리뷰어이신 제이비(jbee)님의 말씀이 더 깊게 와닿았다.

 

인용하자면,

 

일관성을 파괴하는 네이밍 컨벤션

하나의 프로젝트 (또는 어떤 다른 기준)에서 snake_case를 사용한다던가, camelCase를 사용한다던가 이런 표기법은 일관성이 가장 중요합니다.

다른 변수나 함수 네이밍에는 헝가리식 표기법을 적용하지 않다가, 인터페이스에만 헝가리식 표기법을 적용하는 것은 잘못된 것입니다.

 

컨벤션의 목적과 사용되는 언어가 근본적으로 맞지 않는 문제

자바스크립트와 같은 언어에서 변수 또는 함수에 자료형을 드러내기 위해서 사용하던 헝가리식 표기법을 구조적 타이핑을 기반으로 하는 타입스크립트에 적용하는 것은 더욱 말이 안됩니다.

 

이렇게 말씀해주셨다.

배우는 입장에서 이렇게까지 생각은 못해봤는데, 일관성과 언어의 특성에 위배된다고 깔ㅡ끔하게 알려주셔서, 헝가리식 표기법을 사용하는 안되는 이유가 가장 잘 이해가 되었던 글이었다!