Code of Poem
Unknown programmer's programming note.

C++の開発環境を見直す

ゲーム制作を再開するにあたって、C++の開発環境を一度見直しておこうと思います。

テキストエディタ

前まではGeanyを使ってました。Geany、大部分は気に入っているのですが、一つだけどうしても気になる部分があります。というのは、プラグインに「ウィンドウを分割 (Split window)」というのがあって、これを有効にするとエディタを左右、あるいは上下に2分割して別々に操作できるようになります。広く使われているエディタの多くはこのような機能を備えていています。Geanyはこれをプラグインで提供しています。このプラグインに問題があって、仮に左右に分割したとすると、右側が追加のウィンドウとなります。この追加のウィンドウではまともに作業できないのです。例えば、右の追加のウィンドウにカーソルをおいてある状態で、

といった具台です。解決策は見つかってません。苦肉の策としては、追加のウィンドウを閲覧用の補助的なウィンドウとして扱い、一切編集を行わないという使い方をすることで問題に対処することも出来ます。しかし、ウィンドウの分割というのは私の感覚ではテキストエディタにとっては基本的な機能であるように思えます。もし本当に使えないならそれで構わないのですが、このような中途半端な状態で利用可能になっているのは気持ちよくありません。いっそ完全に編集不可にしてほしかったです。

というわけで、Geanyを使うのは当面やめておくことにします。他の部分は気に入っていただけに残念です。

乗り換え先のエディタとしては、

あたりが候補です。一度古巣に戻ってEmacsを使うことを検討しました。Emacsの一番の問題は拡張性が高すぎることです。ほんの僅かな動作が気に入らないため、例えばフォントの表示が微妙に気に入らず調整してたら半日過ぎてたとか何度も経験してます。もうこういうのはいいです。elispの基礎を鍛えればまだまだ上達できるのでしょうが、終わりがありません。そこで素のEmacsはやめて、Emacsの亜種(というのが適切かどうか分かりませんが)、Spacemacsというのを使うことにしました。Spacemacsの最大の特徴は、レイヤーと呼ばれるものでカスタマイズすることです。イメージ的にはパッケージを直接使うのではなく、一つ層を挟んでカスタマイズする、その名の通りレイヤーです。デフォルトでいろいろな言語のためのレイヤーが提供されていて、なかなかいい感じの状態でコーディングを始めることが出来ます。また、もう一つ大きな特徴があって、Vimのキーバインドを真似たものがデフォルトになっています(ただしEmacsのキーバインドが良ければEmacsにできます)。またスペースキーを起点としたキーバインドになってます。例えばファイル(バッファ)の保存は SPC f s です。Spacemacsの名前の由来はおそらくこのスペースキーではないかと思われます。チュートリアルを読んでいたら、腱鞘炎を避けるためにこのようなバインドになっていると書かれていました。つまり、スペースキーは一番頑丈な指である親指で押すので負荷が少ないということだそうです。Emacsは左手の小指でCtrlを押すので小指が腱鞘炎になりやすいそうです。どうでもいいですが私はベースやギターをやっていて左手の指は割と鍛えられているのかどうか知らないけどEmacsを使っていて小指が痛くなったことはありません。この話の信ぴょう性がどの程度なのかも分かりません。なので特にキーバインドはVimスタイルを採用する決定的な理由がありませんでした。Emacsスタイルを選択するとスペースキーの代わりに M-m (Alt+M) を起点としたキーバインドを使うようになります。でも、せっかくスペースという名前がついているのであえてVimスタイルを選択してスペースキーを中心としたキーバインドを身に付けてみることにしました。もう使い始めて数ヶ月経って少しは慣れた気がしますが、Emacsスタイルとどっちが効率がいいのかはよく分かりません。

VSCodeとAtomはよく似てます。しかしC++に限っていうならVSCodeに軍配が上がります。VSCodeはいくつがパッケージを追加するだけでIDEのような開発環境が整います。特にデバッガが優秀です。Atomには探した範囲ではC++のデバッガは提供されていませんでした。

QtCreatorは仕事で使ってました。Qtの開発には快適でした。というかQtCreatorなしでQtを使う気にはあまりなれませんでした。デバッガも非常に優秀です。堅牢でクラッシュしたことはありません。Qtを使わない場合の使い心地はどうなのか興味があります。ビルドにCMakeを使うことができるのでおそらく同じような感覚で使えるのではないかと推測されます。

microは今使っているGaruda Linuxというディストリビューションの標準のコンソールのテキストエディタです。Debianベースのディストリビューションの多くが標準としているnanoと比べると、より直感的な操作になっていて、より高機能で、さらにLuaによる拡張が可能です。コンソールでのコーディングを中心とする場合、実用に耐えうるものなのかどうか検討してみてもいいかもしれません。

geditはGNOMEのデフォルトのテキストエディタです。プログラミングの機能も備えているようです。ほとんど使ってないです。実用的なのかどうか興味があります。

これらのうち、microとgeditはおそらくIDE的な使い方は出来ないでしょう。外部のツールによるサポートが必要です。この場合、テキストエディタで完結するのではなく、Linuxの環境全体でC++を開発するためのIDE捉えて、そのようにチューニングしていくことになります。Linuxにおいてこのやり方は悪くないと思います。UNIXの哲学としては一つのプログラムは一つの仕事をこなすようにして、プログラムと連携して仕事をするようにするというのをどこかで読みました。GeditはGUIのプログラムなので当てはまらないですが、とにかくテキストエディタはテキストの編集のみを行うようにしてビルドやデバッグまでエディタ上でやる必要はないだろうという考えです(適当に言ってます)。

ビルドツール

CMakeを使います。もう2021年です。C++を使うのにCMakeを使わない理由が思い当たりません。Makefileを書いていないと書き方を忘れてしまうのではないかという不安があるかもしれませんが、もう忘れ去って構いません。CMakeに精通したほうが良いです。

バージョン管理

Mercurialも捨てがたいのですがGitを使います。特に理由がなければGitを使うのがいいです。

テストフレームワーク

もっと早くにテストの基礎を身につけるべきでした。考え直すきっかけとなったのは、Squeak By Exampleという本を読んでいて、Squeakでユニットテストの手法が紹介されていたことです。SUnitというテストツールでした。その本ではテスト駆動開発を推奨していました。ゲームのテストがいつもツールによって自動化できるとは思えないのですが、少なくともモジュール化を促進する動機とコードを堅牢にするのに一役買ってくれることは間違いないでしょう。テストされていないソフトウェアなど信用できないです。それにテスト駆動開発ってなんかかっこいい。

試したテストフレームワークは3つです。

Boost.TestはBoostライブラリの中に含まれています。という点はポイント高いです。C++を使ってるならおそらくBoostもインストールされているだろうから、だいたい使えます。使い方も割と普通です。しかし、GoogleTestの方がより直感的に使えます。別途インストールしないといけないという点に目をつぶればGoogleTestが一番テストに不慣れでも使いやすいです。まずはGoogleTestで経験値を貯めようと思います。Catch2は他とはだいぶ異なります。テストコードがより自然に読めるように、よくわからないですがBehavior Driven Development (BDD)というスタイルで記述できます。上級者向けという感じがします。