アカウント名:
パスワード:
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 が今一つ識別しにくい気がして、変数に _ 使ってる。型識別のためにハンガリアン記法使おうとは全く思わないけど
そもそもフィールド使わずプロパティ使え!ではなかったか?
それはたしか「"パブリックな"フィールドを使わずプロパティ使え」で、この件はプライベートなフィールドに関することなので関係ないです。
戦争になるからだよ。言語として1通りの書き方した出来ないものもあるだろうけど、方言を認めないと普及しない。c#としてはcやjavaあがりも取り込む必要があったからなおさら。必要ならばIDEでコード規約の強制もできるわけだしな。
しかしc#は当初からcaml/Pascal形式の命名規則があったし、実際警告対象(CA1707,CA1709)なのだが、それにも反してるよな。確かによくわからん
うるせー。ハンガリアン記法復活させるぞ!
Windows使ってる限りlpStringとか見かけるし……
流石にもう無い。COBOLと同じ絶滅危惧種。
つWindows API
生で使うことは今の時代は無い
そうでもない
おじいちゃん、もう時代は変わったのよ
過去資産読み込んだらいちいち言ってこられるのもちょっと
なーに、警告を完璧にゼロにしてコンパイルするやつなんか初心者向け教科書以外で存在しない
ログに埋もれたあげくに面倒なバグに遭遇して解決後にワーニング出てたじゃんってなるやつ
何が存在しないって?警告出力の設定も決められていて、警告を全て消すことを求める企業も存在しますよ
そこそこ名の通ったドイツのERPソフト会社に居たけど、コーディング規則に引っかかった(コードチェッカーから検出された)ソースコードをコミットする時は、Business Justificationを添えてQAに許可をもらう必要があったし、普通は警告なんか残さなかったね。
全部消せと言われる企業、そんなにレアではないと思う。
〇〇するときは❌❌することは大抵〇〇だけして終わり。
もう少し実際的な妥協点だとプラグマで部分的に無効化する。警告が残っていると、それが確認済みなのかが分からず、どのコミットで導入されたのかも追跡しづらい。
Sun時代のSolaris OSは、警告を完璧にゼロにしてリリースしてましたけど?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
単純なコーディング規約なんてツールで実装すればいいのに (スコア: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)
それはたしか「"パブリックな"フィールドを使わずプロパティ使え」で、
この件はプライベートなフィールドに関することなので関係ないです。
うじゃうじゃ
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: (スコア:0)
なーに、警告を完璧にゼロにしてコンパイルするやつなんか初心者向け教科書以外で存在しない
Re: (スコア:0)
ログに埋もれたあげくに面倒なバグに遭遇して解決後にワーニング出てたじゃんってなるやつ
Re: (スコア:0)
なーに、警告を完璧にゼロにしてコンパイルするやつなんか初心者向け教科書以外で存在しない
何が存在しないって?
警告出力の設定も決められていて、警告を全て消すことを求める企業も存在しますよ
Re: (スコア:1)
そこそこ名の通ったドイツのERPソフト会社に居たけど、コーディング規則に引っかかった(コードチェッカーから検出された)ソースコードをコミットする時は、Business Justificationを添えてQAに許可をもらう必要があったし、普通は警告なんか残さなかったね。
全部消せと言われる企業、そんなにレアではないと思う。
Re: (スコア:0)
〇〇するときは❌❌することは大抵〇〇だけして終わり。
Re: (スコア:0)
もう少し実際的な妥協点だとプラグマで部分的に無効化する。
警告が残っていると、それが確認済みなのかが分からず、どのコミットで導入されたのかも追跡しづらい。
Re: (スコア:0)
Sun時代のSolaris OSは、警告を完璧にゼロにしてリリースしてましたけど?