VB6プログラマ向けのOption Strict Onおよび.NET

Question

.NETプラットフォームに移行するVisual Basic 6プログラマを対象としたVisual Basic 2005のクラスを準備しています。

常に Option Strict を有効にすることを推奨するかどうかについてアドバイスをお願いします。

私は主にJavaとC＃のようなCスタイルのプログラミング言語のみを使用してきました。そのため、明示的なキャストはオプションではなかったので、私がしなければならないことを常に期待しています。
ただしコードの型を過度に明示する必要がないため、実際に時間を節約できるので、 late-binding が組み込まれた言語で作業することの価値を認識しています。これは、動的言語ランタイムを備えた.NETプラットフォーム上であっても、動的型付け言語の普及によってさらに証明されます。

これを念頭に置いて、VB.NETを使用してVB6のバックグラウンドを持つ.NETに初めてアプローチする人は、コンパイル時の型チェックを使用する必要があるという考え方に入ることをお勧めします。それが「ベストプラクティス」です。 CLRで？または、「OK」ですか？遅延バインディングのメリットを引き続き享受するには？

Answer 1

はい！ Option Strictは間違いなく.Netのベストプラクティスです。 .Netはその中心にある厳密に型指定されたプラットフォームであり、DLRがより完全にサポートされるまではそうであることを強調してください。いくつかの例外を除き、すべての Dim および Function には、それに対応するように明示的な型を宣言する必要があります。 LINQやBooとJScriptなどは、ルールを証明する例外です。

他に指摘すべきことがいくつかあります。あなたはこれらすべてをよく知っていると確信していますが、以前のVB6ersによって書かれた多くのVB.Netコードを操作し、維持しなければならなかったので、これは私にとって非常に痛い点です：

• 古い文字列関数を使用しない： LEN（）、 REPLACE（）、 TRIM（）など
• ハンガリーのwar贅は推奨されなくなりました。 oMyObject と sMyString はコーシャーではありません。信じられない場合は、 Microsoftの設計ガイドラインで参照を示します。あなた。
• 新しい AndAlso / OrElse 論理演算子について学習していることを確認します
• PARAMETERIZED QUERIESおよび最新のADO.Net。それを十分に強調することはできません。再度 CreateObject（）を呼び出す必要はありません。
• .Netのスコープの動作はVB6の場合とは異なります（より重要です）。 VB.Netにはまだモジュールがありますが、現在は静的クラスにより類似しています。 VB6が提供する部分的なOOPサポートとは対照的に、実際のオブジェクト指向環境での開発がどのように異なるかを理解することが重要です。メソッドを不気味な長さで実行できるようにする正当な理由はもうありません。
• GenericsとInterfaces（ IEnumeralbe（Of T）を含む）の概要を確認し、 ArrayList を再び使用しない理由を確認します。

続けていきますが、 VB.Netの非表示機能この暴言を締めくくる質問。

Answer 2

Option Strictを有効にして開発に費やす時間は、後でデバッグ時間を大幅に節約します。

Answer 3

Option Strict は、優れた単体テストに取って代わることができないことは明らかです＆＃8211;しかし、どちらも逆ではありません。ユニットテストは Option Strict と同じエラーを検出できますが、これはユニットテストにエラーがないこと、ユニットテストが頻繁に早期に行われることなどを意味します＆＃8230 ;。

適切な単体テストを作成するのは簡単なことではなく、時間がかかります。ただし、コンパイラは既にいくつかのテストを実装しています＆＃8211;型チェックの形で。少なくとも、これは時間を節約します。より可能性が高いのは、テストが間違っていた/すべてのケースをカバーしていなかった/コードの変更を説明するのを忘れていたため、多くの時間とお金を節約することです（少なくとも時々）。

要約すると、ユニットテストが正しいという保証はありません。一方、コンパイラーによって実行される型チェックが正しいこと、または少なくともそのグリッチ（チェックされていない配列の共分散、循環参照のバグ＆＃8230;）がよく知られ、十分に文書化されているという強力な保証があります。

別の要約：はい、オプションを厳密にオンにすることは間違いなくベストプラクティスです。実際、このようなオンラインコミュニティで長年働いてきました。明らかに Option Strict が有効になっていないコードについて誰かが助けを必要とするときはいつでも、これを丁寧に指摘し、これが修正されるまでそれ以上の助けを与えることを拒否します。時間を大幅に節約できます。多くの場合、問題はこの後に消えました。これは、HTMLサポートフォーラムでヘルプを求めるときに正しいHTMLを使用することに多少似ています。無効なHTMLは機能する可能性がありますが、それでも問題の原因ではない可能性があります。そのため、多くの専門家が支援を拒否しています。

Answer 4

はい!!!!

私の意見では、開発者として、そして大学の講師としてはい。

最初から良い習慣を身に付けることが最善であり、プロセス全体がはるかに簡単になり、Option Strictは私の考えでは必要な要素の1つです。

追加

文字通り、理由として挙げられる理由はたくさんありますが、重要なのは、それがベストプラクティスであるということです。新しい言語を教えるときは、最初からそれらのベストプラクティスを教えることが重要です。

Answer 5

ここには2つのレベルがあります。

オプションの明示 オプションの厳密性

2つの主な違いは、Option Strictが異なるデータ型のVBの自動変換を無効にすることです。変数を別の型に割り当てるには、CTypeまたは別のデータ変換関数を明示的に使用する必要があります。

1.0からVBを使用していますが、この点はわかりますが、さまざまなインターフェイスやクラスを実装または継承したオブジェクトを扱う場合、厳密には熱心すぎると思います。

最初はStrictから始めますが、邪魔になる場合はExplicitにドロップダウンします。しかし、両方をオフにしないでください。その方法は、狂気と過度のデバッグ時間にあります。

VBの長年にわたって、私はすべての浮動小数点変数にDoubleを使用しています。これにより、丸めや精度の低下に関する多くの問題を回避できます。 VB6では32ビット整数である限り使用しましたが、整数はInt32であるため.NETでも同様に機能します。 Microsoftがこれらのキーワードを再定義することになった場合に備えて、Integer、Longなどの代わりにInt32、Int16などを使用することもお勧めします。

Answer 6

RS Conleyに同意しません（非常に珍しい）。私のお気に入りのVB6グル-フランチェスコバレナ、ダンアップルマン-すべてがVB6の自動変換を嫌い、 in お気に入り .NETの Option Strict 。多くの経験豊富なVB6プログラマーは、「悪の型強制」としての自動変換を知っています。 （ pdf ）。 Option Strict 。

多くの複雑なリフレクションコードを避けるために、 Option Strict を使用せずに1つの小さなモジュールを使用する方が良い場合があります。しかし、それはルールを証明する例外です。

Answer 7

開発サイクルの早い段階で問題を修正するとリソースが最も少なくなるというBoehmの考えを考えると、私は開発者が「正しく」するのに役立つすべてのツールのファンです。できるだけ早期に。この理由から、私はIntelliSenseのようなものを提唱しています。IntelliSenseは、効率を高め、サイクルの早い段階で作業コードを実装するのに役立つツールです。 （動作していますが、必ずしもは正しくありません。）

この理由から、「設計時」のミスステップとその結果の修正を深く保つための方法として、Option Strictの使用もサポートしています。

Answer 8

タイプのチェックに慣れている場合は、オプションを厳密にオンにすることをお勧めします。オフにすることには利点がありますが、コンパイラが通常文句を言うエラーを発見するように脳が調整されていない場合は、そのままにしておきます。私はVB.Netで多くの仕事をしてきましたが、ほとんどの場合、オプションを厳密にオフにして作業していましたが、オンにするとかなりの数が妨げられる状況がたくさん見られましたバグ。