きれいなコードを書けという話について - Software Transactional Memo

前回のブログから90日以上経ってしまったので広告が載ってしまったから短文でもアウトプットしておく。 プログラマとして仕事をしているとコードと向き合っている時間の9割以上は既存のコードを読んでいる、だから読みやすさは重要である、という言説は耳にタコができるほど誰もが言っている。 仕事で書かれるコードが誰のレビューも通ること無くマージされている現場は凄惨だが、自分より明らかに経験を積んだ人たちが何度もレビューを重ねたコードが読みやすいかというとそうとは限らない。良いコードが守るべきルールをすべて守っていても不可解なコードはあるし、どんなに読みやすいコードでも数千行の規模になってくるとやはり脳内からこぼれて一度に覚えておける範囲からはみ出る。 変数名や関数名をわかりやすくするとか不必要な技巧を凝らさないとかわかりやすい設計にするとか主観的な事を偉そうに語る本は山ほどあり、それらの本を崇める事は悪

[kknsd]

意図がわかる事が重要で、それがコード自体で充足できれば良いのだけど、現実はそうもいかない

[ledsun]

メンタルモデルと一致したソースコードなら読みやすい。数年手を入れてると、メンタルモデルが変わってくる。ソースコードは古いまま。ソースコードを直すしかないんすよ。動いてても、それなりにきれいでも

[hwalker]

if (r<0) return;を三行に分けて書け、ついでにコメントもいれろ、みたいなルールが一番めんどい。

[rryu]

一番きついのは書いた人の気持ちを脳内で再現したら書いた人もコードを理解して書いていないという結論になった時。結果としてはこれだけだからこの処理は要らないはずって削ると動かなくなるという

[caynan]

きれいなコードっていうのは、文章で言えば、てにをはをちゃんとしましょう、段落を分けましょう、というレベルの話であって、それだけで何か伝わるものではないけど軽視していいものでもないよね。

[hatfatcat]

“不要なコードとテストをどんどん消すこと” 10年くらい運用されてるサービスで 、どこで使われてるかわからないメソッドとかが大量にあったなー。

[UDONCHAN]

長い

[YassLab]

“コードの読みやすさというのは書き方の小手先や技法でどうにかなるものではなく、時系列方向への弛まぬ努力の果てに達成しえる物である”

[uzuki05]

“書き手と読み手の心が一致した時にようやく読みやすいコードになるのであって、変数名だの諸々はその前では些細な問題である。”

[PrivateIntMain]

今の現場はいらなくなったコードを消さない文化(呼ばれんなら放置でいいし、金かけて書いたもの消すのはもったいない)なので調査のハードルが跳ね上がっている。

[okinaka]

“巨大なコードを読むときに真に必要なのはありきたりな教条ではなく、書いた人の気持ちを脳内で再現することである。”

[onk]

非常に分かりやすい！＜「デザインドキュメント」だが(...)首をかしげそうな気配を感じたらとりあえず書くブログ記事のようなものである

[kiririmode]

“「ソフトウェアエンジニアリング」とは単にコードを書く行為のみならず、組織が時間の経過に応じてコードを構築し保守するために用いるツールとプロセス全てをも包含するということである。”

[razokulover]

もっとコメントちゃんと書いてくれ頼む…みたいなコード結構多いので納得感がある

[koogawa]

コミットログが「レビュー修正」とかだと、そのレビューってなんなのよ！！ってなる

[blue1st]

「わかりやすい変数名をつける」とか当たり前のラインはあるけど、そこから先は色々な環境要素で変わってくるというのは首肯するところ。「コードを読み解く労力を最小化する」手段としての「意図の伝達」。

[clockwork9]

究極的には、最もきれいなコードは読み手の主観で決まる。可読性を突き詰めた先は沼。実行速度のように客観的な数値で示される要素は実質的な正解があるかもしれないけども。

[sd-craft]

きれいなコードとは何か？それで何を解決したいのかを考えないとダメ

[juejue]

過去に「コードを読めばわかる」とコメント書こうとしない奴がいたが、コードを読んで思い出す作業にいつも時間を要してた。コメント書いておけばすぐなのに。そんなアホにはなりたくない。

[harumomo2006]

人それぞれ書き方の癖があるのでみんな綺麗なコードの形が違ってて分かり合えない

[funa-1g]

ここしばらく仕事で言っている話がきれいに言語化されてる。ありがたい。コードに残留思念が残せるようになるといいとずっと思ってる。

[getcha]

見た目は綺麗だけど、むりやり一行に詰め込んでいて、横に長く読んでかないといけないコードは嫌いだ。目をさらにして区切りを見つけながら読まないといけないだろ。と思う。

[ikkitang1211]

読んだ。 やっぱ、色んなリンク辿れるようにするのいいな

[number917]

AIにコード書かせて、それをAIに読ませる世の中になると？

[natu3kan]

仕様的にコメントまみれにしないと分からないケースもあるよな。

[Wafer]

if (x>0) if (r<0) return; else y=0; さてこの時elseはどちらのifのものだろうか。ということがあるのでif (x>0) { if (r<0) {return;} else {y=0;}} と書くようにと静的解析ではrecommendされる

[mumei-0]

“デザインドキュメントをたくさん書くこと”

[Lat]

大事な話だ。私は大部分をドキュメント自動生成ツール（有料版）に頼っていて、コメント規約などを守って書いている。そのおかげで記憶からほぼ消えている過去の仕事について話をふられてもなんとかできている。

[ghostbass]

レベルによるなあ。概念のずれた命名をされるとずれたほうに思考が引きずられるし、1文字変数にされると脳内スタックにいちいちラベル付けていかないとつらくなるし、とか。

[sabinezu]

きれいなっつうか、客観的に意味がわかるか、だよ。「きれいな」って言うと、読み手によって意味が変わってくる。構造化されてて命名規則も統一されてればすんなり入ってくる。バカの作ったコードは無駄の塊。

[tacamula]

「きれいなコード」の話のときにソフトウェアアーキテクチャまで話が行かないの微妙に思ってる。イメージ的には図書館で本の分類法なしに本棚の整理方法だけ考えてるイメージ

[sigwyg]

「不要になったら消す」のが書いた人の責任、としたいとこあるよね。他人のコード消すのはハードルがある（だからTODOコメント大事）

[yamadadadada2]

2年ぐらいしたらGPTがやってくれるようになる。結果仕事がなくなる。君たちはどう生きるか

[nekoluna]

“書いた人の気持ちを脳内で再現”

[secseek]

程度の問題ってのはありそうです。コンパイラが警告を出してくるレベルくらいは少なくともなくしておかないと無駄な時間ばかりがかかります。ただコードさえきれいなら問題ないかと言えばそうではないんでしょうね

[NOV1975]

でもこれ、本質的には設計書書こうって話に近いよね。

[hatest]

コードを書くときに「ありがとう」「素敵だね」などのいい言葉をかけるときれいなコードができる。コンパイルも早くなる。

[nicht-sein]

メンテナンスが大事というのは諸手をあげて賛意を示すところだけれど、自分がそれを実践しているかを問われると挙げた腕を地面について俯くことしかできない

[circled]

綺麗なコード真理教が安易に増えてそうだけど、その綺麗なコードは愚直なコードや汚いコードよりも300倍以上も遅くなるって話も合わせて理解してからトレードオフを語るべし！と常々思う → https://youtu.be/tD5NrevFtbU