이전의 프로젝트를 진행하며 인터페이스 네이밍 규칙으로 다른 변수명과의 구별을 위해 접두사 I를 붙이는 헝가리안 네이밍을 사용했었다.
그러나 MS의 Typescript Coding guidelines에 접두사 I를 사용하지 말라는 규칙이 있는 것을 보고 이에 대해 고민해보게 됐다.
(참고로 MS의 가이드라인은 타입스크립트 규정은 아니니 반드시 따를 필요는 없다. 그러나 참고용으로 굿굿)
Typescript에서 I 표기를 지양하는 이유?
1. 더 이상 변수명으로 역할을 구분할 필요가 없다.
헝가리안 표기법의 가장 큰 장점은 접두사를 통해 인터페이스를 한눈에 구분 가능하다는 것이다. 그러나 최근에는 IDE를 통해 인터페이스인지 타입인지 명확한 구분이 가능하다. (변수명으로 구분할 필요가 없다.)
2. 명명규칙이 늘어나고 가독성이 떨어진다.
인터페이스만을 위한 명명규칙이 생겨난 것이기 때문
3. 캡슐화 원칙을 위배한다.
캡슐화는 객체의 내부 상태와 구현 세부 사항을 외부로 노출시키지 않고 은닉하는 것을 의미하는데, 인터페이스를 헝가리안 표기법으로 명명할 경우 이는 타입 정보를 변수 이름에 포함시키는 것이므로 캡슐화 원칙을 위반하는 것이 된다.
4. 일관성을 파괴한다.
다른 변수, 함수와 다르게 인터페이스만 특별 취급하게 되며 위의 2번에 명시한 것처럼 새로운 명명규칙을 생성하여 적용하게 된다.
5. 언어의 특성에 위배된다.
타입스크립트는 구조적 타이핑을 기반으로 한다.
구조적 타이핑은 변수나 객체의 실제 구조를 기반으로 타입 호환성을 파악하므로 변수나 객체의 이름에 의존하지 않는다. 따라서 변수 이름을 통해 역할을 구분하는 헝가리안 네이밍 규칙은 타입스크립트의 언어적 특성에 위배된다.
이러한 이유로 더이상 헝가리안 네이밍 규칙을 통해 인터페이스를 명명하는 것이 권장되지는 않지만, 여전히 이러한 네이밍 규칙을 사용하는 곳은 많고 팀 내 네이밍 규칙을 설정하기 나름인 것 같다.
(보통 기존의 규칙이 헝가리안이면, 그 규칙을 계속해서 따른다.)
결론적으로 우리는 파스칼 케이스를 사용하기로 규칙을 정했다!! 프로젝트를 거의 새로 만들어가는 단계이기도 했고, 사용을 지양해야 하는 다양한 이유를 제쳐두고 반드시 사용해야 할 이유는 없기에
'Typescript' 카테고리의 다른 글
인덱스 시그니처 (0) | 2024.05.14 |
---|---|
Element implicitly has an 'any' type because expression of type 'string' can't be used to index type (0) | 2024.03.27 |
Type of emit value is always 'any' with new style defineEmits (0) | 2024.03.27 |
@input event의 타입 (0) | 2024.03.27 |
타입스크립트 인터페이스 어떻게 선언할까? declare / export (0) | 2024.03.27 |