あなたは実際に「きれいなコード」を書いていますか？[閉まっている]

何人かのプログラマーがコードを何度も何度も微調整して、「うまく機能する」ようにするだけでなく、「見栄えよくする」ようにしました。

IMO、「きれいなコード」は実際、あなたのコードがエレガントで、完全に理解でき、保守可能であることを示す賛辞です。そして、見た目が魅力的なコードと、ストレスの多いコードを選択する必要がある場合に違いが生じます。

では、実際に「クリーンなコード」を書く人は何人いますか？それは良い習慣ですか？この他の利点または欠点は何ですか？

私たちの多くはきれいなコードを書かないと主張します。そして一般的に、それは私たちの仕事ではありません。ソフトウェア開発者としての私たちの仕事は、時間通りに機能する製品を提供することです。

Joel Spolskyのブログ記事：The Duct Tape Programmerを思い出します。

彼はCoders at Workから引用しています。

一日の終わりに、f ***** gのものを出荷してください！コードを書き直してきれいにすることは素晴らしいことであり、3回目には実際にきれいになります。しかし、それはポイントではありません。コードを書くためにここにいるわけではありません。製品を出荷するためにここにいます。-ジェイミー・ザウィンスキー

また、ロバート・マーティンのブログの反応を思い出します。

そう。賢明であれ。きれいにしてください。シンプルに。船！ダクトテープの小さなロールを準備ができた状態に保ち、使用することを恐れないでください。-ボブおじさん

開発者が書いたコードがクリーンであり、作業（成果物）である場合、誰にとっても良いことです。しかし、開発者がクリーンで読みやすいコードをタイムリーに提供することを犠牲にしていじくり回しているのであれば、それは悪いことです。動作させ、ダクトテープを使用して、出荷します。後でリファクタリングして、非常に豪華で効率的にすることができます。

はい、きれいなコードを書くことをお勧めしますが、配信できることを犠牲にしてはいけません。ダクトでテープで留められた製品を予定通りに提供することの利点は、決して完成して提供されなかったクリーンなコードの利点をはるかに上回ります。

私が出会ったコードのかなりの部分はきれいではありません。いくつかは実にいです。しかし、それらはすべてリリースされ、実稼働で使用されました。乱雑なコードを書くことは専門的ではないと言う人もいます。同意しません。専門的なことは、それがクリーンであっても面倒であっても、動作するコードを提供することです。開発者は、配信前に割り当てられた時間を考慮して、できる限り最善を尽くす必要があります。その後、クリーンアップに戻ります-それはプロフェッショナルです。うまくいけば、提供されるコードは純粋なダクトテープではなく、「十分にクリーン」です。

コードが非常に読みやすく、クリーンで、保守可能であることを確認する必要があります。それはすべてのプログラマーがしなければならないことです。

しかし、あなたはその作者の自我以外の何にも役立たないことについて話しているover styling（その用語のように少女コードよりもいい）。

過去に多くの開発者が自分たちの作成をとても誇りに思っていました（トイレのように知っています;））、彼らはコードをきれいにし、磨きました。それらのいくつかは非常に細心で、メンバー間の正しい空白が尊重されることを保証しました。

多すぎる。

そのような行動は逆効果だと思います。では、プロのコンテキスト、あなたでなければならないプロ。きれいで、非常に読みやすく、保守しやすいコードを書いて、幸せなユーザーや同僚と話をすることで満足を得ることができます。

この質問に対する受け入れられた答えに同意しません。

あなたの責任は明らかに出荷することですが、通常、あなた自身と将来の開発者が可能な限り費用対効果の高いものを出荷する責任もあります。

文書化されていない巨大なシステムを理解してデバッグしなければならない、貧弱なメンテナンスプログラマーまたはコンサルタントとしての期間を費やしてきました。最初の開発者による余分なN時間の労力が私の時間の面で5Nのコスト削減につながる可能性がある多くの状況を考えることができます。

これについては統計情報が浮かんでいますが、複数のプロジェクトにわたる私の経験では、記述されたコードの各行は、拡張および保守中に5〜20回読み取られます。

だから、コードをその寿命の1インチ以内にクリーンアップすると言いたいです。時間がかかりますが、プロジェクトの全期間にわたって純コストを節約できる可能性があります。

フードの下でトラブルシューティング、保守、修正がすべて面倒で困難であり、実行するのに必要以上のリソースが必要であることがわかっている場合、私たちの誰もが車を買うでしょうか？

なぜソフトウェアごとに違うのでしょうか？

エンドユーザーが内部を見ることができないからといって、彼らがそれを決して知らないというわけではありません。遅かれ早かれ現れます。

「実際に「クリーンなコード」を書いていますか？」という質問に答える - そうそう。！

「クリーンコード」とは、コードができるだけ明確であることを確認するために邪魔にならないという意味ですか？

そうそう。

コードがすっきり、明確になればなるほど、保守が容易になり、長期的には時間を節約できます。きれいなコードを虚栄心と見なさないでください。将来の労力と時間を節約するための投資と考えてください。

正直に依存します。私は誰もが「きれいに文書化されたコードに満たないものはまったくの悲惨さだ！」多くのコードは、他の誰もが書いていると主張するクリーンで完璧なコードを書くことは非常に困難です。

私は大体私の能力を持っている人が簡単に保守できるコードを書きます。トリッキーな部分にコメントを付け、プログラム、変数、およびクラスにわかりやすい名前を付けて、デプロイします。他に何もする時間がありません。

時々私はそれについて少し罪悪感を覚えますが、そうではありません。あなたが私が日常的に扱っている恐怖のいくつかを見るはずです。数十年に渡り、ドキュメンテーションのない不明瞭な言語のカスタムコード。同僚の1人がVisual Basic 6.0でのみ開発し、暗号化された名前のバイナリを至る所に展開しています。私が交換した女性はRPGでのみプログラムされました。

私が信じているのは、プログラマーとして何年も見たほどひどいがらくたで、誰もがきれいなコードしか生成しないと信じるのは非常に難しいです。

私は「女の子コード」という用語は好きではないと思いますが、きれいなコード=保守可能なコードです。それ以下はプロフェッショナルではありません。

一般的なルールとして、私は自分の混乱を見なければならない次の開発者を検討します。

多くの場合、それは私です...数ヶ月後...それがどのように機能するか覚えていないとき...そして、私は変更を行う時間がさらに少なくなります。

ボブ・マーティンの意味で「クリーンなコード」を書くことを試みます（例えば、OOデザイン）。きれいなコードを書くことには大きな価値があります。それははるかに保守可能です。

次に、ReSharperに「きれいなコード」を作成させます（たとえば、位置合わせ、改行など）。ある良い値はかなりのコードを書くことに。しかし、収益は減少しています。読みやすくするため、ある程度の注意が必要です。

コードを読みやすくするために巨大なコードブロックをきちんと並べる必要があると思うなら、問題はコードの巨大なブロックです！大きすぎます。非常に貧弱に設計されたコードを偽装するために多大な苦労をしている人々の多くの例を見る。

ReSharperがなかったとしても、きれいなコードは残っていますが、それほどきれいではありません。

コーディングに費やす時間の5％を超える時間を費やすべきではないと思います。つまり、私のエディターがより強力になり、より精通すればするほど、私はもっと多くのことをできるようになります。

貴社にとって何が一番の利益になるのか、誰も指摘していないようです。

常にではないにしても、多くの場合、プログラマは単なる従業員であり、管理上の決定が私たちを苛立たせるかもしれませんが、多くの場合、彼らが持っているすべてのデータを持っているわけではありません。

たとえば、会社が、ソフトウェアの準備が間に合わなければ支払われないという条項を契約しているとしましょう（結局、支払われたと思いますが、それは私たちに起こりました）。きれいなコードは重要ですが、支払い日までにコードを機能させることがより重要です！

別の例-会社は財政状態が悪く、資金を調達する必要があります。誰が品質に関心があると思いますか？後で修正できますが、必要な場合は出荷するだけです！

議論は「なぜ私は売り切れてくだらないコードを書くべきなのか？」かもしれません。さて、なぜあなたの会社は毎月あなたに素敵な小切手を払うべきですか？選択肢、私の友人。理想主義をお望みの場合は、Free Software Foundationをお試しください。彼らはかなりクールなことをしていると聞きます（これは私が意味し、FSFとOSSを尊重しています）。

反対に、爆発的な使用量の増加が予想されるプロジェクトに取り組んでいる場合（そのような予測はほとんど正確ではありませんが）、ほぼ確実なメンテナンスであるため、必要な最高のコード品質を備えた強固な基盤を構築することをお勧めしますプロジェクトのコストが大きくなります。

プログラマーは、それが何を意味するにせよ、「きれいな」コードが大好きです。きれいなものに同意することさえできませんが、私たちはそれが大好きです。ただし、使いやすさと正確さがそれほど重要ではない場合もあります。これらは同義語のように見えるかもしれませんが、そうではありません-真のPerlハッカーが2時間使用して捨てるつもりで書かれたコードを4時間で見た場合、それはクリーンではないことを認めますが、動作します。

ですから、時々、自我は別として、私たちはただそれを機能させるべきです。悪いコードを習慣として書くことはお勧めしません。私はただそれが必要かもしれないと指摘しています。あなたの会社が持っていないかもしれない完璧には時間がかかります。したがって、雇用主がソフトウェアを作成することを気にしない場合は、作業コードを書くだけでよいのです。「ワンサイズですべてに対応する」答えではありません-優先順位を付ける必要があります。

「見栄えが良い」とは言えませんが、「エレガントで、完全に理解でき、保守可能」であることは同等です。

私は、「エレガントで、完全に理解でき、保守可能な」コードを書き込もうとしています。これらの基準によりよく一致するように、独自のコードをリファクタリングします。

結果として生じるコストを除いて、欠点はありません。

コードを「見栄えよくする」ために、自動化されたツールがたくさんあります。これは、必要に応じてすべてを適切にインデントし、スペースを空けます。

あまりにも多くのことは決して良いことではありません。

ただし、「汚れた」コードで留意すべき重要なことは、「壊れたウィンドウ」に簡単につながる可能性があるということです。コードのフォーマットが非常に悪い場合、コードベースを初めて使用する人の多くは、メンテナンスと進化で良い仕事をする気が減り、最終的にソフトウェアの動作状態に影響を与える下向きのスパイラルを引き起こすと思います。

したがって、コード内の特定のレベルのクリーンさを維持することは、仲間の開発者以上に有益です。あまり時間をかけないでください（5％まで言及されています）。クラフトのツールを使用して手動タスクを自動化する方法を学習します（この場合はコードの書式設定）。あなたがしていることに責任を持ち、あなたの会社/顧客/ユーザーにとって最も有益だと思うことを常にしてください。

これは、Bob MartinによるClean Codeからの引用です。

このポイントを家に戻すために、もしあなたが医者であり、時間がかかりすぎたために手術の準備としてすべての愚かな手洗いをやめることを要求する患者がいたらどうでしょうか？明らかに患者はボスです。それでも、医師は絶対に服従を拒否すべきです。どうして？なぜなら、医者は患者よりも病気や感染症のリスクについて知っているからです。医師が患者に応じることは専門家ではありません（決して犯罪者ではありません）。

プログラマが混乱を起こすリスクを理解していない管理者の意志に屈するのも、専門家ではありません。

「きれいなコード」は、物理学/工学/数学の試験で書いた方法と同じか、きれいでなければなりません。面倒すぎる場合、グレーダーはあなたの仕事を理解せず、たとえたとえそれが正しいとしても間違っているとマークするでしょう。

コードは読みやすいのが好きですが、最も重要なことは一貫性です。私にとっては、命名規則と関数間のスペース、ifステートメントの同じ行または次の行の括弧などとの整合性を意味します。

もちろん、誰かが一貫したコードスタイルで何かをプログラムし、それでも私を狂気に陥らせ​​ることがあります。特に、「息」のないコード。例えば：

void function1(){
    //whatever code
}
int fooBar(){
    //whatever else
}
Foo* someOtherFooBar(int value){
    if(value){
        //do something
    }
    return ...;
}

さて... Objective-Cのメソッド、さらに多くのネストされたifステートメント、および80文字をはるかに超える行では、見た目が悪くなります。しかし、それはまだ私を悩ます:)

コードをきれいにするためにかなりの時間を費やしています。バグを目立たせるのに大いに役立つと思います。

クリーンコードは将来への投資であるため、「今すぐ出荷する」という概念には同意しません。また、出荷されるソフトウェアが多すぎると、バグが多すぎます。私の意見では、1つのバグを解決する方が、1つの新しい機能を実装するよりも優れています。

また、プログラマーの生産性の推定値を見ると、私はあまり悪いスコアを付けていないと思います。きれいなコードを書くことは習慣であり、プログラマーとしての経験が多いほど、効率的になります。一度も試していないのであれば、明らかに、経験を積むことはありません。

考慮すべきもう1つのポイントは、開発者のほとんどの時間はコードの読み取りに費やされるため、読み取り可能なコードは読み取りに費やす時間を大幅に削減することです。たとえば、文書化されていないアルゴリズムを理解すると、コストがかかり、新しいバグを招く可能性があります。

私が間違いなく見逃しているのは、自分のスタイルに適応できる自動コードフォーマッターです。これは、特に他の人のコードを読むときに、時間を大幅に節約できます。

クリーンコーディングには完全性へのリンクがありますが、これは決して実現しないというリスクがありますが、それは主に最初に問題になると思います。 、年齢を重ねるほど生産性が向上し、厄介なコーダーよりもバグに悩まされることが少なくなります。

これは、私のコーディングスタイルを示すコードです。

「バニティコード」は避けてください。純粋に（またはOCDのせいで）まったく物事を行う開発者はたくさんいますが、他には何もありません。私のパンティーは本当にそれらの人々とねじれます。

与えられた問題を最も効率的かつ理論的に「エレガント」な方法で解決しようとするコードを書きます。その意味では、それだけがきれいです。私が終わったときにたまたま「きれい」だったら、それで。

私の限られた経験で私が見つけたことは、人々が「クリーンコード」について不平を言うとき、さは通常コーディング規約よりもひどい解決策の結果であるということです。

もっときれいなコードを書く努力をしたと思いますが、時間の制約や、何か難しいことに取り組んでいる場合、それは変わる可能性があります。それを機能させることに集中するとき、それは厄介になる傾向があります。それから私は戻ってそれを確認しながらクリーンアップします。コードに戻って、メモリの更新に多くの時間を費やす必要がある場合は、十分なコメントをしていません。

クリーンなコードは優れていますが、他のすべてのコードと同様に、十分にクリーンであることが必要です。5行のコード4スペースと1行5スペースをインデントしても、読みにくくなりません。

私はそれがあなたがしていることに依存していると思います。概念実証アプリケーションを作成している場合、基本的には、お尻をカウボーイでコーディングし、振り返ることはありません。私が実際にしばらく作業する予定のアプリケーションで作業している場合は、今から1か月後に理解しやすくするだけでなく、十分にコーディングするようにします。

あなたのコードをスタイリングするのは少し不確かだと思います。上記のいくつかで述べたように、あなたの仕事はフォーマットされたコードではなく製品を作ることですが、少なくともコメントやコーディングの定義されたスタイルに固執すべきだと思います。ラクダの変数の半分とハンガリー語の残りの半分を見るのは嫌です。

しかし、それは「クリーンコード」の意味にも依存します。

私はそれを認めています。そして、利益は私がそれを見るたびに悩まされることではありません。読みやすくなると思うので、バグはより明白になります。本当の理由は、Iいコードに我慢できないことです。

コードをリファクタリングしてエレガントにすることで、読みやすく、保守しやすくなります。変数の割り当てを調整するなどの小さなことでも：

int foo    = 1;
int bar    = 2;
int foobar = 3;

より読みやすい

int foo = 1;
int bar = 2;
int foobar = 3;

つまり、後でデバッグするときに簡単に読み飛ばすことができます。

また、PHPでは、任意の数のランダムコードブロックが許可されています。これらを使用して、論理タスクをグループ化します。

// do x
{
    // ...
}

// do y
{
    // ...
}

これにより、関連するコードに明確な定義が追加されます。

編集：追加のボーナスとして、これらの論理コードブロックの1つに、if (false)一時的にスキップしたい場合に先行するのは簡単です。

会社の標準に従ってコードを書くだけです。「きれい」にしたい場合は、コードビューティファイアーで実行できます。