ルールズ・オブ・プログラミング読書会vol.43

https://scrapbox.io/files/655372c161a776001bf71cc6.jpeg

開催日時

2025年10月14日（火） 19:30～21:00

開催URL

参加人数

6人

ウォーミングアップ

ルール18 コードに自らの物語を語らせろ

良い物語を語る

findPermutation

読めない・・・

ワンライナーマンセー

達成感はある

満足して普通に書き直す

Qiitaのマークダウン書式が変わった

直すスクリプトを作って公開したときはワンライナーで済ました

ミニファイ（minify）

アグリファイ

難読化

C#は目が滑らない糖衣構文を追加してほしい

(でちまるさんとさおさんのこのやりとり懐かしい)

プログラミング漫才

中身は見てないけど関数名から挙動は推測できる

インデントが変

僕ぐらいになるとインデントなくても対応がわかる

tryFindPermutation

私なら関数に利用サンプルをコメントを書くかな

温かみのあるコメント

前回のXMLドキュメント論争再燃

使い方のコメントを書いてほしい

「チェックする」みたいな曖昧なコメントはちょっと・・・

処理を直ちに終了し、物事を単純にする。

「処理を直ちに終了する」でよくない？

自分が書くなら後ろにそんな自明なことは書かない

レビュアーに対する補足なのでは？

西海岸文化なのかな？

知らんそんなもん。大阪湾文化にしろ！

プルリクに書いたらいい

コメント過多気味

3行はいらない気がする

長いと関数に分けると言い

長さというより１行でも関数にした方がいいケースはある

例：ビット演算

orとかしているだけ

サッカーパンチはコメント量が多そう

やっぱコメント多くない？

わざとらしく書いてる

「次の処理に移る」とか見ればわかる

プログラム見ればわかること書かなくていいって手前で言ってなかった？

コメント書かない主義

コメント書いてて処理が変わった場合、コメントも追従する必要が出てくる

コメントがなければその必要がない

今ならAIにコメント部分だけを書き直してもらうことができそう

なんでこれが欲しかったのかをまずドーンとコメントで書く

あとはコードがずらーっとでいい

関数よりも大きい単位（クラスやファイル）

ややこしいことする関数なら書く

「なぜこの方法にしたのか」よりも「なぜこの方法じゃだめ」とかが書かれていた方がいいケースもある

選定理由

ADR

「ADR」は、プログラムの文脈では主に「Architecture Decision Record」（アーキテクチャ決定記録）を指し、ソフトウェアのアーキテクチャに関する重要な意思決定とその背景を記録する文書です

コードに現れない部分をコメントに書く

コメントがないと考古学になる

どちらでもいいケースもある

例：文字列操作

sedだろうが正規表現だろうがワイルドカードだろうが操作できれば何を使ってもいい

ルール19 作り直しは並列で行うこと

お悩み雑談室