じゃんぬのどっとてきすと

雑記とネタと時々プログラミング

ホーム 連絡をする 同期する ( RSS 2.0 ) Login
投稿数  982  : 記事  4  : コメント  16165  : トラックバック  277

ニュース

My Website

初心者向けのサイトです。

C# と VB.NET の入門サイト

最近のできごと

少し前に女のコが生まれました。家事と育児と仕事にと奮起しています。めちゃくちゃかわいいです。あと Blog の更新は全然してませんが、Twitter とかでアホなこと呟いています。見つけることができたら、ぜひフォローしてあげてください。けっこう喜びます。

Sponsored Link1

Sponsored Link2

Archive

書庫

MSDN2 ライブラリに VB のコーディング規約 (標準) がありますが、個人的に異議を唱えたいと思います。あくまで個人的な異論であり、私のメモ代わりです。

Visual Basic のコーディング規則 (microsoft.com) からの引用

Main メソッドを使用するときには、新しいコンソール アプリケーションの既定の構造を使用し、コマンド ライン引数には My を使用します。

.NET Framework クラス ライブラリや Visual Basic ランタイム ライブラリよりも My の機能を使用します。

無理に My を推奨する必要はないと思います。個人的にはむしろ、My は使わないでくださいにしようと思います。せっかく .NET Framework Class Library で統一感が出ているだけに勿体ないです。

クラスの海に溺れないように My が登場したとのことですが、My が登場することによって、また覚えることが増えて余計にクラスの海に溺れることを危惧しています。

そもそも、はじめはクラス内のメンバをすべて覚える必要はありません。どんなクラスがどの名前空間に属しているかを何となく覚えておけば、インテリセンスやリファレンスですぐ使いたいものは調べられます。その方が覚えやすいでしょう。また今後のためにもなります。My ですべてカバーしているわけではなく、結局 .NET Framework Class Library も覚えていかなければなりませんから。

.NET Framework クラス ライブラリはサービス指向ですから、慣れてしまえば、はじめて使う機能もどのあたりにあるか予想がつくようになります。VB をそこそこやっているプログラマであれば、VB 専用の関数を 9 割くらいは覚えているハズです。そのような方が、名前空間とクラスを覚えられないとは私は思いません。それとも、自分たちで決めた名前空間の階層がわかりにくいと言うのでしょうか...

配列指定子は、次のように、型ではなく変数に指定します。

   Dim letters() As String = {"a", "b", "c"}

次のような記述は避けます。

    Dim letters As String() = {"a", "b", "c"}

.NET CLR では、すべての型で配列にすることができます。配列は、System.Array から派生した型になります。ですから、型に配列修飾子である "()" を付けた方が、私はわかりやすいと思います。.NET CLR は型を強く意識しておりますからね。

VB6 時代では仕方なく変数名に配列修飾子を付けていました。しかし、VB6 時代でも関数 (メソッド) の戻り値については「型」につけるしかなかったですよね。この時点で「揺らぎ」があるわけですから、統一すべきだと思います。

1 つのオブジェクトに対する呼び出しが続く場合には、With キーワードの使用を検討します。

これだと、無法 With 地帯 になり兼ねないので、もっと制限事項を設けた方が良いと思います。私ならば、以下のことを盛り込みます。

  1. With ステートメントはネストしないこと。(With ステートメントのブロック内に With ステートメントを書かない)
  2. 初期化等、省略したインスタンスに対して処理が明確である場合にのみ使用すること。
  3. With ステートメントのブロック内が数 10 行に及ばないこと。
  4. With ステートメントのブロック内に With で省略したインスタンスに直接関係しない処理を記述しないこと。
  5. パフォーマンスが上がるなどと思い込まないこと。(VB6 以前は除く)

ここまで盛り込むとなかなか使えなくなります。そう、無理に使う必要などありません。省略すると返って見難くなるケースが多いと感じます。私は Smalltalk のカスケードさえも好きになれません。

My.Forms.Form1.ShowDialog ではなく Form1.ShowDialog を使用します。

VB2005 でウリ (?) になっている「フォームの既定のインスタンス」ですが、そもそも私は使わせません。

MessageBox.Show または Console.WriteLine の代わりに MsgBox を使用します。

.NET Framework クラス ライブラリよりも Visual Basic ランタイム ライブラリを使用します。

いやですw 統一感を出すためにも、.NET Framework Class Library を優先して使用します。

投稿日時 : 2007年3月22日 10:20

コメント

# re: VB のコーディング規約 (標準) に意義あり 2007/03/22 10:27 シャノン
> 統一感を出すためにも、.NET Framework Class Libraly を優先して使用します。

FCLや統一感にこだわり過ぎるのもどうかと…
int や Integer ではなく Int32 を使え! というわけでもないでしょうし。
良くも悪くも「VBらしさ」、他の言語との差異化があっていいんじゃないかと。
Visual Basic アプリケーション モデル(http://msdn2.microsoft.com/ja-jp/library/w3xx6ewx(VS.80).aspx)なんていう素晴らしいものもあるわけですし…
「それもまたVB文化」ということでひとつ。

# re: VB のコーディング規約 (標準) に意義あり 2007/03/22 10:46 じゃんぬねっと
> int や Integer ではなく Int32 を使え! というわけでもないでしょうし。

そのあたりのエイリアスには拘っていません。
(C# にだってありますからね)

VB らしさを出したいなら、.NET Framework に相当するものを作って欲しいわけですが、そういうわけでもないのでしょう。

言葉尻だけ捉えられるとわかりにくいのですが、

> また今後のためにもなります。My ですべてカバーしているわけではなく、
> 結局 .NET Framework Class Library も覚えていかなければなりませんから。

こういった理由も加味して欲しいです。
結局、覚えていく必要があるわけです。

それと、CSharper でもわかりやすいという都合もあります。
このあたりは、会社/部署次第でしょうけど、私のところでは My を使われると生産性が落ちるのは確実でしょう。

だから、個人的な意見だと前置きしているわけですが。

# re: VB のコーディング規約 (標準) に意義あり 2007/03/22 10:56 某B
新規参入者にとっては二度手間にしかならない。C#な人やVB2003な人にとっても覚えることが増えるだけ。
統一性があった方が良く。メリットより、デメリットの方が多いのは確か。
だから使わない。

使わない理由としては十分だと思われ。
逆にMyを勧める理由がないというのがつらいよねぇ。

# re: VB のコーディング規約 (標準) に意義あり 2007/03/22 11:05 じゃんぬねっと
> 逆にMyを勧める理由がない
一応、FCL ではできないものが My にはあったりします。
ただ、My にしかできないというわけではありませんけど...

# re: VB のコーディング規約 (標準) に意義あり 2007/03/22 11:10 シャノン
> だから、個人的な意見だと前置きしているわけですが。

ま、それを言われてしまうとどうにもならんのですが。

> メリットより、デメリットの方が多いのは確か。

確かではありません。
某Bさんはそう思う、ということでしょう。

もちろん、そう思うが故に、使わないことや勧めないことは結構ですが、メリットを感じる人がいても否定しないでくださいということです。

# re: VB のコーディング規約 (標準) に意義あり 2007/03/22 11:14 επιστημη
s/意義/異議/g (ボソッ

# re: VB のコーディング規約 (標準) に異議あり 2007/03/22 11:27 ぽぴ王子
s/仕様すること/使用すること/g
s/Libraly/Library/g
(ボソッ

My は確かに控えた方がいいかなぁと思います。
結局僕も CSharper だから、ということに落ち着いてしまうのですけど(逆にそれ以上の説得力がないとも言えますね)。
とりこびとさんの一連のシリーズでも思ったのですが、VB おかんは甘やかしすぎるので VB 以外の言語に行ったときに「VB にあったこんな機能は C# にはないの? C# なんてだっせー、つかえねー」とか思われてしまいそうです。
実際は「つかえねー」とか思っても覚える必要はあるわけで、それなら変に甘やかさずに「わんぱくでもいい。たくましく育ってほしい」的にスパルタ教育をした方がいいんじゃないかなぁ、とか思ったりしてます。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/22 11:28 じゃんぬねっと
>シャノンさん
まあ、こちらが否定されない限りは否定しませんと書こうと思ったのですが、そういってしまうと意味がなくなるので、れっきとした根拠があるなら聞いてみたいです。

ただし、その前提ならば「否定するな」は受け付けられないと思います。

>επιστημη さん
この手の誤変換は仕事でもよくやっちゃいます。
目が悪いため、問題ないように見えてしまいます。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/22 11:41 某B
>確かではありません。
>某Bさんはそう思う、ということでしょう。

そうだけどそれがなにか?
現状のままでは長い目見た時に「確か」だと確信している。
そう思っている。そう発言することに何か問題ある?
事実に違いないと言ったところでそれが事実がどうか定かでないのはいかなる場合でも一緒でしょ。

それが違うというなら何なりとデメリットを超えるメリットを添えて反論すればいいだけ。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/22 11:52 Mr.T
Mr.Tです、こんにちは。

>逆にMyを勧める理由がないというのがつらいよねぇ。

my.と二文字打てばインテリセンスで楽チン、というのは新規参入初心者には直感的でわかりやすい、というのはあるのかもしれませんね。

やっぱり、体系的な知識が必要だよとサポートしてくれる人がいないとなぁ。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/22 12:11 Ognac
Ognacです。 Vberの現場では永遠のテーマだと諦めているのですが。 以下は個人的な認識なんですが。
 VS2003までは、 VB/C# は FrameWork/FCL の表現の差で, CLR/CLIの方言であると.認識していました。  Csharper/Vberが技術レベルで同一土俵に立てるので切磋琢磨できて好ましいことだと考えてきました。(VB7.0ベータ1の ように, 配列宣言は, Cと同様にサイズにスベキだったと今でもおもってますが)
ところが,VB2005から再び独自文化から繁殖しだしてからは、疑問が一杯です。既定のForm, My機能,,当等. 既存のVberの不満を聞き入れたのが間違いか?
 デフォルトで OptionStrict Offが 納得できないし, MSの提示するサンプルが Strict Offが前提だったりするのも疑問。
不満は一杯なんですが, VBerの世界が, FCLの世界で仕事しているグループと, VBのだけの世界で仕事をしているグループに二分されてしまった現状は是正しようがない...と諦めつつあります。 (VBを母国語にしている人の階級さは広がるばかり。.....世のながれか)
 そればかりか, CSharperの人のなかに, VBのMy機能, VB特有メソッドを使う人が現れているのに危惧します。人は楽なほうに流れてしまう。ああ無常。



# re: VB のコーディング規約 (標準) に異議あり 2007/03/22 12:27 はつね
人は楽な方に流れるし、できるならば楽に使えるものがいいのですが、問題は「楽に走ったときに判りづらくなったりバグの温床になる」という点だと思うのです。
規定のインスタンスのFormなどは、その1例ですよね。

My機能は、確かにMy.でインテリセンスが効くので便利ではありますが、その便利さって、すべてカバーしきれていないため、コーディングの統一感が図れない部分ができてしまう中途半端感があるのが嫌ですね。
現状のままってのは受入がいたですが、拡充されてMy主流になってもいいとは思います。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/22 13:03 某B
>my.と二文字打てばインテリセンスで楽チン

可読性の損失によるデメリットが大きいと思われ。
それにその程度の楽をしたいのだったらオブジェクト指向言語自体使わない方がいいよね。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/22 13:05 某B
>やっぱり、体系的な知識が必要だよとサポートしてくれる人がいないとなぁ

あ。これには賛成。でもそういう人ってMyは勧めないかも。
やっぱり仕事で使っているのもあってMyを禁止にするプロジェクトも多くなるんじゃないかな?

# re: VB のコーディング規約 (標準) に異議あり 2007/03/22 13:46 とりこびと
そんな Viaual Basic 使いのとりこびとです。

私は、ぽぴ王子さんのコメントのとおりブログでいろいろ書いているわけですが、Visual Basic 言語仕様自体に否定的なわけではありません。(このエントリもそういった部分はないようですしね。)

ただ、今回のコーディング規約を見るにVisual Basicがどうも.NET Framework の中に収まろうとしていない気もしますね。逆に言えば .NET Framework の中で Visual Basicの存在意義を見出そうとするとこうなるんでしょうか。

個人的には、My 機能は企業によって、またプロジェクトによって、独自のクラスライブラリを持っているところもあるでしょうし、それと同じような感覚です。言い方に御幣があるかもしれませんが、ホビーなクラスライブラリとしてみると確かに便利です。
生業のためのツールとしては少し問題があるのかとも思いますが、Visual Basic はそれ以外の面から見ると恩恵が大きい場合もあるのではないかと思います。


Visual BasicやC♯など多言語が混在した環境が現状であり、そこにVisual Basic 独自の実装が入るとちょっと・・・ってことなんでしょうか。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/22 13:51 シャノン
VBの文化を否定するなら、VBを勧める理由は何かある? と聞いてみたい。
「VB文化ではなくFCLを使え」と言いつつ、「VB文化ではなくC#文化を使え」になっていないかと聞いてみたい。

> そもそも、はじめはクラス内のメンバをすべて覚える必要はありません。

その通り。最初はとりあえずMyから覚えればよい、とも言える。

> VBerの世界が, FCLの世界で仕事しているグループと, VBのだけの世界で仕事をしているグループに二分されてしまった現状は是正しようがない...と諦めつつあります。

それで何か問題があるのだろうか?

> 可読性の損失によるデメリットが大きいと思われ

可読性などというものはそれこそ主観の極みであり、事実、「Withを使った方が読みやすい」という人もいる。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/22 14:01 Ognac
>それで何か問題があるのだろうか
主観的に問題視しているだけかも知れません。「技術者は職人であって欲しい」という願望が生み出した偏見が
入っているのかもしれませんね。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/22 14:26 某C
>それにその程度の楽をしたいのだったらオブジェクト指向言語自体使わない方がいいよね。

たぶんVBプログラマの多くはOOなんて使いたくないし7.0以降なんて使いたくない、ってな方が大勢かと。

#VBの人の感覚って、いまだに文字列のEmptyをNothingと比較して確認してみたり、OOって? という人も見受けられます...

>会社/部署次第でしょうけど、私のところでは My を使われると生産性が落ちるのは確実でしょう。

案件次第ですよね。VBの方言なしでVB.NETを書ける協力会社さん探すのも大変ですから。
 使ってほしくないし、推奨するのが分らん、というは心情的に理解できます。でも、現状でVBの方言を否定しまうとM$離れが本格的になるから商売上仕方がないかも。

#VBプログラマを甘やかしすぎ!、うんそれだ!




# re: VB のコーディング規約 (標準) に異議あり 2007/03/22 14:59 かるあ
C# を母国語とする人から見れば VB の My は気持ち悪く映るんでしょうね。
僕も My の中で済むのなら My で片づけてもいいと思う一人です。

それに普段プログラムを作っていて OO を意識することってそうないんじゃぁないでしょうか?
クラスライブラリを作っていれば別ですが、業務ロジックでOOなんてそう使わないし。
My で簡潔にコードを記述できるならむしろ My を使っていけばいいと思います。


それでも既定のインスタンスは使ってほしくないけれど。。。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/22 17:02 某B
>VBの文化を否定するなら、VBを勧める理由は何かある? と聞いてみたい。
C出身者だが普通に見やすいと思える。C#より見た目は結構好きかもね。

>「VB文化ではなくFCLを使え」と言いつつ、「VB文化ではなくC#文化を使え」になっていないかと聞いてみたい。
そんなことは誰も言っていないと思う。
それになんでC#に限定する必要があるのか不明。
3rdパーティ製品も含めるとFCLを利用している言語は他にもたくさんある。

VBの互換性ぷりぷりなものではなく少しFCL寄りを使った方が他の.NET言語を使う場合において役に立つと見ている。
そういう意見で統一性の話が出ているんじゃない?

>可読性などというものはそれこそ主観の極みであり、事実、「Withを使った方が読みやすい」という人もいる。
そういう人もいるだろうけどそれはVBの人に限った話。
Withについてはアホな使い方さえしていなければ別にどうでもいい。
共通型システムに入っている以上そっちに寄った方がいろんな言語出身者が業務に入りやすい。
つか俺はプロジェクト管理者の立場で話をしているからまずいのか。
人を集めるのに苦労すっからね。どうしても。

んで。郷に従えってことでプロジェクト内で何らかの規約を設けて行なうべき。
記事の内容はそれが個人的にあっていないからと書いてある。
で俺はそれに同意。自分のプロジェクトでもそうするだろうという意。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/22 19:52 frontline
最近は、人を集めると結構「C#はやってましたが..VBは...」なんて人も増えてきているように思います(私の周囲だけ?)。なので、VB6以前出身の人も、ほかの書き方があることくらいは把握しておいて欲しい(また、それぞれメリットデメリットがあることも)、というくらいかな。私の場合。




# re: VB のコーディング規約 (標準) に異議あり 2007/03/23 9:01 シャノン
#極端なことを言っているのは承知の上で。

VBをやっているうちはVB文化にどっぷり漬かり、他の言語をやることになったら改めてその文化を学べばいいじゃないか、とゆーこと。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/23 9:16 某B
で。そういう書き方をしているシャノン氏は自身のいうVB流儀のプログラミングをしているの?
していないのにとりあえず否定的な意見を言ってみてるようにも見える。

>VBをやっているうちはVB文化にどっぷり漬かり、他の言語を
>やることになったら改めてその文化を学べばいいじゃないか、とゆーこと。
個人的にならそれでいいかもね。でも仕事では勘弁してほしいな。
どうしても人不足でそんな流儀を知っている人なんて掻い摘めないからさ。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/23 10:56 シャノン
> で。そういう書き方をしているシャノン氏は自身のいうVB流儀のプログラミングをしているの?

してないよ。VBでプログラミングしてないもん。

> 個人的にならそれでいいかもね。でも仕事では勘弁してほしいな。

まぁそれはそれ。
ご自身も書いているように、某Bさんがコーディング規約を決める立場なら好きなようになさればいい。
でも、コーディング規約なんてものは、その中身の如何よりも、統一されていることの価値の方が大きいもの。
このMS提唱のコーディング規約だって、ちゃんと使われているなら、そう馬鹿にしたもんでもないんだろう。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/23 12:15 某B
最初に否定から入るからまずいんだろうな。
自身がそう思っていなくともその可能性があれば否定する。
それでは議論パターンとして間違ってるよ。

@ITにもobjectという人がいて否定パターンから入ってこちらの意図に対して少しも留意を示してくれない人がいる。
まあその人と同類などというつもりはないけどね。

最後の投稿のような書き方なら納得ですわ。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/23 12:19 某B
>その中身の如何よりも、統一されていることの価値の方が大きいもの。

統一は前提じゃない?
前提を差し置くなんてありえないわけで。

で。前提があってのことなら中身が大事だよ。
ただ内容は環境(仕事なら部署とか)で変わるから寄り良い方法というのには差異はでるだろうね。

VBプログラマーしかいないなら勝手にさせるけど。
そうじゃない場面がこれからも多く出るだろう。
それを危惧しての意見ダカラ。それは何度でも言おう。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/23 13:11 未記入
じゃんぬさんの意見に賛成。
このままVBの独自性が進むと、.NET以前の開発となんら代わりのないものになるように思えて仕方がない。
だから私は開発ツールが自動生成したコードを使わないで、VBでも出来る限り全て手打ちしている。
もちろん、Myクラスは使用しない。
私が思うにMyクラスを作るのではなく、コード スニペットの機能を充実させるべきだったと思う。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/23 13:15 シャノン
> 統一は前提じゃない?

前提だったためしがないね(そう経験が多いわけじゃないが、少ない経験に占める割合はほぼ100%)。

仕事でやる場合ならとやかくは言わんよ。
逆に、例えばこのMS謹製の規約がプロジェクトで採択されたならば、それにケチを付けることに意味は無い。
決める過程に口を挟めるのならば別だがね。

ただ、ある個人が(仕事の中ではなく)この規約を守っていた時、それに他人が意見をする時は気をつけような、というだけさ。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/23 16:00 某B
>前提だったためしがないね
まじで?それって意味なくね?
だって守って欲しいルールに則れば統一になるよね?
何のためのコーディング「ルール」なんだ・・・

>逆に、例えばこのMS謹製の規約がプロジェクトで採択されたならば、それにケチを付けることに意味は無い。
だからそういってんじゃん。

>>んで。郷に従えってことでプロジェクト内で何らかの規約を設けて行なうべき。
>>記事の内容はそれが個人的にあっていないからと書いてある。
>>で俺はそれに同意。自分のプロジェクトでもそうするだろうという意。

最初に確定的に言ったのは俺のチームじゃ絶対やらないから。
それが誤解されたと途中で気付いてそう書いた。

>決める過程に口を挟めるのならば別だがね。
決められる側じゃないから大丈夫。

ただネット上でもコーディングルールとかってのがあるよね。
これはネット上のリソースを整備するためのものだと認識している。
それに関しては決める側じゃないから反対するしかないなぁ。

> ただ、ある個人が(仕事の中ではなく)この規約を守っていた時、それに他人が意見をする時は気をつけような、というだけさ。
それが「否定するな」にあたるのね。ようやく繋がった。
でも別に否定はしてもいいでしょ。どうせ否定しあいっこなんだし。

あ。同じく仕事していて決められた後に否定してもいいじゃないという意味じゃないよ。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/23 18:49 某A
コーディング規約もVBの能力を引き出す為の規約と考えれば納得のできる範囲。
MSがVBを開発してきた背景・経緯を理解しての議論とは思えない状態だが、大事な視点ではないのかな?
よって
・VBを他のオブジェクト指向言語と同じ視点で議論することに意味は(さほど)無い
・VBという言語を選択するという意味を議論したほうが(よっぽど)建設的
というのが私の考えで以下に多少の補足的意見。

と、いうわけで
>このままVBの独自性が進むと、.NET以前の開発となんら代わりのないものになるように思えて仕方がない。
そもそも独自性により、
・開発者のしきいを下げて
・工数の削減を目指してきた
言語がVBと大雑把に考えていたんだが(もちろん結果は別としての話し)。

>だから私は開発ツールが自動生成したコードを使わないで、VBでも出来る限り全て手打ちしている。
私なら自動生成されたコードを手直しする。効率を求めて開発環境を選んでいるのだから。
もっと、純粋で余計な拡張がない事を望むならVBを選ばなければ良いだけのこと。ユーザ要求により仕方なくVBなんて話しは(たぶん)無いわけだし。

ついでに
>個人的にならそれでいいかもね。でも仕事では勘弁してほしいな。
>どうしても人不足でそんな流儀を知っている人なんて掻い摘めないからさ。
「構文なんてやればわかる話しだ」という意見も結構ある。
何年たっても規約を守りたくない奴は存在するし、素人みたいな新人やべてらん?だって存在する。
なので、言語が違ってもコアな部分のインターフェースが統一されていれば十分ではないかと思う。
コーディング規約なんかより実装の統一を図る事のほうが重要な気がしているので、コーディング規約の議論は社内でも滅多に起こらないし熱が入らない。


#引用元の投稿者に対する他意はないのであしからず。。。



# re: VB のコーディング規約 (標準) に異議あり 2007/03/23 19:00 シャノン
>> 前提だったためしがないね
> まじで?それって意味なくね?

意味ねぇ。
あ、「コーディング規約なんか意味ねぇ」ってことじゃないよ。
現に今の仕事では規約が存在してないし、前の仕事では一応規約文書はあったけど、サーバ上のどこに置いてあるのかすら周知されてなかった。

> 決められる側じゃないから大丈夫。

幸せだね。

> ただネット上でもコーディングルールとかってのがあるよね。
> これはネット上のリソースを整備するためのものだと認識している。
> それに関しては決める側じゃないから反対するしかないなぁ。

オープンソースプロジェクトとかの話じゃないよね?(それは仕事と同じ、決まった以上は逆らえない)。
たとえばこういうの?
http://www.objectclub.jp/community/codingstandard/
ネット上のリソースの整理というのがよくわからないけど…

> でも別に否定はしてもいいでしょ。どうせ否定しあいっこなんだし。

否定というか過干渉というか…
「お前がその書き方をするのは気に入らんが、それはお前の勝手だ」程度ならいいかと。
「お前のその書き方は間違えている!改めるべきだ!」はしちゃならねぇってことよ。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/23 23:43
>「お前のその書き方は間違えている!改めるべきだ!」はしちゃならねぇってことよ。

そんなアドバイスが受け入れられないなら一人で生きるべきでは?
熱くなってるのはわかるけど傲慢が過ぎるような気が。

いかがでしょう?

# re: VB のコーディング規約 (標準) に異議あり 2007/03/23 23:54 Jitta
> Try...Catch の使用
ここも、だなぁ。「Try ... Finally」だなぁ...

> AddHandler ではなく Handles を使用します。
 いやだ。
 それができるのは VB だけ。また、動的なイベント置換やコントロールの追加に対応できない。

さて、新機能「コミュニティ コンテンツ」を試してみよう!!


# re: VB のコーディング規約 (標準) に異議あり 2007/03/24 1:54 druekeberger
.NET Frameworkの一応の売りであるところの
いろんな言語が.NETで動作します。
ってところを真っ向否定な意見が笑えますね。

良し悪しはともかく各言語の個性を尊重しないなら、
たった一つの言語があればよい。
そしてそれはC#でもない。
過去のしがらみのない言語であるべきだ。
ま、個人的な意見ですが。
#こう書けば、否定される筋合いはないわけですな(笑)



# re: VB のコーディング規約 (標準) に異議あり 2007/03/24 11:52 じゃんぬねっと
> いやだ。
> それができるのは VB だけ。

私はこの部分 (イベント周り) に関しては VB の方が好きですね。
C# でも取り入れて欲しいくらいです。

永続的にひもづけられているハンドラは、Handles で定義した方が、InitializeComponent とで分離されず見やすいです。

> また、動的なイベント置換やコントロールの追加に対応できない。

イベントのほとんどは永続的なものばかりです。
動的に何かをするのは、それほど多くはありませn。
また、そういった時には AddHandler, RemoveHandler を使うしかありません。

> > AddHandler ではなく Handles を使用します。

というのは、永続的に関連づけられたハンドラの場合のみしか適用されません。
要するに 'そういった言葉' をあの文書には追加すべきだと思いますね。

行間を読まないと、AddHandler を使うなと書いてあるように見えてしまいます。

# re: VB のコーディング規約 (標準) に異議あり 2007/03/24 12:40 じゃんぬねっと
何だか「C# こそが '標準' である」ということを誰かが言ったかのようになっていますが、そのようなことはどなたも言っていないと思いますよ。

そもそも、VB の記事であるのに C# という引き合いが出てしまったのがいけないのでしょうね。
C# というよりは、他の .NET CLR 言語と書けば良かったでしょうか。
"私の会社では" という身近な例として、CShaper という単語を出しました。
(人数的な事情で、伝わりやすい例かと思いまして)

--

仮に C# で独自のパッケージを持っており、且つ FCL に存在している機能とかぶっていたら同じように「いやです、使いません」と書くでしょう。

My と VB 名前空間に関してはそれ以上のことを書くつもりはありません。
そして他の部分に関しては趣味の範囲で (メモ) で書いています。

たとえば、System.Array という型を重視して、型に配列修飾子をつけるというところ。
これは、'たまたま' それが C# (←そもそも C# だけではないのですが) のスタイルと同一だったというだけです。

決して、C# をひいきしているわけではありません。
C# のコーディング規約のページがあって、独自性を出していれば同じような記事を書くでしょう。

--

ちなみに、規模は違えど自分の所属しているところで、コーディング規約があるのであれば、それに従うのは当たり前です。

# それに対して否定的という意見はないはずですが、
# そっちの方に議論が拡散していたので、ちょっと confirm

--

過去にしがらみのない言語は難しいですね。
今やどの仕様を取り入れても、何かを踏襲した形になってしまい技術者に偏りができてしまいそう...

ですので、Framework だけでも充実してそこで統一が計れれば、どの言語であってもメリットになると考えています。
My や VB 名前空間については、そういう意味で記事を書いています。
(↑何度もくどいことを書いていますがw)

# re: VB のコーディング規約 (標準) に異議あり 2007/03/26 10:30 シャノン
> そんなアドバイスが受け入れられないなら一人で生きるべきでは?

アドバイスではなくて強制という意味で書いています。

# re: VB のコーディング規約 (標準) に異議あり 2007/04/11 1:12 某D
>「構文なんてやればわかる話しだ」という意見も結構ある。
>何年たっても規約を守りたくない奴は存在するし、素人みたいな新人やべてらん?だって存在する。

MyとかVB独自の概念って構文レベルの話じゃないと思う。
ところで「はなしし」ってなに?

# re: VB のコーディング規約 (標準) に異議あり 2007/04/11 1:17 某D
ついでに、某A氏とdruekeberger氏の意見こそ建設的でないと感じるね。
記事の内容理解できていないんじゃない?
それと自分で言ったことを自分に向ける脳みそはないのかな?

そんな位置で話すより、シャノン氏や某B氏のような突っ込んだ書き方のほうが見ごたえがあるし有意義。

# re: VB のコーディング規約 (標準) に異議あり 2009/07/04 18:00 某E
始めまして

Myを使用するのはオブジェクトが絡んでくる時ですよね
MSだって意味あって実装しているんだから逆に規制をかけないで欲しいです
かけるならメソッド名、定数名、変数名くらいにして欲しいです

仮面ライダーの敵役(戦闘員)がA~Zまで居たとします
戦闘員CとEの制御をどうするかを考えてみてください。
それぞれの戦闘員の体力は互いに見えない物とします。
私は戦闘員の定義に溺れそうです

------------------------------------------------
戦闘員Aには、叫ぶように命令
戦闘員Bには、戦闘員Cに「とりあえず走れ」と命令するように命令
戦闘員Cには、自分が叫び疲れたら、戦闘員Bの指示を受けるように命令
戦闘員Dには、戦闘員Eに攻撃をするように命令
戦闘員Eには、自分の体力が無くなったら横たわるように命令
戦闘員Gには、爆弾を埋め込みたい
戦闘員H~Zは省略

# re: VB のコーディング規約 (標準) に異議ありに異議あり 2010/04/27 21:29 ぺろ
>>With ステートメントのブロック内が数 10 行に及ばないこと。

これは違うと思うなぁ。
SQLの文字列連結なんかや、データーテーブルなんかの単純な処理で、10 行以上になってもいいと思います。

# re: VB のコーディング規約 (標準) に異議あり 2010/04/28 0:14 じゃんぬねっと
> これは違うと思うなぁ。
> SQLの文字列連結なんかや、データーテーブルなんかの
> 単純な処理で、10 行以上になってもいいと思います。

自分はこの手の処理で、With ステートメントが必要になることはないので考えていませんでした。 が、考えたところで私の言いたいことは変わらないと思います。 書き方が微妙で申し訳ないのですが、"10 行以上" と "数 10 行" は若干違うわけで、意味合いとしては 1 画面で目視できる量であることという意味です。 つまり、可読性の確保という意味で、(数 10 行という書き方は微妙で申し訳ないですが) べろさんの反論は私にとっては反論になり得ないということになります。

# re: VB のコーディング規約 (標準) に異議あり 2015/10/07 16:36
っていうか、SQLの文字列連結なんてするなよ
おまけにWithを使うだと?w

# okhhibvkmxg@softbank.jp 2017/10/01 6:11 エルメス時計
商品がとても素敵で スムーズな発送など すべてにおきまして 大満足です
ロエベ ハンドバッグ♪送料無料 新品Aランク ロエベ ハンドバッグ アマソナ28 レザー ブロンズ 新品 ミニボストンバッグ 革 150525044 LOEWE AMAZONA
気に入りました
商品がとても素敵で スムーズな発送など すべてにおきまして 大満足です

# uogkyf@docomo.ne.jp 2017/10/30 5:20 パネライ時計
注文から確認、発送までとても敏速でした(^^)お店の対応も丁寧で、とても信頼出来ます。
商品が写真で見るより綺麗で嬉しいビックリがありました。
パネライ時計 http://www.fujisanwatch.com

# cxhytsux@softbank.jp 2017/11/08 2:47 ロレックスコピー品
此のヴィトンは美品で価格も安価で落札出来ました。やはり
ヴィトンはいいですね。幾つ有っても飽きがきませんから
不思議です。ブランドという魅力は怖いです!!
ロレックスコピー品 http://www.kopi356.com

# mdurhc@nifty.com 2017/11/13 1:41 A品バーバリー
商品到着まで非常にスムーズで、安心して買い物を終えることができました。またこちらからのお願いに対しても、細やかな心遣いをいただきありがとうございました。また利用させていただきます。
送料&代引手数料無料☆新品ランクSA【送料無料】★ルイヴィトン★モノグラム★ポルトモネ・プラ★コインケース/小銭入れ★M61930★
本日商品が到着しました。とても状態の良い品物で、プレゼントしたヴィトン好きの妻も大喜びでした。こちらのショップの商品ランクの正確さに大満足の買い物でした。
A品バーバリー http://www.nawane111.com/panerai.htm

Post Feedback

タイトル
名前
Url:
コメント: