コーディング規約（保存版）

# <b>コーディングの重視ポイント</b>

◼　見やすさ・わかりやすさを重視する
◼　ネーミングはわかりやすくする
◼　理解しないコードを使わない
◼　同じコードを二度書かない（DRY →　Don't report yourseff）
◼　役割の単一化
◼　保守性優先
◼　CheckStyle厳守

## 参考

- [CleanCode](https://www.slideshare.net/wakaleo/clean-codingpractices?from_action=save)

- [OracleCodeConventions](http://www.oracle.com/technetwork/java/codeconventions-150003.pdf)

- [GoogleJavaStyleGuide](https://kazurof.github.io/GoogleJavaStyle-ja/)

- [SunCodeConventions](https://future-architect.github.io/coding-standards/documents/forJava/Java%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E8%A6%8F%E7%B4%84.html)

 
# <b>ネーミングの規約</b>
## 2.1 名前決定方針

- 統一名称を用いる
    - 例： find, change, update, new, contains, exits...    
  
- 目的が逆関数に対して、ペアになってる言葉を使用する
    - add/remove
    - start/stop
    - begin/end
    - up/down
    - previous/next
    - forward/backward
    - push/pop
    - before/after
    
- わかりやすい単語を使う。意味が曖昧単語をできるだけ使わない
    - compare：比較という意味だが、比較結果がわかりづらい。isSmaller, isBigger...等を検討すべし
    - toggle：状態を入れ替えるという意味だが、turnOff, turnOn等の単語使ったほうがわかりやすい


## 2.2  全般
- 大文字・小文字で区別しない
- JDK標準に存在している名前を使用しない
- 名詞に含まれる単語はできるだけ省略しない。
    - なぜなら：勘違い・意味分からないことを避けたいからだ


　悪い例：

```
private int number;
private int Number;
```



## 2.3 パッケージ名
- 全て小文字にする。アンダースコア使わない
    - 例：
        - GOOD: `com.jp.examplejava`
        - BAD: `com.jp.example_java`,  `com.jp.exampleJava`
- パッケージ名を読んですぐ意味理解できるようにする

## 2.4 クラス
UpperCamelCase使用

- 先頭を大文字
- それ以外は小文字
- 言葉の区切りは大文字

例:

```
- MainActivity
- LoginAction
```

- 内部クラス基本使用禁止
    - なぜなら：再利用性・可読性を損なうからだ

- abstractクラスに関してはAbstractをつけること
    - 例：`AbstractSample`

## 2.5 メソッド
### ■一般
lowCameCase使用

- 先頭を小文字
- 以降も小文字
- 言葉の区切りは大文字
- 予約語ではない英単語と略語を組み合わせることが多い
- 簡単・小さいメソッドが望ましい
- 一つのメソッドに一つの役割しか持たない
- 深いネスト避ける

例：

```
- registerViaGoogleId()
- getCountLoggedInUser()
```

### ■Boolean型の戻り値
- is + 形容詞  
    - 例：`isActiveUser`

- has + 過去分詞
    - 例：`hasFavoriteContents`

- can + 動詞
    - 例：`canAccess`

### ■Getter/Setter
- get/setメソッドはクラスの一番下に記入する
- IDEに自動生成に任せいる 

### ■ファクトリメソッド
- create + オブジェクト名
    - 例：`createAppUser()`

### ■CRUD系
- データ操作に関するメソッドは命令規則を統一する
    - insert
    - update
    - delete
    - findById
    - findByName
    - findAll 

## 2.6 定数
- すべて大文字
- アンダースコアで結合

## 2.7 フィールド
- 全て小文字
- 複合文字の場合は区切りを大文字する
- 変数名を見てデータの中身を想像できる
- Romaji使用しない
- finalのstaticではない変数を避ける 
- 親クラスで定義されているフィールドと同じ名前のフィールドを定義しない
- ループの変数も明確に記入したほうが良い

    ```
    for(int index; index < length; index ++ )
    ```

## 2.8 フォーマット
-  一行の最大文字数は80文字以内を収めるべし
- 改行
    - 開始中括弧の前に改行を入れない。
    - 開始中括弧の後に改行を入れる。
    - 終了中括弧の前に改行を入れる。
    - 終了中括弧の後に改行を入れる。
        - 但し、終了中括弧が文やメソッドの本体を終える時のみである。
        - 例えば終了中括弧の後に else や、カンマが続く場合は改行をしない。

- 1行に2つ以上のステートメントを記載しない
    
# <b>実装関連</b>
## 3.1 Switch分
- defaultが必須
- フォールスルー（複数値に対して同じ処理をする）を極力使わない。バグの元になるかだ。
- nullは分岐条件の値に指定できないので、switch分入る前にnull check する必要がある

例：

```
int value = 0;
switch (value) {
case 0:
case 10:
	// 処理1
	break;
default:
	// 処理2
}
```

## 3.2 Try Catch 
- キャッチされた例外は無視しない
- 明記なExceptionをCatchすべき
    - DAOException, NullPointerException, ParseExceptionなど

## 3.3 Staticメンバーの取扱
- staticメンバーを修飾する必要がある場合はクラス名を使う

# <b>JavaDoc</b>

- public なクラスとそのクラスの public 、 protected なメンバーに書かれる。
- OverrideするメソッドはJavaDoc必須ではない
- メソッド名で用途判断できる簡単なメソッドは必須でない
- Javadocにクラスの目的・責務を記載する
- 更新履歴は記載しない
- 作成者情報は記載しない（@authorタグを記載しない）

# <b>そのた</b>
## 5.1 TODO管理
- コーディング終了時に全て消しておく
- 
- 必要に応じてタスク切る

## 5.2 フォーマット
- IDEのコードフォマットに従う

## 5.3 コーディング

- 最新JDKの機能を積極的に使う
    -  Lambda Expressions, Stream ...

- DeadCode残さない
    - 既存の場合、解消する（十分検証が必要）