はじめに
#NO IMAGEThe Rust Programming Language 日本語版 - The Rust Programming Language 日本語版
を読んでいる
- songmuさんと飲みがおもしろかった
お勉強
#メモ
#NO IMAGEリファクタリングしてモジュール性とエラー処理を向上させる - The Rust Programming Language 日本語版
- 今日はここから
この問題は、2番目の問題にも結びついています: queryとfilenameはプログラムの設定用変数ですが、 fやcontentsといった変数は、プログラムのロジックを担っています。mainが長くなるほど、 スコープに入れるべき変数も増えます。そして、スコープにある変数が増えれば、各々の目的を追うのも大変になるわけです。 設定用変数を一つの構造に押し込め、目的を明瞭化するのが最善です。
3番目の問題は、ファイルを開き損ねた時にexpectを使ってエラーメッセージを出力しているのに、 エラーメッセージがファイルが見つかりませんでしたとしか表示しないことです。 ファイルを開く行為は、ファイルが存在しない以外にもいろんな方法で失敗することがあります: 例えば、ファイルは存在するかもしれないけれど、開く権限がないかもしれないなどです。 現時点では、そのような状況になった時、「ファイルが見つかりませんでした」というエラーメッセージを出力し、 これはユーザに間違った情報を与えるのです。
- たしかにね
4番目は、異なるエラーを処理するのにexpectを繰り返し使用しているので、ユーザが十分な数の引数を渡さずにプログラムを起動した時に、 問題を明確に説明しない「範囲外アクセス(index out of bounds)」というエラーがRustから得られることです。 エラー処理のコードが全て1箇所に存在し、将来エラー処理ロジックが変更になった時に、 メンテナンス者が1箇所のコードのみを考慮すればいいようにするのが最善でしょう。 エラー処理コードが1箇所にあれば、エンドユーザにとって意味のあるメッセージを出力していることを確認することにもつながります。
- おお、こんなに問題があるのか
プログラムをmain.rsとlib.rsに分け、ロジックをlib.rsに移動する。
コマンドライン引数の解析ロジックが小規模な限り、main.rsに置いても良い。
コマンドライン引数の解析ロジックが複雑化の様相を呈し始めたら、main.rsから抽出してlib.rsに移動する。
- すさまじく抽象度が高いことを言っている気がする
引数解析の機能をmainが呼び出す関数に抽出して、コマンドライン引数解析ロジックをsrc/lib.rsに移動する準備をします。 リスト12-5に新しい関数parse_configを呼び出すmainの冒頭部を示し、 この新しい関数は今だけsrc/main.rsに定義します。
-
OK,書いててわかってきた気がする
-
structを書く時に
#[derive(Debug)]がsnippetとして提示されたが必要なんだろうか
Stringのデータは、多くの異なる手法で管理できますが、最も単純だけれどもどこか非効率的な手段は、 値に対してcloneメソッドを呼び出すことです。これにより、Configインスタンスが所有するデータの総コピーが生成されるので、 文字列データへの参照を保持するよりも時間とメモリを消費します。ですが、データをクローンすることで、 コードがとても素直にもなります。というのも、参照のライフタイムを管理する必要がないからです。 つまり、この場面において、少々のパフォーマンスを犠牲にして単純性を得るのは、価値のある代償です。
- ここは考えられるようになりたいね
まとめ
#- ただひたすらに書く
- つぎはここ
NO IMAGEリファクタリングしてモジュール性とエラー処理を向上させる - The Rust Programming Language 日本語版