100日後にエンジニアになるキミ - 47日目 - プログラミング - コーディング規約

昨日までのはこちら

[100日後にエンジニアになるキミ - 42日目 - クラウド - クラウドサービスについて](https://qiita.com/otupy/items/d1765f1541a104ed6133)

[100日後にエンジニアになるキミ - 36日目 - データベース - データベースについて](https://qiita.com/otupy/items/7af17635d576677606dc)

[100日後にエンジニアになるキミ - 24日目 - Python - Python言語の基礎1](https://qiita.com/otupy/items/6d1e5453f530e07b7aec)

[100日後にエンジニアになるキミ - 18日目 - Javascript - JavaScriptの基礎1](https://qiita.com/otupy/items/2f71d5f9c754b29d9555)

[100日後にエンジニアになるキミ - 14日目 - CSS - CSSの基礎1](https://qiita.com/otupy/items/61a97863f6df14171994)

[100日後にエンジニアになるキミ - 6日目 - HTML - HTMLの基礎1](https://qiita.com/otupy/items/cd2315dcb38671cfded0)


## コーディング規約とは

コーディング規約とはプログラムや情報システムを作る時に、
プログラマたちが守るよう決められたルールのことでプログラムをどう作るべきかという取り決めのことです。

コーディング規約の大きな目的は「保守性」「品質」の確保になります。

有名なところだと下記のような言語向けのコーディング規約が存在します。

**PEAR(PHP)**
https://pear.php.net/

**pep8(Python)**
https://pep8-ja.readthedocs.io/ja/latest/

これとは別にシステム作成者の側での独自のコーディング規約を定めることもあります。
必ずしも規約に準拠しなければいけない訳ではありませんが、プログラムの品質を上げるためには
ある程度規約に沿ったコーディングを求める必要があります。

## 主なコーディングのルールについて

### 変数、関数、クラス、メソッドの命名規則

まずは命名規則のルールを定めた方が良いでしょう。

**変数、関数、メソッド、モジュール**
小文字の英単語をアンダースコアで区切る
`lower_case_word_and_underscore`

**クラス名**
先頭だけ大文字の英単語を繋げる、アンダースコアは使わない
`ClassName`

**プライベート変数・プライベートメソッド**
変数名やメソッド名の前にアンダースコア
`_private_variables`

**定数**
大文字の英単語をアンダースコアで区切る
`UPPER_CASE_WORDS_AND_UNDERSCORES`

**パッケージ名**
小文字のみ(1単語がベターかも、造語でもOK)
`lowords`



### 命名方法

命名方法に関しては変数であればどんなデータが入っているのか
関数などであればどのような処理をするかが分かるような英単語を用いましょう。

**記述順番**

簡易変数であっても逆記法を使うと読みやすく、書き直しやすくなると思います。
変わる部分を後に持ってきます。

```python
# 好ましくない例
1_point
2_point
3_point
```

```python
# 好ましい例
point_1
point_2
point_3
```

**使う品詞**

プログラムの性質上、動詞だけ、名詞だけだと意味合いがおかしく感じてしまいます。
適切な品詞を使用した方が好ましいです。

***クラス名,変数名***
名詞にする ：`magic_point`

***メソッド,関数***
動詞から始める ：`get_wild`

***真偽値（boolean型）***
`is + 形容詞` : `is_enabled`

`has + 過去分詞` : `has_sent`

`can + 動詞原型` : `can_get`

`三単現動詞` : `exists`

`三単現動詞 + 名詞` : `exists_error`,`has_error`

`should + 動詞原型` : `should_redirect`


### importの記載順序

`import`の順番はこのようにすると良いようです。

```python

import 標準ライブラリ

import サードパーティ関連（別途installしたやつ）

import 自作ライブラリ

```

**パッケージのimport**

1つずつimportする

```python

import pkg1
import pkg2

```

**モジュールのimport**

モジュールは複数同時でもOK

```python
from pkg import module1 , module2
```

**importの記載の仕方**

モジュールをまるごとimportし、呼び出し側で制御する。

```python
from pkg import module1

class_1 = module1.class1()
```

### docstrings

クラス、メソッド、関数などにはドキュメントを書いてあげると分かりやすくなります。
引数や戻り値、呼び出し方などを明記しておくと非常に使いやすくなります。

```python
class Account:
    """
    クラスの説明書きをする
    """

    def __init__(self , name):
        self.name = name

    def method(self , name):
        """
        メソッドの説明書きを書く
        """

```


### 関数やメソッドの引数

関数やメソッドは引数を取る事ができますが、引数の数が多すぎるのは問題です。
引数の数が10あるような関数を作るのは好ましくありません。

ここは現場のルールによりますが
出来れば数を制限して3-4個、多くても6個程度に収めましょう。

それ以上の引数を用いたい場合は
辞書型やリスト型の引数として渡して関数の中で参照してあげるのがよいでしょう。

```python
# 好ましくない例
def function_plus(a, b, c, d, e, f, g):
    total = a+b+c+d+e+f+g
    return total
```

```python
# 好ましい例
def function_plus(h):
    a = h['a'] 
    ...
    total = a+b+c+d+e+f+g
    return total
```

### コードの文字量

1行に書くコードの長さを制限する事が多いです。
すべての行の長さを、最大XX文字までに制限しましょう。

ここは製作者の側でのルールになりますが概ね72-99文字くらいで改行するケースが多いようです。
変なところで改行するのも読みにくくなります、適切なところで改行して読みやすくします。

```python
# 好ましくないコード：改行が無い
with open('/path/to/some/file/you/want/to/read') as file_1, open('/path/to/some/file/being/written', 'w') as file_2:
    file_2.write(file_1.read())
```

```python
# 好ましいコード
with open('/path/to/some/file/you/want/to/read') as file_1, 
     open('/path/to/some/file/being/written', 'w') as file_2:
    file_2.write(file_1.read())
```

```python
# 好ましくないコード：演算子の位置
income = (gross_wages +
          taxable_interest +
          (dividends - qualified_dividends) -
          ira_deduction -
          student_loan_interest)
```

```python
# 好ましいコード：
income = (gross_wages
          + taxable_interest
          + (dividends - qualified_dividends)
          - ira_deduction
          - student_loan_interest)
```

### 空行

コードを密集させすぎると読みづらくなります。適切に空行を入れて読みやすくしましょう。

### 式や文中の空白文字

コードのどこに空白を入れるかのルールが定まっていないと読み書きが辛くなります。
空白を入れる、入れないを含めた空白書きのルールを定めた方が良いでしょう。

考慮すべき点は以下のようなところです。

`括弧やブラケット、波括弧 のはじめの直後と、終わりの直前`
`末尾のカンマと、その後に続く閉じカッコの間`
`カンマやセミコロン、コロンの直前`

```python
# 好ましく無い例
spam( ham[ 1 ], { eggs: 2 } )

bar = (0, )

if x == 4 : print x , y ; x , y = y , x

```





## まとめ

コーディング規約に完全準拠する必要は無いですが、一定のルールは定めておいたほうが
読みやすくなるし品質も上がるでしょう。

読みにくいコードはこの世から消えるべきです。

一貫性の高いコーディングルールで可読性の高いコードを書くように心がけましょう。


君がエンジニアになるまであと53日

## 作者の情報
乙pyのHP：
http://www.otupy.net/

Youtube：
https://www.youtube.com/channel/UCaT7xpeq8n1G_HcJKKSOXMw

Twitter：
https://twitter.com/otupython