33

私は ghci デバッガーを使用しましたが、ブレークポイントを設定するプロセスを簡素化するために、テキスト エディターとある程度統合されていると本当に好まれます。おそらく、すべての可視変数を厳密に評価する必要はありませんが、少なくともローカル状態を確認するプロセスを簡素化する必要があります。

最近、難しい場所からのデバッグ出力を可能にすることで役立つトレース機能を見つけました。

4

4 に答える 4

13

Haskell コードをデバッグする良い方法は、QuickCheckSmallCheckを使用して代数法則を書き、テストすることです。Hat、Hood、Freya など、いくつかの Haskell デバッガーがありましたが、長期間維持する価値があるほど価値があると認識されているものはありません。

Haskell の場合は、やり方を別の方法で考えなければなりません。QuickCheck ページの ICFP ペーパーには、開始するための良い例がいくつかあります。実際の例が必要な場合xmonadは、QuickCheck を使用して広範囲にデバッグされます。

于 2009-03-24T02:57:07.927 に答える
5

Debug.trace補足として、マルチスレッド プログラムをデバッグするときは、 は役に立たないことに注意してください。

テストは、長期的には進むべき道です。

于 2009-03-25T23:41:38.520 に答える
3

私自身の目的のために、それは要因の組み合わせであることがわかりました。

  1. デバッグしやすい関数コードを書きます。これは、関数が比較的小さく (5 ~ 20 行)、それぞれ明確に定義された 1 つのことだけを行うことを意味します。
  2. HUnitを使用して、問題を明らかにするテスト ケースを定義します。

他の回答に見られるように、多くの人がQuickCheckを愛しています。少なくとも一部のコードでは意味のある QuickCheck テスト ケースを定義するのが難しいことがわかったので、通常は標準の単体テストをより活用します。そうは言っても、Real World Haskell の第 11 章に QuickCheck の使用に関する優れた紹介があります。

QuickCheck と HUnit の両方を使用している場合は、test-frameworkを調べてみてください。

于 2009-04-01T15:58:38.203 に答える