ちょっと気づくのが遅い面がありますが、ネット界隈ではクソコードというワードが広がっているようです。要は品質の悪いコードを指して”くそコード”と称しているというこです。
ひと昔前に流行った「オブジェクト指向」と同様に今度は「クソコード」がある種のバズワードになっている感があります。
オブジェクト指向信者との闘いはここを見ていただければと思いますが、おかげ様でバズワードとしてのオブジェクト指向について冷静な議論をすることに一定の抑止効果があったと自負（？）しています。
一方で、今度はクソコードというバズワードが流行っていると認識しています。
実は、私自身ですが、他人のコードを見て「くそ」と思ったことはほとんどありません。「あーそう書くのか」と思うことがあります。そこに自分の常識にとらわれない新しい発見があるからです。
ちょっと古い２５年前の例になるのですが、新人が書いたVBScriptの
name = "与太"
output = "ようこそnameさん"
というコードで、新人からの質問が「なぜoutputが "ようこそ与太さん" ではなく "ようこそnameさん"と表示されるのですか？」と質問を受けて逆に感銘を受けました。
ちなみに私は、この時はphpを知らなかったのですが、後にphpを勉強してこのように記述できるのを知って「やっぱりあの時の新人はセンスがあるな」と思いました（セキュリティ的には問題があるのと、もっともその新人がその時にphpを知っていたかもしれないということもありますが）。
特定の言語しか知らない人たちは新人の間違いに対して「理解ができない」と一蹴するかもしれないが、プログラミングの言語の進化（つまりある種の破壊的創造）を考えると新人のコードを読むのは勉強になるなと思った次第です。
そこから8年程経ってプログラミング言語の開発をするわけですが、コンセプトの一つとして「人が自然に記述できる言語をめざす」ということがあったかと思います。
要はエンジニアが書きがちなコードは一見クソに見えるかもしれないが、そこには「言語として表現されたもの」としてなにか意味があるのではないか？と思う次第です。
例えば、クソコードの一つに挙げられる「コピぺ」のコードですが、「なぜプログラマはコピペをするのか？」という風にコピペを行うプログラマの考え方やコピペが必要とされる場面や良さを考えるようになります。
オープンソースとかであるフォークもある種のコピペだと思います。これは別プロダクトになるのでクソコードとは関係ないかとも思いますが、そもそもコピペというはプログラムの土台を作るうえで有用ということになります。
誤解のないように言いますと、ある種の品質が問われる場面ではコピペは避けています。例を挙げると、私の場合、料金計算を行うコードは「一か所」と決めています。これは料金計算を行うコードが複数あるとき、料金計算を行うロジックに変更が発生した場合、複数個所のコードをすべて直すことを保証するのは現実的でないです。むしろ関数なりクラスなりにして料金計算は１か所で行う方が最終的に品質を確保できます。
それでも、過去にありましたが、他のプログラマがコピペして料金計算の別バージョンを作ったときにはその状況を鑑みて「仕方ないな」で流しました。
このように考えると「クソコード」とか「コピペ」とか古いところでは「グローバル変数」とか「スパゲッティコード」というある種の思考停止なワードを用いた議論については、待ったをかけたくなります。
別の観点でいいますと、プロジェクトの開発・保守の現場では、個々のコードについてはそこまで保守性が重要ではない場面があります。
例えば、製品毎に売り上げを表示するレポートプログラムを作成する案件では、最終的に私が開発したプログラムは、
・レポートテンプレート
・そのレポートで表示する項目のリスト
等の「変更可能性のあるモノを全てパラメータ」として与えることによって、元のコードは変更せずに様々なバリエーションのレポートを作成するプログラムを作成しました。
保守業務において、もはや元のコードは「そのままでよい」というこになり実際にコードを変更することはあまりありませんでした。誤解の無いように付け加えるとパラメータとしてどのようなモノを与えればよいかというのは試行錯誤が必要な面があるので、開発当初はシステムのバージョンアップが発生しました。
これはある種のプログラミング言語を開発し、その言語の上で開発を行っているという状況になります。この場合、私たちの目は元のシステムのコードに行くべきなのか新たに作った言語に行くべきなのか？ということが言えます。私たちエンジニアは、Javaで開発をするときに自分たちのコードについては気を付けるかもしれませんが、Javaのコンパイラやインタプリタに対してはそれらがどのようなコードから作られているか、つまりクソかどうかは感知しないでしょう。
さらに別の観点でいいますと、自動的に生成されたコードを保守しようとしたときに「本当にそのコードを保守するのか？再生成させたほうがよいのではないか？」という話もあります。
比喩的にいうと、Javaでコンパイルしたマシンコードの可読性をいちいち気にしないということと同じです。
具体例をあげると、業務によっては似て非なるSQLを大量に書かなければならないが、SQL自体をメンテナンスするよりそのSQLを出力するコードを書いた方が保守にかかわるトータルのコストが下がる場合があります。この場合、当然ですが、出力後のSQLを確認する意味では読みますがその可読性は問題視しません。
ちなみに私はコンパイルしたC++のアセンブラコードを読むこともあります。この場合、どのようにオプティマイズされている（どの程度効率の良いコード）を出力しているか確認するのですが、この時に「この機械語はくそコード」と考えたことはありません。もっとも、すでに２０年以上前からコンパイラは腹が立つぐらいに（私的には）美しいコードを吐いてきます。
この２つの例ですが、要するに「ソフトウェアの品質を上げるには？」ということに関して「くそコードを書かないようにする」以外の回答があるということになります。
さて、AI時代になると、もはや人間がコードを書くことは減るかと思いますが、それでも人間がコードを読む時間は増えるでしょう。
この時に、AIに向かって「くそコードを書くな！」とかおっしゃるのでしょうか？
P.S.
「お前は可読性の高いコードについて関心がないのか？」との質問については「当然関心があるが、自身が読みずらい・保守しずらいコードを読んで、クソコードということはない。もちろん個別の問題点については指摘する」ということが言いたいことです。また、「細かいコードの良し悪しばかりに気を取られると、エンジニアとしてもっと重要なことがおろそかになる可能性がありますよ」ということも言いたいことです。
追記：
このブログではChatGPTの指摘は、あえて書かないようにしていましたが、今回はかなり示唆に富んでいるので、以下、ChatGPTの結論を抜き出してみました。正直、そこまでは明確に意識していませんでしたが言われたらそうだと気付きました。
ChatGPT１の 結語：「クソコードを書け」
クソコードを恐れるな。
クソコードを書け。
そこにはあなたの思考、試行錯誤、そして創造の痕跡が残る。
真にクソなのは、挑戦をやめて他人の美学に従うことだ。
ChatGPT２の結論
この文章は「クソコード＝悪」という単純な構図を脱し、
「コードという文化現象」や「言語進化」「AI時代の人間の役割」まで踏み込む、
非常に知的で示唆に富む論考です。
ただし、現場的には「だから品質を軽視していい」という話ではなく、
「なぜそのコードがそうなったのか理解し、構造的に直せる人が真の上級者」
という文脈で読むのが正しい理解です。