Variables naming
  1. 변수명은 대문자와 소문자를 섞어서 알아보기 쉬운 형태로 작성하되 소문자로 시작한다.
    (ex. xCnt, yCnt, nameImg)
  2. 변수들 중 상수처럼 한 번 정한 후 변경할 필요가 없는 변수는 대문자를 사용할 수 있다.
    (ex. Width, Height)
  3. 동사와 명사가 섞인 변수명을 작성할 때에는 동사를 먼저 적는다.
    (ex. saveGame, loadGame)
  4. 되도록 변수명 앞에는 그 변수의 타입을 나타내는 접두어를 적는다.
    (ex. imgBack, imgForward)
  5. Boolean형의 변수는 접두어로 is나 can을 붙인다.
    (ex. isValid, canMove)
  6. 순환문 내부에서 사용하는 인덱스 변수는 i, j, k를 사용한다.
    (ex. for(i=0; i<MAX; i++))
  7. 클래스 전체에 통용되는 클래스형의 변수는 접두어로 m이나 g를 붙인다.
    (ex. mContext, mThread)
  8. 변수명에는 반드시 주석을 달아주어 변수에 대한 설명을 첨부한다.
    (ex. int xCnt, yCnt; //이미지의 가로, 세로 조각 수)



Methods naming
  1. 메소드명은 변수명의 명명규칙을 따르되 라이브러리에서 기본적으로 제공하는 메소드와 구분하기 위해 첫 문자를 대문자로 시작한다.
    (ex. public void DrawPictures())
  2. 메소드가 private 형식이면 메소드명은 소문자로 시작한다.
    (ex. private void drawPictures())
  3. 하나의 메소드가 길어져 전체를 한 화면으로 보기 곤란한 경우에는 두 개 이상으로 나누어 하나의 메소드가 30라인을 넘지 않도록 한다.
  4. 메소드명 바로 위에는 주석을 달아 메소드의 기능과 어디에서 호출하고 있는지를 명시한다.
    (ex. /* DrawPicture: Option Menu에서 호출 */)
  5. 닫는 중괄호 "}" 가 많이 중첩되는 경우에는 "}" 오른편에 어느 부분의 끝인지 명시한다.
    (ex. } //endfor, } //endif)



15 Best Practices for Variable & Method Naming

http://linuxism.tistory.com/573

  1. Use short enough and long enough variable names in each scope of code. Generally length may be 1 char for loop counters, 1 word for condition/loop variables, 1-2 words for methods, 2-3 words for classes, 3-4 words for globals.
  2. Use specific names for variables, for example "value", "equals", "data", ... are not valid names for any case.
  3. Use meaningful names for variables. Variable name must define the exact explanation of its content.
  4. Don't start variables with o_, obj_, m_ etc. A variable does not need tags which states it is a variable.
  5. Obey company naming standards and write variable names consistently in application: e.g. txtUserName, lblUserName, cmbSchoolType, ... Otherwise readability will reduce and find/replace tools will be unusable.
  6. Obey programming language standards and don't use lowercase/uppercase characters inconsistently: e.g. userName, UserName, USER_NAME, m_userName, username, ...
    For example for Java,
    • use Camel Case (aka Upper Camel Case) for classes: VelocityResponseWriter
    • use Lower Case for packages: com.company.project.ui
    • use Mixed Case (aka Lower Camel Case) for variables: studentName
    • use Upper Case for constants : MAX_PARAMETER_COUNT = 100
    • use Camel Case for enum class names and Upper Case for enum values.
    • don't use '_' anywhere except constants and enum values (which are constants).
  7. Don't reuse same variable name in the same class in different contexts: e.g. in method, constructor, class. So you can provide more simplicity for understandability and maintainability.
  8. Don't use same variable for different purposes in a method, conditional etc. Create a new and different named variable instead. This is also important for maintainability and readability.
  9. Don't use non-ASCII chars in variable names. Those may run on your platform but may not on others.
  10. Don't use too long variable names (e.g. 50 chars). Long names will bring ugly and hard-to-read code, also may not run on some compilers because of character limit.
  11. Decide and use one natural language for naming, e.g. using mixed English and German names will be inconsistent and unreadable.
  12. Use meaningful names for methods. The name must specify the exact action of the method and for most cases must start with a verb. (e.g. createPasswordHash)
  13. Obey company naming standards and write method names consistently in application: e.g. getTxtUserName(), getLblUserName(), isStudentApproved(), ... Otherwise readability will reduce and find/replace tools will be unusable.
  14. Obey programming language standards and don't use lowercase/uppercase characters inconsistently: e.g. getUserName, GetUserName, getusername, ...
    For example for Java,
    • use Mixed Case for method names: getStudentSchoolType
    • use Mixed Case for method parameters: setSchoolName(String schoolName)
  15. Use meaningful names for method parameters, so it can documentate itself in case of no documentation.



References


저작자표시 비영리 변경금지

티스토리툴바