読者です 読者をやめる 読者になる 読者になる

ASP.NET エンジニアリングガイドラインを読んだ感想

C# 雑記

Engineering guidelines · aspnet/Home Wiki · GitHub

ASP.NET のコントリビュート方法が公開されていた。


最近は勤務先のコードスタイルガイドラインを整備していることもあって、気になった部分をまとめておく。
ここではコードの書き方についてだけ取り上げる。


コーディングスタイル全般

  1. タブは使わずスペース4つ
  2. プライベートメンバは _camelCase で書く
  3. this は必要にならない限り使わない
  4. メンバのアクセス修飾子は省略しない

もっともなところ。
宗教論争になりがちなので明確化が必要と感じる。


var の使い方

コンパイラが許す限り var を使う

C# 3.0 から var が使えるようになった。
ついついクセで型を書いてしまうことがあったけど、var を優先する、というルールはメンテナンス面から見て大事。


.NETの型より C# の型を優先する

たとえば String ではなく string

ルール自体には文句はない。
今さらなのかもしれないけど、String は .NET の型だったんだ、と初めて知った。
VB やらないからそれを意識することがなかった。
そういえば WindowsAPI をインポートするときは .NET の型を使ってたなあ。


InternalVisibleTo はテストアセンブリに対してのみ使う

そうしないと混沌とするから当然だよなと納得。
いずれはコンパイラ側で防いでほしい案件。


拡張メソッドの使い方

前提として標準の static メソッドでよければ拡張メソッドは使わない。

ここの切り分けは自分の中で整理できてないなと感じる。
メンバを生やしてはならないクラスに、そのクラス自体に生えていてほしいメンバは拡張メソッドを使ってしまっている。
もしかすると世の中の標準とはずれているのかも。

クラス名は<Feature>Extensions, <Target><Feature>Extensions, or <Feature><Target>Extensions のどれかで書く。

はじめに細かい突っ込み入れると、最初の例は<Target>Extensionsのミスっぽい。
クラス名のみはよく使っていたけど、Feature の名前入れるパターンはあまり意識できてなかったので参考にしたい。


最後に

OSS化のニュースの直後は、「これでマルチプラットフォームで動作するようになる」とか「Microsoftが開発者を支援する企業に変わってきた」といったマクロな話をよく見かけた。
MSの今回の発表で何が起こるのか、の私的感想 - 亀岡的プログラマ日記


公開された情報から開発者がこうして何かを考えるきっかけになるのはいいことだなと感じた。
こういう面からもC#ASP.NET界隈が活気づいて、良くなっていくと面白いなあ。


リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)