********************************************************************** セッションS4-d 分科会4 テーマ:可読性って何だろう〜コーディングルールをどう使う? コーディネータ:井村米和(SESSAME WG3 ㈱デイシス) 日時:9/5 13:30-15:10 参加人数:約15名 ********************************************************************** 井村:時間となりました。 まだ食事から戻られていない方もいらっしゃるので ゆるゆると始めさせていただきます。 このセッションは、「要求品質」として「仕事で求められる」ソースの可読性に ついて、拙論若干を報告し、皆様からは「可読性とはこうではないか」との意見 ・反論を賜わり、「可読性の落とし所」を模索する討議を目標といたします。 (配布資料・スライドとも予稿集に少し加筆してあります。ご容赦ください。) 記述のスタイルを統一すれば可読性が上がる、短く簡潔に書くと可読性が良い とよく一般に言われています。 しかし、それらは解釈に幅のある指標です。 仕事で使う要求品質としての「可読性」は、指標・方向性を明確に決めないと、 良し悪しの落としどころが見つけにくい危険で曖昧な要求になってしまいます。 大抵の場合、レビュー等で他人にソースを見て貰っているとき、意図を追えな くなった読み手側から「もう少し可読性を良くしてよ」と要求される所から「可 読性」の検討は始まります。 書き手側はそれなりのスタイルで書込んだつもり なので、曖昧に可読性の改善を指摘されても何をどこまでどうしたらいいのかが ピンときません。書き直しが続くと意図せぬバグを作り込む恐れもあります。 井村:自分はSESSAMEのワーキンググループ3ことMISRA-C研究会のメンバとして 堅牢なコーディングのために作られたルールについて調査・検討を行いました。 MISRA-Cは欧州の自動車工業会で今から10年前、SWEST開始の1998年に定めれた C言語用のガイドラインで、百数十のコーディングルールを提示するものです。 日本にも広く導入され、最近のコーディング標準の在り方を確立しました 10年ほど前の日本では、『コーディングルールを徹底すれば誰が書いても同じ ソースコードができ、スタイルが統一され品質が良くなる』という仮説が各方面 で堂々と語られていました。(今でも「可読性」という言葉でwebを検索すると、 同様な見解を可読性向上手法にあげているものがあります。) しかし、それは全くの嘘ではないものの、MISRA-Cを含むコーディングルールの 効果として過大であり、実践したプロジェクトマネージャを失望させてしまった のではないだろうかというのが、自分の意見であります。 「誰が書いても(わかりやすさや品質が)同じソースコード」論からこの10年、 各々のソースについて、記述・品質のレベルが均一・均質なことを検証する手法 は、どれだけ進んだのでしょうか? 設計工程の成果物と対比させつつソースの 記述意図を「人力」で追うしか、確実な検証方法は無いでしょう。 その結果、 「ソースが同じ」ことが簡単に測れない代わりに「コーディングルールへの適合」 を調べるという考え方が生まれてしまいました。 これは品質特性が別物です。 ソースをどう書けば何を伝えたいか判る・意図が伝わると言う目的を置き去り にしたまま、コーディングルールに適合してればよいという方法で問題が片付け られてしまった現場も実際多いと思います。 MISRA-Cが日本に定着したといって も、ソースをルールチェッカーにかけ非適合が出なければOKという大雑把な使わ れ方をしているところもあるでしょう。 これはMISRA-C本来の目指す所、特に 逸脱手順でコーディングの難しい所を明らかにする思想とは異なると言えます。 IT業界での中流工程(コーディング含む)の見える化手法検討で、問診表を 使えばマネージメントスキルだけでコーディング標準への妥当性チェックが可能 という意見があるのは、そんな状況を反映しているからでしょうか。 コーディング標準だけで可読性が上がり品質もよくなるという見方は、迷信と までは言えません。 しかし、標準化に関するさまざまな誤解を解くためには、 ソフト開発に関わってきた人たちが、ソースの可読性はこうじゃないかという、 ストレートな議論を各々の場所で続けていく必要があると私は思います。 井村:そこで本日、皆様が「自分の考える可読性」をご発言、またはアンケート 用紙に書いていただいたことをまとめたいと思います。 また、可読性について の井村の発表する仮説について、途中途中で突っ込みを入れて頂ければ幸いです。 身の回りのプロジェクトで「コーディングルールで可読性をあげろ」、レビュー の席で何の基準も示さず「君のソースは可読性が悪い」と言われた/言ったことが ある方、どちら側の立場からのアプローチでもかまいませんが、不満・理不尽な 点を話して頂けたら、「要求品質としての可読性」や「コーディングルール」に ついての幻想が崩せるのではないでしょうか。 井村:ここで少し宣伝ですが、MISRA-Cの1998年版と2004年版は、自動車技術会 から公式な日本語訳がテクニカルペーパーとして発行されています。 その解説本はMISRA-C研究会で作成し(財)日本規格協会から発行されてます。 MISRA-C:1998の解説本「組込み開発者におくるMISRA-C」 MISRA-C:2004の解説本「組込み開発者におくるMISRA-C:2004」 SESSAMEのホームページhttp://www.sessame.jp/ にはこの2冊の正誤表が載って います。 解説本へのご意見およびMISRA-Cの各ルールの内容への問合せは下記の 連絡先にお問合せください。お待ちしています。 sessame-misrac-query@blues.se.uec.ac.jp ----------------------------------------------------------------- 可読性の妥当化 ・共通の用語を用いて説明する ・落としどころを明確にする ・主観的なことは基準に含めない ----------------------------------------------------------------- 井村:まず明解な共通語を用いて「仕事で使える可読性」を定義付けます。 「可読性」が共通語として機能しないと、「可読性のいいソースはこう作る」 の『こう』がますます曖昧になり伝わりにくくなります。 また、落としどころ(クリアする基準)、すなわち、どこまでできればいいのか という基準も要求品質には必要です。 定義しがたい官能性や主観(好き嫌い)に左右される記述方法は、要求を諦める ことが必要でしょう。 業界標準のMISRA-Cでは制御フローの大まかな書き方の 基準(出口を1つ等)を定めているが、波括弧位置やインデントの量などの基準 は定めていません。 --------------------------------------------------------- ソースを書く人の意図→ソース→ソースを読む人の理解 このV字の過程で生じる誤解の程度が可読性の良し悪し -------------------------------------------------------- 井村: プログラマが設計仕様書の意図に実装上の工夫+αしてソースコードの 記述意図を作りだします。 その記述意図をソースに十分表現できなかった部分 は、意図の空白や誤解として読み手に伝わります。 そこに不具合が潜んでいる と「読んでも解らない」では済まないので、リスクがあっても可読性向上の修正 が必要になります。 記述意図の空白が生じる原因には、前工程の設計成果物に 問題がある場合があります。 -------------------------------------------------------- ソース記述に対する具体的な要求とその目的 -------------------------------------------------------- 井村:ソースの書き方に対する要求は実に多種多様ですが、どの要求の背後にも 読み手側に特定の目的や意図が必ずあります。 ひたすら守れと要求やルールだけを示すのではなく、その目的も明示すれば、 どこまで書込むべきか、基準を決めやすくなると思います。 例 式が2行に渡るとき演算子を行末に置いて改行する記述方法を要求 → この要求の目的は、複数ある演算の順序を読み手が追いやすくすること → どの演算子で改行するかは演算子の優先順を元に決めよう 例 保守時には、修正行以外には手をつけない → この要求の目的は、変更した箇所をdiffなどで把握しやすくすること → コメント部分も手をつけないと言うことだな 具体的な要求の目的・用途を見失わないためには、いきなり会社単位の標準に 導入せず、まず身近なプロジェクトのルールとして盛り込むのが肝と思います。 -------------------------------------------------------- 可読性をISO9126-1の品質特性に対応付ける -------------------------------------------------------- 井村: 可読性を要求品質として捉えるとき、共通語として最も普遍的な概念は ISO9126-1の2001年版(JIS-X-0129:2003)の「品質特性」であります。 ソースの可読性など開発段階の成果物の品質には、使用性・保守性・移植性・ 効率性・機能性・信頼性の6つの品質特性があります。 このそれぞれに外部 品質(動的なもの、実行時の振る舞い)とや内部品質(静的なもの、実行前の内容) が割当てられています。 ソースの可読性は、ビルド前にソースを読む用途で問題になりますから、内部 品質に該当します。 一方、エンドユーザーにとっての品質は「利用時の品質」として、有効性・ 生産性・安全性・満足性という4つの品質特性があります。 エンドユーザの 使い勝手や「操作性」などの品質は、利用時の品質の生産性・有効性として、 内部品質の「使用性」とは区別されます。 -------------------------------------------------------- ソースコードの可読性の定義 -------------------------------------------------------- 井村: ソースの可読性は特定条件下で使うこと=読むときの品質ですので ISO9126-1:2001に当てはめると、「内部品質」の「使用性」にあたります。 ソースをデバッガで動かしたふるまいがどうだという外部品質ではなく、 レビューや仲間同士でソースそのものを見せ合ったりするときの静的な品質 であるためです。 また外部品質は割と上流の方の中間成果物が示す仕様に関係しています。 ソースの使用性には3つの副特性があります。 ソースの魅力性、これは読み手の感性に訴え、引き付けたり、逆に引かせ たりする性質と言えます。 インデントのスペース数がその例でしょう。 あるプロジェクトでは読みやすいと決めた数が、別の部署では文化の違いで 通用しないことが起きます。 魅力性の良し悪しは可読性の物指しとして 適切ではないと言えます。 インデントのスペース数がルールで決まっていたことはありますか? A氏:40年前に決めたことがあって、4tabでした。 (決めた基準は)8tabだと深すぎる、ということだけですが。 B氏:うちも4tabですね。 井村:GNU式の2tabのかたはいらっしゃいますか? ⇒ いない この辺は理屈を抜きにした文化の傾向が強いと言う話が一般的です。 pascal系の言語経験がある職場では3tabという例もあるでしょう。 一方、既存ソース(レガシーコード)との整合はどこの場所でも難しい 問題になっていると思います。 新しいルールで書き直す方法で解決する のではなく、ファイル内元から使われていたインデントで統一するという 方法が適切というところに落ち着くでしょう。 魅力性についてもアンケートにご意見を書いてもらえると嬉しいです。 ------------------------------------------------------ 理解性 ・相手に意図が伝わるかどうか ・可読性を考えるときはソースのみで伝えられることを考える →伝えられないものもある ------------------------------------------------------ 井村: 次の副特性は理解性、理解のしやすさです。 ソースのみで伝達可能なことだけを、ソースの可読性の「理解性」と すべきです。 フロー制御やデータ構成などの理解がここに該当します。 例えばホワイトボックステストが容易に書けるソフトが、理解性が高い、 わかりやすい、すなわち可読性が高いといえるのではないでしょうか。 他のドキュメント、設計書などと一緒に読まないと解らないことまで ソースに求めるべきではありません。 設計書の情報不足が原因になって いる場合もあると思います。 ------------------------------------------------------ 使用性標準適合性 ・決めた通りの書き方で作っていることが説明できること ・標準は共通の認識なので、説明不要という利点がある ------------------------------------------------------ 井村: 標準だからしかたない・・・という諦めもあると思います。 これは可読性とは別ものかもしれません。 ------------------------------------------------------ 可読性に保守性を加えるべきか ------------------------------------------------------ 井村: 使用性の他に、保守性という品質特性もあります。 バグがあるかどうか解析しやすいこと、次の製品を作る時にどこに手を 加えればいいかがわかりやすいというのが保守性の副特性「解析性」だと 思います。 ソースだけで直すべき所が解ることもあるでしょうが、上流の成果物・ 機能仕様に照らして判断するのが一般的な方法ではないでしょうか。 直すべき所が解りにくいとき、ソースコードだけが悪いというのは少し 理不尽です。 ある分岐で、あるフラグが立つ、というようなことは、 設計書のほうが説明しやすいと思います。 解析性は、ソースの可読性とは別物だろうと思います。 要求仕様そのものが解析しにくいとき、ソースだけ解析しやすいように ロジックを構成しなおすべきでしょうか? ややこしい仕様にはそれなりに 決まった理由があるかもしれません。後々の要求変更に備え、複雑であって も変に最適化せず、要求仕様に沿ったコーディングの方が無難でしょう。 ------------------------------------------------------ 可読性を向上するにはこう書くべき、というご意見や、 自分の見解とコーディングルールが合わなかったことが 皆様ありますか? ------------------------------------------------------ A氏:自分の考える可読性は「読むための努力が少なくなるようにするもの」 だと思う。 似たような働きの関数の中で使っている名前は統一しないと、 ソースコードのあちこちを見なくてはいけないので大変。 そういう無駄を 減らすものが可読性ではないか。 スタイルのルールはある。見てくれのインデントとか中括弧とかも可読性に 関係がある。 ただし、ツールで直せば良いのであまり問題にはならない。 B氏:教員をやっていて、90名の学生からレポートがくるのだが、魅力性は (読んでいて苦痛を覚える)重要なファクターになっている気がする。 C氏:皆さんの意見が聞きたい D氏:ルールに厳密に従っているよりも、意図がどうやったら伝わるかという 本質をレビューアに見て欲しい。 どうすればいいのかについては検討を。 D氏: マニアックなコーディングはやめてもらいたい(無理に一行に詰め込む ような書き方)。 コーディングルールというよりももっと弱い標準「こころがけ」という形で の呼びかけが必要なのではないか。 E氏: 名前の統一はすべきだ。 関数や変数の名前には正しい名前を使って 欲しい。 ぱっと思いついた名前や、日本語の読みのまま変数にした名前など もやめて欲しい。ひどいと思う。 F氏: 先日のコーディングレビューのソースには、tempという名の重要な変数 があった。 ひとつの変数を複数の意味で使っている上、重要な意味を持たせ ていたりした。 変数の名前は重要だ。 変数の生存期間も意識してコードを 書いて欲しい。 G氏: グローバル変数名とローカル変数名を両方とも小文字から始めていた。 グローバルは大文字から始める規則で見やすくして欲しい。 また変数名の中の単語の頭文字は、大文字で記述してつなげて欲しい(いわ ゆるキャメル 例 abcDefGhi)。 井村:単語をつなげる際に"_"を使う方法もありますが、これを認めるか議論さ れたことはありますか? G氏:"_"を使うと長くなってしまう(ので採用しません)。 H氏:上司によって規則が違ったりする。 区切りが"_"のソースとキャメルの ソースが混ざったりする。混ざるというのがよくない。 またキャストのつけすぎとか、社内で基準が違っていて可読性がよくない。 I氏:キャストについてどういう議論がありますか? H氏:不要な(暗黙に行われる)キャストをつけると長くなったりするので、 それを嫌う人もいる。 井村: char型からint型の汎整数拡張には不要というMISRA-Cルールがありま すね。人によって暗黙の型変換の問題認識が違うことはありますね。 J氏: サイズだけでなく使い分けが必要だと思う。 意図が伝わるようにする ことが重要。 C言語のキーワードと関数名の区別をつけられることが重要。 if文の後にスペースをつけるかつけないかも可読性を左右する。 grepで関数 /キーワードだけを拾いたいときに、検索結果が変わってしまう。 K氏: 可読性は重要視されるべきでないと考えている。 パフォーマンスと可読性を天秤にかけるとパフォーマンスが重要だと思う。 読みやすさが評価につながったりはしない(例えば、給料があがったり)。 入れ子が深くなって可読性が下がったとしてもメモリの使い方を考えると、 悪いとはいえない場合があると思う。 昔、Symbian OSの開発でやったことがあるが、○○をする関数には××を つけなければいけないとOS側から決められていた。そのときは確かに可読性が よかった。 井村:システムとしてユーザー関数の命名規則を決めるという強力な可読性の 維持方法もあるんですね。 L氏: 可読性は雑誌の紙面を作る視点でも興味深い。 ソースコードを書籍に 掲載する場合など、命名規則とか複数の著者が書くとばらばらになったりする ので気をつけている。全体を通して同じ表記になるように注意している。 読者が勘違いしないために部分部分でルールが異なることがないようにしている。 井村:MISRA-Cの解説本もサンプルソースはいろいろな人が書いており、統一 されていませんでした。すみません。 J氏: 構造化プログラミングが世に出てきた理由は生産性がよかったからだ。 ある組織が生産性が高い。 なぜかというと構造化プログラミングと書き方の 統一をしていた。 統一した書き方によりレビューしやすく生産性が上がって いた。 メモリについては、昔ほど厳しくないだろうから複数人が見るコードについて 可読性について考える意味はある。 ソースの寿命は長くなっているので、誰がソースを読むかなんてわからない。 プロジェクトとして困らないソースコードとは?と考えると可読性はその一つ なのかなと思います。 M氏: 相当しばらく先までソースコードは人が読むので、可読性は避けられない 問題だと思う。 パフォーマンスをあげるために可読性を下げることがあると いうのはよくあることなので、コンパイラに任せるのも良い方法ではないか。 J氏: コンパイラがソースコードを読む際に、エラーを出さないような書き方も 重要だと思います。 N氏: シンビアンOSの話があったが、javaエンタープライズ系ではソースの自動 生成も重要。ネーミングコンベンションに従わないと動作しないこともあるので。 井村: 正確な名前をつけるのは人間にとってもマシンにとっても重要ですね。 命名規則に優先度をつけて、高い順に適用するのがいいのかなと思います。 可読性について規則を決め、それに従って書いてみたた後に、効果の判断が できる人に相談に伺うというのも1つの手かなと思います。 演算の順序を明確にするためには括弧を使うことも必要。 ------------------------------------------------------ 書く人への提案: 記述意図をうるさい位に主張し、誤解の入る余地を無くしましょう。 ------------------------------------------------------ 井村: MISRA-Cにはループから抜けるbreak文を一つにする規約があります。 break文を探せばどういう場合に抜けるかがすぐわかる。 これはMISRA-Cの中でも 効果が解りやすいルールだと思います。 MISRA-Cでは暗黙の型変換全てを否定しているわけではありません。 型変換の意図が明確なものについてはキャスト演算を省略する基準を決めるために、 式の中の型とは別に、潜在型という概念を使っています。 MISRA-Cを使っている方はいますか? (数名挙手) MISRA-Cを使っている方で潜在型を導入されていた方はいますか? (いない) Y女史: このように、MISRA-Cを使っても潜在型を使っている人は少ないので、 これはあまりよくない例だと思っています。 井村: コーディングルールについて、今まででてきたような(トリッキーな) 書き方などに関して、可読性向上の取り組みがあれば教えてください。 もしくは、アンケートにでも書いていただければ幸いです。 O氏: switch文のcase節にbreakを書かないことはよくあると思う。 その意図をコメントで明示することはよくやられていると思います。 default省略についても同様です。逸脱する場合にはその際にはコメントを いれる等の対応が必要だと思う。 他にも例外事項の記述にコメントは必要だと思う。 井村: コメントがあれば可読性があがることもあります。 他にも「こういう書き方は嫌いなんだけど」とか意見ありますか。 O氏:ソースを読む人に考えさせてはいけない(思考を止めさせない)。 読むんじゃなくて見て一発でわかるというのも可読性の一つではないか。 見てすぐにおかしいということに気づかせるということも重要。 井村:どうすればそうなるかという問題はありますが、可読性のポイントですね。 ルールとは別の心がけというのもポイントになりそうです。 ルールではなく心がけというレベルで提唱されなくてはならないことがあり、 このレベルを考えることも大事です。 まとまりがありませんでしたが、時間がそろそろなのでセッションを終わります。 ありがとうございました。 ----------------------------------------------------------------- まとめ ・可読性について -記述意図を相手に誤解させないこと (品質特性の使用性、副特性の理解性が可読性の要点) -ルールではなく心がけレベルでも考え示す必要がある -可読性に対する自分達の取り組みを共通用語で説明可能にする ・可読性を高めるために -名前付け・・・長すぎない、意味のある名前、生存期間の明確化 -基準を設ける・・・主観的要素は除く -優先度にしたがって可読性を高める -優先度が低い可読性要求のあきらめも大事