スネークケースが開発に向いている理由

Meridian計画。
リファクタリングをゲームのように楽しんでいる今日この頃です。
さて、開発にはとりあえず動きさえすればOK、最低限自分がわかればOK、というプロトタイピングから、誰が使ってもロバストに動くまで世に出さないという高いレベルまでいろいろあると思います。
いま行っているリファクタリングは、自分自身がコードを保守したり追加開発したりしやすくするための作業でありますが、できれば他の人にとっても増改築しやすくできればと思っています。

自分のコーディングスキルはプロトタイピングレベルで、かなり前にPython検定をとってそのあとPaizaでAクラスの問題がギリ解けるようになったぐらいです。なので基本がスコンと抜け落ちたような我流コーディングからなるべく脱却すべく、教科書で学んだりChatGPTに命名やコードが変じゃないか聞きながらリファクタリングを進めています。（ChatGPTはGithubを学びまくっているので、コーディングの一般的な常識力についてはかなり強い方だとみています。）

関数名にスネークケースを使いたい理由

スネークケースはROSの本で学んだ時に関数名がスネークケースだったからという理由が大きいです。
以前の記事では細かい話と思い触れませんでしたが、スネークケースを採用したいと思った大きな理由が他にも２つあります。

① Meridian出身の関数ということがわかりやすい！

C++では関数名はキャメルケースが圧倒的にメジャーです。
スネークケースだらけのMeridianのコードの中にキャメルケースが入っていると、Meridian以外のところで作られた関数だということがわかりやすくなります。
Meridain側で修正すべき箇所かどうかのスコープがはっきりするので、開発の時にとても便利に感じます。

② アンダースコアのところで階層化できる！

Meridianはゆくゆくは全ての関数を公式ライブラリ化していく予定ですが、一方で、開発中は関数の中身がいつでも見えるようにしておいてほしいというリクエストもあります。また関数は今後も増えるので、クラスのメソッドに階層化していきたいとも考えています。
そこで、Meridianの関数ではスネークケースのアンダースコアを階層の区切りとして命名するようにしています。
こうすることで、関数名の見た目は統一しつつも、開発進捗によって関数をクラス化、ライブラリ化とステップアップでき、逆に公式ライブラリとなったものを手元でローカル関数に格下げしてカスタマイズすることもできます。具体的な方法については以下に書きます。

スネークケースの関数名の階層化について

たとえば、
mrd_disp_hello_tsy()
という関数の場合、それぞれの単語は、

mrd : メリディアン関連の関数
_disp : シリアルモニタリング用のメッセージ出力に関係する関数
_hello : メッセージの具体的な機能
_tsy : teensyに特化した関数

というように階層を示しています。
リファクタリング前の初期の段階では、関数化せずにコードがスパゲッティになっていたので、まずそれを関数に切り出し、それをカテゴリごとにヘッダファイルにまとる作業をしました。
具体的には、mrd_disp_hello_tsy() のようにmrd_disp..で始まる関数を、
mrd_disp.hというヘッダファイルにまとめました。

必要な関数が大体出揃ったところで、次はこれをクラスの関数にまとめていきます。
クラス化では、mrd_dispという関数のまとまりを作るので、
mrd_disp.hello_tsy() という関数になります。
さらに安定してきたら公式ライブラリに入れていきますが、その場合は、
mrd.disp.hello_tsy()
という感じにピリオドで区切り、クラス内クラスなどでまとめていく予定です。（.と_の微妙な差になりますが…）

公式ライブラリ化した後も mrd_disp.h というヘッダファイルとその中にコードを残しておけば、ピリオドをアンダースコアに書き換えることで、元のライブラリに手を加えず、関数を改良していくことができます。これはキャメルケースにはない、スネークケースならではのちょっと便利なところだと思っています。

ルールがありつつ、変幻自在でもありたい

PCやクラウドだけで完結する通常のソフトウェアや、ハードウェア構成が固定している製品や教材用のロボット向けソフトと違い、Meridianが対象とするのは個人が自由に組み上げるロボットです。それぞれの事情でかなりのローカライズが必要になると思いますので、わかりやすさと変幻自在なカスタマイズ性をなんとか両立させたいと考えています。

教科書には載ってなかった

「構造化プログラミング」「リーダブルコード」などを参考に作業をすすめていますが、スネークケースとピリオドによる関数の階層化については特に載っておらず、どうやら我流のようです。我流ではありますが、合理性を考えて作業を進めていくと自然とそうなるという使い方だと思うので、きっとどこかでは常識的に使われている方式なのではないかと思います。
もっといいやり方があるぞという方はぜひ教えてください。

なんとかがんばって、オプション関数を作るのが楽しくなるようなシステムに仕上げられればと思います。

次回記事：

前回記事：

目次：