書いてみましたが，何も自信はありません．
本当か嘘か全くわかりません．
コードを書く前のお話です．
コードを安易に書き始めるとバグる可能性が飛躍的に上がります．
例えば，途中で方針の変更を余儀なくされた場合など最悪です．
この変数の値が表す意味を変更したという場合は結果的に混同してしまいがちです．
変更前のコードの名残が悪さをすることもあります．
変更前だと配列サイズはこれで良かったけど変更したら1足りてない，とかよくあります．
なによりも，変更前の方針に引きづられて，変更後の方針において（簡潔な・バグりにくい）実装方法が（思いつかない・移行したくない）ということになったりします．
最速（First ACなど）を目指す場合はまずコードを書き始めないと話にならない場合も多いですが，コードを書き始める前に多少時間を費やしたほうが平均的には早くなる気がします．
前提です．
まず，問題内容自体を大きく勘違いしてしまうと，実装以前の問題です．
これも，誤読した問題に引きづられて，正しい内容の問題に対する解法が（誤読しなかった場合に比べて）思いつきにくくなります．
万が一，これに嵌ったら，一度リフレッシュするために，別の問題に一度取り掛かると良いことがある気もします．
さて，問題内容を大きく勘違いしなくても，細かい条件を読み落とすことがあります．
そのような条件がなくても解けちゃうとなれば，解けるからいいやと問題文を精査しなくなる，が原因の一端を担っている気がします．
実はそれが簡潔な実装を可能にする条件だったりすることも多いのです．
問題を解く方法は1つだけではありません．
まず1つ解法が思いついても，より簡潔な解法がないか，少し考えてみると良いかもしれません．
特に，アルゴ系の競プロにおいては，条件を満たせばACがもらえて，それ以上の差がないことに注意してください．
簡潔な $O(N^2)$ で通るのに，複雑な $O(N \log N)$ の解法を選択する必要はないです．
解法が決まっても，実装の方法はたくさんあると思います．
実際にコードを書く前にある程度どのように書くかを考えておきましょう．
どんな変数を用意して，名前はどのようにしますか？（特に複雑になってくると短さよりもわかりやすい・かぶらない変数名を考えたほうが良いです）
この部分は関数にしてしまいますか？（関数にしておくと，万が一バグったときのデバッグがやりやすいかもしれません）
信頼できるライブラリがあるなら使う（整備しておく）のも手です．
言うことはあまりありません．
1. で考えたことを着実に書いていくだけだからです．
ただ，1点だけ言います．
慣れてくると，無意識でコードを書いていることがあるかもしれません．
ちゃんと一文一文意識をはっきり持って，間違えてないかチェックしながら書きましょう．
コードを書いた後のお話です．
書いたコードが無事バグがなくコンパイルできACもらえることを祈りましょう．
万が一駄目だったら，なんとかしてデバッグしてください．
ただし，この記事の趣旨としては，その時点で負けです．
デバッグについてはchokudaiさんがtwitterで良いこと書いてたような気がします．
解き終わった後に，より簡潔な方針・実装方法が思いつくことは珍しくないです．
また，他の人の実装を覗いてみると参考になると言われている気がします．
同じような状況に出くわしたとき，どのように実装するとバグりにくいのか考えてみておくと後々のためになります．
また，このような状況においては自分はこういうふうに実装する，と大雑把な方針を決めておくと，混同しにくくなり，バグが減る場合もあります．例えば
などです．
ところで，私はどれもできていません．
常にバグらせています．
助けてください．
Current time: 2024年04月25日14時36分39秒
Last modified: 2021年11月03日18時38分20秒 (by laycrs)
Tags: no_tags
トップページに戻る
Logged in as: unknown user (not login)