1

メソッドを古いものとしてマークしたいのですが、Delphi 5 にはそのような機能がありません。

例として、推奨されていない新しい推奨形式の作成されたメソッドを次に示します。

procedure TStormPeaksQuest.BlowHodirsHorn; overload; //obsolete
procedure TStormPeaksQuest.BlowHodirsHorn(UseProtection: Boolean); overload;

注:この架空の例では、パラメーターなしのバージョンを使用することは単純に悪いと想定しています。「保護を使用しない」ことには問題があります-良い解決策はありません。保護を使用する必要があることを好む人はいませんが、保護を使用しないことを望む人もいません。そのため、 Hodir の角笛を吹くときにプロテクションを使用するかどうかを発信者に決定させます。パラメータなしのバージョンをデフォルトで保護を使用しないままにすると、次のようになります。

procedure TStormPeaksQuest.BlowHodirsHorn;
begin
    BlowHodirsHorn(False); //No protection. Bad!
end;

その場合、開発者はあらゆる種類の厄介なものの危険にさらされます。パラメーターなしのバージョンで保護を使用するように強制すると、次のようになります。

procedure TStormPeaksQuest.BlowHodirsHorn;
begin
    BlowHodirsHorn(True); //Use protection; crash if there isn't any
end;

開発者が保護を受けていなかったり、所有していなかったりすると、問題が発生する可能性があります。

これで、廃止されたメソッドの名前を変更できます。

procedure TStormPeaksQuest.BlowHodirsHorn_Deprecatedd; overload; //obsolete
procedure TStormPeaksQuest.BlowHodirsHorn(UseProtection: Boolean); overload;

しかし、それはコンパイル エラーを引き起こし、人々は私を愚弄します (そして、私は彼らの泣き言を聞きたくありません)。実際のエラーではなく、 nagを取得してもらいたいです。

アサーションを追加することを考えました：

procedure TStormPeaksQuest.BlowHodirsHorn; //obsolete
begin
   Assert(false, 'TStormPeaksQuest.BlowHodirsHorn is deprecated. Use BlowHodirsHorn(Boolean)');

   ...
end;

しかし、開発者がアサーションのないバージョンを出荷しないとは保証できず、顧客にとって厄介なクラッシュが発生します。

開発者がデバッグしている場合にのみ、アサーションをスローすることを考えました:

procedure TStormPeaksQuest.BlowHodirsHorn; //obsolete
begin
   if DebugHook > 0 then
      Assert(false, 'TStormPeaksQuest.BlowHodirsHorn is deprecated. Use BlowHodirsHorn(Boolean)');

   ...
end;

しかし、私は本当にクラッシュを引き起こしたくありません。

デバッガーにある場合は MessageDlg を表示することを考えました (これは私が過去に行った手法です):

procedure TStormPeaksQuest.BlowHodirsHorn; //obsolete
begin
   if DebugHook > 0 then
        MessageDlg('TStormPeaksQuest.BlowHodirsHorn is deprecated. Use BlowHodirsHorn(Boolean)', mtWarning, [mbOk], 0);

   ...
end;

しかし、それでも破壊的すぎます。また、モーダル ダイアログを表示する際にコードがスタックするという問題が発生しましたが、ダイアログ ボックスは明らかに表示されませんでした。

私は、彼らが目をえぐり、最終的にコードを変更するまで、そこに座ってしつこくする警告メッセージを期待していました。

未使用の変数を追加した場合、おそらく考えました：

procedure TStormPeaksQuest.BlowHodirsHorn; //obsolete
var
   ThisMethodIsObsolete: Boolean;
begin
   ...
end;

誰かがコードを参照した場合にのみ、これがヒントになることを望んでいました。しかし、廃止されたメソッドを実際に使用しなくても、Delphi はヒントを表示します。

他に考えられる人はいますか？

4

7 に答える 7

5

のようなものはどうですか

procedure TStormPeaksQuest.BlowHaldirsHorn; //obsolete
begin
  if DebugHook > 0 then asm int 3 end;  
  // This method is Obsolete!  Use XXXXX instead.
  Abort; // Optional, makes method useless  
  // old code here . . . 
end;

アサーションとショーメッセージの間の一種の妥協。開発者は F9 を押すだけで続行できます。Abort を挿入すると、メソッドは何も実行せず、強制的にメソッドを切り替えることができ、ブレークによってメソッドが認識されます。

個人的には、新しいバージョンの Delphi にアップグレードすることをお勧めします。2007 と 2009 は素晴らしいリリースであり、アップグレードする価値があります。

于 2009-01-13T01:11:01.377 に答える
4

私が最終的に使用したのは、非推奨のコードを持たないことに同意するシステムを選択し、それ以外の場合はデバッグ文字列とブレークポイントを出力するという組み合わせでした。

stricthtml のように、 Strictdefine を作成しました。

が定義されている場合、すべての共通ユニットには廃止されたコードStrictが定義されています。そうすれば、開発者は、プロジェクトに非推奨のコードを持たないことに同意します。

{$IFNDEF Strict}
procedure TStormPeaksQuest.BlowHaldirsHorn; overload; //obsolete
{$ENDIF}
procedure TStormPeaksQuest.BlowHaldirsHorn(UseProtection: Boolean); {$IFNDEF Strict}overload;{$ENDIF}


{$IFNDEF Strict}
procedure TStormPeaksQuest.BlowHaldirsHorn; //obsolete
begin
   OutputDebugString(PAnsiChar('TStormPeaksQuest.BlowHaldirsHorn is deprecated. Use BlowHaldirsHorn(Boolean)'));

   //Don't debugbreak without a debugger attached!
   if DebugHook > 0 then
        Windows.DebugBreak;

   ...
end;

したがって、開発者が適切なコードを持ちたい場合、新しいものが非推奨になったときにコード変更を実行する必要がある場合は、次のことができます。

{$DEFINE Strict}

そうでない場合は、常にOutputDebugStringが存在し、 Debug Viewを持っている人なら誰でも(顧客であっても) 見ることができます。出力デバッグ文字列が残っている商用ソフトウェア (Microsoft のものでさえ) を見るのは面白いことです。

最後に、デバッガーが接続されている場合、どこからともなくデバッグ ブレークポイントが取得されます。誰かに尋ねられたら、その機会を利用して彼らをからかうことができます。

于 2010-01-29T14:52:33.267 に答える
0

メソッドを使用したかどうかを区別できないため、完全な解決策ではありませんが、Delphi 5 で使用できる場合は$MESSAGEコンパイラ ディレクティブを使用して、コンパイル時に警告を発することができます。

于 2010-01-30T00:15:32.047 に答える
0

「私を直してください！」と言うものは何もありません。コンパイラブレークのように。
そうは言っても、「共通コード」ルーチンの署名を定期的に変更する同僚がいます...そして、うんざりです!

私が好む (つまり、私たちのチームはまだ完成していません :/) アプローチは次のとおりです。

  1. すべての開発者は、自分のマシンですべてのプロジェクトのフル ビルドを簡単に実行できなければなりません。
  2. 共通コードを変更することを決定した人は誰でも、その結果について責任を負うべきです。つまり、影響を受けるすべてのコードを修正します。
    • 確かに、開発者はすべての修正を適切に実装して検証するのに理想的ではないかもしれないと言われることがあります。
    • しかし、同様に、独自のコードで「新しいコントラクトを採用する」ことを課せられた開発者は、新しいコントラクトの詳細について明確でない可能性があります。いえ
      • 保護を使用するために何か特別なことをする必要がありますか?
      • 保護の使用はどのように実装されていますか?
      • 既存のコードがどのように壊れる可能性があるかについて、どのような懸念がありますか?
    • これが、テスト ケースの包括的なセットが重要である主な理由です。
  3. 一般に、すべての変更の波及効果をできるだけ早く適用する必要があります。つまり、変更のより細かい詳細が元の開発者の心に新鮮なうちに、注意が別のことに移る前に!
  4. 波及効果が非常に大きい (数千行) ため、長期間にわたって変更を適用する必要があることはまれです。
    • このような場合は、ビルド プロセスに統合された単純なコード メトリック収集ツールを実装して、未解決のインスタンスの数を報告します。

ポイント 2 は、特にチーム内での協力とコミュニケーションの必要性を強調しているため、非常に重要であると考えています。

冒頭の発言に戻りますが、エラーを見つけて修正するのは早ければ早いほどよいのです。
コンパイラに中断を報告させましょう! -- これは、私たちが持っている「最も早い機会」のエラー報告メカニズムです。

それは私の 2 つの銅です ！:D

于 2011-04-18T22:14:10.127 に答える