변수명과 메소드명 명명 및 작성규칙

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.

 

경축! 아무것도 안하여 에스천사게임즈가 새로운 모습으로 재오픈 하였습니다.
어린이용이며, 설치가 필요없는 브라우저 게임입니다.
https://s1004games.com

 

References

 

[출처] http://sens.tistory.com/341

 

 

본 웹사이트는 광고를 포함하고 있습니다.
광고 클릭에서 발생하는 수익금은 모두 웹사이트 서버의 유지 및 관리, 그리고 기술 콘텐츠 향상을 위해 쓰여집니다.
번호 제목 글쓴이 날짜 조회 수
698 DOCKER에서 GUI프로그램을 돌려야 할 때. file 졸리운_곰 2018.06.26 75
697 XML, JSON, BSON, MSGPACK 장,단점 비교 졸리운_곰 2018.06.26 93
696 BSON 이해하기 졸리운_곰 2018.06.26 71
695 워드프레스 이메일(Wordpress Email) 설정 ( Mailgun 의 SMTP 서비스 활용) file 졸리운_곰 2018.06.22 127
694 SQL과 NoSQL의 장점을 결합한 NewSQL에 대해 file 졸리운_곰 2018.06.21 110
693 "새로운 SQL이 뜬다" SQL과 NoSQL의 장점 결합한 NewSQL 졸리운_곰 2018.06.21 105
692 아마존 킨들에 영한사전 넣는 방법 file 졸리운_곰 2018.06.14 267
691 Scaffold로 빠르게 웹 서비스 개발하기 file 졸리운_곰 2018.06.09 67
690 Docker 명령어 정리 졸리운_곰 2018.06.09 100
689 Dockerfile 명령어 정리 졸리운_곰 2018.06.09 84
688 아주 간단한 Docker 사용법 정리 file 졸리운_곰 2018.06.09 74
687 [Docker] Docker 기본 사용법 정리 졸리운_곰 2018.06.09 101
686 일반 PHP 프로젝트 개발 환경에서 docker 사용하기 file 졸리운_곰 2018.06.06 93
685 Docker (Compose) 활용법 - 개발 환경 구성하기 file 졸리운_곰 2018.06.06 93
684 레일즈 API 서버 구축시 고려사항 졸리운_곰 2018.05.27 115
683 Rails에서 Swagger를 이용하여 API Docs 사용 시 인증 처리 file 졸리운_곰 2018.05.27 73
682 Ruby on Rails - Swagger UI : 레일즈 Swagger UI 적용 file 졸리운_곰 2018.05.27 118
681 가짜 동영상 제작툴 사용법 : deepfake : DeepFakes FakeApp Tutorial file 졸리운_곰 2018.05.26 7714
680 딥러닝 워크북 부록파일 file 졸리운_곰 2018.05.24 94
» 변수명과 메소드명 명명 및 작성규칙 졸리운_곰 2018.05.14 92
대표 김성준 주소 : 경기 용인 분당수지 U타워 등록번호 : 142-07-27414
통신판매업 신고 : 제2012-용인수지-0185호 출판업 신고 : 수지구청 제 123호 개인정보보호최고책임자 : 김성준 sjkim70@stechstar.com
대표전화 : 010-4589-2193 [fax] 02-6280-1294 COPYRIGHT(C) stechstar.com ALL RIGHTS RESERVED