堕天使の煉獄

DXライブラリに依存しない部分を別ライブラリとして分ける作業をするついでに、また1からソースを見直しているのだけども。

そのタイミングでしかできない事として、コーディング規約の見直しという物がある。

んでもこれ、絶対的な正解なんてのが無いものだから、ある意味厄介な問題なんですよね。

今現在採用してるのは

以下の表記使用
パスカルケース＝アッパーキャメル→　　ClassName
キャメルケース＝ローワーキャメル→ className
スネークケース　　　　　　　　　→　　class_name
として。

class、struct、Enum、はパスカル。
メンバ関数名はキャメル。
メンバ変数名はキャメルにm_を頭につける。（あんま使わないけどpublicの場合はm_無し）
フリー関数はスネーク
ローカル変数はキャメル、スネーク正直どっちでも良い（どうせ外から見えないので）
定数はローカル変数と同じ。基本constexpr指定するので、間違った使い方すればエラーになるので特に書き分ける必要はないと思う派。
namespaceはすべて小文字で文字は区切らない。namespaceのみ略語を許可。
マクロはすべて大文字のスネーク。

とりあえず命名規約についての所では、大まかにはこんな感じなのだけども。

コーディング規約についてのネットの記事は結構古い物がおおくて、あんましこう、最近のトレンド的なのって、よくわからないぽ。

んートレンド的には、ＳＴＬの命名方法が、結構アレなんだよなぁ。

昔からここの命名基準はちょっとおかしなのが多くて、結構混乱の元だった時代もあったんだけど……（ＭＳに比べればマシか……ｗ）

ｃ++11以降はさらにSTLへの依存度が高くなってきた事も合ってか、ＳＴＬの書き方に合わせようって流れが来てる感じなんですよね。

クラス名も小文字でスネークな感じとか。

その根底にあるのは、namespaceの重要性というか、一般化した影響というか。

基本的にクラスや型は必ずどこかのnamespaceに属していて、using namespaceは使わない方向。
ってことになると、名前のコンクリフトをほぼ考えなくて良くなる感じになるぽ。
そうなると、別に全部小文字でもええやんと。shiftキー押す手間省けるしね。
んでもって、namespaceに括るのがあたり前になると、ネームスペースはすべて小文字になるので

dx::Rect

よりは

dx::rect

の方がしっくり来る感じになるんですよね。

std::vectorとかSTLで慣れちゃってる分、ネームスペースのあとのパスカルケースはなんか気持ちが悪い感じがするようになってきちゃった最近。

そんなもんだから、using namespaceして、ネームスペースは名前衝突時の保険ぐらいの扱いにして、

DxRect

と現状ではネームスペースをusingしちゃって接頭辞をつける方向に流れていったんだけども。

んでも接頭辞はあんまし良くないよなぁ。ってのは常々おもってはいて。

そこで今回、ＤＸライブラリの依存のない部分を汎用的なライブラリとして別に分けようとなっているんだけども。
そこで、その非依存なライブラリについてはSTL風の命名にしてみようかなーとかいう考えが出てきてたりで。

んで、ＤＸライブラリ依存べったりな方は、今まで通りDxなんとか～と接頭辞付で。
そんでもって全体namespaceでくくってあるけど、利用時にはusing namespaceしちゃう方向で。

どうせＤＸライブラリ依存べったりの部分は移植性とか考えなくていい。
逆に依存部分があるので、安易に移植とか考えちゃいけないコードだよというのが明確になるのでいいのかなと。
using namespaseしちゃうのは、接頭辞あるからコンクリフトは避けられるので、一応お作法として括ってあるだけの有名無実になるけど……。

んでもその辺はＱＴの方向性を真似てる感じかな。
ＳＴＬと同居するのにコンクリフト避けるための接頭辞Ｑ付の名前ってのと、Ｑ何とかなクラス群はソースのクロスプラットフォームが保証されるっていう目印になってる感じだとか。

そんなかんじでＳＴＬとか標準的なものと衝突をさけつつ、ＤＸライブラリ依存なコードですよ。
ってのが判る感じなので、これはこれでいいのかなという感じがしてる。

かたや非依存な汎用的な部分の奴は、ネームスペース分けて、利用時はＳＴＬと同じようにネームスペース指定付で記述すると。（あとはusingエイリアスとかで対応）

そんな方向性に進んでみようかなぁ。

それで、ＤＸライブラリ以外のなんか組むときに、非依存の部分のクラスとか流用するときに、ＤＸライブラリ全然関係ないのにDxなんとか～とかついてるのきもちわるーい。とかにならずに済むしｗ


あとは、関数名とか、スネークにするかキャメルにするか……。
いまだに決めかねてる。

どうも最近微妙に、コーディング規約関係でヒットするサイトで、日付の新しいものではスネーク記法押しが結構目立つようにはなってきてる感じもするんだけど……。

でも個人的にはスネークってなんか長ったらしくなってコンパクトさに欠けるというか、なんかだらしない印象があって、いまいち好みでは無かったりする。

特にメンバ関数なんかが気になる所。
呼び出しがいくつもつながってる時、スネークのアンダーバーがいくつもあると、可読性落ちる気がするぽ。下線とドットと、文字の下部に記号が増える所為なのかな？　そんな印象を受ける。

でも、単体でみると、単語の区切りが明確というのは確かにそうだなとも思う。
なので、フリー関数なんかではスネークの方が良いかなとは思ってたりするぽ。

んでもスネークとキャメル入り乱れるのも混乱の元かなぁという気もするし。
かといって、どちらかに統一するって話になると、どっちもそれぞれメリット・デメリットある感じだったりするので。

ＩＤＥ上では最後まで自分でタイプすることは稀で、入力候補から選ぶのが普通なので、タイピングの手間的には、大文字も下線もわりとどーでも良い感じかと。


Ｃ＃なんかはクラスも関数もみんなパスカル表記がデフォっぽいんだよなぁ。

でもあっちはソースの先頭に使う分のネームスペースをusingしちゃえばいいので。

Ｃ++の方は気軽にusing出来ないんですよね。ファイルスコープまたいだりとか、あとヘッダ(.h)とソース（.cpp）でもusing namespaceの有効範囲が変わったりするので厄介。
ヘッダの読み込み順（定義の順番）とかも考えなきゃいけないし。

namespaeで括るのが当たり前になったんなら、そのへんもＣ＃の様な感じで使える用になるといいんだけどなぁ。
ついでにこれまたＣ＃のようにヘッダの依存関係とか気にしないで済む用にもｗ
その辺ｃ++、namespaceで括るのが当たり前になったのに、使いにくさが目立つ部分だったりして。

とかいう愚痴はおいといてｗ

問題は、コーディング規約は規約の内容よりも、プロジェクト全体でキチンと守られているか、と言うことの方が重要だったりするので、一度決めた規約を途中でやっぱこうした方がよかったなーとか思っても、修正量を考えるとなかなか移行出来なかったするぽ。
中途半端についつい部分的に違う規約を適用しちゃったりし出すとカオスになるしｗ

そんなかんじなので、1からリファクタリングとかするときには規約の見直ができうるタイミングだったりするのだけど。
うんうん悩んでばっかりだとちっとも作業進まないんだよなぁ。

どないしょ。