キノコタケノコ論争、終わりがないですよね。
タケノコの方が優勢だそうですが、わたしはキノコ派です。
でも最近、タケノコの良さもあるな…と浮気しそうです。
結果、どちらの派閥からも煙たがられるでしょう。
プログラマ界隈では、「タブは実際のタブかスペースか、どちらが適切か」なんて事が論争になったりします。
わたしは長いこと実際のタブ（４文字分）派でしたが、色々あってスペース派でいいかな、と思うようになりました。これもまた、どちらの派閥からも煙たがられそうです…。
待ってください！ その前に、わたしの言い訳を！
サイトにコードを載せる時、思ったんですね。
他の方がソースを丸ごとコピーした時、４タブじゃない人はズレが結構煩わしくなってしまうな…と。
他にも Visual Studio がスペースタブを年々強めに押してくるので諦めた、なんてのもありますが（笑）
スペースだとアライメントを合わせる時、悩まないのもいいですね！
Code alignment が、より身近な存在になりました。
このように、今まで自分が良し、としなかった方法も、いざやってみると利点があったりするものです。
そこで、わたしがいつも漫然と行っている C# の「コーディング規約っぽいもの」も、その利点と共に紹介してみようと思いました。
ご笑覧いただければ、幸いです。
本人が守ってないケースもたまにあるので、「ぽいもの」としておきます。
private はつけない
のっけから御叱りを受けそうなスタイルですが、C# はデフォルトが private なんですよね。
なので、記述が楽な「省略」を選んでいます。文字が少ない方がスッキリ！
同じような理由で var も好きです。わりと。
private string stringValue = "string value"; ↓ string stringValue = "string value";
「メソッド内の auto 変数と区別は…？」と思われるかもしれませんが、そもそもオート変数を書くような場所に private 宣言をすることがないので、実害はないかなぁ、と思っています。
{} の列を合わせたい
コードをご覧ください。わたしはこう書いています。
// お手本の書き方
foreach (var blist in alllists) {
AssetBundleBuild bundle = blist.Build;
}
// わたしの書き方
foreach (var blist in alllists)
{
AssetBundleBuild bundle = blist.Build;
}
プログラマ初心者の頃、お手本のようにしててよく中括弧の数が合わなくなったんですよねー。
それを避けるために編み出したのがこの書き方でした。
行数が多い = 悪と考えるコーダーや、行数によって金額を算出する会社には不評を買うことでしょう。
番外編ですが、以下のコードは混乱して、わたしには無理デシタ。
列を合わせる、という意味では確かに理にかなっている。
// 番外編：友人がやってた（凄腕プログラマの方）
foreach (var blist in alllists)
{
AssetBundleBuild bundle = blist.Build;
}
public 変数は頭文字を大文字、それ以外は頭文字を小文字
これは人によって、会社によって、言語の推奨などもあったり、千差万別ですよね。
なお、public だけ書きましたが、厳密には protected と internal も大文字です。クラス外からアクセスできるなら大文字、と言った方が適切でしょうか。
これも一般的ではありませんが、C# を始めた頃になんとなく決めた自分ルールをいまだに使っています。パッと見てわかるし、結構使い勝手いいんです。
int privateValue;
public int PublicValue;
void privateMethod() {}
public void PublicMethod() {}
private 変数は、こんな書き方を見かけることもありますね。
これらも、一目見てわかりやすいです。変数は必ず小文字スタートという縛りがあったとしたら、わたしも使っていたかもしれません。
int m_privateValue; int privateValue_;
なんとなく、小文字の方がかっこいいイメージが（界隈に）あると思うのですが、あれはなんでだろう
なお、オート変数の場合全て小文字で、ワード間を _ で区切るようにしています。
が、ここは private と同じ書き方にしてしまう事も多いですね…。自分の中で、区別する有用性をあまり感じていないんだと思います。
{
int auto_value = 0;
}
const は全て大文字で
これもパッと見てわかりやすくて好きです。ワード間を _ で区切ります。
const string VERY_LONG_STRING = "";
/// コメントはなるべくつける。public の場合ほぼ必須でつける
Visual Studio ではメソッドの上で /// と入れると自動的にコメントが入るので、これはなるべく記述するようにしています。
ただ、後で自分が困らない程度に留め、引数まで細かく記述するのは稀です。
（あまりきちんとやろうとすると、結局面倒でコメント自身を書かなくなった過去の教訓です）
/// <summary>
/// Get Real Name
/// - 実際のアセットバンドル名（暗号化した場合、その名前）を返します
/// </summary>
public static string GetName(string bundlename) {}
コメントは本当に必要な所にすべき
確かにその通り。ただ、残念なことに「本当に必要な所」が、人のプログラミングスキルによって異なるところですね…。
そのせいで、（有無の）議論が平行線になることもしばしば。
わたしは /// コメントが出来る箇所はなるべくつけて、それ以外は半年後、自分コードを見た時「なにこれ？」と思いそうな部分にコメントを入れています。
たまに「コメントは完全不要」と仰る方もいますが、そこまでストイックだとわたしは辛いですね…。
// 後でわからなくなる例
deleteFiles = deleteFiles
// 1.余計なディレクトリ消す 2.\\->/ 3.[.manifest]消す
.Select( (a) => a = a.Remove(0, a.IndexOf('\\')+1).Replace("\\", "/").Replace(".manifest", "") )
// StreamingAssets は管理ファイルなので除外
.Where( (a) => a.IndexOf("StreamingAssets") < 0 )
.ToArray();
名前付けで悩まない。後で「名前の変更」をすればいい
これはルールではありませんが、プロの環境でも知らない人がいたので一応触れておきます。
変更したい変数やメソッドの上で F2、もしくは 右クリック - 名前の変更。
名前を変えて Enter で決定、Escape でキャンセルです。
名前を参照しているものも含め、全て置き換わります。grep 置換よりも安全です。
対処に困った会社ルール
public int AKC0030001;
private int AKC0030012;
void AKB000100()
{
if (AKC0030012 == 3)
{
AKB000103(AKC0030001, AKC0030012);
}
}
お役所系の仕事をすると、こんなコード規約に縛られることがあります。
セルフ難読化…？
これの名前と機能対応表が別の設計書にありましたが、そちらは見事に途中で更新が止まっており、理解を更に難しいものにしていました。
いくらなんでも今はないでしょ！ と思うかもしれませんが、確定申告用のXMLテンプレートなどを国税庁からダウンロードすれば、まだ全然現役選手であることがうかがい知れます。
ルールはどのくらい厳密にするべきか
それなりにデキル人たちが集っているのであれば、極端な話ソースコード毎になんとなく統一されていれば、読むのに困ることはないのかもしれません。
最初とっつき辛くても、３日もすれば慣れるでしょう。
ただ「ルールも何もよくわからない」「なぜ統一するべきなのか理解できない」といったレベルのコーダーがメンバーにいる場合、社内統一ルールを作った方がよさそうですね。
ルールを決める場合は「できるだけ覚えることが少なく」「そのルールに則ると簡単になる」事が望ましいですね！
