본문 바로가기

1-12. 이름을 잘 짓는 간단한 규칙 (불필요한 맥락을 없애기) 일반적으로 짧은 이름이 긴 이름이 좋다. 단 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다. //불필요한 맥락이 추가된 예 Gas Station Deluxe(고급 휘발유 충전소) 앱을 개발 시 모든 클래스 이름을 GSD로 시작하는건 바람직하지 못하다. accountAddress, customerAddress는 Address 클래스 인스턴스로 좋은 이름이나 클래스 이름으로는 좋지 않다.(Address는 클래스 이름으로 적합하다.) 예를들어 포트주소 MAC주소, 웹 주소를 구분해야 한다면 PostalAddress, MAC, URI라는 이름도 괜찮다. 그러면 의미가 더 분명해진다. 더보기
1-11. 이름을 잘 짓는 간단한 규칙 (의미 있는 맥락을 추가하기) 아래와 같은 경우는 함수 이름은 맥락의 일부만 제공하며, 알고리즘이 나머지 맥락을 제공한다. 그래서 함수를 끝까지 읽어보고 나서야 member, verb, pluraModifier라는 변수 세개가 통계 추측이라는 메시지를 사용한다는 사실이 드러난다. 불행이도 독자가 맥락을 유추해야만 한다. 그냥 메서드만 훑어서는 세 변수의 의미가 불분명하다. //맥락 불분명 예시 private void printGuessStatistics(char candidate, int count){ String number; String verb; String pluraModifier if(count == 0) { number = "no"; verb = "are"; pluraModifier = "s"; } else if(count.. 더보기
1-10. 이름을 잘 짓는 간단한 규칙 (한 개념에 한 단어, 한 목적에 한 단어로 사용해라.) 프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다. 의미를 해석할 책임이 독자에게 있는 논문 모델이 아니라 의도를 밝힐 책임이 저자에게 있는 잡지 모델이 바람집하다. DeviceManager와 ProtocalController는 근본적으로 무엇이 다른가 만약 다르지 않고 같은 개념이라면 Manager 혹은 Controller로 통일시켜주어야 한다. 왜냐하면 이름이 다르면 독자는 당연히 클래스도 다르고 타입도 다르리라 생각한다. 일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다. 만약 여러 클래스에 add라는 메서드가 있다고 해보자. 모든 add 메서드의 매개변수와 반환값이 의미적으로 똑같다면 문제없다. 하.. 더보기
1-9. 이름을 잘 짓는 간단한 규칙 (생성자를 overload할 때는 정적 팩토리 메서드를 사용한다.) 생성자(constructor)를 overload할 때는 정적 팩토리 메서드(static factory method)를 사용한다 * 정적 팩토리 메소드는 직접 생성자를 통해 객체를 생성하는 것이 아닌 메서드를 통해 객체를 생성하는 것. //안좋은 예시 Complex fulcrumPoint = new Complex(23.0); 생성자 사용을 제한하려면 해당 생성자를 private로 선언 (클래스 내부에서만 접근 가능하도록) //좋은 예시 Complex fulcrumPoint = Complex.FromRealNumber(23.0); 더보기
1-8. 이름을 잘 짓는 간단한 규칙 (클래스와 객체의 이름은 명사나 명사구가 적합하고, 메서드 이름은 동사나 동사구가 적합하다.) 클래스와 객체이름(명사, 명사구) //안좋은 예시 (모호한 명사, 동사) Manager, Processor, Data, Info 등과 같은 단어는 피하고 동사는 사용하지 않는다. //좋은 예시 Customer, WikiPage, Account, AddressPaser 메서드 이름(동사, 동사구) //좋은 예시 postPayment, deletePAge, save 등등 접근자(accessor), 변경자(mutator), 조건자(perdicate)는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다. //접근자 String name = employee.getName(); //변경자 customer.setName(); //조건자 if(paycheck.isPosted()){ ... } 더보기
1-7. 이름을 잘 짓는 간단한 규칙 (자신의 기억력을 자랑하지 말자) 독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다. 루프에서 반복 횟수를 세는 변수 i,j,k는 괜찮다. 단 루프 범위가 아주 작고 다른 이름과 충돌하지 않을 때만 괜찮다. //안좋은 예시 int a; int b; int c; 등등 더보기
1-6. 이름을 잘 짓는 간단한 규칙 (인코딩을 피하자) 자바 프로그래머는 변수 이름에 타입을 인코딩할 필요가 없다. (변수 이름에 타입 작성 X, 헝가리식 표기법이 오히려 방해가 됨.) 이런식으로 이름에 타입을 인코딩하면 변수, 함수, 클래스 이름이나 타입을 바꾸기가 어려워지며, 읽기도 어려워진다. 또한 독자를 오도할 가능성도 커진다. int PhoneNumber; String phoneString; //이렇게 변수 이름에 타입을 인코딩하면 나중에 변수 타입이 바뀌어도 이름이 바뀌지 않는 경우 발생 멤버 변수(메소드 밖에서 선언된 변수)의 m_이라는 접두어를 붙일 필요도 없다. 클래스와 함수는 접두어가 필요 없을 정도로 작아야 마땅하다. 또한 멤버 변수를 다른 색상으로 표시하거나 눈에 띄게 보여주는 IDE(프로그래머가 소프트웨어 코드를 효율적으로 개발하도록 .. 더보기
1-5. 이름을 잘 짓는 간단한 규칙 (검색하기 쉬운 이름을 사용하기) 아래 예시를 통해 검색하기 쉽게 소스코드를 짜는 법을 알아보자 변경 전 for (int j = 0 ; j < 34 ; j++){ s += (t[j]*4)/5 } 변경 후 int realDaysPerIdealDay = 4; const int WORK_DAYS_PER_WEEK = 5; int sum = 0; for(int j = 0 ; j < NUMBER_OF_TASKS ; j ++){ int realTaskDays = taskEstimate[j] * realDaysPerIdealDay int realTaskWeek = (realTaskDays / WORK_DAYS_PER_WEEK); sum += realTaskWeek; } sum이 별로 유용하진 않으나 최소한 검색이 가능하다. WORK_DAYS_PER_W.. 더보기
1-4. 이름을 잘 짓는 간단한 규칙 (발음하기 쉬운 이름을 사용하기) 발음하기 쉬운 이름은 개발자들 간의 지적 대화가 가능하게 만든다. 개발자간의 의사소통을 원활히 하기 위해서라도 발음하기 쉬운 이름을 사용하자. 안좋은 예시 private Date modymdhms; private fianl String pszqint = "102"; 좋은 예시 private Date generationTimestamp; private Date modificationTimestamp; private final String recordId = '102' 더보기
1-3. 이름을 잘 짓는 간단한 규칙 (의미 있게 구분하기) 동일한 범위 안에 다른 두 개념에 같은 이름을 사용하지 말아라. 읽는 사람이 차이를 알도록 이름을 지어라. 다음과 같이 이름을 짓는 것은 피하라. getActiveAccount(); getActiveAccounts(); getActiveAccountInfo(); 연속된 숫자를 붙이지 말아라. 연속적인 숫자를 덧붙인 이름(a1,a2, ...,aN)은 아무런 정보 제공도 안하고 저자의 의도가 전혀 드러나지 않는다. public static void copyChars(char a1[], char a2[]){ for (int i = 0 ; i < a1.length ; i ++){ a2[i] = a1[i]; } } 불용어(의미가 없는 단어나 조사)를 추가하지 말아라. 불용어를 추가한 이름 역시 아무런 정보를 제공.. 더보기
1-2. 이름을 잘 짓는 간단한 규칙 (그릇된 정보 피하기) 코드에 그릇된 단서를 남기지 말아라. 그릇된 단서는 코드 의미를 흐린다. - List가 아니라면 이름에 List를 넣지 말아라. accountList 대신 accountGroup, bunchOfAccounts, Accounts라 명명하는게 명확하다. - 서로 흡사한 이름을 사용하지 않도록 주의하라. - 널리 쓰이는 단어를 다른 의미로 사용하지 말아라. hp, aix, sco 등등 - 일관성이 떨어지는 표기법도 그릇된 정보다. 표기법에 일관성을 지켜라. 더보기
1-1. 이름을 잘 짓는 간단한 규칙 (분명한 의도) 1. 분명한 의도 함수, 변수, 클래스 등에 존재 이유, 수행 기능, 사용 방법등에 대한 주석이 따로 필요하다면 의도를 분며이 드러내지 못했다는 것을 뜻한다. 물론 주석이 필요할 때도 있지만 주석을 최소화로 하여 코드를 읽기만 해도 대부분 이해가 되도록 의도를 명확하게 표현해야 한다. 이런 아무런 의미가 드러나지 않는 변수명보다는 다음과 같이 측정하려는 값과 단위를 표현하는 변수명이 좋다. ex) 아무런 의미가 드러나지 않는 변수명 int d; //경과 시간(단위 : 날짜) ex) 측정하려는 값과 단위를 표현하는 변수명 int elapsedTimeInDays; int daysSinceCreation; int daysSinceModification; int fileAgeInDays; 또한 분명한 의도를 가.. 더보기