《코드 깔끔의 길》 독서노트

을 읽는 데는 두 가지 이유가 있다. 첫째, 당신은 프로그래머이다.둘째, 당신은 더 좋은 프로그래머가 되고 싶어요.읽고 나면 다음과 같은 기술을 획득할 수 있습니다.

코드에 대해 더 많이 알고 있다

코드와 나쁜 코드의 차이를 잘 구별

좋은 코드를 어떻게 쓰는지 습득

나쁜 코드를 좋은 코드로 바꾸는 법을 배워라

Later equals never. 어떤 일들은 지금 하지 않으면 앞으로 하지 않을 것이다.
프로그래머 기초 가치 수수께끼
이전에 혼란스러웠던 코드가 뒷다리를 끌었지만 개발자들은 기한의 압력을 짊어지고 혼란을 계속할 수밖에 없었다.제작 혼란은 기한을 맞추는 데 도움이 되지 않는다.
기한을 맞추는 유일한 방법은 코드의 정결을 시종일관 유지하는 것이다.
깔끔한 코드를 쓰는 것은 마치 그림을 그리는 것과 같다.다수의 사람들이 그림이 좋은지 나쁜지 알고 있지만, 우열을 가릴 수 있다는 것은 그림을 가릴 줄 아는 것이 아니라, 코드의 우열을 가릴 수 있는 사람도 깔끔한 코드를 쓸 줄 아는 것을 의미하지 않는다.
깔끔한 코드를 쓰는 데는 대량의 작은 기교를 따라 각고의 노력을 통해 습득한'깔끔함'을 관철해야 한다.이런 코드 감각이 바로 관건이다.
깔끔한 코드란?
깔끔한 코드는 한 가지 일만 한다.깔끔하고 우아해요.
모든 함수, 모든 종류, 모든 모듈은 사방의 세부적인 방해와 오염을 받지 않고 한 가지 일에 전념한다.
의미 있는 명명
변수, 함수, 매개 변수, 클래스, 패키지, 파일.명명해야 할 곳이 많다.어떻게 명명해야 간단명료할 수 있습니까?
1. 명실상부하다
말하기는 간단하지만, 이것은 매우 엄숙한 문제다.좋은 이름을 고르는 데는 시간이 걸리지만, 절약하는 시간은 낭비하는 것보다 훨씬 많다.일단 좋은 이름이 생기면 낡은 것으로 바꾸어라.

명칭에 주석이 필요하면 이름을 잘못 지었다는 뜻이다.(명실상부하지 않다)

//     
int d;          //      ，    。
    
//     
int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;

본뜻을 나타내는 명칭을 선택하면 코드를 쉽게 이해하고 수정할 수 있다.

public List getThem() {
    List list1 = new ArrayList();
    for (int[] x : theList) {
        if (x[0] == 4) {
            list1.add(x);
        }
    }
    return list1;
}

위의 코드는 비록 간결하지만, 우리는 그것이 도대체 무엇을 했는지 분명히 말할 수 있습니까?문제는 코드의 간결도가 아니라 코드의 모호도에 있다. 즉, 상하문이 코드에 명확하게 나타나지 않는 정도다.위 코드에서는 이와 유사한 질문에 대한 답을 알려달라고 합니다.

theList에서 어떤 종류의 물건인가

theList 0 아래에 표시된 항목의 의미는 무엇입니까

치 4의 의미는 무엇입니까

되돌아오는 목록을 어떻게 사용하나요

문제의 답안은 코드 섹션에 나타나지 않았는데, 이것이 바로 그들이 마땅히 있어야 할 곳이다.예를 들어, 우리는 천둥치기 게임을 개발하고 있는데, 판면이 theList라는 단원격 목록이라는 것을 발견하면, 그 이름을 게임 보드로 바꾸자.
디스크 위의 모든 칸은 간단한 그룹으로 표시됩니다.0으로 표시된 항목은 상태의 값이며, 이 상태의 값은 4로 표시됨을 나타낸다.의미 있는 명칭으로 바꾸면 코드는 상당히 개선될 것이다.

public List getFlaggedCells() {
    List flaggedCells = new ArrayList<>();
    for (int[] cell : gameBoard) {
        if (cell[STAUS_VALUE] == FLAGGED) {
            flaggedCells.add(cell);
        }
    }
    return flaggedCells;
}

더 나아가 int수 그룹이 칸을 표시하지 않고 다른 클래스를 쓸 수 있다.이 종류는 명실상부한 함수 (isFlagged) 를 포함하여 그 마술수 (바로 그 4) 를 덮는다.그래서 함수의 새로운 버전을 얻었다.

public List getFlaggedCells() {
    List flaggedCells = new ArrayList<>();
    for (Cell cell : gameBoard) {
        if (cell.isFlagged()) {
            flaggedCells.add(cell);
        }
    }
    return flaggedCells;
}

이름만 간단히 바꾸면 무슨 일이 일어났는지 쉽게 알 수 있다.이게 바로 이름을 고르는 힘입니다.
2. 오도 방지
프로그래머는 코드의 본뜻을 감추는 잘못된 단서를 남기는 것을 피해야 한다.본의에 어긋나는 단어의 사용을 피해야 한다.예를 들어 계정이 정말 리스트 형식이 아니라면 계정을 계정으로 가리키지 마라. (용기가 하나의 리스트라도 이름에 용기 형식 이름을 쓰지 않는 것이 가장 좋다.)계정이 포함된 용기가 정말 리스트가 아니라면 잘못된 판단을 불러일으킬 수 있다.그래서 account Group이나 bunch Of Accounts, 심지어 직접 accounts를 사용하는 것이 좋습니다.
서로 다른 점이 비교적 작은 명칭을 사용하는 것을 경계하다.모듈 중 어느 곳XYZControllerForEfficientHandlongOfStrings과 다른 곳XYZControllerForEfficientStorageOfStrings을 구분하는 데 얼마나 걸릴까요?이 두 단어의 외형은 정말 너무 비슷하다.
오도성 명칭이 정말 무서운 예는 소문자 l과 대문자 O를 변수명으로 사용하는데 특히 조합해서 사용할 때이다.문제는 둘이 숫자 1과 0처럼 보인다는 점이다.
3. 의미 있는 구분
숫자 시리즈와 쓸데없는 명칭은 컴파일러를 충족시킬 수 있지만 턱없이 부족하다.

public static void copyChars(char[] a1, char[] a2) {
    for (int i = 0; i < a1.length; i++) {
        a2[i] = a1[1];
    }
}

숫자 시리즈로 명명(a1, a2,...aN)은 의미에 따라 명명된 대립면이다.이런 명칭은 순전히 오도이다. 정확한 정보를 전혀 제공하지 않았고, 작가의 의도를 이끄는 단서를 제공하지 않았다.
만약 매개 변수의 이름을 소스와 destination으로 바꾸면, 이 함수는 훨씬 그럴듯할 것이다.
쓸데없는 말은 또 다른 무의미한 구분이다.프로듀서 종류가 있다고 가정해 봐.만약 ProductInfo나 ProductData 클래스가 하나 더 있다면, 그것들의 명칭은 다르지만 뜻은 다르지 않다.Info와 Data는 a, an, the처럼 의미가 모호한 쓸데없는 말이다.
명확한 약속이 없으면 변수 money Amout은 money와 다를 것이 없고 customer Info와customer는 다를 것이 없고 account Data와account는 다를 것이 없고 the Message도 메시지와 다를 것이 없다.명칭을 구분하려면 독자가 서로 다른 점을 감별할 수 있는 방식으로 구분해야 한다.
4. 읽은 이름으로
읽을 수 있는 명칭은 기억하기 쉽다.명칭을 읽지 못하면 토론할 때 바보 같다.

Date genymdhms //     ， 、 、 、 、 、 

Date generationTimestamp;

5. 검색 가능한 이름 사용
찾기MAX_CLASSES_PER_STUDENT는 숫자 7을 찾는 것보다 훨씬 쉽다.같은 알파벳 e도 검색하기 쉬운 변수 이름이 아니다.너무 흔하니까.
알파벳 이름은 짧은 방법의 국부 변수에만 사용됩니다.명칭의 길이는 그 작용역의 크기와 상응해야 한다.만약 변수나 상수가 코드에서 여러 곳에서 사용될 수 있다면, 검색하기 편리한 이름을 부여해야 한다.
6. 유형이나 역할 영역을 이름으로 묶는 것을 피한다

헝가리어 표기법(Hungarian Notation, HN)

초기 컴파일러는 유형 검사를 하지 않으며 프로그래머는 헝가리어 표기법(Hungarian Notation, HN)으로 유형을 기억하도록 도와야 한다.
Windows의 C 언어 API 시대에 HN은 전설적인 색채를 가진 마이크로소프트 프로그래머 찰스 시모니를 기념하기 위해 매우 중요하다고 전해진다.이런 표기법은 비교적 간단하다. 즉 변수 이름은 이 변수 데이터 형식을 나타내는 소문자로 시작한다.
예를 들어, szCmdLine의 접두사 sz는 string end of zero를 나타냅니다.0으로 끝나는 문자열.
strPhone - Phone이 문자열 유형임을 나타냅니다.
현재 대부분의 언어는 강한 유형이고 코드 편집 환경은 컴파일을 시작하기 전에 유형 오류를 탐지할 정도로 선진적이다!그래서 HN과 다른 유사한 포맷 인코딩이 불필요해졌어요.
그것들은 변수, 함수, 또는 클래스의 이름이나 유형을 수정하는 데 어려움을 증가시켰다.

PhoneNumber phoneString;

//     ，      。

구성원 접두어

m 를 사용할 필요도 없다접두사로 구성원 변수를 표시합니다.클래스와 함수를 충분하게 작게 만들어서 구성원 접두사에 대한 수요를 없애야 한다.

인터페이스 및 구현

인터페이스 앞글자 I가 남용되었습니다.
7. 유형명은 명사 또는 명사단어, 방법명은 동사 또는 동사단어
Customer, WikiPage, Account와 같은 클래스 이름입니다.Manager, Processor, Data 또는 Info 등의 클래스를 사용하지 마십시오.
PostPayment, deletePage 또는 save와 같은 메서드 이름입니다.속성 접근기, 수정기, 단언은 그 값에 따라 명명되어야 하며, Javabean 표준에 따라 get, set, is 접두사를 붙여야 한다.
8. 동일한 개념에 대응하는 통일된 단어
예를 들어 get,fetch,retrieve 표현의 의미는 차이가 많지 않기 때문에 가능한 한 여러 종류가 같은 쓰기를 사용하도록 유지한다.
Controller, Manager, Driver의 의미는 비슷하며 가능한 한 일치하도록 합니다.
9. 쌍관어를 쓰지 않는다
10. 솔루션 영역 이름 사용
코드는 프로그래머에게 읽어주는 것이고 컴퓨터 분야의 용어로 이름을 붙이는 것은 좋은 방법이다.예를 들어 AccountVisitor, JobQueue 등입니다.
프로그래머가 익숙한 용어로 이름을 지을 수 없다면, 관련 문제의 영역 이름을 사용하십시오.
11. 의미 있는 언어 환경을 추가하고, 쓸모없는 언어 환경을 추가하지 마라
만약 당신이 좋은 클래스, 함수, 또는 명칭 공간을 명명해서 명칭을 배치한다면, 독자에게 언어 환경을 제공하는 것이 가장 좋다.없으면 마지막 방법으로 이름에 접두사를 추가합니다.
예를 들어firstName,lastName,street,hourseNumber,city,state 변수라고 하는데, 함께 놓을 때 주소가 명확합니다.만약 단지 하나의 방법에서 단독으로state 변수를 보았다면, 당신은 당연히 하나의 주소로 추정해야 합니까?
언어 환경을 제공하기 위해 접두사 addrFirstName,addrLastName,addrState를 추가할 수 있습니다.
'주유소 디럭스 에디션'(Gas Station Deluxe)이라는 애플리케이션이 있다고 가정하면 각 클래스에 GSD 접두사를 붙이는 것은 좋은 아이디어가 아니다.