Naming Conventions

1. Naming conventions

1) Name은 의미를 쉽게 파악할 수 있도록 한다.

- Underscores를 이용해 단어를 구분한다.

2) 각 Name은 식별이 보장되도록 한다.

3) 혼동될 문자는 가급적 사용하지 않도록 한다.

4) 발음 상 혼동이 되는 Name의 사용을 피한다.

5) Global 변수는 등록한 후 임의 갱신을 피한다.

6) 약어(abbreviations)의 사용을 자제한다.

- 빈번한 사용시에는 의미를 설명한뒤 사용한다.
- 불분명한 약어는 사용하지 않는다. 

※ Naming convention은 project의 특성상 사용하는 tool, 다른 library와의 호환성, 표준 API등에 의해 영향을 받는다.

2. Underscore 와 Field naming convention

멤버 Field의 네이밍 가이드 라인에서 언더스코어(_, underscore)의 사용에 대한 의견이 분분하다.

언더스코어를 사용하는 개발자는 대/소문자로 구별하는 field/property가 익숙하지 못하다.
언더스코어를 싫어하는 개발자는 _가 사족 같다라는 느낌을 지울 수 없다.











가령

1. 언더스코어 사용 규칙

class Person{

private int _age;

public int Age

{

get{return _age;}

set{_age=value;}

}

}

2. 마이크로 소프트 프레임워크 규칙

class Person{

private int age;
public int Age
{
get{return this.age;}
set{this.age=value;}
}

}

1번과 2번의 규칙 어떤것이 좋냐에 대한 의견이다.

1번은 C, C++ 또는 MFC에서 헝가리안 표기법의 멤버를 나타내는 m_ 에서 m을 제거하고 표기하는 규칙으로,  옹호론자들은 명백하게 노출하지 않을 멤버 필드임을 코딩시에 알 수 있다 이다.

2번의 옹호란자들은 Visual Studio IDE를 사용할때 , 직관적으로 나열되므로 코딩에 편하다. 이다.

1번의 단점은 코딩시에 의미 없는 언더스코어의 나열을 봐야 하는 것이다. 2번의 단점을 멤버임을 대소문자로 구분하기가 약간 힘들다는데 있다. 또한 C#코드에서 대소문자를 구별하지 않는 VB등으로 변환시에 문제가 발생할 수 있다는 점이다.

1번 2번 모두 장단점에 대해 분명하게 말하기는 힘들지만,  2번 스타일을 권하고 싶다.

Field의 이용시에는 명확하게 this 키워드를 이용하며, 인텔리센스의 도움을 더 잘 받기 때문이다.