언더스코어를 사용하는 개발자는 대/소문자로 구별하는 field/property가 익숙하지 못하다.
언더스코어를 싫어하는 개발자는 _가 사족 같다라는 느낌을 지울 수 없다.
가령
1.언더스코어 사용 규칙
class Person{
private int _age;
public int Age
{
get{return _age;}
set{_age=value;}
}
}
2.마이크로 소프트 프레임워크 규칙
class Person{
2.마이크로 소프트 프레임워크 규칙
class Person{
private int age;
public int Age
{
get{return this.age;}
set{this.age=value;}
}
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 키워드를 이용하며, 인텔리센스의 도움을 더 잘 받기 때문이다.
1번과 2번의 규칙 어떤것이 좋냐에 대한 의견이다.
1번은 C, C++ 또는 MFC에서 헝가리안 표기법의 멤버를 나타내는 m_ 에서 m을 제거하고 표기하는 규칙으로, 옹호론자들은 명백하게 노출하지 않을 멤버 필드임을 코딩시에 알 수 있다 이다.
2번의 옹호란자들은 Visual Studio IDE를 사용할때 , 직관적으로 나열되므로 코딩에 편하다. 이다.
1번의 단점은 코딩시에 의미 없는 언더스코어의 나열을 봐야 하는 것이다. 2번의 단점을 멤버임을 대소문자로 구분하기가 약간 힘들다는데 있다. 또한 C#코드에서 대소문자를 구별하지 않는 VB등으로 변환시에 문제가 발생할 수 있다는 점이다.
1번 2번 모두 장단점에 대해 분명하게 말하기는 힘들지만, 2번 스타일을 권하고 싶다.
Field의 이용시에는 명확하게 this 키워드를 이용하며, 인텔리센스의 도움을 더 잘 받기 때문이다.
'개발표준가이드라인' 카테고리의 다른 글
| 모든 디자이너들이 다운로드 받아야 할 30개의 필수 PDF Document (1) | 2008/11/12 |
|---|---|
| 좋은 개발자가 되는 91가지 방법 (1) | 2008/11/12 |
| Underscore 와 field 네이밍 컨벤션 (1) | 2008/10/13 |
| C# Coding Style Guide (1) | 2008/07/07 |
| 버그없는 코드를 만드는 프로그래머의 자세 (1) | 2008/06/10 |
| 자바 스크립트 와 웹 접근성 - javascript accessibility (0) | 2008/04/08 |
