1. 코딩 컨벤션 이란?

코딩 컨벤션이란 가독성이 좋고 관리하기 쉬운 코드를 작성하기 위한 코딩 스타일 규약을 말한다.

코딩 컨벤션을 준수하면 가독성이 좋아지고 성능에 영향을 주거나 오류를 발생시키는 잠재적인 위험 요소를 줄여줘 유지보수 비용을 줄일 수 있다.

2. 코딩 컨벤션

• 선언은 한 줄당 하나의 선언문을 사용한다
• 일관된 네이밍 규칙을 사용한다 (카멜 케이스, 스네이크 케이스 등)
• 한줄의 코드 길이는 최대 80자로 한다
• 의미 있고 가독성이 좋은 변수, 함수명 사용
• 사용하지 않는 코드는 제거 한다 (주석)

2-1. 변수명 작성 방법

1. Boolean형 네이밍

   Boolean형 변수명을 지을 때 prefix 로 is, has 를 많이 사용한다

   • 모든 케이스가 True 인 경우

     const XXX = users.every(user => user.isActive)
     

     변수명	적합성	설명
     isUsersLoggedIn	🤢	문법적으로 비적합하다.
     areUsersLoggedIn	🤬	커스텀된 prefix이다.
     (are은 쓰지 않는다.)
     isEveryUserLoggedIn	👍	Array.prototype.every에 부합한다.
     isEachUserLoggedIn	🥰	"every" 라는 용어보다 더 자연스럽다.

   • 케이스 중 부합(True) 하는 값이 있을 경우

     const XXX = users.some(user => user.isActive)
     

     변수명	적합성	설명
     isUsersActive	😱	문법이 부적합하고 모호하다.
     isAtLeastOneUserActive	😵	너무 단어가 길다.
     isOneUserActive	🤥	의도와 다르다.이러한 변수명은 오직 한명의 유저만 접속했다고 착각 할 수 있다.
     이런 혼란스러운 변수명은 피하자.
     isSomeUserActive	👍	Array.prototype.some에 부합한다.
     isAnyUserActive	🤗	"some"이라는 용어보다 더 자연스럽다.

   • Custom Prefix

     변수명	적합성	설명
     wasPaidFor	🤢	커스텀 prefix
     paidFor	😣	prefix가 없다.
     areBillsPaidFor	😧	커스텀 prefix
     hadHaveHadBeenPaidFor	😶	단어도 너무 길고 그냥 말도안된다.
     isPaidFor	😊	적합하다.

   • 긍정적인 변수명

     // Bad Case
     if (!account.isDisabled) { }
     
     // Good Case
     if (account.isEnabled) { }
     

     변수명	적합성	설명
     isDisabled	🤢	네거티브한 변수명이다.
     isNotActive	🤮	!isNotActive 이런 코드만봐도 답이없다.
     hasNoBillingAddress	😞	"no"라는 것은 변수명에 필요없다.
     isEnabled / isActive / hasBillingAddress	😁	positive한 변수명을 이용함으로써!isActive같은 것들도 자연스러워진다.

2. 클래스나 메소드명은 파스칼 표기 (대문자 카멜표기)

   // Bad Case
   public class Accesstoken
   
   // Good Case
   public class AccessToken
   

3. 변수, 파라미터명은 카멜 표기

   // Bad Case
   private boolean Authorized;
   
   // Good Case
   private boolean authorized;
   

4. 메서드 이름은 동사/전치사

   renderHtml()
   toString()
   findById()
   

5. 상수는 대문자로 작성하고 복합어인 경우 ‘_’(underscore) 로 구분

   public final int SPECIAL_NUMBER = 1;