카멜표기법

출처 : http://croute.me/307 

헝가리안 표기법 (Hungarian Notation) 

Data type, Control type, Dao type, Definition 등을 미리 정한 약어(줄인 표현)로 전위 표기(prifix)하는 것

?

1

2

3

4

double dScore;

float ePoint;

int nNumber;

String sSentence;

?

1

2

Frame fraName;

Combobox cboData;

 카멜 표기법 (Camel Notation) 

단어와 단어 사이를 대문자로 구분하는 방법. 낙타의 혹을 닮아서 붙여진 이름

?

1

2

3

4

5

6

7

8

9

private void getInformation()

{

 

}

 

public void getStudentCafeteriaMenuInformation()

{

 

}

 파스칼 표기법 (Pascal Notation) 

모든 단어의 시작을 대문자로 하는 방법. 보통의 경우 property, event, class name에 권장 됨

?

1

2

3

4

5

6

7

8

9

public class CrouteMe

{

 

}

 

public class UniversityOfIncheon

{

 

}

 밑줄 표기법 (Underscore) 

언더스코어 표기법은 변수를 만들 때, 각 단어를 구분하기 위하여 언더스코어(언더라인, 언더바 _ )를 사용한다.

?

1

2

int first_valuable;

double second_valuable;

 위의 것들 외에도 생각해보면 좋을 것들 

1. 메소드는 동작을 하는, 기능을 수행하는 역할이기 때문에 "동사"형태이거나, "동사+목적어"로 끝나는 것이 좋다.

2. 메소드 이름이나 변수명은 풀어서 쓴다.

3. 클래스 이름은 파스칼 표기법으로, 변수이름은 카멜표기법으로 사용한다.

 정리해보자면...

헝가리안 표기법을 반대하는 사람들의 이유

1. 공식된 규약이 아니다.

    - 헝가리안 표기법은 다수의 패널이 참여하는 오픈그룹에서 제정한 규약이 아니다.

    - 일종의 관습 규약이며 MS의 WIN32 API에 적용되며 입지를 굳혀나가 Windows 개발자들에게도 흡수된 것이다.

2. 정식으로 쓰이는 것이 아니다.

    - WIN32에서 쓰이는 고유 변수형에 대한 정의도 포함되어 있어 다양한 플랫폼에 적용하기 어렵다.

    - 오히려 'a' 나 'dbl' 접두어 같이 변형된 사용예가 헝가리안 표기법처럼 보이기도 한다.

    - 통일된 것이 아니다.

3. 툴이 좋아졌다.

    - 예전엔 쓸만한 에디터가 없었지만 요즘은 에디터가 많이 좋아졌다.

    - C언어를 생각했을 때, C언어는 연산에 참여하는 변수들의 type checking에 신경을 쓰지 않기때문에, 유연성 있는 

      언어가 되었지만, 코드를 읽어감에 있어서는 신경을 써가며 봐야했다. 

      이때 어려움을 해소하기위해 헝가리안 표기법을 사용했었다.

      즉, 개발자가 큰 프로젝트를 진행할 때, 변수명 만으로 변수의 형과 쓰임세를 알기위해 헝가리안 표기법이 고안,

      사용되었던 것이다.

      하지만 요즘 에디터들은 변수타입정도는 자동으로 알려준다.

      이런 상황에서 헝가리안 표기법을 사용하는 것은 하드디스크 낭비 및 코드 가독성 저하의 원인이 되고있다.

4. MS도 이제는 사용하지 않는다.

    - 헝가리안 표기법 확산의 공신이었던 MS에서도 이제는 헝가리안 표기법을 사용하지 않는다.

    - .NET과 C#의 핵심 리더인 앤더스 헤질스 버그에 의해 헝가리안 표기법이 퇴출되었다.

       .NET reference document에 이런 내용이 언급되어 있다. Do not use Hungarian notation

[출처] [C#] 낙타표기법 (Camel Casing) 파스칼표기법 (Pascal Casing)|작성자 에스이오케이

    - 대신에 camelCasing 또는 PascalCasing을 권장하고 있다.

다른 이유들

1. MyControl* pControl;

    - 이런 변수 선언은 의미 없다. 저 변수가 포인터라는건 개발자라면 누구나 알 수 있다. 광고할 필요없다.

2. 헝가리안 표기법을 고수하는 것은 이미 이에 익숙한 기존 개발자들의 횡포다.

   - 이는 새로운 후배 개발자들이 느끼는 높은 진입장벽이며, 솔직히 아무런 멋도 없다.

3. 정식으로 쓰이지도, 공통된 규약이 있는것도 아니다. 모두가 자기 입맛에 맞게 사용할 뿐이다.

4. 조금 편해보고자 만든 이기였을뿐이다. 이제는 더 불편해 지고 있다.

헝가리안 표기법을 사용하는 사람들의 이유

1. 네이밍(naming)은 코드의 발생에 직접 개입하지는 않지만 소스의 관리나 작성과 사용에서 중요한 역할을 한다.

    - 결국 프로그래머에게 편리한 방식을 택하면 된다.

2. 어느 언어에서건 표기법이 규칙에서 어긋나지만 않는다면 편하게, 코드분석이 쉽게되는 방향이 좋다.

    - 보기 좋고, 자신에게 편한 코딩스타일을 유지하는것이 최고다.

    - 여러명이 같이하는 프로젝트라면 팀에서 정한 규칙을 따르면 된다.

3. 코드가 길어지고 변수가 많아 질 때,

    - 변수가 수백개가 넘어가는 경우, 이름만 보고 어떤 자료형인지, 어떤 기능을 하는지 확실치 않게 될 때가 있다.

      혹, 어떤 기능을 하는지 알지라도, 어디에 쓰이는지 가독성이 떨어질때가 있다.

      헝가리안 표기법을 붙여두면, 나중에 어떤 자료형인지 명확하게 알 수 있다.

 결론 - 안드로이드 프로그래밍에 사용할 Naming

같은 팀에서 사용할 Naming이나 Coding Style은 팀내에서 정하면 된다는 것입니다.

대신 가독성이 높고, 편리하며, 낭비가 없고, 체계적인 틀을 정해두면 좋을것같네요.

저는 앞으로 위의 표기법들을 거의 모두 사용하여 이름을 정해볼까 합니다.

1. 클래스 이름

    - 클래스 이름은 대문자로 시작한다.

    - 클래스 이름은 파스칼표기법을 사용한다.

    - 단어의 시작은 대문자이다.

    - 역할에 따라 이름뒤에 Activity, Domain, Adapter, DataSet 등을 추가한다.

2. 변수 이름

    - 변수 이름은 소문자로 시작한다.

    - 변수 이름은 카멜 표기법을 사용한다.

    - 단어와 단어의 사이의 구분을 대문자로 한다.

    - 변수 이름은 명사로 한다.

    - 예외 : static 변수의 경우 모든 알파벳을 대문자로하고 언더스코어를 사용한다.

    - boolean 변수 : is변수이름 으로 사용한다.

    2.1 멤버 변수

        - 멤버변수의 맨 앞에 멤버변수의 표시인 m을 붙인다. 

        - 단, m_이 아닌 m만 사용해서 카멜 표기법을 유지한다.

        - 꼭 필요한 경우가 아니면 멤버 변수의 선언을 지양한다.

    2.2 메소드 내의 지역 변수

        - 카멜 표기법만을 사용한다.

        - 변수 이름은 명사로 한다.

3. 메소드 이름도 카멜표기법을 사용한다.

    - 단 메소드는 역할이 있기 때문에 역할에 대해서 "동사", "동사+목적어"의 표현으로 한다.

    - 단어와 단어의 사이의 구분 대문자

    - 

4. xml 파일 이름

    - xml 파일 이름은 매핑 되는 액티비티의 이름을 언더스코어 표기로 변경해서 사용한다.

    - xml 파일 이름엔 소문자와 숫자, 언더바(_)만 올 수 있다. [a-z], [0-9]

    - 매핑되는 액티비티 이름으로 만들경우 명시적이기 때문에 가독성이 높다.

5. 접근제어자, 접근제한자

    - 클래스 내에서만 사용하는 멤버변수에는 private을 붙여준다.(not default)

    - 클래스는 일반적으로 public class로 만들고, 멤버변수, 메소드에 접근제어자를 다르게 해서 제어한다.

접근제어자(접근제한자, 가시성 등)에 따른 접근 권한

접근제어자 같은 클래스 같은 패키지 다른 패키지 상속 어디서나

public     ○              ○          ○             ○

protected     ○               ○          ○             Ｘ

default     ○              ○         Ｘ             Ｘ

private     ○              Ｘ                 Ｘ             Ｘ

6. package

    - 패키지는 역할별로 나눈다.

       ex) .activity / .adapter / .domain / .common / .utility

    - Activity들을 모아둔 activity 패키지

    - Adapter들을 모아둔 adapter 패키지

    - Domain들을 모아둔 domain 패키지

    - 여러 클래스에서 공용으로 쓰는 클래스를 모아둔 common 패키지

    - Utility들을 모아둔 utility 패키지

    - 역할별로 나누어서 하나의 패키지에 너무 많은 클래스들이 모인 경우엔,

      [기능패키지->역할패키지]로 한 단계의 depth를 추가한다.

       ex) .login.activity / .login.adapter

7. 위젯

    - 위젯은 어떤 위젯인지 명시하기 위해 헝가리안 표기법을 사용한다.

    - 대신 일반적인 변수의 데이터 타입은 헝가리안 표기법 사용을 지양한다.(혼란 방지)

    - ex) TextView -> txt / ListView -> list or lv / Spinner -> sp / Button -> btn

    7.1 버튼, 이미지버튼, 텍스트뷰

        - Button의 경우 btn을 사용한다.

        - ImageButton의 경우도 btn을 사용한다.

        - TextView의 경우에, 버튼으로 사용할 경우 txt 대신에 btn을 사용한다.

    7.2 멤버 변수의 경우

        - 멤버 변수의 경우 m과 혼합하여 mBtn이름 / mTxt이름 을 사용한다.