コーディング標準の恐怖物語

最初の仕事では、マークという名前の男のために働きました。 マークは非常に賢く、目標指向のプログラマーであり、私は彼から多くのことを学びました。 しかし、彼と私は常に標準とコーディングスタイルについて突き止めました。



次に、VAX BasicでDEC VAXの下に書き込みました。 ストーリー全体を理解するには、VAX Basicがあなたが考えている古典的なBasicではないことを理解する必要があります。 DECコンパイラ開発者は、Basic構文から始めて、FORTRAN、Modula II、およびPascalのすべての優れたものを徐々に追加しました。 たとえば、1980年代初頭に、言語にはすでに例外がありました。



また、1980年代には、豊富なコードエディター（Visual Studioなど）を備えた本格的なIDEがなかったことを覚えておく必要があります。 TPU（Text Processing Utility）と呼ばれるものを使用しました。 このプログラムはメモ帳よりもやや強力でしたが、最新のエディターよりもかなり劣っていました。 その後、彼女はEmacsおよびviと競合しました。 その結果、各開発者は独自のスタイルのコードを担当し、テキストエディターはこの問題にまったく干渉しませんでした。



マークは、コードを記述するための厳格なルールと標準のセットを定義しました。 彼のこれらの基準の順守は狂信に近いものでした。 たとえば、コードレビューのために、彼は自宅から夜に動作しているコンピューターに接続することができます（その時点では、速度が約1200ボーのモデムを使用することを意味していました）。 翌朝、私はマークとの会議を待っていました。そこでマークは行ごとに私のコードについてコメントし、スタイルのエラーを指摘し、今日修正するよう要求しました。



いくつかのルールは不合理に思えました。 たとえば、彼は各行がタブと2つのスペースで始まることを要求しました。 考えてみてください-タブと2つのスペースの両方！ なぜ2つ？ 私はまだこれを知りません、しかし、それは我々の標準でした。 マークには、変数とは言えない単語のリストがありました。 はい、それらの一部は言語のキーワードのリストからのものでしたが、約半分はマークが個人的に好きではなかった単なる単語でした。 彼は、正確に長い行をどこに折り返すか、その場合はどのようなインデントが必要かなどを定義しました。



私はこのすべてについておかしくなりました。 これらの2つのスペース、これらの禁じられた言葉-なんてナンセンスだ！ いくつかのルールは一見無害でした-Ifの後の次の行にThen行をラップするように。 しかし、この場合に新しい行が出現したという事実は、再びこれらの2つのスペースを追加することにつながり、再び私を怒らせました。



しかし、私は何ができますか？ マークは私の直属の上司であり、これは大学卒業後の私の最初の仕事であり、80年代の不況が庭にありました。 何千人もの有資格プログラマーが仕事なしで労働市場に出ていたので、私はそれを単に危険にさらすことはできませんでした。



私は気にしないと言っているのではありません-時々、私のキャラクターが単に私を黙らせないことがありました。 しかし、それでも、私は議論を急性期に至らなかった。 まあ、マークは私のボスのままであり、標準への彼のコミットメントはどこにも行かなかったので、これらの標準は私の第二の性質になりました。 その後、私はあなたがそれらについて別の方法で考えることができることに気付きました。 基準は私の想像力を制限するものではなく、彼らの枠組みの中で創造する機会を与えてくれました。



有名な芸術家の作品を見ると、創造性に対するいくつかのフレームワークの賦課がしばしば傑作を作成するための鍵であったことがわかります。 創造性のある人々はしばしば意識的にこれらの制限に行きます-これが彼らの創造性の背景をつかむ方法です。 ソフトウェア開発は100％の芸術だとは思いませんが、優れたコードで創造性を見ることができます。



これらのコーディング標準をすべて吸収していたMarkでの数か月の作業の後、別の会社が会社を買収して吸収しました。 マーク、私、および他の数人は、このプロセスをうまく生き延びました。 私たちは全員ミネソタからバーミンガムに移りましたが、それは別の話です。 一部の州の間の文化的な違いは、アメリカとヨーロッパの間の文化の違いよりも時々悪いとしか言​​えません。



私の最初の会社を買収した会社もソフトウェア開発に関与していました。 従業員数も同様でした。 ただし、コーディング標準はまったくありませんでした。 また、彼らはDEC VAXの下で書き、VAX Basicも使用しました。 しかし、各開発者は望みどおりに書き、他の人のコードには注意を払いませんでした。



プログラマーの1人はFORTRANで始めました。 彼は、VAX BasicコードはFORTRANスタイルで記述できることを発見しました（そして、DECはほとんどのFORTRAN機能を慎重にBasicにドラッグしたことを覚えています）。



別の開発者がAppleでのプログラミングを学んでいた] [そしてVAX Basicのコードには行番号がありました。 冗談じゃないよ！ Applesoftのように！



このオフィスの全員が、まったく異なる方法で、まったく異なる方法で書きました。 背後にある古いものを引きずる人もいれば、新しいアプローチを使用する人もいました。 後で、彼らが意図的にそれをしたことが判明しました。 その理由の1つは、彼らの誰もが何か新しいことを学びたくなかったからであり、また、それが何らかのセキュリティを彼らに与えたからでもあります（あなた以外の誰もあなたのコードを理解せず、サポートする必要がある限り、彼らはあなたを解雇しません）。



これはMarkの世界の正反対でした。Markの世界は私には馴染みがあり、各行が明らかに同じ標準に対応していたため、誰がこのコードまたはそのコード行を書いたのかを言うことはできませんでした。



そして、これが私の職業生活における最初の洞察が私に現れた瞬間でした。 はい、コーディング標準に厳密に準拠することは容易ではありませんが、代替手段ははるかに悪いです！



それ以来、私が働いていたすべてのプロジェクトで、厳格な標準とプログラミングスタイルを適用するというアイデアを促進しようとしました。 さらに、標準のいくつかの奇妙な点（タブの後の2つのスペースなど-これは非常に、非常に、非常に愚かです！）標準がない場合よりもはるかに優れています。 そして、カオスが唯一の選択肢であるなら、私はこれらの2つのスペースでさえも激しくサポートします。



もちろん、標準を議論する段階で、明らかに悪いことを見つけて批判しようとしますが、決定が下されるとすぐに受け入れられ、私は最も猛烈な擁護者になります。



マークから多くのことを学びました。 何かが良かった、何かが悪かった。 しかし、彼が標準を順守していたことが、品質の高いソフトウェアに対する私の考えを大きく形作りました。