僕が考える「良いコード」 - give IT a try

こんなコードだとわかりやすい 僕が考える良いコードの特徴（条件）を挙げてみると、 ぱっと見たら、だいたい何をやっているのかがわかるメソッド名 ぱっと見たら、だいたい中身が何なのか想像がつく変数名 ぱっと見たら、だいたい何をやっているのかが把握できるメソッドの内の処理フロー 驚きが少ないメソッド 副作用が少ないメソッド（責務が1つしかないメソッド） DRY原則を守っているコード だいたいこんな感じ。 つまり「すんなり読めて、すんなりわかるコード」が理想。 プログラムが小さいうちや、一人で開発しているうちは「汚くてわかりにくいコード」であっても「自分さえわかればOK」で済んじゃうけど、プログラムの規模が大きくなったり、複数人で開発するようになると、「汚くてわかりにくいコード」は絶望的に開発効率を下げる。 こんなコードはわかりにくい たとえば上の反対で、 メソッド名だけ見ても何をやっているのか想

[nemoba]

「名前が大切」の大切さが分かるまでが長い。良い名前ってのは設計なんだと気付いてもらう必要がある。

[circled]

DRYとかSOLIDにこだわり過ぎて初期段階から変になるよりは「同じ処理を3回以上書いたら見直す」とかの緩い制約にしといた方が幸せになれるよ？リファクタリングの時に読みやすいコードを意識した方が生産性高いかも

[mayumayu_nimolove]

共同で作る良いコードと単独で作る良いコードは違うからね。

[otihateten3510]

“驚きが少ないメソッド”　この表現いいね、変なこととか変わったことしてないやつね

[kobito19]

名前が大切なのはそうだけど、みんなそんな名付けの才能無いんだからちゃんとコメント書こうな

[pmint]

つまり「コピペしやすいコード」。作法のすべてがこれに行き着く。測定・評価できない「良さ」は無意味。

[uva]

でも、人間がコードのディテールまで考える時代はもうすぐ終わるかもしれないですね

[Error401]

尊敬できるソフトウェアエンジニアだが、WHATコメント(summary, abstract)に否定的なところは意見が合わない

[m41bulldog]

良いコードを悪いコードと同じ速度で作れるようになりてえなあ

[beejaga]

わかりやすいコード良いよね！／実際は、何をもって「わかりやすい」というかが人や文化によって違うのが問題なのだが……

[ryu39]

「良いコード」の参考になるサイトへのリンクがまとまっててありがたいです。

[canadie]

少なくともメソッドや変数名について凡人があれこれ考えるより実装の説明やコードを入力してGPT-4に書かせるほうが完璧だし紛れがない（ローカルのコード規約があるならそれも入れる）。Codexでもおおよそ事足りる

[knj2918]

驚きが少ないメソッド

[strawberryhunter]

すぐに理解できるコードが良いコード。

[mak_in]

実際の場面でDRYを真面目にやるべきか、は否定派。リファクタで。めんどくさい、ログなど明らかなものをまずDRYに。処理がほぼ一緒だけど、ユースケースが違う場面が多々あって、それを正しく判別するのは案外難しい

[pinossos]

超わかる

[asada_bao]

参考図書がよさそう

[to4iki]

“読む時間を節約できるコードになっていることの方が重要。” わかる