kichi2004 です．
先日，AtCoder の解説についてのツイートを複数行ったところ，かなり広範囲に広まってしまい，いくつかのルートでは，誤解を含んで広まっているようでした．
この記事では，AtCoder の解説についての個人的な考えを述べます．
書かれている意見は，所属組織の見解を代表するものではありません．あくまでも一個人の意見として読んでください．
私について
現在，大学の情報系学部の 1 年生です．
中学2年生から競プロを始め，現在青色です．(AtCoderプロフィール)
また，仕事や趣味，大学の授業でソフトウェア開発（界隈で「業プロ」などと言われていること）を行ったり，CafeCoder というコンテストサイトを運営していたりします．
CafeCoder では，サービス全体の開発，運営，コンテストの管理，問題作成など，幅広く関わっています．現在は休止中ですが，何も動いていないわけではありません．
注意
今回，ABC-A/B 問題などの「プログラミングできますか？」みたいな問題については言及しないこととします．
一部，kyopro_friends さんの「実装例について」を引用しています．引用に際し，引用元の一人称など，一部を修正している場合があります．
この件が広まる原因となったツイートの言及先は kyopro_friends さんの解説ですが，この記事で言及するのは kyopro_friends さんの解説に限りません．
また，kyopro_friends さんの方針を一概に批判するものでもありません．実際，kyopro_friends さんの Twitter での解説や，実装例を除く解説の部分については，十分にわかりやすいものが書かれていると思います．
本題
青色というわけで，本番中に解けなかった問題では，解説を見ることも多いです．
一時期（1～2年前）は，解説が数行，「2 次元 DP をすれば時間計算量 O(N^2)，遷移もうまくやれば十分高速です．」みたいな感じの解説になっていない解説もいくつかありましたが，最近はそうでないように感じます．
AtCoder の問題はかなり考察寄りとは言っても，特に ABC では，実装で詰まる点が存在する問題も多くあります．
writerは、わざわざ実装を読まなくとも理解できるような解説を書くべきですし、読者は、そのような解説を読んで理解できないのであれば理解できない部分は自分で考えたり調べたりするべきです。
という意見は自分も概ね同意ですが，本当に「実装を読まなくても理解できるような解説」をすべての Writer が書いているかといえば，そうではないと思います．
また，実際にコードを追いながら，コメントも使って処理の流れを把握する，というほうがわかりやすいという人も多くいると思います．
本当に「実装を読まなくても理解できるような解説」であるか，考察が本質で，実装は（問題のレベルに対して）大幅に簡単である場合は不要かもしれませんが，そのような場合以外は，「実装例」が存在することは重要だと考えています．
ここで「実装例」というのは，解法を説明するための「例」であって，解の正当性を示すためのものではなく，「人に読んでもらうコード」であると思います．
（直前に上げた不要な例に当てはまる場合は，単に「Writer解」が存在するだけで良いと思います．）
「人に読んでもらうコード」であれば，人に読まれるなりのコードである必要があると考えています．（空白や改行を適切に行う，短すぎる変数名を使わない，マクロを多用しない，など）
今回気になった解説はユーザ解説ですが，最近の公式解説で，実装も本質だと思われる問題でも，実装例として「人に見せるためではないコード」が示されています．これは，以下の記事の記述とも矛盾しません．
（略）基本的に実装例にはwriter解がそのまま貼ってあります。writer解というのはつまり「私にとって読みやすいコード」です。（略）
「人の見せるコードは整えて欲しい」に対する答えは「人に見せるコードではありません」
「人の見せるコードを用意して欲しい」に対する答えは「その必要はないと考えています」
（「人の見せるコード」はおそらく「人に見せるコード」のことだと思います．この部分は原文そのままです．）
これは Writer との意見の違いであって，どちらが間違っているというものではないと思います．
私は「大半の問題では実装例が必要」で「実装例は人に見せるコードであるべき」だと思っています．
現在は，解説の内容はすべて Writer の裁量に任されていますが，AtCoder 社は解説の質（下限）を指定したほうが，ユーザに納得を与えることができるのではないでしょうか．
自分なりの「解説」は，このブログの過去記事にあるので，良ければ見てみてください．（AtCoder のアカウントを作り直した影響で，提出ページは見られなくなっています．また，今の私とは違う考えである点も存在するとは思います．）
何か意見があれば，コメントに書いていただけると嬉しいです．（後述の UserScript に関することは，GreasyFork のページか GitHub に書いてください．）
私なりの解決策
自分は AtCoder の Writer でも Admin でもなく，彼らと意見が違う以上は，自分でなんとかしなければならないと考えました．燃えそうで怖かったというのもあります．
そういうわけで，解説・提出ページなどのコードをボタン1つで整形してくれる UserScript を作成して公開しました．
これを通しても変数名やマクロについては改善しませんが，それでも整形されていない（詰まった）コードを読むよりはかなり読みやすくなると思うので，解説に対して同じ気持ちの人はぜひ導入してみてください．
その他の意見
参考程度に，自分が観測できた範囲の意見を貼っておきます．
時系列がバラバラなのと，観測できる範囲だと賛同意見が多くなりがちですが，許してください．
自分の書き方と違う流儀の時点で少し読みにくさが発生するのは仕方なくて、解説のコードは問題ない程度の読みにくさだと思います
— バッテリー/指差し確認/郵便局 (@SSRS_cp) November 12, 2022
これどうなんだろ。自分は解説の文章とソースコードが同時に見えた方が嬉しいと思ってるので、解説用のコードを書くときは、フォーマッタ外して頑張って改行を減らしてるんだけど、そのままのが嬉しい人が多いのかな？https://t.co/FDthFzQHJ4
— chokudai(高橋 直大)🍆@AtCoder社長 (@chokudai) November 13, 2022
これめっちゃ同感、、
（あまり何か言える立場でもないけど）解説のコード、とりあえずformatterにはかけて欲しいといつも思ってる
— じゅんや (@Junya_Tsukuba) November 13, 2022
競プロフレンズさんのコード、) の後にスペース入れてなくて読みづらいこと割とあるhttps://t.co/Cv5aMS5NCz
— ゴジラ＠競プロ (@gojira_kyopro) November 13, 2022
うにの意見と元の声明を要約した文章の位置がごちゃごちゃでちょっと読みづらい…… pic.twitter.com/oYy8j8gGTx
— ✹うにだよ✹ (@u2dayo) November 14, 2022
書いた言葉には責任が出てくる(例えそれがTwitterのような呟くだけの場所であったとしても)ので、"実装例"と書いたならやっぱり例として見せられるものが良いなって
Writer解、なら例ではないので別に良いかなと思うし、そもそもリンク貼る必要も無いんじゃないかなというお気持ち— 31536000 (@CuriousFairy315) November 14, 2022
