MicrosoftのC#コーディング規約に「privateフィールドにはプレフィックス」と追記されて混乱を呼ぶ 129
混乱 部門より
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.」について、「どうしても必要な場合を除いて避ける」と記載されている。
ヒューマンエラーの原因 (スコア:2)
言語としての規定じゃない以上、privateじゃないフィールドに「_」を付けても
コンパイラ等でエラーになるわけじゃないんでしょ。
そんな人間の努力目標でしかない仕様はヒューマンエラーの原因になりそうに思える。
--------------------
/* SHADOWFIRE */
Re:ヒューマンエラーの原因 (スコア:3, おもしろおかしい)
コーディング自体がヒューマンエラーの温床だからコーディング禁止しようぜ
Re:ヒューマンエラーの原因 (スコア:1)
このばあい修正すべきはニューマンのほうでは
Re:ヒューマンエラーの原因 (スコア:2, すばらしい洞察)
> コンパイラ等でエラーになるわけじゃないんでしょ。
コンパイルエラーにもできる。
C#の場合、コーディングスタイルの不一致のほとんど(機械検出が難しいのは無理)は、コンパイラのオプションで無視するもよし、ワーニングにするも良し、コンパイルエラーにするも選択可能。
Re: (スコア:0)
逆だよ。ヒューマンエラーを防ぐためにつける。ぱっと見でその変数がローカルなのかprivateなのかを区別できるからエラーを減らせる。もちろんローカル変数に間違えて_をつけるミスを起こしたら～なんてのはあるけど、_で区別しないのに比べたらエラー率が下がる（メリットが上回る）。
＃C++もC#も_派
Re:ヒューマンエラーの原因 (スコア:1)
C++では_の次の文字によってはUBになるのでやめてくれ
Re:ヒューマンエラーの原因 (スコア:1)
単純なコーディング規約なんてツールで実装すればいいのに (スコア:1)
IDEやコードエディタ、その他各種開発ツールで、単純なコーディング規約は実装して、
強制適用すればいいのに
なんで単純なコーディング規約を人が注意しないといけないんだ？
Re:単純なコーディング規約なんてツールで実装すればいいのに (スコア:1)
今のVisualStudioでは、たとえば「パブリックなプロパティやメソッドは大文字で始めろ」みたいにコーディングスタイルに関することまでメッセージを出すようになってるよ。
初期設定ではWarningより控えめなMessage扱いで、エラー扱いにして強制する設定もできる。
だからまあ、このプライベートフィールドのプリフィクスについても今後VisualStudioの標準アナライザでメッセージを出すようになるかどうかでMicrosoftのスタンスを判断することもできそう。
うじゃうじゃ
Re: (スコア:0)
＞のプリフィクスに
やっぱプリだよね？ プレじゃなくて・・・
Re:単純なコーディング規約なんてツールで実装すればいいのに (スコア:1)
あ、気づいてなかった…
個人的にはプリフィクスの方が一般的という印象だけど、wikipediaなどでは「プレフィックス [wikipedia.org]」となっていますね。
まあ英語のカタカナ表記ではよくあること、で済ませることになるんでしょうか
うじゃうじゃ
Re: (スコア:0)
今回のアンダーバーの件は関係ないけど、
JavaからC#に来た時に、ローカル変数以外がPascalCase指定で「え？Javaと同じにしとけばいいのにどうしてわざわざ変えたの？」ってなったね。
camelCaseならHogeList hogeListとかすりゃとりあえずわかりやすい変数を定義できるのに、PascalCaseだとHogeList HogeListとなってしまう。
Re:単純なコーディング規約なんてツールで実装すればいいのに (スコア:1)
それはたしか「"パブリックな"フィールドを使わずプロパティ使え」で、
この件はプライベートなフィールドに関することなので関係ないです。
うじゃうじゃ
Re: (スコア:0)
戦争になるからだよ。
言語として1通りの書き方した出来ないものもあるだろうけど、方言を認めないと普及しない。
c#としてはcやjavaあがりも取り込む必要があったからなおさら。
必要ならばIDEでコード規約の強制もできるわけだしな。
しかしc#は当初からcaml/Pascal形式の命名規則があったし、実際警告対象(CA1707,CA1709)なのだが、それにも反してるよな。
確かによくわからん
Re: (スコア:0)
うるせー。ハンガリアン記法復活させるぞ！
Re: (スコア:0)
うるせー。ハンガリアン記法復活させるぞ！
Windows使ってる限りlpStringとか見かけるし……
Re: (スコア:0)
流石にもう無い。
COBOLと同じ絶滅危惧種。
Re: (スコア:0)
つWindows API
Re: (スコア:0)
過去資産読み込んだらいちいち言ってこられるのもちょっと
Re: (スコア:0)
なーに、警告を完璧にゼロにしてコンパイルするやつなんか初心者向け教科書以外で存在しない
Re: (スコア:0)
ログに埋もれたあげくに面倒なバグに遭遇して解決後にワーニング出てたじゃんってなるやつ
Re: (スコア:0)
なーに、警告を完璧にゼロにしてコンパイルするやつなんか初心者向け教科書以外で存在しない
何が存在しないって？
警告出力の設定も決められていて、警告を全て消すことを求める企業も存在しますよ
Re: (スコア:1)
そこそこ名の通ったドイツのERPソフト会社に居たけど、コーディング規則に引っかかった（コードチェッカーから検出された）ソースコードをコミットする時は、Business Justificationを添えてQAに許可をもらう必要があったし、普通は警告なんか残さなかったね。
全部消せと言われる企業、そんなにレアではないと思う。
_ 付きが普通だと思ってました... (スコア:1)
2005 年あたりから ReSharper という Visual Studio というアドインを利用しています。ReSharper のデフォルト設定は _ 付きだったので、それが普通なんだと思って、そのときから _ 付きに変えてます。
> 本家のC#においては、プレフィックスを付けずに this. で参照する文化があり
ASP.NET Core のフレームワークのソースコードも _ 付きなので、_ 付けないほうが少数派だと思っていました。
個人的には統一されていて、コードチェッカーでちゃんと検査してくれるならどっちでもいいんじゃないかと思いますが。
自分の観測範囲だと、Microsoft の名前付け規約無視している人たち (そもそも知らない) が多いので、混乱なんか起きないんじゃないかなあと思います。
Re:_ 付きが普通だと思ってました... (スコア:1)
thisで参照する文化というよりもVisualStudioのエディタでthis.と入力するとインテリセンスでフィールド/プロパティ/メソッド/イベント各種が候補に出るので判り易いからだと思うけど。だからthis.と手癖で入力する。
あと、変数とフィールドを同じ名前にしてしまってバグる可能性が減らせる。
Re: (スコア:0)
あった方が読みやすくて好きだったけどな
VBのMeとどちらかに揃えてくれとは思ったけど
Re: (スコア:0)
Visual Studio標準設定でもthis付けると薄文字で表示されて「省略できるよ」って表示されるからthisは使わなくなった。
Re: (スコア:0)
https://docs.microsoft.com/ja-jp/dotnet/standard/design-guidelines/gen... [microsoft.com]
このセクションでは、単語の選択に関連する一般的な名前付け規則、略語と頭字語の使用に関するガイドライン、言語固有の名前の使用を回避するための推奨事項について説明します。
(略)
アンダースコア、ハイフン、英数字でないその他の文字はいずれも使用しないでください。
いや、Microsoft の名前付け規約無視している (そもそも知らない)のお前。
Re:_ 付きが普通だと思ってました... (スコア:5, 参考になる)
そもそも今までのMSのガイドラインはpublic/protectedなモジュールの外に公開するものに対してのみ規定されてたの
private/internalなモジュール内で完結するものについては特に言及がなかったし実際.NET Frameworkの標準ライブラリ内でも単独の規約を守って作られていたわけではない
.NET Coreでオープンソース化するにあたって.NET Coreの標準ライブラリにおいてモジュール外非公開のものについても規約を決める必要があって定義されたのがこれ
それが今回.NETにおける開発全般の標準規約として示されたという状況
Re: (スコア:0)
外部に公開するプロパティとかはそうだね。
Re: (スコア:0)
_はプロパティのバッキングフィールド用として使われてた。
Re: (スコア:0)
個人的には統一されていて、コードチェッカーでちゃんと検査してくれるならどっちでもいいんじゃないかと思いますが。
これが全てだよな。
Re: (スコア:0)
同じく、ReSharperが付けろっていうので _ 付ける派。最近はもっぱらRider使ってるけど。
このあたりはMSとJetBraindで解釈違いがあるんだなぁとは思ってたけど、そもそもMSの中の人も好みがあるっぽいので、
じゃあもうJetBrainsの人が考えたデフォでいいやって思ってそっちに寄せてる。
凡人の好みなんぞよりJetBrainsの天才の方々たちが考えたデフォ設定の方が尊いに決まってるしネ。
もはやインテリセンスは言語の一部でしょ (スコア:1)
なので、インテリセンスでわかるようなことをわざわざ名前に付けるってのはあまりに前時代的。
ハンガリアン記法が時代を超越して最初から無意味であったとは思わないが、
いくつかのメリットと言われるものも今や価値がない。
それより括弧の字下げスタイル (スコア:1)
個人的に privateについて言及する前に、C＃の字下げスタイルを Java や JavaScript や Rust や Go のように
開け括弧を同じ行に書いてから改行する形に変えて欲しい。
elseの前の 閉じ括弧を同じ行か前の行かはどっちでもいい。
オブジェクト初期化子とか ラムダ式だと横に書いてたりして破綻してるようにしか見えないんだよねぇ。
コード書いてるときは見づらい程度で済むけれど、
チャットで説明とかする場合に無駄に１行ずつ取られるのが結構しんどい。
オールマンスタイルが好きな人もいるんだろうけど、内容が連続していないように見えるんだよなぁ。
Re:それより括弧の字下げスタイル (スコア:1)
// そこじゃないってばよ
Re:それより括弧の字下げスタイル (スコア:1)
Re:それより括弧の字下げスタイル (スコア:1)
つべこべ言わずに従え (スコア:0)
既にやってるので高みの見物
Re: (スコア:0)
うるせーバカ、規約使って欲しかったら、
勝手につくようにしろor warning 出せ
って思う。
Re: (スコア:0)
ReSharper使ってればwarning出るが?
なんだ (スコア:0)
C#か
自分はMozillaのやつが好きだった (スコア:0)
プライベートフィールドは m、引数は a とか色々。
でもこれってかなり昔の話かな。
今のスタイルガイドどうなってたかな・・しばらく追ってないや。
あとDelphiはフィールドに f をつけてたっけ。
Symbianはこれまた面白くて、「2フェーズコンストラクタ」が必要なクラスは C、
そうではないが後始末に CloseL() メソッドなどが必要なものは R、
それ以外の単純なデータ型構造体は T をつけてたなあ。
きちんと厳密にしとかないと、何しろ相手はリソースの限られた端末だったもんね。
なんてWindows開発者は (スコア:0)
プレフィックスが好きなのか。
Re: (スコア:0)
マイクロソフト社員によって提言された記法(アプリケーションハンガリアン記法と呼ばれる)を
マイクロソフトが誤用(システム・ハンガリアン記法)で広め、各種APIで使用したから・・・
Re: (スコア:0)
やってみたら「悪くない」と思う人たちが続出したから残ったんですよね。
こういう人がいなかったら残るはずがないわけで。
Re: (スコア:0)
Windows開発者ではないが、いかなるプリフィクスをも敵視する風潮は如何なものかと思う。
コード規約に採用すべきかは慎重に取り扱うべき事案だが、現実にはそれを採用し成功しているシステムも多数存在している。
# なお個人的にはまず採用しない模様
Re:なんてWindows開発者は (スコア:1)
Re: (スコア:0)
アンチM$(笑)ってこれがC#の話だって事すら分からない無能しかいないの？
そもそも言語仕様じゃなくてコーディング規約だろ
Re: (スコア:0)
コンパイルは通るのだから、気にしなければよい