アカウント名:
パスワード:
IDEやコードエディタ、その他各種開発ツールで、単純なコーディング規約は実装して、強制適用すればいいのに
なんで単純なコーディング規約を人が注意しないといけないんだ?
今のVisualStudioでは、たとえば「パブリックなプロパティやメソッドは大文字で始めろ」みたいにコーディングスタイルに関することまでメッセージを出すようになってるよ。初期設定ではWarningより控えめなMessage扱いで、エラー扱いにして強制する設定もできる。だからまあ、このプライベートフィールドのプリフィクスについても今後VisualStudioの標準アナライザでメッセージを出すようになるかどうかでMicrosoftのスタンスを判断することもできそう。
今回のアンダーバーの件は関係ないけど、JavaからC#に来た時に、ローカル変数以外がPascalCase指定で「え?Javaと同じにしとけばいいのにどうしてわざわざ変えたの?」ってなったね。camelCaseならHogeList hogeListとかすりゃとりあえずわかりやすい変数を定義できるのに、PascalCaseだとHogeList HogeListとなってしまう。
その影響もある気がする。camelCase が今一つ識別しにくい気がして、変数に _ 使ってる。型識別のためにハンガリアン記法使おうとは全く思わないけど
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
単純なコーディング規約なんてツールで実装すればいいのに (スコア:1)
IDEやコードエディタ、その他各種開発ツールで、単純なコーディング規約は実装して、
強制適用すればいいのに
なんで単純なコーディング規約を人が注意しないといけないんだ?
Re: (スコア:1)
今のVisualStudioでは、たとえば「パブリックなプロパティやメソッドは大文字で始めろ」みたいにコーディングスタイルに関することまでメッセージを出すようになってるよ。
初期設定ではWarningより控えめなMessage扱いで、エラー扱いにして強制する設定もできる。
だからまあ、このプライベートフィールドのプリフィクスについても今後VisualStudioの標準アナライザでメッセージを出すようになるかどうかでMicrosoftのスタンスを判断することもできそう。
うじゃうじゃ
Re: (スコア:0)
今回のアンダーバーの件は関係ないけど、
JavaからC#に来た時に、ローカル変数以外がPascalCase指定で「え?Javaと同じにしとけばいいのにどうしてわざわざ変えたの?」ってなったね。
camelCaseならHogeList hogeListとかすりゃとりあえずわかりやすい変数を定義できるのに、PascalCaseだとHogeList HogeListとなってしまう。
Re:単純なコーディング規約なんてツールで実装すればいいのに (スコア:0)
その影響もある気がする。
camelCase が今一つ識別しにくい気がして、変数に _ 使ってる。
型識別のためにハンガリアン記法使おうとは全く思わないけど