本書は「リーダブルコード」という書籍で「C#で読みやすいコードを書く50の方法」を紹介しています。
Udemy
本書はUdemyという学習用プラットフォームで公開しているコースの書籍版です。動画で学びたい方は，ここからアクセスしてください。
オブジェクト指向含まず
内容は「オブジェクト指向」とかそういうことではなく，シンプルに「書き方をこうしたほうがいいですよ」みたいなやつを選りすぐって紹介しています。
だからオブジェクト指向的な内容は含んでいません。インターフェースとかデザインパターンとかそういうの使うとこういう感じでよくなるよみたいな書き方はいっぱいあるんですけど，そこまで含めると，情報が膨大になってまとまらないので，それは別の機会に解説することとして，本書には含めていません。
ですので，逆にオブジェクト指向が理解できていなくても，即効性があると思います。
本書には単純に「こう書いた方が確かに見やすよね」みたいなやつが，いろいろ出てくると思うので「オブジェクト指向あまりよくわからないな」っていう方でも読んでもらったら，いいと思います。とりあえずC#の文法は覚えたけどっていう感じの方にも理解していただける内容になっていると思います。
「テスト駆動開発」「ドメイン駆動開発」含まず
テスト駆動開発とかドメイン駆動開発などの内容も含んでません。
ですので，「プログラム設計」としていい書き方，というよりは「単純にこういう風に書いた方が分かり易い」という感じの内容になっています。
コーディングルール含まず
あと，別の書籍で「C＃のコーディングルール」というのをものがあり，そこでは，スタイルコップライザーというツールを使って，マイクロソフトが定義している警告に引っかからないようにコードを統一していく書き方や，C#のコーディングルール全般を解説している書籍がありますが，その内容とも被らないようにしているので，基本的にはそういうコーディングルールは分かった上で，「こうしたこういう書き方がいいですよ」みたいな内容になっています。
あと注意点としては，本書の内容が「100%の正解ではない」という事。
こういうプログラミングの世界は，複数の書き方がある場合，どうしても100%の正解が出ないケースというのがあります。例えばコンパイルエラーになったり，実行時エラーになるのであれば，それは書いてはいけないコードという事が分かるし，チーム全体でもめることもないのですが，2つ以上の書き方があり，どちらも正常に動作する場合は，「保守性」「わかりやすさ」「パフォーマンス」「バグの混入確率」「テスト容易性」等を考慮して，より良い書き方を導き出すのですが，どちらも一長一短がある場合などは，誰にも決められないケースもあります。そういう場合は皆さんのチームで話し合ってもらったり多数決をとってもらったり，そういった感じで決めてもらわないといけない物もあります。そういう場合，本書では，私はこうしていますという感じで紹介しているので，「ここ背きたいな」という事であれば，背いてもらってもOKです。絶対的な正解ではないという事をご理解ください。
コードの判定区分
本書は下記の区分で，いいコードと悪いコードを表現しています。
- BAD：良くない書き方
- NOTBAD：別に悪くはない
- GOOD：いい書き方，推奨
「BAD」は良くない書き方なので，書かないでほしい物。GOODは書いてほしい書き方。あと，いい書き方ではないけど，ある程度仕方ない書き方というのも存在するので，「悪くはない」という感じでNOTBADという区別をしています。
基本的には，この3段階でコードを判定しながら解説しているので結構わかりやすいものができたと思っています。
実行環境
本書はWindows10上で動作するVisualStudio2022のC#にてサンプルプログラミングを行いながら解説しています。VisualStudio2019やVisualStudio2017，VisualStudio2015あたりでも同様の動作をすると思いますが，バージョン違いによるキャプチャー画面の違いなどは，考慮しながら読んでいただきたく思います。
また，ラムダ式が存在しないVisualStudio2005などでは動作しませんので最低でもVisualStudio2008以上を使っていただく必要がありますが，家で学習する際は，最新のVisualStudioが無料でダウンロードできるので，そちらを使用してください。皆さんが本書を読むころはVisualStudio2022やもっと新しいバージョンかもしれませんが，おそらく問題ないでしょう。
VisualStudioのインストール方法はYoutubeを参照してください。
VisualStudio2022のインストール方法はこちらの動画を参照してください
#02_プロジェクトの作成
#03_右に長いコードを書かない_隣のとなりまでしか訪ねない
#04_隣のとなりまで_右スクロールより縦スクロールの方がいい
#05_IFとELSEがある時は肯定系をIF否定形をELSEにする
#06_比較する時は変数を左_定数を右にする
#07_複数の比較を1回のif文でやらない
#08_booの比較でTrueやFalseを書かない
#09_否定の否定はしない
#10_型チェックはasを使う
#11_メソッドはできるだけ早く抜ける_返却する値を無駄に変数に入れない
#12_対象外の時はすぐに抜ける
#13_都合が悪いケースはガードする
#14_必ずやりたい処理はfinallyを使う
#15_比較演算子はできるだけクラスにさせる
#16_ifの中括弧の省略はしない
#17_if文のリーダブルコードまとめ
#18_名前の付け方
#19_意図が明確な名前を付ける
#20_名前は素直に付ける_連想ゲーム的な名前を付けない
#21_1つの事しかしていなければ短い名前でも理解できる
#22_長いクラス名の扱い方
#23_単数形と複数形で表現する
#24_対になる言葉の組み合わせを決めておく
#25_業務で使う名前は統一する
#26_名前を統一するための辞書ツール作成
#27_メンバー変数にアンダーバーを付ける
#28_ハンガリアン記法を使わない
#29_メソッド内の変数をメソッド最初に全部宣言しない
#30_メソッド内の変数は直前に宣言する
#31_ループの変数はループ内で宣言する
#32_変数を使いまわさない
#33_boolの戻り値はどちらがTrueかをわかるようにする
#34_解放が必要なオブジェクトにはusingを使う
#35_varを推奨する場合
#36_メソッド名の付け方
#37_voidとFunctionを意識する
#38_インテリセンスを意識した名前にする
#39_生成メソッドはCreate_型変換はToを使う
#40_無駄に変数に入れて返却しない
#41_重複をなくす
#42_リージョンで区切らない
#43_アクセス修飾子とsealedを付ける
#44_クラス名はソリューションエクスプローラーで並べることを意識する
#45_クラス名は名詞か名詞句で命名する
#46_クラス名で継承元や特性を表現する
#47_メソッド内にコメントを書かない
#48_分かりづらい部分はメソッド化をしてメソッド名で想いを伝える
#49_コードを読んだ人が「えっ？」と思うことが予想される場所にだけコメントを付ける
#50_コメントで悪いコードを取り繕うことはできない
#51_未実装機能はTODOコメントを書く
#52_リーダブルコードまとめ