コーディング規約を守っても品質は上がらない
最初に結論を書いておきます。コーディング規約を守っても品質は上がりません。スキルの無いプロジェクトマネージャが品質保証のためにコーディング規約を活用しますが、あれが良くないです。コードの品質は中身です。コーディング規約を守ることで、可読性の一部は担保できますが、全体の品質は担保できません。
そもそも、コードはエンジニアとセットになって価値を発揮すると考えています。属人化は避けるべきですが、それぞれのエンジニアの持つ特性は切り捨てられません。本来であれば、エンジニアの持つ特性を解析したり、継承したりして、会社としての知的財産として扱うべきです。ただ、今の日本でそれができている会社は本当に少ないです。
コーディング規約でガチガチにしばれば、エンジニアの持つ特性は切り捨ててコードを規格化することができます。また、コーディング規約という物差しを使えば、スキルの無い人でも「コーディング規約に沿っていない」という理由で、スキルが自分より高い人を押さえつけることができます。そういうケースを何度となく見ているので、私の中では、コーディング規約は低品質を隠す隠れ蓑というイメージが定着しています。
また、「こういうロジックはこう書けば分かりやすいはずだ」という部分までコーディング規約で定義しているプロジェクトもありました。ただ、そのコーディング規約を作ったのはコードをほとんど書けないマネージャさんでした。コーディングできない人がロジックまで介入すると、規約ではない別物になります。エンジニアをコントロール下に置く手法です。残念ですが、これをコーディング規約と認識しているエンジニアは少なからずいます。
エンジニアをコントロール下に置きたがる不勉強なマネージャさんは速やかに転職いただければと思います。ツールを使ってコーディング規約に書いてある書式の部分は自動化しようよ?と、何年か前にエンジニアさんの登壇で聞いたことがあります。規約云々さわいでいるエネルギーを考えるべきことに集中すれば、結果も出やすくなるだろうとのことでした。
基本的な話ですが、コーディング規約を守っても、コードに書いたロジックの担保は何もできません。なので、コーディング規約を守っても根本的な品質は上がりません。
コメント
匿名
この記事はコーディング規約では品質を高められない、と題していますが、
コーディング規約は品質を高めるべきにある、という例が書かれていないので、
イマイチなぜそこからスタートになるのかな、という気がしました。
私の読解力不足でしたらすいません。
中段のがちがちに固められた規約について書かれている部分も、品質高めるためにそうしている、などがかかれているわけでもないので。
わたしは、コーディング規約は保守性と可読性をある程度担保してくれるもので、
品質を高めるものが第一ではない、ということだと思っているので、
筆者の考えもわかるのですが、この記事の前提となる発端などが、あったのかが、しりたいとおもいました。
山無駄
工事現場では、「安全行動」や「基本動作」という言葉があります。例えば階段を上りおり
するさいは必ず手すりをもつ。靴紐はきちんと結ぶなど、一見当たり前の動作を規定してい
ものです。実のところ大きな事故は、この当たり前の行動が守られていなかったことが原因
でおこる事が多く、「安全行動」の徹底が義務付けられます。
コーディング規約の似たようなもので、確かに直接全体の品質には影響しないかもしれませ
んが、規約を遵守できているシステムは総じて、全体の品質がよいのもまた事実です。
しかし、規約は陳腐化、形骸化するのもので、そうなるといくら規約を守っても品質には寄
与しません。工事現場では形骸化しない様に、ヒヤリハットをKYを行って、「安全行動」の
見直しや本日作業で気をつけることを意識づけしています。
ということは、コーディング規約もただ決めたことを遵守すればよい、というものではなく
見直しや、開発するものによって重要視するものを変えてゆく必要があるのでしょう。
これは開発マネージメントの仕事ですので、これらを行わない開発マネージャは職務怠慢と
いうことで退場願うのが世の幸せだと思います。
Horus
> 匿名さん
> イマイチなぜそこからスタートになるのかな、という気がしました。
文章の構成上、結論を一番最初にもってきました。
具体的なケースを挙げると、コード規約に言語上間違えた書き方が記載されていました。そして、誰もそれを指摘せずに「それが正しい」という基準で動いていました。
また、コードの保守性もコード規約を守るだけでは上がりません。コード規約に違反していないが、Case文を使わずIf文で条件分岐をやっていたため、ロジックが無駄に複雑になっていた事例もあります。
大雑把なところでこんなところです。
Horus
> 山無駄 さん
> 規約を遵守できているシステムは総じて、全体の品質がよいのもまた事実です。
「言われたことを何%できたか」基準で品質を決めるなら、ご指摘の通りです。
このコラムの発端の案件では、条件が「言われたとおり」なら品質は八割達成です。「メンテナンスを意識したロジック」はゼロ、処理内容に対しての労力をコスト換算すると大幅にマイナスだったので、品質は最低という評価です。
お客さんには説明できているが、実工数で考慮すると八人月無駄に払ってました。
あと、一応指摘しておきます。「安全行動」の徹底はどちらかと言えばシステム利用のコンプライアンスです。セキュリティ事故と品質低下が混同されているように思います。
ごぼう
「最初に結論を書いておきます。コーディング規約を(守っても)品質は上がりません。」
でしょうか
Horus
> ごぼう さん
ですね。
まんまん
最初に結論を書いておきます。制限速度を守っても交通事故は減りません。
匿名A
コーディング規約を品質を上げるためのものと考えている方がいらっしゃるのですね
驚きでした
そういう方はそもそもコーディング規約は書き方を統一して可読性を上げるためのものなので品質とは無関係なことを理解していないのですね
ただコーディング規約自体は有用で、キーワードの順序や改行の箇所、スペースの幅などが揃えられることで人力の理解も早くなりますし、差分比較でも無駄な差分が出ないので重宝しています
当然自動化は前提となりますが。
Horus
> まんまん さん
うまいこといいましたね。
匿名B
コーディング規約を守ってもコードを誰もチェックしない
なら守っても意味がないと思いますが、コードチェックを
するなら一定の効果があるあるのではないでしょうか?
Horus
> 匿名A さん
> コーディング規約を品質を上げるためのものと考えている方がいらっしゃるのですね
マネージャさんがコード読めないような人だと、コーディング規約に則っていることイコール品質のようにお客さんに説明してます。
コードレビューでコードを全部印刷して、スペースの数やら変数の名前を一生懸命チェックしているのを見て唖然としたものです。
Horus
> 匿名B
一見そうなりそうですが、いくつか問題があります。
・ コーディング規約を盛り過ぎると把握しきれず守れない。
・ 曖昧な記述があると、人によって解釈のばらつきが出て統一できない。
・ そもそも、規約一つでまとまるほどコーディングは単純じゃない。
コーディング規約にこだわり過ぎると、規約にに則っているか否かで無駄な議論が起きて大量の工数を無駄に消費します。また、議論が起こる度に解釈の揺れが発生して、「一体どっちだよ!」となり、コードを書くのに無駄な労力がかかります。
結果として、スキルのないマネージャさんがコーディング規約を掲げると必ず炎上します。だからこそ、規約だけ決めて自動化するのがベストです。
Horus
コメント付ける時は、マジで名前入れてください。
匿名さんに返信つけてるときに別の匿名さんがコメントとか、ちょい待てよww
気づかなければ、意味不明の返信になるところだった。
匿名ですみません
品質の良いプログラムを開発するには「コーディング規約」だけを遵守しても難しいと思います。
あるべきアーキテクチャなど理解していないPMが、単にコーディング規約だけを押し付けてくる場合、現場から不満の声が聞こえてくる気がします。
当然コーディング規約だけでは品質は上がらないですし、「設計プロセス(DDD等)」や「開発者のスキル」なども品質に影響する要素だと思います。ですが、一定の品質を保つ上で、コーディング規約や必要だと考えます。(Eclipseではチェックを自動化、チームで共有化できるようです)
ksiroi
やはり規約が「デキる人を束縛する」という事実はもっと知られてもいいよね。
色々と勘違いしている人多すぎや。
品質とは何か、理解とは何か、自動化することによるメリットは知っているがデメリットは何か、ってのを考えたことがない思考停止マンが多すぎるんじゃないか
匿名C
コーディング規約を守らないことが品質の低下に繋がりうるということに同意できるとするなら、コーディング規約を守るということは、コーディング規約を守らないということに比べて品質は向上すると言える。
Horus
> 匿名ですみません さん
> Eclipseではチェックを自動化、チームで共有化できるようです。
これがベストプラクティスだと思います。よく勘違いしているのが、ロジックとフォーマット (インデントやら改行のやり方) をごっちゃにしている人です。コメントをみても、ごっちゃにしている人は結構な数、見受けられます。
フォーマットを自動で直したあとじゃなければ、ロジック見直すにもやりにくはないでしょうか。
Horus
> ksiroi さん
正にそれに尽きます。
Horus
> 匿名C さん
申し訳ないが何が言いたいかよく分りません。
ぬ
コーディング規約については、私もおおむねHorusさんと同意見で、どちらかというと否定的なのですが、このコラムに関しては、ちょっと一言いいたくなりました。
このコラムは、コーディング規約にまつわる悪しき実例をたくさん挙げて、
「だからこそ、コーディング規約は、ダメなのだ」
という結論を導いています。
その結論自体にはさほど異論はありません。
ただ、現実問題として、いろんな現場で、今なお、コーディング規約は、生きていますよね。
であれば、そこには何らかの理由があるはずです。
大半が愚にもつかない理由であったとしても。
「一分」(「いっぷん」じゃなくて「いちぶ」)くらいは、品質担保につながる、何らかの合理的な理由があるのではないか?
そこにも考えを巡らせたうえで、「にもかかわらず、コーディング規約は、ダメなのだ」
という結論を導く展開であれば、より説得力が増しただろうなぁ、と思いました。
Horus
> ぬ さん
頂いたご意見に対する返答ですが、このコラムが「コーディング規約の何がダメか」にフォーカスを絞ったものだからです。あと、コーディング規約が上手く運用されている現場で働いたことがないという、私の現場運の悪さもあります。
コラムでも軽く触れていますが、コーディング規約は一部の読みやすさ、例えばインデントがそろっているとか、適切に改行されているとか、くらいは担保できます。しかし、「規約」ではそこが限界だと思っています。
理想で言えば、簡単な規約だけ決めておいてツールでチェックする。そこからコードレビューをして品質を上げていくというアプローチでしょう。多分、そういう理想的な運用ができているところもあるでしょう。
お答えしていると一本コラムが書けてしまうので、機会があれば別視点で同じテーマをコラムに書いてみようと思います。
匿名C
> Horus さん
理想的な品質を100としたとき、コーディング規約なしに個々人が勝手に自分が書きたいように書いたとき、以下のような理由で品質が落ちると私は考えます。
* そのコードがコードレビュワーに取って読みづらいものだった場合、レビューのモチベーションが下がり、問題が見逃される可能性が増大する
* コードの作者以外がメンテナンスを行う場合、その担当者にとって読みづらいものだった場合、メンテナンスのモチベーションが下がり、工数が余計にかかったり、問題を見逃したりする可能性が増大する
ということに同意できるとするなら、コーディング規約があることにより何かが改善したとすれば(私はすると思う)、その分品質は向上すると言える。
ksiroi
投稿した内容の添削はイタダケないかなー
Horus
> 匿名C さん
まず、一つ一ついきます。
* そのコードがコードレビュワーに取って読みづらいものだった場合、レビューのモチベーションが下がり・・
レビューの前にツールで整えれば、インデント等による見にくさは回避できます。ロジック自体が読みにくければ、そこから問題提起すれば良いかと。
* コードの作者以外がメンテナンスを行う場合、その担当者にとって読みづらいものだった場合、メンテナンスのモチベーションが下がり、工数が余計にかかったり、問題を見逃したりする可能性が増大する
ケースとしてはあり得ます。ただし、コード規約に沿っているかどうかの議論で多くの工数が消費されることもあります。現場による。というのが私の見解です。
どうすれば品質が上がるか、コード規約がどうなのかはそれぞれの考えるところだと思います。私がコラムを書いているのは、個人としての意見を述べているだけです。それを人に押しつける気はありません。匿名C さんの考えかたも、あり得ると思う部分もあります。
Horus
> ksiroi さん
改行は弄ってます。コメントはできるだけ誤読のないよう、内容を判断して区切ってます
あと、このコメントでもやってますが、自分のコメントは後から追記、、編集はしてますし、コラムの本文も誤字脱字や変な表現に後から気付いたら修正してます。
匿名C
> Horus さん
Horusさんと私で、大きな認識の違いがある気がしたので追記します。
まず、コーディング規約が決まったという前提で、最初にコードを書いてSCMにコミットする人が、自分が書いたコードが規約(のスタイルガイド部分)に沿ってなければ、その人が整形してコミットすればいいのではないかということです。
そうしなかった場合(コーディング規約に沿っていないコードがコミットされる状況)に比べて、コーディング規約に沿ったコードのみがコミットされるなら、それは前者に比べて品質が上がったと言えるのではということです。
> コード規約に沿っているかどうかの議論で多くの工数が消費される
大抵の言語の場合、静的解析ツールが存在するので、あるコードが規約に沿っているかどうかのチェックにかかる工数は限りなくゼロになると思っています。
逆に言えば、コーディング規約は、それらの静的解析ツールが検出できる範囲にとどめるというのがベターだと思います。
> どうすれば品質が上がるか、コード規約がどうなのかはそれぞれの考えるところだと思います。
大抵のコーディング規約の「これを定める目的」には、メンバーのコードの品質を一定に揃えるというのが入っていると思います。
つまりは、極端に品質が低いコードが生産されることを防ぐのが目的です。
これは、個々人の考え方の違いによって左右されることではないと思います。
Horus
> 匿名_C さん
とりあえずいくつか指摘しておきます。
・ あなたのやっているのは議論ではなく自己主張です。
・ 私に何を言ってもあなたの望む答えが出るわけでもありません。
・ あなたの言いたいことは分かりますが私のケースと違います。
匿名Cさんの考え方を否定する気はありません。ただ、私とは違います。それだけです。認識の違いは最初から認めています。他人と意見の相違があっても当然なので「それでOKだよ」とコメントをつけたつもりですが。
話がかみ合っていないですよ。
匿名
「規約は必要ではない」と断言するのは誤解を招くでしょう。
強い制約が必要ではない事には同意しますが、制約がない無秩序状態には同意できません。
各々考えが違いますから、ある程度の「決まり事」は必要です。
コーディングガイドライン程度は必要でしょう。
Horus
> 匿名 さん
こういう意見もありますというだけなので、別に同意は求めていません。コーディングガイドラインが必要とおもうなら、ご自身がその立場になったときにベストと思われるものを作ればいいかと思います。
以上。
ksiroi
ちょいと会話の旬を逃してしまったが、他人の発言は出来うる限りそのまま載せたほうがいい
意図や人格が捻じ曲げられることもままあるからね。
自身の発言はもちろん編集してもかまわないが、他人のは止めたほうがええよ。少なくとも私は一文字でも発言を変えられるなら金輪際コメントも書かないな。
発言に責任が持てなくなるリスクほど怖いモンはないでな…
通りすがり
・コーディング規約(法律)を守れば、幸せに暮らせるか
・幸せに暮らすために、コーティング規約を造るか
この辺が見えたんですが、当方の勘違いかもしれません。
Horus
> 通りすがり さん
多分、コメントの方を読んだのでは。コラム本文は、コーディング規約って品質上げるためのものじゃないって話です。
ついでなので補足ておくと、厳密に言えばコーディング規約でも品質は上がります。ただし、百桁の数字の一の桁が変わる程度です。
「品質を下げないためのアプローチとしては有効だが、品質自体は上がらない。」
たくさんコメントを付いたのを見て、こう書いた方が的確だったと思っています。こう言えば分かりやすかったか・・・。