ルールズ・オブ・プログラミング読書会vol.15
https://scrapbox.io/files/655372c161a776001bf71cc6.jpeg
開催日時
2024年7月9日(火) 19:30~21:00
開催URL
参加人数
10人
ウォーミングアップ
ルール7
「また、関連する引数を~」
cpp20からのstd::formatを使えば解決
ここに書いてるprintMessageにも利点がある
「"作者名"」といった具体的なフィールド名を指定できる
それはstd::formatにはできない
C#に変数名を文字列に書いておけば置き換えてくれる機能あるよね
シェルスクリプトには昔からある${hoge}
そこまで実装しなくてもと思うけど、使う側としては便利
${**} の中に関数呼び出しとかできるタイプはセキュリティの担保が大変そう
ローカライズを想定してMessageIDを用意しているのが読み取れる
そういう明示的な説明が欲しかったな
タイミングが全て
静的型付け言語ではない環境で書けます?
書けます!shellscriptで書いてます!
それは別にええわ
テストの手数の多さでカバーできる
自分が強くなれば型が無くても書ける
自分が強くなる必要がある
静的型付け言語だと初心者がコンパイルに成功して実行できるまでに多少壁がある
フェイルファースト
戦略の悪さを戦術でカバーすることに定評のあるC++
C++最近は戦略の方を修正してきている
テンプレートハック → concept
プリプロセッサinclude → module
言語ごとの非推奨→削除について
C#だとそうそう使えなくなることはない
C++はひっそりと姿を消すパターンがある
Unicodeの悪口 個性的な特徴に関する議論
もっと複雑な例
falseが3つ並んでいる
DDDな考えだとそれぞれに型をつけていく
C++だと1つの構造体をコンストラクタ引数に引き渡して構造体のメンバに項目を増やしていくことが多い
C#だとイミュータブルでありたい
名前付き引数
毎回つらつら書くのが嫌ならデフォルト値を設定するSetDefaultParam関数を用意すればいいのでは?
params.drawSphere(...)
Params型のお前がdrawすんのかーい!
Params型を受け取った別のオブジェクトがdrawするのならまだわかる
こいつのほうがかなりまずくない?
この後でてくるDraw型もツッコミどころある
動詞かーい
キャラの頭の上に表示されるオブジェクトのことをParamsという型だと思えばdrawするのもギリ納得できる
好意的に深読みしすぎでは?
そうなら名前が悪すぎる
よくわからないものにはめっちゃ複雑な名前をつける派閥
後ろにWillBeRenamedをつける
ひと目でヤバそうなのがわかる
逆にX一文字にする派閥
一文字だと見逃す危険性がある
「そして、コンストラクターの引数の追加や~」
次回ここから
お悩み雑談室
ドラム式洗濯機買いました(お悩み解決!)