コードレビュー依頼前チェックシート

毎度確認漏れがあるため備忘録として

## 目次
<details><summary>クラス・メソッド</summary>

1\. 名前は適切か
2\. DocStringが記述してあるか
3\. 修飾子は正しいか
4\. 早期リターンしているか
5\. デバッグ用のコードは残っていないか
6\. リテラルは残っていないか
7\. 機能を分割できないか

</details>
<details><summary>変数</summary>

1\. 名前は適切か
2\. 型は適切か

</details>
<details><summary>コメント</summary>

1\. 意味のないコメントはないか
2\. TODOコメントは残っていないか
</details>
<details><summary>その他</summary>

1\. インデントは揃っているか
2\. 警告・コンパイルエラーは出ていないか
</details>



## クラス・メソッド
#### 1\. 名前は適切か
###### 1-1\.言語の命名規則に則しているか
* JavaとPythonをよく使うのでこの2つのみ

<details><summary><captipn >Java：
キャメルケース </captipn></summary>

| 分類| 1文字目|2つ目以降の単語の頭文字 |例|
|:-:|:-:|:-:|:-:|
|  クラス・インターフェース | 大文字  | 大文字  |HogeClass|
| メソッド |  小文字 | 大文字|hogeFunc|
</details>

<details><summary><captipn >Python：
スネークケースとキャメルケース</captipn></summary>

| 分類| 1文字目|2つ目以降の単語の頭文字 |例|
|:-:|:-:|:-:|:-:|
|  クラス・例外・型変数 | 大文字  | 大文字  |HogeClass|
| メソッド  |  小文字 | 小文字+アンダースコア|hoge_func|
</details>

###### 1-2\.役割が名前から読み取ることができるか
例えば2つの引数を加算した結果を返すメソッドがあるとする
```python:add.py
def result(a:int,b:int) -> int:
    return a + b
#名前以外同じ
def add_num(a:int,b:int) -> int:
    return a + b
```
resultは名前だけだと何をするのかわからない
機能がわかる名前をつけることで可読性が向上する

#### 2\. DocStringが記述してあるか
機能を表すDocStringは全てのクラス・メソッドに記述する
<details><summary>Java</summary>

```Java:docString.java
/**
* 概要
* @param   パラメータ
* @return　戻り値
*/
private int addNum(int a, int b){
    return a + b;
}
```
</details>
<details><summary>Python</summary>

```python:docString.py
def result(a:int,b:int) -> int:
    """概要：2つの引数を加算した結果を返す
    詳細
    パラメータ
    """
    return a + b
```
</details>

#### 3\. 修飾子は正しいか
自クラスでしか使っていないメソッドに`public`がついている場合はprivateに直す

#### 4\. 早期リターンしているか
処理をしないパターンにマッチした場合、早期に値を返すことで可読性が向上する
</details>
<details><summary>Python</summary>
テキトーだがこんな感じ

```python:add_diff_num.py
def add_diff_num(a:int,b:int) -> int:
    """aとbが異なる場合に加算する
    """
    if a == b:return a
    
    return a + b
```
</details>

#### 5\. デバッグ用のコードは残っていないか
Pythonなら`print`、Javaなら`System.out.println`など本処理には関係ない値を確認するコードがあれば削除する

#### 6\. リテラルは残っていないか
<details><summary>プログラム上の素の文字列や数値をリテラルと呼ぶ
</summary>

```python:sample.py
a = 1
str = 'リテラル'
```
</details>
リテラルが残っていると変更が生じた際に膨大なコードからそれらを見つけ出さなければならない。
生産性低下の要因になるため、定数化を試みる


#### 7\. 機能を分割できないか
1つのメソッドで複数の処理を行っているなら、切り分けた方が良い。
* モジュールの結合度が下がり、再利用性が向上する。
* 機能が明確になり命名しやすくなる


## 変数
##### 1\. 名前は適切か
###### 1-1\.言語の命名規則に則しているか
<details><summary><captipn >Java：
基本的にキャメルケース
定数のみスネークケースかつ全て大文字 </captipn></summary>

| 分類| 1文字目|2つ目以降の単語の頭文字 |例|
|:-:|:-:|:-:|:-:|
| 変数 |  小文字 | 大文字|hogeHoge|
| 定数  | 大文字  | 大文字＋アンダースコア  |HOGE_CONST|
</details>

<details><summary><captipn >Python：
スネークケース</captipn></summary>

| 分類| 1文字目|2つ目以降の単語の頭文字 |例|
|:-:|:-:|:-:|:-:|
| 変数  |  小文字 | 小文字+アンダースコア|hoge_hoge|
| 定数  | 大文字  | 大文字＋アンダースコア  |HOGE_CONST|
</details>


###### 1-2\.役割が名前から読み取ることができるか
変数が格納しているデータが変数名から読み取ることができればよい
また、生存時間が非常に狭い(2,3行だけしか使わない)場合は、短い名前をつけても問題ない

##### 2\. 型は適切か
1つの値やインスタンスしか返していないのにリストで受け取るなどの処理をしていないか

## コメント
##### 1\. 意味のないコメントはないか
* コードを読めば理解できるものをわざわざ書いていないか
* 現在使用していないコードをコメントアウトして残していないか
* もしあれば消す
##### 2\. TODOコメントは残っていないか
TODOコメントはIDEの機能で残っているか確認できる
* eclipse：ウィンドウ→ビューの表示→タスク
* VScode：拡張機能「TODO Tree」を使用する

## その他
##### 1\. インデントは揃っているか
見た目は可読性に関わるため揃えた方がよい
##### 2\. 警告・コンパイルエラーは出ていないか
これらが出ているということは、修正すべき箇所があるということ