개시하다

《코드 읽기》는 오라리사가 출판한 것으로 인코딩 기술의 기술서를 모았다.
잘 알려진 명서로, 지인이나 기술류 사이트에 자주 소개되지만 제대로 읽을 기회가 없었던 터라 이럴 때 메모를 정리하면서 읽으려 한다.
그나저나 원본은 Dustin Boswell, Trevor Fourcher의 "The Art of Readable Code"입니다.
원서 제목에 "The Art"라는 글이...설마 코딩 속의 아름다움이 예술이라는 걸 암시하는 건가...

프로비저닝

【今回取り扱う内容】
   - 1章 理解しやすいコード
- Ⅰ部 表面上の改善
   - 2章 名前に情報を詰め込む
   - 3章 誤解されない名前
   - 4章 美しさ
   - 5章 コメントすべきことを知る
   - 6章 コメントは正確で簡潔に
-------------------
(本稿以降の内容)
- Ⅱ部 ループ/ロジックの単純化
- Ⅲ部 コード再編成
- Ⅳ部　選抜テーマ

전체적으로 4개 부분으로 구성돼 난이도 순서대로 장립했다.
저자는 1∼2주 정도 읽고 가볍고 유쾌하게 읽는 것을 추천한다.

컨텐트

독단적인 I부 전체 초개요

"patte 보기"를 통해 알 수 있는 코드입니다. 좋은 코드입니다.

함수/변수 이름에 명확한 정보를 삽입하여 필요 없는 주석을 줄이고 전체 코드를 간소화한다.

간소화된 코드는 유사한 처리와 절차에 따라 종합하여 외관에 편차가 없는 방식으로 배열한다.

전체관을 의식한 토대에서 의식하는 부분과 함정의 요점에 대해 논평한다.

장 요약

주황색 문자는 반드시 의식해야 할 내용이다
자색 문자는 구체적인 대책 방법이다

서장

제1장: 목적

이른바'우수'코드
'이해하기 쉬운 코드=읽기 쉬운 코드=타인이 가장 짧은 시간에 이해할 수 있는 코드'

코드를 쓸 때 우선순위는 다음과 같습니다.
'이해하기 쉬운'코드의 단도입니다.
짧고 복잡하고 이해하기 어려운 코드보다 알기 쉬운 코드를 선호한다.

Ⅰ부 표면상의 개선

제2장: 이름에 메시지를 넣다

동의어 사전 등을 사용하고 명확한 단어('색채가 선명하다'는 단어)를 선택한다

의미 있는 변수에 통용되지 않고 정보가 없는 공허한 이름(tmp/retval 등)

둘 이상의 사이클 이퀄라이저가 있는 경우 사이클 위치 이름이 병합된 이름

을 사용할 수 있습니다.

"무엇을 할 것인가", "어떻게 할 것인가", 동작이나 목적을 나타내는 구체적인 명칭

이 가장 좋다.

단위, 속성, 유형 정보를 포함할 수 있음헝가리

헝가리 기법에 대해 부정적인 의견이 많으니 참작해야 한다
(Qita 기사 "헝가리 필기"등 참조)

저자는 헝가리 기법조차 엄격하지 않고 규율이 느슨한'영어 기법(조어)'

을 추천한다.

역할 영역의 길이에 따라 이름의 길이를 판단한다(역할 영역이 짧으면 짧은 이름도 OK)

일반적으로 알려진 생략 형식(String->str 등)

사용 가능

불필요한 정보는 기재하지 않습니다.필요한 것만 있다.

제3장: 오해받지 않는 이름

크기 문자가 사용되는 위치 구분 (로컬 변수/전역 함수)

애매모호한 단어는 사용하지 않는다

제한이 있으면 limit 대신 min/max를 사용합니다

범위를 지정하면first/last,begin/end(이하/이하) 를 사용합니다

사용자가 원하는 처리를 수행해야 합니다.
("get", "size"처럼 가벼운 액세스기로 재처리할 수 없습니다. "컴퓨터"등으로 변경됩니다.)

원형 계승 모델과 같은 상황에서 추상성이 높은'template'를 사용하지 않는다
"inherit(from experimment)"이라는 이름 사용

아름답다

우수한 소스 코드는'눈에 좋다'는 코드

"프로그래밍 시간의 태반이 코드를 읽는 시간"

읽기 쉬운 코드 "공백, 설정, 순서 3원칙"

독자의 습관과 일치하는 레이아웃을 사용하다

변수 명칭의 길이 등을 고려하여 줄 바꾸기 위치를 조정

변수의 순서는 가시화 순서, 중요도 순서, 알파벳 순서로 배열

비슷한 전선이 비슷해 보여요.

공백을 사용하여 세로줄을 곧게 하기

관련 코드를 함께 블록화하다

작은 코드를 모아서 방법화(조수법 사용)
보기만 해도 절차를 쉽게 이해할 수 있고 코드를 추가하는 것도 수월해진다

유사한 방법으로 각 블록을 종합하고 단락별로 구분

같은 댓글을 모아서 써요.

同じコメントは一ヵ所にまとめて書く
e.g. 同じコンストラクタを用いたインスタンスが何度も繰り返される場合

-----------------------------

【悪い例】
instance1 =
new constructor(
    a1, // aの引数
    b1, // bの引数
    c1, // cの引数
    d1, // dの引数
)

instance2 =
new constructor(
    a2, // aの引数
    b2, // bの引数
    c2, // cの引数
    d2, // dの引数
)
...

-----------------------------

【良い例】
// new constructor(aの引数, bの引数, cの引数, dの引数)
//                 [kbps]   [ms]   [percent]

instance1 = new constructor(a1, b1, c1, d1)
instance2 = new constructor(a2, b2, c2, d2)

제5장: 이 평론의 내용을 안다

"주석의 목적은 작가의 의도를 독자에게 전달하는 것이다"

리뷰에 대한 3가지 주제

댓글을 달면 안 되는 거 알아요.

코드에서 바로 알 수 있는 정보를 기재하지 않음

추상(심각)명칭의 함수에 대한 보충설명이 아닌 곳

일반적으로 코드가 읽기 어려운 주석을 보충할 필요가 없다
우수 코드 > 잔혹 코드 + 우수 평론

코드를 쓸 때의 자신의 생각을 기록하다

'우수한 평론'='생각을 기록하는'용

주석에'TODO:','todo:','maybe-later:'등의 기호를 첨가하여 코드의 결함/수정 부분을 문장화

상수의 정의 시 이유와 배경을 기재하여 조정의 필요성을 통지

독자의 입장에서 무엇을 필요로 하는지 고려하다

틀리기 쉬운 곳이나 의문이 생기기 쉬운 곳에 미리 주석에 기재

전체상 쓰기

블록을 뛰어넘어 먼저 논평(6장: 쓰기 비결에 연결)

제6장: 평론은 정확하고 간결해야 한다

간략한 설명

대명사 피하기

문장을 연마

추상적인 내용이 아니라 올바른 처리를 기재한다

사용 예제

처리를 통해 무엇을 얻고 싶은지 기재

정보 집적도가 높은 단어 사용

후기

나는 현 단계에서 이 책의 내용을 더 이상 총결산할 수 없다고 생각한다.
실제적으로 더 많은 인코딩을 하고 이러한 경험을 쌓은 토대에서 내용에 대한 이해를 깊이 있게 하는 것이 좋기 때문에 잠시 여기에 투고하겠습니다.
만약 무슨 주의가 있다면, 나는 수시로 보도를 갱신하고 싶다.

사이트 축소판 그림

리더십 코드를 읽었기 때문에 적어 놓았다

리더 코드 요약과 리더 코드 요약의 효과적인 이용 방법

FPGA 개발 다이어리

'읽고 바로 전달하는 글'의 3가지 조건