言語仕様によって関数の意味する細かい意味は異なりますが、大体は、ソースコードの実行をひとまとまりにしたものです。
JavaScriptや関数型言語などでは関数は、変数に代入したり、自由に引数に渡したりできるものです。 また、純粋関数型言語では、関数には副作用を記述できません。
多くの言語では、関数はサブルーチン的に使われる、最小単位です。 クラスのメソッドよりも小さい実行単位だと考えてもいいでしょう。
クラスは、オブジェクト指向言語では、データとそのデータを取り扱うメソッドがセットになったものです。 大抵のオブジェクト思考言語はクラスという設計図を元に、インスタンスという実体を作り出します。
クラス自体はそのままでは実行されません。唯一の例外はクラスに含まれるstaticメソッドなどです。
インスタンスはオブジェクトとも呼ばれ、メモリ上に実際に作られたもので、 同じクラスから生み出されたインスタンスでも、インスタンスごとに保持してるデータ（メンバー）は別物です。
class Hoge {
constructor() {
this.hoge = Math.rand()
}
}たとえばこのようなクラスHogeから生み出されたインスタンスのhogeというメンバーは、生成時に乱数が代入されているため、インスタンスごとに、hogeの値は異なります（もちろん、偶然の一致で同じ数値がランダム生成されることもあり得ます）
インスタンスがもつ個々の変数は、言語によりますがメンバーとかプロパティとかインスタンス変数などと呼ばれます。
クラスという同じ設計図から作り出された個々のインスタンスの個性は、このメンバーの中身によって決まります。
メソッドは、インスタンスから実行される関数です。多くのオブジェクト指向言語ではメソッドは this. this-> などを付けることで、自分のメンバーにアクセスができたり、他のメソッドを呼び出せます。
多くの場合では、メソッドとメンバーのセットがオブジェクト指向のカプセル化という利点であると解釈されています。
そのプロダクトの目的によって、善し悪しの尺度は変わります。原子炉や戦闘機の制御コードであれば、おそらく堅牢なコードの書き方が良いコードでしょう。
ビジネスの為のコードであれば、メンテナンス性が影響を与えるでしょうし、ビジネスでも初期段階であれば、MVPを実現するためのコード、あるいは初期の開発をブーストするコードに価値があるでしょう。
メンテナンス性が高くても価値をもたらさないコードは、おそらく良いコードではないでしょう。
ただ、こういった相対的な話をし出すと「ビジネスを考慮しろ」とかだるいだけの一般論にしかなりません。
そこでここでは尺度を決め打ちしてしまいましょう。ビジネスを実現するためのソースコードであり、メンテナンス性をある程度重視する、ビジネス環境の変化に即応できるどうかを尺度としてしまいます。
それ以外の尺度が必要な場合は、それ専門の本なり資料を探すことをオススメします。
名前はプログラミングにおいて基本であり奥義です。 このとき名前は、プロダクト名、ドメイン名、ディレクトリ名、ファイル名、クラス名、関数名、変数名などあらゆる名前を指します。
少し大げさにいうと、JavaScriptはアロー関数によって1ランク上の言語に進化しました。
アロー関数の利点は、ほんの少しの記述で、ソースコードの塊を関数に移すことができ、変数に代入することで「名前を与えることができる」というものです。
これは決してバカにできるものではありません。ソースコードの塊にコメントを付ける必要がこれによって激減します。 少なくとも What をソースコードに記述する理由はなくなりました。What は名前として付けましょう。
驚き最小の法則という言葉があります。Rubyコミュニティが発祥と言われていますが、実際には…
よくあるものに矛盾する、つまり驚きを与えるようなコードは、決して読みやすいコードではありません。 矛盾のある名前付け、一般的ではない記述方法など
DRYはDon't Repeat Yourself. の略で、開発者が、自分自身、つまり人間の手で繰り返すなという原則です。
DRY原則はあくまで、同じ意味の存在を、複数の場所に人間の手で書くことをいさめるだけの原則です。 これは、マスターがどこにあるのかが分からなくなる状態を防ぐためにあります。
「人間の手で」繰り返してはいけないだけなので、たとえばメタプログラミングなどを駆使して、 機械的に繰り返してもかまいません。あくまで、人間がソースコードをいじる上で、マスターがどこかはっきりしていればいいのです。
DRY原則は単純な重複を禁止する原則ではありません。
同じ文字が並んでいるからという理由で異なるコードを統合してはいけません。
同じ意味を持ち、内容も同じであればそれはDRY原則のもと、ある一箇所にのみ記述すべきです。
大切なことは「意味」です。どういう由来でそれが生まれたのか？責務や意味が重要です。
- コードはhow
- テストはwhat
- コミットメッセージはwhy
- ソースコードのコメントは why not （だったかな）
プログラミング言語やライブラリ、フレームワークやパッケージングシステムあるいはOSなどによって文化圏というものが存在します。
Androidの人にはAndroidの世界で通じる流儀、iOSの人にはiOSの世界で通じる流儀、Javaの流儀、PHPの流儀、Ruby... etcetc そういったものを本書では「文化圏」と呼びます。
- 変数などの名前の付け方（大文字小文字アンダースコアなどの取り扱い方）
- ディレクトリ構成
- ファイルに書くべき内容
- 環境整備方法、デプロイ方法
- ソースコードの記述ルール（インデントとか）
必ずしも絶対に守らなければならないとは限りませんが、多くの人がしたがっている場合、 よほどの合理的な理由がない限りは、わざわざその文化を無視すべきではありません。
説明なく文化を破ると多くの場合では、驚きをもたらしてしまいます。
PythonだとPEPとか、RubyならRuby wayとか、そういう、 「界隈でよくあるやつ」
- get といいつつ更新する
- get といいつつネットワークやディスクなどにアクセスする