スマートテック・ベンチャーズ プログラミングガイドライン

バージョン

v1.0.0

はじめに

本プログラミングガイドは、よりよいプログラミングをするためのポイントをまとめたものです。
iOS/Androidのネイティブアプリでのプログラミングを対象としています。

目次

1. クラス、メソッド、変数の役割はひとつにしよう

2. 読みやすいコードを書こう

3. 同じコードを繰り返して書かないようにしよう

4. 良質なコメントは他者のため、未来の自分のため

5. 分岐の少ないシンプルなコード

6. 役割のわかるネーミング

7. レビューは積極的にしてもらおう

8. 自分 → 親 → 先祖 → 人間　共通点は何だろう？

9. スコープが小さいと無駄も小さい

10. コードレスUI

1.クラス、メソッド、変数の役割はひとつにしよう

説明

ひとつのクラス、メソッド、変数の役割はひとつにしましょう。
→単一責任原則 (Single Responsibility Principle :SRP)
ひとつのものに複数の役割を持たせてしまっている場合は、
中身を分割して役割をひとつにしましょう。

非推奨

class HogeFugaClass {
    変数ABCD

    func hogeFuga {
        // 処理A

        // 処理B

        // 処理C

        // 処理D

    }
}

推奨

class HogeClass {
    変数A
    変数B

    func hoge {
        // 処理A
    }

    func fuga {
        // 処理B
    }
}

class FugaClass {
    変数C
    変数D

    func hogeHoge {
        // 処理C
    }

    func fugaFuga {
        // 処理D
    }
}

理由

• シンプルなコードになるため。
• 疎結合なコードにできるため。
• 保守性が高まるため。

2.読みやすいコードを書こう

説明

他の人が見てもわかりやすい（可読性の高い）コードを書きましょう。
他の人とは、レビュアーやチームメンバーだけでなく、「6ヶ月後の自分自身」も含みます。
思いやりの心はコーディングにも必要です。
コードを短くすることは大切ですが、読みさすさを最優先としましょう。

＜例：マジックナンバー＞

非推奨

if self.money >= 100 {
    // 商品を購入する処理
}

推奨

// 商品の値段
let goodsPrice = 100

if self.money >= goodsPrice {
    // 商品を購入する処理
}

上のコードは「100円以上もっていたら商品を購入する」ものです。
非推奨のコードのほうが短いですが、初見（あるいは6ヶ月後の自分）では「100って何？」となります。
if文内を読んでようやく商品の値段だったことを理解します。
推奨コードのように商品の値段を表す定数や変数を用意したほうが読みやすいですよね。

理由

• 開発の効率化に繋がる（読みにくいと効率が悪い）

3.同じコードを繰り返して書かないようにしよう

説明

何も考えずにコピペをすると粗悪なコードになっていく可能性が高いので、
コードをコピペして、違う箇所に流用しようとしたら以下を検討しましょう。

• 既存メソッドを再利用できないのか？
• 別のメソッドやクラスに切り出せないか？
• コピペをした後に変更が発生した場合、コピペ元のコード変更も発生しないか？

→DRY（Don't Repeat Yourself）

自分以外の人も保守しやすい疎結合なコードを書くようにしましょう。

＜例：処理毎にログインチェックが必要な場合＞

非推奨

func hoge {
    // ログインチェック処理ベタ書き

    // 処理A
}

func fuga {
    // hogeメソッドのログインチェック処理をコピペ

    // 処理B
}

推奨

func isLogin {
    // ログインチェック処理
}

func hoge {
    // isLogInメソッドを呼び出してログインチェック

    // 処理A
}

func fuga {
    // isLogInメソッドを呼び出してログインチェック

    // 処理B
}

理由

• 単純に何も考えずにコピペでコードを増やすと、不必要なコードが増えるため。
• 密結合のコードが増えて、保守性が低いコードになるため。
• コードが長くなるため。

4.良質なコメントは他者のため、未来の自分のため

説明

コメントは、複雑なロジックや曖昧なコードをわかりやすく説明するために必要なものです。
コメントを記載することでコード理解の助けになりますが、
誰が読んでも理解できるよう適切なコメントを記載しなければ
余計に難読なコードになってしまいます。

自分だけが理解できる曖昧なコメントではなく、
他者のため、そして未来の自分のためにも
誰が見ても同じ解釈ができる良質なコメントを書きましょう。

コメントが多過ぎると、全体の見通しが悪くなってしまうので
正しい内容のコメントを見やすく残すために以下を注意しましょう。

• （※）どうしてその処理をするのかという、理由をコメントにすることを意識する
• 1行毎の説明をするコメントは記載しない。
• 変数を説明するコメントは記載しない。
  (変数の役割がわかる命名をすることでコメントは不要になります。)
• マジックナンバーを説明するコメントは記載しない。
  (役割がわかる命名で定数や変数として定義することでコメントは不要になります。)
• 不要になったコードはコメントアウトで残さず削除する。
• 「2016-xx-xx 〇〇機能を追加」のようなコードの編集履歴をコメントで記載しない。
• 既存コードを修正した際には、コメントも削除や修正をする必要があるかどうかその都度確認する。

理由

• 可読性が高まるため。
• （※）その処理が何をしているかは、命名によりある程度カバーできるのに対し、
  なぜそういう処理をするかについてはコーディングではカバーできないため

5.分岐の少ないシンプルなコード

説明

if～else文, switch文, for文などで分岐をすればするほど
コードの品質を低下させてしまう恐れがあるので分岐は最小限にすべきです。
分岐が多くならないために以下を注意しましょう。

• ループの中に分岐要因がある場合、別のメソッドに切り出せないか。
• 早期リターンでelse句を無くせないか。

非推奨

// ループの中に分岐がある例
func hogeHoge {
     for 条件a {
        if 条件b {
            for 条件c {
                // 処理A
            }
        }

        // 処理B
    }
}

// 早期リターンにできる例
func hogeFuga {
    if isHoge {
        // 処理Z  
    } else {
        return
    }  
}

推奨

// ループの中の分岐を別メソッドに切り出す例
func hoge {
    if 条件b {
        for 条件c {
            // 処理A
        }
    }
}

func fuga {
    for 条件a {
        // hogeメソッド呼び出し

        // 処理B
    }
}


// 早期リターンの例
func hogeFuga {
    if isNotHoge {
        return
    }
}

理由

• テストを実施する際に分岐を網羅することが困難になり、バグを見逃してしまう恐れがあるため。
• ネストが深くなってしまい、難読なコードになってしまうため。

6.役割のわかるネーミング

説明

役割のわかる命名をすると、コード全体を理解しやすくなります。 何をするクラスなのか、何をするメソッドなのか、何のための変数や定数なのか 名前を見ただけでその処理の概要を知ることができるよう命名しましょう。

＜例：ボタンの変数名＞

非推奨

// 何をするボタンか、名前からわからない
btn1
btn2
btn3

推奨

// 何をするボタンか、名前からわかる
loginButton
cancelButton
logoutButton

理由

• 可読性が高まるため。

7.レビューは積極的にしてもらおう

説明

「うぬぼれ」や「プライド」を捨て、仲間に協力を求めて、よりよいコードを書くように努めましょう。
積極的に第三者からのソースレビューを受けて、品質を高めるようにしてください。
自分の能力のアピールではなく、コードがよりよくなることにフォーカスしましょう。
どれほど極めたと思っていても、上には上がいます。
自分自身もミスをするということを理解し、受け入れましょう。

理由

• 独りよがりのエンジニアになると、よりよいコードが書けなくなるため。
• 自分だけの視点よりも複数の視点があることで、よりよいコードに成長するため。
• 独りよがりのエンジニアは、自己満足で終わり本当の成長がないため。

8.自分 → 親 → 先祖 → 人間　共通点は何だろう？

説明

クラスやメソッドを作成するときは、共通化できるところは極力共通化しましょう。
それぞれのプロパティやメソッドから同じ性質のものを抽出していく作業を抽象化といいます。
クラスやメソッドを抽象化することで、コードの再利用が可能になります。

例えば、
　自分：目、鼻、口、耳などの体がある。職業：エンジニア
　親　：目、鼻、口、耳などの体がある。職業：大工
　先祖：目、鼻、口、耳などの体がある。職業：農家
　人間：目、鼻、口、耳などの体がある。職業：人によって違う

自分を抽象化すると、人間。
　人間：体がある。　←　自分を抽象化した結果。

理由

• 汎用的なコードにできるため。
• 疎結合なコードにできるため。
• コードを小さく保てるため。

9.スコープが小さいと無駄も小さい

説明

クラス、メソッド、変数のスコープをより小さくするようにしましょう。

＜例：可能な限りローカル変数を使う＞

非推奨

class LargeClass {
	let hoge: String

	func method1() {
		hoge = "fuga"
		method2()
	}

	func method2() {
		hoge = "hogehoge"
	}

	// hogeを使っていないメソッドがたくさんある
	// hogeの存在は常に気にしている必要がある
}

推奨

class LargeClass {
	func method1 {
		let hoge = "fuga"
	}

	func method2 {
		hoge = "hogehoge"
	}

	// hogeを使っていないメソッドがたくさんある
	// その他のメソッドからはhogeが見えない = hogeのことは考えなくていい
}

理由

• スコープが小さいと影響範囲も小さくなるため
• 考慮する範囲が小さいと可読性が高まるため

10.コードレスUI

説明

静的なUIの実装は可能な限りコーディングせずに作りましょう。

理由

• コード量が減り、 可読性が高まるため