-エンジニア版-言語の歴史は人類の歴史。人類はコンピュータを言語で動かすようになった。2018/08/01先日書いたコラム「コーディング規約を守っても品質は上がらない」の反響が大きかったようです。続きを書いてみようと思い、このコラムを書きました。頂いたコメントやツイートを確認しましたが、一部の人の間では、「コーディング規約を守れば何かしら品質が保たれる」という考え方が根強いと感じました。ここまでくると一種の信仰です。いう人にこそハッキリ指摘します。自分がやってきたことだから正しいと信じたいだけではないでしょうか。気持ちは分かりますが、SESで横行している、能力の無いマネージャのやり方に毒されていないるように思います。「品質が保たれる」の根拠が、「要求された仕事を一生懸命やってOKをもらったから」では、理由になりません。その考え方はエンジニアとして甘いです。品質云々語る人に突きつけたいのは工数です。規約に沿っている、要件通りに動く。この二つの条件を満たしていれば、確かに品質を達成したと言いたくなります。そこに達するまでどれだけ工数がかかったでしょうか。残業を繰り返してプリントしたソースコードに赤ペンチェックを入れていないでしょうか。あれば、品質以前の問題です。目検でインデントの数を数えているなら、エンジニアを辞めて工場の流れ作業に転職することをお勧めします。いうことはツールで済ませましょう。フォーマットを整えるとコードが見やすくなります。本当にチェックするなら、コードを見やすい状態に整えてからやるものです。フォーマットとロジックを同時に見るのは効率が悪すぎます。実際問題、コーディング規約があったとして項目を全部暗記していること、プラス、内容の理由を技術的根拠を元に説明できること。守る側もチェックする側も、これが最低条件です。覚えてもいないものを守ることもチェックすることもできません。技術教育を行った上で規約をシンプルにまとめないと運用できないということです。SESでよくある、技術教育を省くようなプロジェクトで「コーディング規約を守れば品質が保証できる」と言うなら、可読性や保守性云々以前に、そのあり方自体を全面否定します。フォーマットを整えるとコードが見やすくなります。本当にチェックするなら、コードを見やすい状態に整えてからやるものです。フォーマットとロジックを同時に見るのは効率が悪すぎます。するなら、なぜ最初にSCMにコミットする人がそうしないんですか?なにかを変更するときに、コードを整形せざるを得ないほど酷いもので実際に整形したとしたら、余計な差分が発生してSCMのdiffが役に立たなくなります。マニュアルでコーディング規約に沿うようなスタイルにせずとも、SCMのコミットをフックして自動整形するという方法もあります。品質云々語る人に突きつけたいのは工数です。非常に読みづらいコードが大量に存在したら、それをレビューする人、メンテナンスする人の工数が増大するとは思いませんか。13:05とりあえず、コーディング規約どうこう以前の問題が貴方にあるのはわかりました。遠いところで幸せになってください。13:13一口に「コーディング規約」といっても、いろんな性質のものがあります。読みづらいスタイルのコードを読むのはストレスがかかります。誰もが同じスタイルでコードを書けば、そのような問題は起こりません。ネーミングに関するルール例えば、スコープによって変数名のルールを変えるとか、変数名や関数名をどうつけるべきだとか、そのようなルールです。これも同じく全員がルールを守っておれば、コードのリーダビリティは上がります。言語上の問題に関するルール例えば、==の他に===がある言語で、「==は使ってはいけない」などのルール。これは、バグの温床を作らないということで、明確に品質の低下を防ぎます。最近は、どの言語でも大抵静的解析ツールがあり、できのよいIDEならリアルタイムでルール違反を示してくれるので、コーディング規約を守るのは過去に比べればずいぶん楽になっていると思います。16:17ツールで書式が整えられるからコーディング規約が要らないとか暴挙でしょ。そのツールはコメントも自動で入れてくれるんでしょうか。それともソースにコメントなんて要らない派なんでしょうか。規約が無ければ一切入れない人も見かけますよ。そもそも品質はこれ1つで全て出来るというような銀の弾は無いので地道に品質を上げていくしかないです。確かに規約に盲目的だったり不必要な規約が入っている物も見かけますけど(SQLに改行を入れてログで見やすくしましょうとか意味不明)、そういうのは指摘するべきだし、出来ない立場ならただ守るしかないでしょ。工数上がる旨と本来必要なログが流れる旨を指摘しましたが、不要なのは理解しているが全社的な取り決めなのでここだけ変えることは出来ないと返答頂いたので吐き気を催しながら対応しましたけどね。18:30前回のコラムから、読ませて頂きました。その上で、まず思ったことが「コーディング規約」と言う大きなくくりでお話をされているため、書き手と読み手でイメージに齟齬があるような気がしました。結論をまず書かれるのであれば、レベル感を同じにする意味でも、具体的に○○なコーディング規約はダメ!とされたほうが良かったかなと思います。それはさておき、おっしゃられているのは、規約作成者が説明出来なかったり、過去からの踏襲で無駄にロジックが制限されるような規約の事かなと私は思いました。それについては激しく同意です。品質はおろか保守性や可読性にも帰依しないと思います。ちなみに、私自身は「規約は保守性と可読性のため。」と考えている一人です。ちなみにコメントを書きながら、品質と言う観点でのコーディング規約を少し考えてみましたが、メモリリークなどを防ぐため(Javaでループの中で無駄にオブジェクトをnewするなとか。)とかであれば、品質には帰依するかもしれませんね。さん誰しも問題の一つや二つ抱えてるものでしょう。整形して動作が変わるとか(yamlとか以外は)聞いたことがない結局私のいいたいのもそれです。するなら、なぜ最初にSCMにコミットする人がそうしないんですか?私のことでないので知りません。SCMのコミットをフックして自動整形するという方法もあります。いう便利な使い方があるのであれば、ご活用いただければと思います。それをレビューする人、メンテナンスする人の工数が増大するとは思いませんか。印刷に赤ペンでやればそうなります。事実、そういう原始的な方法をとられて偉い目にあったことがあります。インデント等のスタイルに関するルールコラム本文に書いてますが、こだわりたいならツール使ってください。手作業でやるとしんどいです。ネーミングに関するルール考え込まない程度に決めといてください。一応、コーディング規約作るなという話はしてません。教育した上でシンプルにまとめてとコラムに書いてます。言語上の問題に関するルールそれ、ロジックです。何かぶれているので意見には同意できません。ツールを活用しようとしているので、現場での問題解決は一定の成果が上がっているのではないでしょうか。ツールを活用しようとする姿勢は私も取り入れていきたいです。さんコメントを読んでいて、言いたかったことがだいたい伝わってる感じでホッとしております。コメントを読んで思ったのですが、例えばこれ。メモリリークなどを防ぐため(Javaでループの中で無駄にオブジェクトをnewするなとか。)これはソフトウェアの挙動に関わる分分なので、私はロジックだと受け取っています。規約に書くのは、例外や判断の分岐が発生しない項目に絞るべきかと。例外や分岐が発生するものは、エンジニアの教育で方針をあわせておくとか、そういうアプローチで対応すべきかと。これはあくまで私の一意見です。私が警鐘を鳴らしたいのは、大量のコード規約を作って目検をやってる人です。このコラムを読んでいる人で当てはまらない人も多いかと思います。それは幸せなことだと思うので、コーディングライフを楽しんで頂ければと思っています。さんコメントの内容としては、最初の一文「ツールで書式が整えられるからコーディング規約が要らないとか暴挙でしょ。」意外は、あまりコラムと関係が無いように読み取れます。客観的に見てご自身の独白です。コーディング規約は要らないとは書いていません。技術教育を行った上で規約をシンプルにまとめないと運用できないということです。苦労なさった方なのだろうとは思います。考えて行動されていることもコメントから読み解けます。hogeさんがコラムを誤読するように、規約に書いても誤読する人はいます。守って欲しいなら、シンプルにまとめる努力と教育は必要ということです。20:16あとコラムと全く関係の無い話です。いう風に行間を一つ空けたい時は、改行を二つ入れてください。行間を空けている方を見かけますが、コメントを確認した後に私が手作業で直してます。ブラウザによっては字の折り返し部分で改行が入ってしまうことがあるようです。(明らかに変なところで改行が入っていることがある)。これも私が手作業で直してます。09:06>こういう風に行間を一つ空けたい時は、改行を二つ入れてください。コーディング規約の例かと思いました。さんあなたのために私の時間を使うのが馬鹿らしくなりましたので、もう議論はしません。12:44提供側が守るべきなのは顧客の期待を裏切らないことなので、それ以外の努力は、まぁ本質的に無駄と言えるかもしれません。規約というかルールを作ると、それを監査するコストが必ずかかります。そのコストをまんま顧客に負担させような発想ならAIにやられちゃうかも、ですね。さんそれはおこがましいです。こちらは匿名Cさんの意見も認めた上で、最初から議論する気もありません。付けてくれたコメントなので、私なりによく読んで返信を付けています。勝手に持論を展開して「時間を使うのが馬鹿らしくなりました」はさすがに失礼ですよ。さんこれ、実際に投稿してみないと分からないんですよね。これが>こういう風に行間を一つ空けたい時は、改行を二つ入れてください。コーディング規約の例かと思いました。なります>こういう風に行間を一つ空けたい時は、改行を二つ入れてください。コーディング規約の例かと思いました。-------------------------------------というそれだけです。書いていて、すごく違和感を感じますが、反映されるとそれなりになります。さんおっしゃるその通りです。AIでそれが実現するまで、あまり長くかからなそうですね。02:22前回からの意見をコメントまで一通り読ませて頂き、とても挑発的な意見だと感じました。同時に、とても大切な事が欠落している事に、悲しさを感じました。後者は「品質を上げることを目的とされたコーディング規約」の様です。「可読性を上げることを目的とした整形方法としてのコーディング規約」もあるようですが、これは後者と書いた側に含まれます。私自身は「コーディング規約」を信じております。世の中には、確実に「品質を上げることを目的とされたコーディング規約」が存在し運用されております。品質向上」と検索をすれば、大量の事例が出てきます。その本質は「エンジニアの持つ特性を解析したり、継承したりして、プロジェクトとしての知的財産として扱う」事を目的としていることも、それらに目を通せば理解できるでしょう。コーディング規約についてのコラムを書く前に、マイクロソフト社の発表しているC#やVBのコーディング規則は確認されましたか?Javaは?PHPは?通産省は?私自陣は、これらのすべての内容に両手を挙げて賛同するわけではありません。コーディング規約(規則)として発表されているこれらは、過去のエンジニア達が積み上げてきた経験の一つの成果です。その中に含まれるものを挙げればキリがありませんが、インデントや空白の入れ方等の可読性の向上等も、その一つです。それらを全て細かく意識せず使うことができるところが、コーディング規約の最大の利点です。個性を出して失敗するより、定石や安定行動と言われる手法を使って安全に効率的に開発すべきです。その内容が意識できるのであれば、そこで個人の特性を発揮することもできるでしょう。ここまでのことについて調査や理解を、コラム執筆時点でされておりましたでしょうか?もしそれをせず、自らの体験が世界で起きてる事例の全てであるかのような認識でもって、コーディング規約に対して批判を行っていたのであれば、それは筋が違っていませんか?そして、Horus様が批判をしたい本当の対象は「コーディング規約の尊守率を品質の指標と勘違いしている」ではないでしょうか。あるのならば「コーディング規約を品質の指標とせずにもっと適切な指標を使え」で済む話であり、「コーディング規約をコーディング規約として正しく運用しろ」という話ではないでしょうか。すると、コーディング規約を槍玉に挙げて、批判している理由はそもそも存在しないのではありませんか?また最後に蛇足ではありますが、適切なコーディング規約は品質の向上だけでなく、作業工数を減らし作業の効率化ももたらす例として「デザインパターン」を挙げさせていただきます。さん問題提起なので反対意見も多いと思います。挑発的と取られても致し方ないです。コメント欄で何人かの方が語っておられる「コーディング規約」は別物ではないか、という認識を受けましたが、その点はご承知でしょうか?この手のことを書くと、誤読したコメントがたくさん付きます。いうリスクは承知の上でコラムを書いています。率直、コーディング規約について議論する気もありません。コラムの目的は、SESでやっているクソなコーディング規約を運用している人に何らか刺されば目的達成です。どこからどこまでがコーディング規約かなどどうでもいいです。そんな言葉の定義で議論するのは時間の無駄です。いうことは自分の目的を定められない人の暇つぶしと認識しています。私は、コメントに書き連ねた理想を基準に書いてません。自分の身に起こった事実を元に書いてます。その事実とかけ離れているからコラムを書きました。さんの意見を否定する気はありません。内容自体は元々知っていることなので同意します。知識を羅列して理想を語っているだけだと指摘はしておきます。「デザインパターン」を挙げる相手はクソみたいなコーディング規約を掲げているSESに毒された人たちでしょう。向ける矛先を間違えています。SESでやっているクソなコーディング規約を運用している人に何らか刺されば目的達成です。私に刺さったように思います。工数ばかりかかり、さらに本来規約が目標とすることも達成できない可能性があるからない方がいい逆に解決できれば、可読性、保守性(ひょっとしたら各々の技術レベルアップ)につながる「規約にに則っているか否かで無駄な議論」について1点だけ思うのは、ロジック的な規約で意見がぶつかった時はお互い納得するまで、やりあった方がいいように思います。コード規約に言語上間違えた書き方が記載されていました。どこからどこまでがコーディング規約かなどどうでもいいです。そんな言葉の定義で議論するのは時間の無駄です。いうことは自分の目的を定められない人の暇つぶしと認識しています。ここ、それはコーディング規約じゃなくてロジックですってぶった切ってる発言がブーメランには......ならないんでしょうね、よく分かりませんが。問題提起なので反対意見が多いのではなく、書き方の問題で反対意見が多いのではと感じました。「品質を上げる効果が全くないクソのようなコーディング規約」に縛られている哀れな方に向けたもの、だと認識をしています。その方たちがコラムを読んで何かしら気づきがあれば、という点には非常に納得できます。エンジニアライフで投稿した場合、上記に当てはまらない方の目につく可能性の方が高く、結果反発意見が噴出した、ように見えました。コラムの中で、例えば「コーディング規約が正しく運用されている、或いは理想論を語れば、品質の向上・担保ができる」ことを認めた上で、(Horusさんが体験した限りの)実際の現場ではそうではないことが多いこと、そう言った理想的な環境の人は見ても意味がないし、そういった現場での活用例は特に求めていませんのでお帰りください、といったことが書かれていれば特に反発意見は出なかったのではと思います。コーディング規約の定義をどうでもいいと仰っているので、私が認識していたHorusさんの伝えたいことが根本から間違っている可能性も高そうですけど。万人に受ける必要はなく、伝えたい人にだけ伝わればいいというスタンス自体は否定しません。今回のように伝えたい人以外のレスが多くなり、批判的な内容が多くなってしまった場合、1.自分が信じていたことを否定している人がいる2.コメントを見てみたら否定的な人が多い3.この人の意見は間違っている、つまり自分は正しい!とか、よく分からない思考回路を以て自身を正当化してしまいかねないな、と思いましたので。予防できるのであれば書き方を少し気を付ければ済む話なので、より目標を達成しやすくなるのではないかなと思った次第です。尊敬されている某コラムニストさんがたまにしか炎上しなかったのは、極端なことを書きながらも、あらかじめターゲットを絞っていることが明記されていたり、本文から読み取れたりしたからだと思います。申し訳ありませんが、Horusさんのコラムからはそういったことがあまり読み取れないように感じました。個人の意見ですが、Horusさんがこれによってなにか気付きがあればいいなと思います。私に刺さったように思います。いうことは私が刺したひとですね。さんに付けたコメントですかね?これについては、コメントを付けた方がコラムも読まずに一方的に持論を垂れるのでたしなめただけです。こちらの話も聞かない人と議論する価値はないですから。コメントに書いてあるように「全社的に云々」と言われて規約を更新できないようなところはやはり規約はない方がみんな幸せかもしれないですねご指摘の通りです。規約というのは基本的に禁止事項です。増えれば増えるほど手段が減ります。その、減った手段をどう補うかが問題の本質だと考えています。規約で縛り過ぎると、誰も改善をやらなくなります。私の知っている事例では、上手い書き方をしたら「その書き方、いいね!」と褒めてました。すると、勝手に考えて良い感じの書き方をしてたようです。これが理想かと思います。ここ、それはコーディング規約じゃなくてロジックですってぶった切ってる発言がブーメランには......ならないんでしょうね、よく分かりませんが。分からずに発言する方がよっぽどブーメランですよ。何か投げるなら覚悟を決めましょう。コーディング規約の定義をどうでもいいと仰っているそれは話が長いのでぶったぎっただけです。こんな狭いコメント欄で議論は勘弁してください。エンジニアライフで投稿した場合、上記に当てはまらない方の目につく可能性の方が高く、結果反発意見が噴出した、ように見えました。反発意見が出ないようなヌルいコラムを書く気はありません。某コラムニストさんには挑戦です。申し訳ありませんが、Horusさんのコラムからはそういったことがあまり読み取れないように感じました。あの人みたいに何年もやってるブランドありませんから。「Anubisさんは無理だが、駆け出しのコイツならいけるんじゃねw」という人もたくさんいると思います。おとといお越しください。個人の意見ですが、Horusさんがこれによってなにか気付きがあればいいなと思います。