C#ルールブック 読みやすく効率的なコードの原則
以前に属していた会社での事。
新たにC#のプロジェクトに参画した新人さんのコーディングスタイルが(悪い意味で)個性的すぎるので、教育してほしいと頼まれました。
時間もあまりなかったので、とりあえず.NETの標準的なコーディングスタイルを最低限知ってもらおうと思いました。
厳密に.NETのコーディング標準を知るのなら、MSDNのガイドラインに目を通すのが良いでしょう。
とはいえ、お世辞にも読みやすいとは言えません。
技術熱心ではない(探究心がない)新人さんにも手軽に把握できるようなコーディング標準を探していて、手にしたのがこの一冊。
C#ルールブック 〜読みやすく効率的なコードの原則
posted with amazlet at 12.01.15
C#コーディングの際に遵守すべきスタイルと、その理由について書かれています。
おおよそ、MSDNのガイドラインに従っているのでこの本の通りにコードを書いていれば標準的なスタイルから大きく逸脱する心配はないでしょう。
ただ、いくつか個人的に引っかかるルールがあります。
1. 識別子は英語
業務アプリケーションなどで、専門用語を表す識別子に英語や、略称を使うと却ってわかりにくい事があると思います。
それなら、いっその事日本語で書いた方がわかりやすい。どうせコメントも日本語で書くでしょうし。
ただ、BCLの識別子は英語なので、英語と日本語が混在する事になり、統一性はなくなりますね。
2. 1行80文字までにする
印刷などを考慮してだそうです。
昔ならそうでしょうけど、今日のコーディング環境を考えると少なすぎるのでは。
特にCなんかに比べて、横に長くなりがちな言語ですし。
私は120文字を目安にしています。
というか、ソースを印刷する機会って頻繁にあるんでしょうか。
私はないです。
3. forのカウンター変数はi, j, k
伝統に従っているという意味ではわかりやすいでしょうけど、果たして可読性の向上に繋がるんでしょうか。
4. return文で演算しない
単純なメソッドなら許可しても良いと思うのですが。
5. break, continue使用禁止
強力な制御文なので、使い過ぎると著しく見にくくなります。
が、適切に使えば便利です。なので禁止するほどの物かなと。
でも現実に「適切に使えない人」がいるので、難しいところです。
6. stringの比較はEquals()メソッドで。
何のための==演算子オーバーロードなんでしょう。
7. System.Exceptionではなく、System.ApplicationExceptionを継承する
アプリケーション固有の例外を区別するために独自の例外は「ApplicationExceptionから派生させなさい」という事ですが
CLRがスローする例外の中に、ApplicationExceptionを派生元としているクラスがあります。
従って、派生元クラスの種類でCLR例外と、アプリケーション固有例外の区別をつける事は不可能です。
というか、Microsoftさん自身がApplicationExceptionを使うなと申されております。
標準例外型の使用 | Microsoft Docs
現場でも未だにApplicationExceptionを信じて止まない方達が沢山いますね。
この情報はかなり前にアナウンスされていたと思うのですが、2011年初版の本でこれは如何なものかと。
あれ。
褒めるつもりだったのに突っ込みの方が多くなってしまった。
まぁ、最後以外は好みの問題程度でしょうか。
総合的な評価として、細かい説明は少ないですが、読みやすいし要点は抑えてあるので、
経験の浅いコーダーにコーディングルールについて意識させる材料には丁度良いかと思います。
(私も経験浅いコーダーですけどね)
