chokudai さんがこう言っていて、確かにそうかもなぁと思った。
結構強めに言うけど、ABCのCくらいのコードがめちゃめちゃぐちゃぐちゃになる人が、業務のコードでぐちゃぐちゃにならないとはあんまり思えなくて、実際、経験上かなりの確率でちょっと複雑なロジックが出ただけでぐっちゃぐちゃになってるのよね……。
— chokudai(高橋 直大)🌸🍆🍡 (@chokudai) 2020年1月24日
C問題を瞬時にキレイなコードで解けるようになると、業務コードも良い感じになるのかもしれない？（そうとは限らないけど）
で、自分はどうなのか？というと、なんとも判断ができない。
読みにくいコードは書かないように気をつけているつもり。回答速度が重要な競技プログラミングだけれど、
- 意味のある変数名を考えてつける
- 分離可能な処理はメソッドに切り出す
この2点は意識してやっている。 自分は短期記憶能力が極めて低いと思っているので、これやらないと自分が何やっているのかすぐに分からなくなってしまう。
自分なりには「そこそこ読みやすいな〜」と思いながらやっているけど、自分以外の人の視点で「キレイなコード」なのかは分からない。（「キレイなコード」の定義も人それぞれっぽいけど）
この疑問を解決するには自分のコードを自分以外の人に読んでもらう必要がある。
すでに GitHub には push してあるから誰でも読めるようにはなっているけど、もっと読みやすいコンテンツとして用意した方が良さそうだなぁ。この問題をどう解釈したか、とか、コードを書きながらどんなことを考えていたか、とか、もっとこう書けばよかった、とか。そういうのを書いた方が読み応えがありそうだし自分にとっても学びがありそう。
あと chokudai さんがこういうことも言っていて
なのでやっぱり実装安定しない人は、上位の人のコードを読む習慣はつけた方が良いかなー？って思ってる。
— chokudai(高橋 直大)🌸🍆🍡 (@chokudai) 2020年1月24日
自分で書いてみたコードのお手本を見る、ってやっぱ学習効率かなり良いとおもう。
ああ、他の人のコードをあまり読んでないなぁと思ったし、自分と同じように他の人のコードをあまり読んでない人はそれなりにたくさんいるだろうなと思ったので、「自分以外の人はこんなふうに解いていたよ」という感じでコードを貼り付けて解説してみるとコンテンツとしての価値が上がりそう。
「コード長」「実行時間」「メモリ」で sort できるから、それぞれのトップの提出コードを読んで解説してみると良さそう（読みやすいコードではないかもしれない。特にコード長が最小のやつ）
記事を書く場所はどこがいいだろ。内容的に Qiita が良いかなぁ。ここよりも幅広い人に学びを共有できそうな場所に投稿したいな。
