using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class #SCRIPTNAME# : MonoBehaviour
{
// ---------------------------------------------
// MonoBehaviour
// ---------------------------------------------
halneko halneko5121
- ◎ コミットする際は、レビューする側の立場に立つ。
- 他の人が見て／自分が後から見てわかるように。
- エラーが発生した時の手がかりになるように
- ◎ 色々な作業が混ざったコミットをしない。
- ◯ 細かい単位でコミットしていく
- 5分、10分単位とか、1作業ごととか
- 細かい方が変更を追いやすい（不具合の原因も追いやすい）
- ◎ エラーメッセージ等は、わかりやすいメッセージを日本語で出すのが基本
- ◎ デバッグコマンドを勝手に入れない
- 知らない間にデバッグコマンドが入っていて、それがバグの原因だった……というのを避けるため
- みんながよく使う機能は wiki 等で全体にお知らせする。
- コンストラクタ
- ◎ クラスのメンバ変数は、必ずコンストラクタで全て初期化する。
- 初期化子リストを使う（メンバ変数の定義順に初期化される事に注意！）
- ◎ クラスのメンバ変数は、必ずコンストラクタで全て初期化する。
- 継承
- ◎ 多重継承は原則禁止（インターフェースクラスは多重継承してもよい）
- ◯ 継承は深くなりすぎないようにする
- 機能を足す時は継承ではなく移譲で作っていくようにする（Util等 を作る※1）
※1
- ◎ 角度を用いる時は、radian / degree どちらか明記する。
- ◯ 他の人のソースを触る時は、その人の書式に合わせると親切。
- ◯ ネストは最大でも３段階。
- ◯ ブロック内のコードは最大でも５０行程度にする。
- ◯ cpp は 1000 行くらいを目安に。
- ◯ 独自 Util があちこちに散らばらないように。
- △ 帰宅、休憩前のコミットはできるだけ避ける。特に急ぐ理由がなければ後で。
| プレフィックス | 内容 | バグに繋がる可能性 |
|---|---|---|
| add | 新規（ファイル）機能追加 | 大 |
| update | 機能修正（バグではない） | 大 |
| bugfix | バグ修正 | 中 |
| clean | コード整理（リファクタリング等） | 中 |
| adjust | 調整（パラメ―タ等） | 小 |
| delete | 機能（ファイル）削除 | 小 |
| revert | 変更取り消し | 内容による |
| プレフィックス | 内容 |
|---|---|
| add | 新規（ファイル）機能追加 |
| update | 機能修正（バグではない） |
| clean | コード整理（リファクタリング等） |
| adjust | 調整（パラメ―タ等） |
| bugfix | バグ修正 |
| delete | 機能（ファイル）削除 |
| revert | 変更取り消し |
-
◎ 丁寧なコメントを長々と書くぐらいなら、リファクタリングを検討する。
-
◎ 後で見直したいコード中のメモは「@todo_xxxx」のような書式に統一する。
- 備忘録としても使えるし、他の人がコードを見た時わかりやすいので
-
○ ファイルの先頭には、どういうファイルなのか、をコメントで説明を書く
-
△ 関数や定数には、必ずコメントを書く。
- 関数の場合、処理内容、引数、返り値の説明をつける（引数、返り値の説明はわかりにくい場合のみで可）
- 基本、関数名や引数名の名前から、機能を判断できるようにするのが望ましい
- ◎「using namespace」をヘッダに書かない。
- include したファイル全体にその宣言の影響が出てしまうため。
- cpp で using すれば回避可能。
| 準拠レベル | 内容 | 備考 |
|---|---|---|
| ◎ | 不要なヘッダファイルをインクルードしない。前方参照で済むところは前方参照にする（メンバはポインタで持ち、前方宣言） | ビルド時間を増やさないため |
| ◎ | 自分と同名のヘッダを先頭にする | ヘッダの順番によって、前方宣言が不要になる事を防ぐ |
NewerOlder