あるAnonymous Coward 曰く、
C#のコーディング規約として一番権威あるのは本家Microsoftのものだと思われるが、そのページに、いつの間にか「private/internalフィールドには _ プレフィックス」「private/internalなstaticフィールドには s_ プレフィックス」「ThreadStaticの場合は t_ プレフィックス」を付ける必要がある(should)という項目が追加され、C#er達が大混乱に陥っている(C#のコーディング規則、
発端となったツイート)。C#においては、後発のUnityがプレフィックスを付ける文化を持っている一方、本家のC#においては、プレフィックスを付けずに this. で参照する文化があり、StyleCop.Analyzersなどのスタイルチェックもこれをデフォルトとしている。また、2010年頃のプログラミング書籍では「メンバー変数にプレフィックスを付けるのはIDEが未発達の頃の名残で、IDEが発達した現代では不要」としてプレフィックスを付けないことが推奨されていたと記憶している。
今回の記述はそうしたこれまでの流れと真っ向から対立するもので、Twitter上ではアンダースコア派が歓喜する一方、this派からは大ブーイングが起こっているようだ。ただし、この規約が書かれたのは6年前でそれが今になって反映されただけといったコメントもあるなど、なんでこうなったかはよく分からない。
元となったコーディング規約はオープンソースの.NETランタイム貢献者向けに書かれたものであり、C#開発者一般に向けたものではない。日本語版にはまだ反映されていないが、英語版には「.NET Runtime, C# Coding Style」から取り入れられたものであることが明記され、使いたければ使えばいいという感じになっている。「s_」「t_」の使用はハンガリアン記法を使用しないよう求める.NETの一般的な名前付け規則に反するが、この点は解決されていない。
なお、元のコーディング規約では「this.」について、「どうしても必要な場合を除いて避ける」と記載されている。
| オープンソース
| マイクロソフト
| プログラミング
| デベロッパー
|
関連ストーリー:
Linuxカーネルのコーディング規約、包括的用語使用のガイドラインが追加
2020年07月12日
Linuxカーネルのコーディング規約、1行80桁の制限を撤廃
2020年06月04日
「 いいコーディング規約、悪いコーディング規約?」2019年版
2019年07月25日
Microsoft、ソースコードのコーディング規約を自動推論する技術を開発・プレビュー公開
2018年07月25日
Windows版のChrome 64以降はClangでコンパイルされている
2018年03月10日
Microsoft、オープンソースの.NET実行エンジン「CoreCLR」を公開
2015年02月08日
オープンソースとなった.NETは仕事で使えるか
2014年12月26日
Microsoftのオープンソース受け入れは何を生み出すのか
2014年12月23日
Microsoftが.NET Coreを紹介
2014年12月07日
Microsoft、「.NET Core」をオープンソース化。LinuxやMacもサポート
2014年11月13日
もうやらなくていい昔のコーディングテクニックあれこれ
2009年05月04日
いいコーディング規約、悪いコーディング規約?
2008年07月22日
ExcelやWordの開発者、いよいよ宇宙へ
2007年04月05日
Source: スラッシュドット