C++/ObjC/swift コーディング規約

私が考えるC++/ObjC/swift についてのコーディング規約です。

基本的にコーディング規約はプロジェクトの生産性を最大化するのが目的であり、厳しすぎず、ゆる過ぎないものにするべきです。
以下、箇条書きにしていきます。

守るべき規約

定数は先頭に k のプレフィックスをつける(C++/ObjC)

例: kBlockCount

swiftにおいては定数にはstatic letやenumを使うため、明示的につけない方がいいようです。

プライペートなインスタンス変数にはアンダースコア(_)のプレフィックスをつける(C++/ObjC/swift)

swiftにおいては、プライベートでないインスタンス変数は外部からドットを使って参照しますので、アンダースコアはつけません。

if, else if, else 文のカーリーブレース({})は省略しない(C++/ObjC)

脆弱性を埋め込みやすいので、省略しないようにします。ブレースが省略されていなかったら、Heartbleedの脆弱性（ハートブリード - Wikipedia）は発生していなかったかもしれません。

enumを使う代わりに typedef NS_ENUM を使う(ObjC)

swift から利用するにはNS_ENUMで定義しておく必要があります。

malloc, free を使わず NSObject を継承したオブジェクトを利用する(ObjC)

NSObjectにしておくことでswiftから使いやすくなります。

assertとエラー処理を適切に使い分ける(C++/ObjC/swift)

assertを正しく使うには、ある程度の経験が必要です。 assertはそれが満たされていない場合、アプリをクラッシュさせてよいというほど、絶対に起きない箇所に用います。 それ以外の場所では、エラー処理を入れておかなくてはなりません。

インスタンス変数を使っていない関数はstaticメソッドにする(C++/ObjC/swift)

無駄な依存関係を埋め込まないために行います。

デバッグログ出力は異常ケースでのみ行い、正常ケースでは出さないようにしておく

正常ケースでデバッグログが出力されてると異常がおきていることを見逃しやすくなります。正常ケースで残したいデバッグログは、コメントアウトしておくか、ログレベルを設定できるロガーを作って、レベルを info にしておきます。

コピペしないといけないソースコメントは作らない

例えば、こういうソースコメントをつけてはいけません。

/*************
 *
 ************/

これならコピペせずにかけるのでOKです。

/**
 *
 */

守らないべき規約

不必要な規約は入れないようにします。

カーリーブレースの位置は自由

段落のタブ下げがあってさえ入れば、どこにいれても、それほど可読性は変わりません。

コメントの書き方は基本的に自由

将来の自分にとって役に立つコメントを残しましょう。Doxygenなどのドキュメント生成ツールを使ってドキュメントを残すのでない限りフォーマットを統一するメリットはありません。

[改訂第3版]C++ポケットリファレンス (POCKET REFERENCE)

Effective Modern C++ ―C++11/14プログラムを進化させる42項目