PEP8（命名方法）

Python

一番知りたかったところ。実装時にここに最も頭を使います。

原則

  • 公開されている API の一部としてユーザーに見える名前は、実装よりも使い方を反映した名前にすべきです。
  • l（小文字L）,O（大文字O）,I（大文字I）を変数に利用しない。

実践されている命名方法

CapWords（CamelCase・StudlyCaps）

  • 各単語の先頭のみ大文字
  • 文字が凸凹に見える
  • 先頭が頭字語の場合は全て大文字にする！！

mixedCase

  • 先頭単語が小文字で２単語目以降は１文字目のみ大文字
# CapWordsの例
CapitalizedWords 

# 先頭が頭字語の場合
HttpServerError  （誤）
HTTPServerError　（正）

# mixedCaseの例
mixedCase

パッケージとモジュール名

  • モジュール名は全て小文字の短い名前で、_は利用OK。
  • パッケージ名は全て小文字の短い名前で、_は非推奨。

クラス

  • CapWords方式推奨。

関数や変数の名前

全部mixedCaseを使っていた。ゲホッ！！

関数の名前は小文字のみにすべきです。また、読みやすくするために、必要に応じて単語をアンダースコアで区切るべきです。
変数の名前についても、関数と同じ規約に従います。
mixedCase が既に使われている (例: threading.py) 場合にのみ、互換性を保つために mixedCase を許可します。

メソッド名とインスタンス変数名

関数や変数の名前と同じ。

当然だけど...

パッケージはinit.pyというファイルが存在するディレクトリで、モジュールは.pyファイル。

AWSの環境構築準備（ユーザの作成まで）

AWS

qiita.com とりあえず設定は完了した。MFAは初回登録時以降は入力数値は1パターンのみでよい。 次回以降はいよいよ実際にクラウド上に環境の構築！！！

IAM （AWS Identify and Access Management ）

  • AWSのユーザ管理やリソースのアクセス管理を行うサービス。
  • AWS上では通常ルートアカウント以外で操作を実施する。 そのためまずIAMでグループとユーザを作成し適切なアクセス権の設定（IAMポリシー）を行う。
  • 個別のユーザに対してもMFAの設定ができる。

PEP8（import関連）

Python

読んでみたらプログラムの書き方の参考になりました。これから実装するときはコーディング規約の公式ドキュメントも参考にしよう！
以下に気になったことをまとめました。

はじめに — pep8-ja 1.0 ドキュメント

import

  • import文は通常は行を分けるべき。
#OK:
 import os
 import sys

#OK:
from subprocess import Popen, PIPE

#NG:  
import sys, os
  • import文は次の順番でグループ化すべき。
1. 標準ライブラリ
2. サードパーティに関連するもの
3. ローカルな アプリケーション/ライブラリ に特有のもの
  • 絶対import を推奨。
  • 暗黙の相対importは 絶対に 使ってはいけない。この機能は Python 3 で削除された。
import mypkg.sibling
from mypkg import sibling
from mypkg.sibling import example

参考

blog.amedama.jp

その他全般

  • Guido の重要な洞察のひとつに、コードは書くよりも読まれることの方が多い
  • 1レベルインデントするごとに、スペースを4つ
  • スペースが好ましいインデントの方法である
  • Python 3 では、インデントにタブとスペースを混ぜることを禁止！
  • すべての行の長さを、最大79文字までに制限する
  • トップレベルの関数やクラスは、2行ずつ空けて定義するようにしてください
  • クラス内部では、1行ずつ空けてメソッドを定義してください

AWSの環境構築準備（ルートアカウントの作成まで）

AWS

クラウド上にマシンを作成するまでの道のりがそもそも長かったりする。。。

1.メールアドレスの取得

  • Gmailアカウントを作成した。

2.AWSアカウントの作成

  • マネージメントコンソールにログインできるところまで確認した。
  • 特に難しいことはなく流れにそっていくだけでよい。

セキュリティ設定

ここからが激しく長い。。 qiita.com

3. 二段階認証

そもそもMFAとは

  • Multi-Factor Authentication（多要素認証）。
  • IDとパスワード以外の要素で認証を実施すること。この場合はMFAデバイスが生成した値を認証に用いる。
  • MFA専用のデバイス（キーホルダー型とかがある模様）もしくはスマホアプリの仮想MFAデバイスを利用する。
  • 初回登録時にMFAデバイスと本人情報の連携を行い、2回目以降は本人と連携したデバイスからしか受け付けなくなるのではと推測。

aws.amazon.com

AWS アカウントのルートユーザー または IAM ユーザー 1 人あたり 1 つの MFA デバイスのみ有効にすることができ、デバイスは指定されたユーザーのみが使用できます。
  • iPhoneにMFAのアプリAuthenticator経由でMFA認証を実施した。
  • これでルートアカウントのアカウント名とパスワードが漏洩しても、初回にMFA認証を端末が手元に無い限りログインはできなくなる。

参考

matome.naver.jp

変数・メソッドの命名法

ソースコード実装論 WIP

順次加筆予定

原則１：抽象的な命名は避ける

例１（Memoryとは？）

  • writeMemoryのMemoryが何を指すのかが不明瞭。USBメモリ？キャッシュメモリ？メインメモリ？
  • メモリという名前のつく単語はコンピュータ関連では複数あるため不明瞭になってしまう。
  • 個別の実装内容即した命名などが好ましい。

（前）writeMemory　→　（後）writeVirtualSegment

例２（getXXX系）

  • setter/getter以外でgetは使わない。紛らわしくて混乱する。
  • getという単語自体が抽象的すぎる。取得方法はDB経由なのかコンフィグファイル経由なのかインターネット経由でダウンロードするのかが不明。
  • 受け取った文字列をRegisterに変更するなら、以下のように別単語に置き換えたほうが好ましい。

（前）getRegister　→　（後）convert2Register

原則２：情報量の増えない命名は避ける

例１（XXXFunction系）

  • メソッド名がXXXFunctionの場合、Functionはあってもなくても情報量としては同じ。
  • こうした無意味な名前は冗長にするだけなのでつけない。

参考

クラスの命名のアンチパターン - Qiita

コメントの書き方

ソースコード実装論 WIP

順次加筆予定

コメントの減らし方

そもそもコメントを大量に書く必要がある場合は何かが間違っている可能性を疑う

  • コメントのためのコメントは書かない
  • 変数やメソッド名から内部処理がある程度推測できる名前を利用する

何をコメントとするか

ソースコードだけからでは推定が難しいものを対象とする

全体の実装方針

  • 最初にソースコード全体の実装方針を記載する。
  • 個別の関数やオブジェクトのコード実装が木に相当するなら全体の実装方針は森に相当する。最初にイメージが湧くと読みやすい。

入出力の具体例

  • 具体的な入力値・出力値の例（処理のイメージが湧くため）