テストできるスニペットライブラリ

コンテストで解いたコードはコンテスト番号でファイル名がabc123/e.pyみたいになってる。

なのでまずこれをlibs/lazy_segtree.pyみたいに分かりやすい名前でコピーする。

コンテストで解いたコードは-tでローカルテストが走るようになってるので、テストしながらリファクタリングできる。

再利用に備えて、そのコンテスト特有のコードと、再利用されるライブラリ的コードとを分ける

間にコメントでマーカーを入れる。

スニペット作成スクリプトはlibs/*.pyを読み取って、ライブラリ部分だけを取り出してvscodeのスニペットにする。

docstringの先頭行をスニペットの解説文にする

分離マーカー方式のメリット

libsのファイル全体をスニペットにしない

コンテスト参加中に書いたテストコードをそのまま利用できる

ライブラリとして再利用するときにテストコードはコピペされたくない

マーカーの上にライブラリ、下にテストコードにすればテストコードを温存しつつ、それをスニペットには入れない

手元の小さいテストが保たれるだけじゃなくてatcoderやaojにサブミットできる状態も保てる

大幅に変更したときに、念のため再度サブミットして動作確認することもできる

コンテストでタイムアウトしないかどうかの検証もできる

複数のコンテストで使われたライブラリはだんだんテストケースが増えていく

遅延伝搬セグメント木がまさにそんな感じで、いま7つのコンテストのテストデータが乗ってる

修正した後にも各コンテストで通る状態かを確認できる

以前の話

セグメント木のコードを整理しなきゃなぁと思いつつまだやってないのは、競技プログラミング用の自作ライブラリの整備の仕方についてまだ良い方針が思いついてないせい。普通にモジュールにしてimportして使うようにすると1ファイルで提出するために後からコピペ作業が必要でだるいかなーと。

あと、問題条件に合わせてゴリゴリ書き換えることもあるから最初から提出ファイルに貼り付けちゃうのが良いと思ってるのだが…そして「ファイルを開いてコピペ」の代わりにvscodeのスニペットがいいと思うのだが、その方針でやることの良さにまだ自信が持てない

他の案としてはimport文を置換する「提出用データ作成スクリプト」を作る手もある。この方針の良いところは、その変換のフェーズでデバッグ出力を消すとか、関数呼び出しをインライン展開するとかもできるはずだ、という点。

変換結果はクリップボードに入れる。