アカウント名:
パスワード:
IDEやコードエディタ、その他各種開発ツールで、単純なコーディング規約は実装して、強制適用すればいいのに
なんで単純なコーディング規約を人が注意しないといけないんだ?
今のVisualStudioでは、たとえば「パブリックなプロパティやメソッドは大文字で始めろ」みたいにコーディングスタイルに関することまでメッセージを出すようになってるよ。初期設定ではWarningより控えめなMessage扱いで、エラー扱いにして強制する設定もできる。だからまあ、このプライベートフィールドのプリフィクスについても今後VisualStudioの標準アナライザでメッセージを出すようになるかどうかでMicrosoftのスタンスを判断することもできそう。
>のプリフィクスに
やっぱプリだよね? プレじゃなくて・・・
あ、気づいてなかった…個人的にはプリフィクスの方が一般的という印象だけど、wikipediaなどでは「プレフィックス [wikipedia.org]」となっていますね。まあ英語のカタカナ表記ではよくあること、で済ませることになるんでしょうか
priːfɪksだから自分もプリフィクス派。warning[wɔː·nɪŋ]をワーニングって書く文化(#4032356 [srad.jp]、#4032380 [srad.jp])もあるしよくあること。
今回のアンダーバーの件は関係ないけど、JavaからC#に来た時に、ローカル変数以外がPascalCase指定で「え?Javaと同じにしとけばいいのにどうしてわざわざ変えたの?」ってなったね。camelCaseならHogeList hogeListとかすりゃとりあえずわかりやすい変数を定義できるのに、PascalCaseだとHogeList HogeListとなってしまう。
スコープの種類(数というか)違う。型名と変数名が同じっていう命名に気をつけよ。元々、getXxメソッド /setXx 不要でプロパティが存在していてそれらが大文字始まりだった。javaも get set とると大文字はじまりになる。まぁでも気持ちはわかる。
javaもjavaで stream apiとかのラムダ式を => じゃなく -> にしてみたり、ダイヤモンド演算子つくったけどvarを出してみたり、あたらしい複数行文字列の左側のスペース揃えてくれるのうらやましかったり、いろいろ都合はあるんでしょうよ。
これだからJa馬鹿は┐(´д`)┌ヤレヤレ
その影響もある気がする。camelCase が今一つ識別しにくい気がして、変数に _ 使ってる。型識別のためにハンガリアン記法使おうとは全く思わないけど
そもそもフィールド使わずプロパティ使え!ではなかったか?
それはたしか「"パブリックな"フィールドを使わずプロパティ使え」で、この件はプライベートなフィールドに関することなので関係ないです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
単純なコーディング規約なんてツールで実装すればいいのに (スコア:1)
IDEやコードエディタ、その他各種開発ツールで、単純なコーディング規約は実装して、
強制適用すればいいのに
なんで単純なコーディング規約を人が注意しないといけないんだ?
Re:単純なコーディング規約なんてツールで実装すればいいのに (スコア:1)
今のVisualStudioでは、たとえば「パブリックなプロパティやメソッドは大文字で始めろ」みたいにコーディングスタイルに関することまでメッセージを出すようになってるよ。
初期設定ではWarningより控えめなMessage扱いで、エラー扱いにして強制する設定もできる。
だからまあ、このプライベートフィールドのプリフィクスについても今後VisualStudioの標準アナライザでメッセージを出すようになるかどうかでMicrosoftのスタンスを判断することもできそう。
うじゃうじゃ
Re: (スコア:0)
>のプリフィクスに
やっぱプリだよね? プレじゃなくて・・・
Re:単純なコーディング規約なんてツールで実装すればいいのに (スコア:1)
あ、気づいてなかった…
個人的にはプリフィクスの方が一般的という印象だけど、wikipediaなどでは「プレフィックス [wikipedia.org]」となっていますね。
まあ英語のカタカナ表記ではよくあること、で済ませることになるんでしょうか
うじゃうじゃ
Re: (スコア:0)
priːfɪks
だから自分もプリフィクス派。
warning[wɔː·nɪŋ]をワーニングって書く文化(#4032356 [srad.jp]、#4032380 [srad.jp])もあるしよくあること。
Re: (スコア:0)
今回のアンダーバーの件は関係ないけど、
JavaからC#に来た時に、ローカル変数以外がPascalCase指定で「え?Javaと同じにしとけばいいのにどうしてわざわざ変えたの?」ってなったね。
camelCaseならHogeList hogeListとかすりゃとりあえずわかりやすい変数を定義できるのに、PascalCaseだとHogeList HogeListとなってしまう。
Re: (スコア:0)
スコープの種類(数というか)違う。
型名と変数名が同じっていう命名に気をつけよ。
元々、getXxメソッド /setXx 不要でプロパティが存在していてそれらが大文字始まりだった。
javaも get set とると大文字はじまりになる。
まぁでも気持ちはわかる。
javaもjavaで stream apiとかのラムダ式を => じゃなく -> にしてみたり、
ダイヤモンド演算子つくったけどvarを出してみたり、
あたらしい複数行文字列の左側のスペース揃えてくれるのうらやましかったり、
いろいろ都合はあるんでしょうよ。
Re: (スコア:0)
これだからJa馬鹿は
┐(´д`)┌ヤレヤレ
Re: (スコア:0)
その影響もある気がする。
camelCase が今一つ識別しにくい気がして、変数に _ 使ってる。
型識別のためにハンガリアン記法使おうとは全く思わないけど
Re: (スコア:0)
そもそもフィールド使わずプロパティ使え!ではなかったか?
Re:単純なコーディング規約なんてツールで実装すればいいのに (スコア:1)
それはたしか「"パブリックな"フィールドを使わずプロパティ使え」で、
この件はプライベートなフィールドに関することなので関係ないです。
うじゃうじゃ