ルールズ・オブ・プログラミング読書会vol.20
https://scrapbox.io/files/655372c161a776001bf71cc6.jpeg
開催日時
2024年9月24日(火) 19:30~21:00
開催URL
参加人数
4人
ウォーミングアップ
ルール8 実行されていないコードは動作しない
第4段階:因果応報
味方の一部が消えるのはたしかにわかりにくい
見つけてくれたらそれは優秀なデバッガー
責任追及
メンテナンスを考えると呼び出されなくなった時点で消したい
呼び出されていないことを保証するの難しい
削除してビルドエラーが出るかを確認する
シンボルテーブルを確認してコールグラフを得る
関数ポインタはどこかに値を保存するやつがいるのでそこに着目する
関数ポインタは少数
ClangのAST生成機能を使っても実現できそう
スクリプト言語だとこういった方法が取れない
スクリプト言語でもAST作れる言語があるのでそれならできる
文字列連結で動的に呼び出しするような作りだとAST作れない
(ここらへんまとめに残せない話)
ここの内容は筆者と同じ見解
呼び出されなくなったら消したい
インタフェースを残しておかなければいけない場合
中身を消してASSERTや例外を投げるのがいい
ライブラリの場合
テストの限界
mallocどうやってテストしたらいい?
K&Rくらいのmallocなら内部状態を確認すればテストできる
テストが中身に依存するの気持ち悪い
テストの目的による。ホワイトボックステストであればOK
テストを書かない主義
私が書いたものが正しい!
時間とともに正しさがかわることもある
チーム開発に良いとは言っていない
チーム開発したくない
こんまりが出てきた
鈴木 雅之も出てきた
「違う、そうじゃない」
「削除できると分かればときめく」
コードを書いてるときがいちばんときめく
他人が書いたの消しにくい
コメントアウトされたコードであっても
ifdefで片方を線形探索版、もう片方を複雑な二分探索版で書いていた
ifdefだと非アクティブな方がアップデートされずに古いままになりません?
なる
今回のルールに通じる話
2パターンとも呼び出せるようにしておいて一致するかテストすべきかな
変装機能を追加した人がテストも更新しないと不具合が出る
テストも更新してくれるのは高望み、というのはその通り
テストの限界
ルール9 集約可能なコードを書け
次回ここから
お悩み雑談室
WindowsのC++でGUIを扱うにはどういうライブラリがいい?(定期)
Microsoft Foundation Class
Webブラウザで表示したらということでFluxやReactの話が出た