ジェネリックってなんだろう
Table of Contents
広辞苑: generic
属名
全般に関する,総括的な,一般的な (<=> specific); 総称的な.
ノーブランドの; 商標登録されていない <薬・商品など>
プログラミング: Generics
同じプログラムコードで様々なデータ型のデータを処理できるようにするもの.
http://e-words.jp/w/%E3%82%B8%E3%82%A7%E3%83%8D%E3%83%AA%E3%82%AF%E3%82%B9.html 静的型付け言語では関数やメソッドを定義する際に受け取る引数のデータ型を決定して記述しておかなければならず、異なるデータ型に同じ処理を行うコードが必要な場合は内容がほとんど同じで引数の型だけが異なる関数などを必要な型の数だけ用意して呼び分けなくてはならない。
ジェネリクスを用いると、引数の型の情報を引数として渡すなどの方法で、あらかじめ特定のデータ型に決め打ちせずに処理内容を記述することができる。
Java 的には … 汎用的なクラスやメソッドを特定の型に対応づける機能のこと.
public class Box<T> { T o; public Box(T o) { this.o = o; } public T get(){ return o; } } Box<Integer> b = new Box<Integer>(new Integer(123)); Integer i = b.get(); System.out.println(i);
T
の部分で (動的に) 型宣言をしてあげることによって,
Integer
用, String
用, Long
用の Box
… のようにそれぞれ定義していく必要がなくなる.
- コードミスが発見しやすい (コンパイルエラーを吐いてくれるから)
- 扱っている型が明確で,可読性 UP
といった利点があるらしい.
調べた限りだと静的型付け言語特有の機能の様子. つまり,動的型付け言語 (特にオブジェクト指向言語) では,これらのことを自動的にやっているということなのだろうか.
PEP と PEP8 - コーディング規約の意味を考える
Table of Contents
[what] PEP とは ?
Python には PEP1 と呼ばれる「Python における開発を円滑に進める上で重要なことをまとめた文書群」がある.
もう少し詳しく: Python における新機能・環境を提案したり,現状の課題について議論して意見を集めたりすることで,今後 Python に追加されていくであろうものをドキュメント化するためのものである.
その中の PEP82 には,Python における コーディングの規約 が記載されている3.
これに従ってコーディングすることで,それ (Python) らしいコードが書けるみたい.
cf. https://legacy.python.org/dev/peps/pep-0008/
他の言語 (e.g. 私の場合は C 言語) で守っていたことが,Python だと NG だったりしている.ちょっと驚き.
### OK ### x = 0 y = 1 zzz = 2 ### NG ### x = 0 y = 1 zzz = 2
例えば,こんなの.
=
を列で揃えることはやらない (NG) らしい.
ただし,本質は チーム内で記述方法を統一すること だと思っている. なのでチーム内で規約を新たに決めてしまえば,上の NG 例を採用するのもあり (?).
[why] なぜ作られたか ?
PEP そのものは Python における開発の効率性を高めるために存在する文書群 (と認識している). コーディングするにあたって,効率が良いに越したことはないので,こういう文書群はプログラマーからするとやはりあった方が良さそう.
… 自分で書いておいて 効率 ってなんだろう … ?
と疑問に感じたので,ここでは PEP8 (コーディング規約) において,効率とやらについて考えてみた.
まず,コーディング規約でやりたいことは
開発者のセンス・技術の一部分をチーム全員で共有すること
だと思っている (<- いろいろ調べた結果の考え).
具体的には 2 つ:
- [可読性] 共有すれば,書き手の意図が読み手に伝わりやすい4.
-> 意図が伝われば5,理解しやすいので,どんどんコードが読める ! [保守性] 個々の個性を潰すことで,チーム内での技術的な溝をできるだけ埋める.
- 経験値が少ない人は,規約を一生懸命読みながら書けば,コードの質を保てる (?)
- 経験値が多い人は,規約に従って,わかりやすく一般的なロジックでコーディングをする (自身の技術レベルを周りに合わせる) ことで,経験値が少ない人の助けになる (チームの為になる).
-> 1., 2. より,全体的に読みやすくなって,ミスも減るので,正常に動作するプログラムを保ちやすくなるといえる !
他にも挙げればあるのだろうけれど,可読性 / 保守性を UP させることが規約を守る一番の意味だと現状思っている.
可読性 / 保守性が UP すれば,開発が捗る (効率が UP する) であろうことがなんとなく想像できる.
[How to] どう利用するか ?
PEP8 をなんとなく理解した. 概念が理解できれば,あとはそれをどううまく使うか.
まぁ,規約が理解できたのであれば,あとは単にその規約に従ってコーディングすれば良い訳なのだが, 規約を全て頭に入れて置くのは辛そう.
というわけで,それはツールに丸投げ !!
cf. https://qiita.com/ynakayama/items/8616f4c0c6e372de9a42
これは,規約と照らし合わせて,書き方が正しいかどうかを自動でチェックしてくれるというもの.
… しかし,上記記事を読んでも設定がうまくいかない !!
pep8 のパス指定あたりがよくわかっていない …
とりあえず記事をアップしておきたかったので,設定は保留. 近々追記 (ちゃんと設定)6 しようと思う.
ちゃんとした共同開発の経験がない !
ここまで書いておいて … 私自身,ちゃんとした共同開発の経験がない7. 仕様を固めて,規約を考えて,いざコーディング !! みたいな流れは,教授に相談こそしたが 1 人でしかやったことしかない.
なので,いろいろ考えてメモはとったが,結局上記内容は経験に基づくものではなく,ほぼ想像と言える.
企業で働き始めたらわかるのかな … (笑)
Footnotes
1 PEP: Python Enhancement Proposals
2 文書 No.8 のこと.PEP の一覧をざっと見た感じ,抜けている番号がかなりあった.RFC のように 廃止 制度がある模様.
3 これがいわゆる 標準 (デファクトスタンダート というやつ ?)
4 規約に「ここはこう書くと読みやすい !」とか「この部分のロジックは気をつけましょう」みたいなことを書いておいてチーム全員で共有できれば,「なぜこんな書き方をしているんだろう ?」みたいなことが起きにくい ... 気がする.
5 例えば … コメント無しで,コード (ロジック) だけで書き手の意図がしっかり伝わったらとても嬉しい (ような気がする)
7 ゼミ生と軽い共同開発はやったことがあるが,そのときはコーディング規約なんぞ決めていなかった.