￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ IT ニュース＆コラム 2015/12/28 通巻703号 技術版 ソフトウェアデザイン館 Sage Plaisir 21 ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 　　　　ルールをルールにするな - リーダブル・コード(43) 特別編 開発を始める前に、コーディング ルール（コーディング規約）を決めておくことで、 コードの書き方や名前の付け方に迷わなくなることと、統一性が出るというメリット があります。 しかし、メリットが分からないルールは無駄に感じます。 どこまで 厳密にルール化したほうがよいのでしょうか。 厳密にルールを遵守したソース コードは、ソース整形ツールを使えば見ることが できます。 たとえば、mbed SDK という公開のプロジェクトでは、Artistic Style というツールで、こういったオプションを指定する、といったことを決めています。 ソース整形ツールを使えば、初心者が開発したようなソース コードでも読みやすく なります。 では、自分が最近作成したソース コードに対してソース整形ツールを通してみま しょう。 設定は自分のスタイルに合わせてください。 おや、今度は少し読みに くくなったと感じると思います。 なぜなら、ツールは、コードの背景や考えを 踏まえることができず、文字だけから変換しているからです。 よって、一部の 状況でしか効果がない、他の状況では非効率になる「乱暴なルール」を強引に 採用したときと同じ結果になるのです。 コーディング ルール（スタイル）は、プロジェクトによってバラバラです。 一部のルールが例外的に異なるということが必ずと言っていいほどあります。 寄稿する文書のフォーマットや、中点・長音記号のルールが、それぞれ出版社ごと にバラバラであることも、同じような状況なのでしょう。 そんな状況なのに、ルールにしてしまっていいのでしょうか。 バラバラな状況をほぼ脱した UML（図のルール）の存在は、非常に稀です。 オブジェクト指向の方法論が議論されていたころは、図だけでなくオブジェクト 指向の概念や用語もバラバラだったので、統一理論が望まれていました。 理論を統一することは非常に難しいと思われたのですが、最終的には、図の 統一化が UML で、開発プロセスが IBM の Rational 統一プロセスという名前で 実現しました。 統一されたので普及したとは言えませんが、形ができるまで対立が 続かなかったのは、関心が高い方法論と、関心が低い図やプロセスを切り離すことが できたからでしょう。 1990年代のオブジェクト指向の方法論の本には、それぞれの図が定義されていて、 方法論の顔ともいうべき存在でした。 図を使って設計するように書いていたので、 「慣れ」が必ずあるはずです。 方法論を戦わせていた者同士が、顔である図を統一 することができたのは、見慣れた図と違う図という問題は大した問題ではなかった からでしょう。 つまり、コーディング ルールを守れない人がいる原因は、表現が 見慣れていないことが原因ではないのです。 多くのプログラミング言語が使える のに、コーディング ルールが守れない（統一できない）のは、表現や慣れだけが 原因ではなく、表現以外の何か関心がある問題が、表現に関わってしまっている からです。 たとえば、最新のプログラミング言語で使えるラムダ式は、そのメリットがよく 分かっている人にとっては使いたいものですが、残念ながら記号でしか表現されて いないので、ネットを検索してもヒットしないので理解不能になってしまいます。 だからといって、ラムダ式を禁止してしまうと、関連性が高いコードがバラバラに なって、非効率になります。 そこで、ラムダ式より delegate というキーワードがある 匿名メソッドにすることをルール ブックに示したり、コメントに、 /* => is lambda expression */ を、関数内で１つは必須にするようなルール にしなければ、本来のルールの目的である効率化と反対の効果になってしまいます。 使いたい人が対案を作成する必要がありますが、禁止する人は保留する必要が あります。 会社を素人集団にしたいのですか。 UML の図や用語の定義に UML 自身や メタモデルを使ってまで明文化されて いるところを見ると、ルールに遵守する（共通化する）にはかなりの説明が 必要なのだといえます。 「こうすること」とシンプルで簡単にルールブックしか 見たことがないのですが、そのように書かれているだけでは遵守できないのです。 そのルールが、それぞれ開発者が会得したルールより優れているとは考えにくい、 いや本当に優れていないことが本当に多いのです。 Windows または Linux しか知らない食わず嫌いの開発者や、時代遅れな 開発者がほとんどだと思いますので、数回試してみることは重要です。 ルールを 変えることができるのは、自分のルールを変える覚悟のある奴だけです。 つまり、 ルールを変える必要がない管理者や顧客は、部外者です。 食わず嫌いが原因なのかそうでないのかは、食べてみないことには分かりません。 つまり、数回試すことは必須にし、それでも従えなかったルールは推奨に変えるか 破棄する、というフィードバック ループを形成することが正しいルールの運用と 変更なのです。 一度もそのループを回していないルールをいきなり正式なルール にしてはいけません。 ドイツ政府の標準であり、各社が採用している Vモデルの開発プロセスは、 政府が関わっているだけに権威があります。 しかし、基本設計とシステムテスト の対応関係など、それぞれ水平に対応するプロセスの定義の違いがあるのに、 対応すると言い切ってしまっている問題があります。 開発現場で試せばすぐに 気づくことで、必ず見かけ上の整合性をとる対応策を議論する羽目になります。 ドイツ政府はシステム開発の顧客であり開発者ではありません。 顧客や管理者 が、状況の概要を理解しやすくするために、ウォーターフォールに関連を 追加したのが Vモデルなのでしょう。 つまり、顧客や管理者が行うべき 状況把握の仕事が、開発者が行う説明資料の作成に変わってしまったのです。 オブジェクト指向の方法論者がプロセスを切り離して統一化できたのは、 開発プロセスが開発を効率化するための方法論ではなく、顧客や管理者が 把握するための方法論なので関心がなかったからなのかもしれません。 製品の要求を開発のルールにしてはいけません。 下請法と同様に直接指示して はいけません。 民主主義に関わってきます。 UML があるにも関わらず、未だにフローチャートが望まれます。 なぜなら、フローチャートが表現する対象の概念を理解するのが簡単だからです。 UML の表現対象は、オブジェクト指向の概念なのですが、大規模なソフトウェア の全体を理解するスーパープログラマーが必要とする概念です。一部しか 開発対象にしていないライブラリーを開発していない一般の開発者にとっては 理解する必要がないのです。 しかし、一般の開発者が利用するライブラリーは、 オブジェクト指向や構造化プログラミングなどの概念を踏まえて整理されている 必要があります。 これは、作家さんが高度な技術を必要としているのに対し、 読者にその技術は必要ないといった関係と同じです。 といっても、JIS が定義する情報処理用流れ図（フローチャート）のすべてを 知っている人はほとんどいませんし、望まれてもいません。 ネットで検索すれば 見ることができますが、JIS X 0121-1986 にある、手操作入力の記号、 表示の記号が実際に使われていることを見たことはないでしょう。 構造化 プログラミング言語がこんなに浸透しているのに、ループの処理については、 ループ端の記号ではなく判断の記号が使われているのをよく見かけます。 つまり、UML よりフローチャートのほうが求められているのではなく、簡単で 数が少ない（公約数の）よく知っている概念に対する表現のルールが求められて いるのです。 話を最初に戻して、コーディング ルールは、どこまで厳密にルール化したほうが よいでしょうか。 開発時にはどんなルールも推奨に留めるべきです。 開発者それぞれに関心がある 得意分野や技術レベルが異なり、開発の方法論の統一は不可能であることから、 多くのコーディング ルールは許容できても、許容できない表現もあるからです。 スタイルの変更は煩わしく感じますが、ルールの順守に比べればたいしたコスト ではありません。 ただし、食わず嫌いだけは禁止すべきです。 そして、リリース するときには、最低限のコーディング ルールに遵守するために、コード整形 ツールを使うべきです。 内部リリースするときは、ユーザーがツールを使うよう にするべきです。 公約数だけのルールにはない、他の人のコーディング ルールは、 読解力の向上やルールの改善のヒントになるからです。 自動整形できない コーディング ルールは、推奨に留めて試すことをルールにすべきです。 外部の人にとっては、遵守していることが推奨していることより「常に」良い としか理解できない（勉強する時間がない）ので、ルールに遵守していると 言うことになると思います。 ここにも理解の厳密さが関わっています。 参考 [ThinkIT] 第1回：UMLの現状 (14) https://thinkit.co.jp/free/compare/12/1/ フローチャート - Wikipedia https://ja.wikipedia.org/wiki/フローチャート Development Style Round Table Talking：第1回 オブジェクト指向の弱点 http://www.itmedia.co.jp/im/articles/0311/22/news001.html ＠IT：FAQ UML篇 UMLの文法はどのように定義されているんですか？ http://www.atmarkit.co.jp/im/carc/serial/dstylefaq/uml/uml3_1/uml3_1.html Vモデル - Wikipedia https://ja.wikipedia.org/wiki/Vモデル 注目ニュース 一覧 ◇ OneDriveの無料15GBを守る方法。1月末まで手続き必須。 http://www.itmedia.co.jp/pcuser/articles/1512/17/news122.html … OneDrive Preview が何かよくわからないが、個人向けなのでいいだろう。 ◇ JASRACの健全な対抗軸に。著作権管理新会社NexTone。 http://av.watch.impress.co.jp/docs/news/20151217_735955.html … 健全だけでなく、いかに納得がいく方法で効率よく回収ができるかがカギ。 ◇ HTML5で作られた表計算ウィジェット。Excelライクな「SpreadJS 9J」発表。 http://www.publickey1.jp/blog/15/html5excelspreadjs_9j.html … HTML5 は遅いといううわさがあるが。 ◇ Facebook、動画をデフォルトでFlashからHTML5に移行。 http://www.itmedia.co.jp/news/articles/1512/21/news048.html … HTML5 でも遅くないらしい。 ◇ テックウインド、真の省スペースを実現する キーボードPC。Windows 10を搭載。 http://pc.watch.impress.co.jp/docs/news/20151215_735364.html … ノート PC に画面を除いたもの。 ◇ スマホをWindows PCのように操作。マイクロソフトの Display Dock。 http://japan.cnet.com/news/commentary/35075524/ … Windows スマホから直接画面に出るのはないのか。 ◇ マイクロソフト、中間者（MiTM）手法を用いたアドウェアを禁止へ。 http://japan.cnet.com/news/service/35075450/ … 無料（広告）プロバイダーに影響か？ ◇ Twitterに 紅白歌合戦 絵文字が登場。ハッシュタグで紅組・白組を応援。 http://www.itmedia.co.jp/news/articles/1512/24/news071.html … ハッシュタグを付ける投稿に、絵が自動的につく。 ◇ あなたの身近にもある、IoT活用の変革事例。 http://techtarget.itmedia.co.jp/tt/news/1512/24/news05.html … ロングテール市場を Amazon のようにまとめる企業が現れるかどうか。 ◇ マイクロソフト、軽量なプロジェクト管理ツール Office 365 Planner。 http://www.publickey1.jp/blog/15/office_365_planner.html … グループウェアをクラウド上に構築することに力を入れ始めた。 ◇ 電子書籍は、なぜ消えるのか？世間にはびこる俗説を斬る。 http://japan.cnet.com/sp/t_hayashi/35075470/ … 所有しても意味がないって、所有したいんだよ。 次回、2016年は、1月 17日から発行します。 ソフトウェアデザイン館 Sage Plaisir 21 ホームページ >>> http://www.sage-p.com/ メルマガ >>> http://www.mag2.com/m/0000083983.html ブログ >>> http://blog.livedoor.jp/sage_p/ ツイッター >>> http://twitter.com/Ts_Neko ダウンロード >>> http://www.sage-p.com/freesoft.htm サポート掲示板 >>> http://www.sage-p.com/kg_ban09/z6037C8.cgi 東日本大震災 >>> http://www.sage-p.com/saigai.html メール >>> ts-neko◇sage-p.com ←◇を@に変えてください 緊急メールは件名に「うどんメール」を付けてください。 このメルマガの登録・解除 - http://www.mag2.com/m/0000083983.htm