博士

やっほー、ロボ子！今日もRustの闇を暴いていくのじゃ！

ロボ子

博士、こんにちは。今日もよろしくお願いします。Rustの闇、ですか？

博士

そう！今日は、Rustでよくあるアンチパターンについて話すぞ。例えば、ベクトルのインデックス化！

ロボ子

ベクトルのインデックス化、ですか。`clippy::indexing_slicing`で防げるものですね。

博士

その通り！ベクトルの長さをチェックせずにインデックス化すると、コンパイラが警告してくれないから、エラーの元になるのじゃ。スライスパターンマッチングを使うと、コンパイラがすべての状態を考慮するように強制できるから安全じゃ。

ロボ子

なるほど。`match`アームが実行された場合にのみ要素にアクセスできる、という点が重要なのですね。

博士

それから、`Default`の使用も要注意じゃ！多くのフィールドを持つオブジェクトを初期化するときに、`..Default::default()`を使うと、バグの温床になることがあるぞ。

ロボ子

すべてのフィールドを明示的に設定することで、コンパイラにすべてのフィールドを処理させるのですね。

博士

`PartialEq`、`Hash`、`Debug`、`Clone`などのトレイト実装も、構造体のフィールドが頻繁に変更される場合は、すべてのフィールドを明示的に処理する必要があるのじゃ。デストラクチャリングを使うと、フィールドの追加時にコンパイラが再検討を促してくれるぞ。

ロボ子

構造体のフィールドが増えた時に、コンパイラが教えてくれるのは便利ですね。

博士

そうじゃ！それから、`From`と`TryFrom`の使い分けも重要じゃ。常に成功する変換がない場合は、`From`ではなく`TryFrom`を使うべきじゃ。

ロボ子

`clippy::fallible_impl_from`でチェックできますね。失敗の可能性を明示的にすることで、安全なコードが書けるのですね。

博士

`match`とキャッチオールパターン`_ => {}`の組み合わせも危険じゃ。後で新しいケースを追加したときに、処理を忘れる可能性があるから、すべてのバリアントを明示的に記述するのじゃ。

ロボ子

`clippy::wildcard_enum_match_arm`で防ぐことができますね。網羅的でないマッチは、予期せぬバグを引き起こす可能性がありますから。

博士

未使用の変数に`_`を使うのも考えものじゃ。どの変数がスキップされたか混乱を招く可能性があるから、記述的な名前を使うのがおすすめじゃ。

ロボ子

たしかに、`_`だけだと、後からコードを読むときに分かりにくいことがありますね。

博士

データが一時的にのみ可変である場合は、それを明示的にすることで、初期化後の意図しない変更を防ぐのじゃ。防御的なコンストラクタの処理も重要で、無効な状態を表現不可能にするために、コンストラクタから`Result`を返すなど、検証ロジックを強制するのじゃ。

ロボ子

コンストラクタで検証することで、不正な値が構造体に格納されるのを防ぐのですね。

博士

`#[must_use]`属性も便利じゃ。重要な戻り値を誤って無視することを防ぐことができるぞ。

ロボ子

ライフタイム中に保持する必要があるガードタイプや、チェックする必要がある操作の結果に役立ちますね。

博士

ブールパラメータはコードを読みにくく、エラーが発生しやすいため、enumを使って意図を明示的にするのじゃ。多くのオプションを持つ関数には、パラメータ構造体を使用して設定するのが良いぞ。

ロボ子

`clippy::fn_params_excessive_bools`でチェックできますね。ブールパラメータが多い関数は、可読性が悪くなりがちですから。

博士

最後に、`clippy::unneeded_field_pattern`も忘れずに！不要に多くの構造体フィールドを`..`で無視している場合を特定してくれるぞ。

ロボ子

博士、今日はRustのアンチパターンについてたくさん教えていただき、ありがとうございました！

博士

どういたしまして！ところでロボ子、今日の夕食は、エラーハンドリングが完璧なカレーライスにするのじゃ！

ロボ子

エラーハンドリングが完璧なカレーライス、ですか？具材の切り方で`Result`型を返す、とか…？

博士

そう！そして、辛すぎたら`Err`を返すのじゃ！