2011-12-30
■[Objective-C][iOS] コーディングルールと必要悪
まだ学習を初めて1ヶ月も経たないが、Objective-Cは柔軟性、拡張性に富んだその素晴らしい機能と裏腹に、間違いやすくコーディングによるバグを内包しやすい言語とは思う。(それを上手く使うのもプログラマの仕事である)
特に衝撃を受けたのは、(メッセージ式を含んだ場合の)コンパイルの緩さである。
ここでは故意にタイポしているが"inits"というメソッドはNSDateFormatterクラスは勿論のこと、そのクラス階層のどこにもに無い。この状態でコンパイルすればJavaやC#であれば間違い無くエラーだが、Objective-Cの場合コンパイルは成功する。
しかしこのまま実行するとランタイムで例外が発生するのだ。
"NSInvalidArgumentException" "[NSDateFormatter inits]: unrecognized selector sent to instance〜"が発生している。
このようにコンパイル時にメッセージ式では型の厳密なチェックは行われない。親切なXcodeさんがいないとミスがあることすら判らないのである。
「言語が文化を既定する」ではないが、個人的には言語の仕様に沿ってコーディングする以上のルールは不要だと考えているし、それがプログラミングの道具としての言語の理想だと思っているが、このような言語を使ってプログラムを書く場合、読みやすくミスを起こしにくい一貫したコーディングルールは必要なのだなと思う。
このような場合、いきなりオレオレルールを作るのではなく、まずは先達の方々が作ったルールを参考にするのが常道だろう。
Coding Guidelines for Cocoa: Introduction to Coding Guidelines for Cocoa
Google Objective-Cスタイルガイド 日本語訳 | textdrop
両者とも非常に参考になるが、Googleの規約はどうしてインデントが2桁なのだろう。 これは4桁にしたい所。
※iOS5ではARC(Automatic Reference Counting)が導入されたものの、未だにGCは使えない。これはこれで正しい見識だと思う。
- 14 http://reader.livedoor.com/reader/
- 6 http://www.google.co.jp/reader/view/
- 6 http://www.google.co.jp/url?sa=t&rct=j&q=nexus s root&source=web&cd=2&ved=0CDAQFjAB&url=http://d.hatena.ne.jp/Kazzz/20110108/p1&ei=lBT-TpnqB66SiAeZqKzbCA&usg=AFQjCNGb1iBv70uVXXuI-X7n0bF9lPLcbQ&sig2=U3bmV5qZXIuT6NTe7lXshg
- 5 http://www.google.com/reader/view/
- 4 http://d.hatena.ne.jp/
- 4 http://d.hatena.ne.jp/thorikawa/20101130/p1
- 4 http://t.co/SyZZICFD
- 4 http://www.google.co.jp/url?sa=t&rct=j&q=android superuser&source=web&cd=3&ved=0CDoQFjAC&url=http://d.hatena.ne.jp/Kazzz/20110110/p1&ei=ip79TvKjGs-YmQXywMjOCQ&usg=AFQjCNFR4_-TMUee6CBF59u6V743Fe0f-g
- 4 http://www.google.co.jp/url?sa=t&rct=j&q=androidhttpclient&source=web&cd=1&ved=0CB8QFjAA&url=http://d.hatena.ne.jp/Kazzz/20100730/p1&ei=Hbr9TpKfDO2emQWxkf2uAg&usg=AFQjCNE4wvuYFBktgu6zM1ZhZUPR2Ugcrg
- 4 http://www.google.co.jp/url?sa=t&rct=j&q=googletoolbaruser_32&source=web&cd=1&ved=0CB8QFjAA&url=http://d.hatena.ne.jp/Kazzz/20100224/p2&ei=upz-TtPgE-jhmAXK6tWtAg&usg=AFQjCNHKdAbYUl4j2wBQ7I16CA0cMC694g