ASP.NET エンジニアリングガイドラインを読んだ感想 - ぐだぐだ言ってないでコードを書けよ、ハゲ。

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

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

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

タブは使わずスペース4つ

プライベートメンバは _camelCase で書く

this は必要にならない限り使わない

メンバのアクセス修飾子は省略しない

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

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

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

たとえば String ではなく string

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

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

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

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

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

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

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

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