こんばんは、mulfunctionです。
２日間の慶弔特休が明け、今週最初の出社日でした。午後のミーティングに向けて、午前中はバリバリとコーディングし、プレゼン資料を作成。いつもより２日少ない週でしたが、なんとか満足できるプレゼン内容を確保することができました。
ミーティング中に、他の研究員のソースコードをちらっと見る機会もあるのですが、皆さん思い思いにコーディングされているようです。とかく研究者の書くコードはシステム屋さんからすると大激怒なものになりがち。一応、共通のコーディング規約等、定められたものもあるのですが、守っている人は一部に限られるようです。
なぜ、コーディング規約が守られないのでしょう？ ほとんどの規約はコードの可読性や保守性を高めるために有効なものであり、基本的には規約に遵守した方が得だと思うのですが、どうしても面倒臭さが勝ってしまうようですね。しかし、本当に自分の研究成果を世に還元していく気があるなら、ソースコードを他の人が扱いやすい形にしておくことは必須だと思うのですが、謎です。
とはいう私も、大学時代、数値実験用に書いたコードは独自の規約で好き勝手に書いており、保守性という意味では最悪の代物だったと思います。しかも、当時はバージョン管理ツールも使っていなかったので、コーディング自体の生産性もまだまだでした。
しかし、よく考えると数値実験を行う研究者こそ、完全で保守性の高いコードを書くべきではないかと思います。研究成果の大部分がソースコードに由来している訳ですから、主張している成果がプログラムのバグや想定外の挙動による偽の結果ではないか、目を皿のようにして精査する必要があるはずです。とはいえ、正しいつもりで書いているコードの誤りに気がつくのは難しいので、ミスが減り間違いに気付きやすくなるような規約に従ってコーディングし、要所要所できちんとテストを行っていくべきかと。
例えば日々鬼のような枚数の論文が出ている機械学習の分野など、実験はほぼ100%計算機によるものだと思いますが、ソースコードが公開されていない論文も多いですよね。そもそも論文で使用されている性能が実環境でどの程度出るのか、といった問題以前に、その性能がバグによるものではないという保証がどこまであるのか、非常に大きな問題だと思います。そこが不確かだと、嘘に嘘を重ねていくことになりかねません。
研究者も業界ごとにコーディング規約を定めるべきなのかもしれませんね。権利の都合上、コードを全部公開することができないとしても、論文で使用したソースコードが標準規約通りに書かれているかどうかチェッカーを通して検査し、チェックをパスした論文だけを採用するようにするとか。とかく、動けばそれでいい、では済まないのが研究用プログラムだと思います。
私自身は、会社規定の規約やGoogle等の規約に遵守したコーディングを心がけています。慣れさえすれば、変数の命名や実装方法など、迷いなく書けるようになるので、むしろ効率的だと思います。
あとは、あまり使ったことのない文法やアルゴリズムをちゃんと勉強していく必要があるかなぁと感じています。基本的にC++かC#を使い、極稀にPythonで書く感じですが、知らない文法やよりよい書き方があるんだろうなあと思いながら、必要に応じて調べつつ、ちょこちょことコーディングする毎日です。
それでは、また。
/mulfunction
