職場で確立された慣習に従うためだけに、悪いコーディングスタイルに従うべきですか？

私は約1年間仕事で働いています。私は主にCバックエンドのメソッドを使用するGUIインターフェースで作業しますが、通常は戻り値を除いてそれらを処理する必要はありません。私たちのGUIは、制限があるため、かなり合理的に構成されています。

私は、プログラムのコマンドライン部分に関数を追加する仕事をしました。これらの関数のほとんどは、長さが300行で使いにくいものです。特定のアラーム情報を取得するためにそれらの断片を収集しようとしていますが、整理するのに苦労しています。単一の長い関数でテストを行うことで、テストをより複雑にしていることを知っています。

既存の機能のスタイルに従って、すべてを巨大な機能に保持する必要がありますか、それともアラームを独自の機能にカプセル化する必要がありますか？

現在のコーディング規約に反するのが適切かどうか、または単に弾丸を噛んでコードを少し混乱させて書くべきかどうかはわかりません。

要約すると、私は比較しています

showAlarms(){
    // tons of code
}

に対して

showAlarms(){
   alarm1();
   alarm2();
   return;
}

alarm1(){
    ...
    printf(...);
    return;
}

編集：みんなのアドバイスのおかげで、ファクタリングされたコードを設計し、彼らが何をしたいのかを尋ねることに決めました、そして彼らがそれをすべて1つにしたいなら、ファクタリングされたコードから切り取って1に戻すことができます大きな機能。これにより、すべてのコードを単一の定義で必要とする場合でも、簡単に記述してテストできるようになります。

更新：彼らはファクタリングされたコードに満足しており、複数の人がこの前例を設定してくれたことに感謝しています。

これは本当にあなたとあなたのチームメイトの間です。誰もあなたに正しい答えを伝えることができません。ただし、行間をあえて読むと、このスタイルを「悪い」と呼ぶという事実から、ゆっくりとする方が良いという情報が得られます。実際に「悪い」コーディングスタイルはほとんどありません。私が使用しないものもありますが、彼らには常に韻や理由があります。これは、これまで見てきた以上のストーリーがあることを私に示唆しています。尋ねることは非常に賢明な呼び出しです。誰かがあなたが知らないことを知っているかもしれません。

私は、リアルタイムのミッションクリティカルなコーディングへの最初の進出で、個人的にこれに遭遇しました。私はこのようなコードを見ました：

lockMutex(&mutex);
int rval;
if (...)
{
    ...
    rval = foo();
}
else
{
    ...
    rval = bar();
}
unlockMutex(&mutex);
return rval;

私は明るくて光沢のあるOO C ++開発者であったため、RAIIを使用するのではなく、ミューテックスを手動でロックおよびロック解除することによるバグのリスクについてすぐに声をかけました。私はこれが優れていると主張しました：

MutexLocker lock(mutex);
if (...)
{
    ...
    return foo();
}
else
{
    ...
    return bar();
}

もっと簡単で安全ですよね！コンパイラーがあなたに代わってできるのに、すべての制御フローパスでミューテックスのロックを解除することを忘れないでください。

さて、後で見つけたのは、これには手続き上の理由があるということです。確かに、ソフトウェアが正しく機能し、使用が許可されているツールの有限リストがあることを確認する必要がありました。私のアプローチは別の環境で優れていたかもしれませんが、私が働いていた環境では、RAIIのC ++コンセプトをコードのセクションに取り入れただけなので、アルゴリズムの検証に関わる作業量を10倍に簡単に増やすことができますこれは、Cスタイルの考え方を実際に受け入れやすい標準に従っていました。

だから、私にとって悪い、実に危険な、コーディングスタイルのように見えたものは、実際によく考えられていました。

だから周りに尋ねる。どうしてこの方法でそれをするのかを理解するためにあなたと一緒に働くことができる上級開発者が必ずいるでしょう。または、コードのこの部分のリファクタリングのコストと利点を理解するのに役立つ上級開発者がいます。どちらにしても、聞いてみてください！

正直に言って、300行の使いにくい機能を持っているのはスタイルの問題だと思いますか？それで、悪い例に従うと、一貫性のためにプログラム全体をより良い状態に保つことができますか？あなたはそう信じていないと思いますが、そうでなければここでこの質問をしたことはないでしょう。

私の推測では、私たちのビジネスには読みやすさ、コード品質、適切な命名、単体テスト、リファクタリングを気にせずに機能の上に機能を積み重ねる平凡なプログラマーが多く、適切な抽象化を作成することを学んだことがないため、これらの機能は非常に長いと思います。その群れを追いたいのか、より良いプログラマーになりたいのかを自分で決めなければなりません。

コメントによる補遺：「300行」と「使いにくい」は、不正なコードに対する私見の強い兆候です。私の経験では、Cort Ammonの答えの例に匹敵するような、より読みやすい方法でこのようなコードを実装できない「隠された技術的理由」はほとんどありません。ただし、コードまたはこの「スタイルの種類」を変更できない不明瞭な理由を見つけるのではなく、物事を壊さずにコードを安全にリファクタリングする方法を見つけるために、チームの責任者とこれを議論する必要があるCortに同意します。

番号。

本Pragmatic Programmerで、著者はBroken Window Theoryについて話しています。

この理論の状態：

壊れた窓がいくつかある建物を考えてみましょう。窓が修理されていない場合、破壊者はさらにいくつかの窓を壊す傾向があります。最終的に、彼らは建物に侵入することさえあり、もしそれが空いているなら、おそらく内部の不法占拠者または小火になります。

または、舗装を検討します。いくらかのごみがたまります。すぐに、より多くのごみが蓄積します。結局、人々はそこに持ち帰り用のレストランからゴミの袋を置き去りにしたり、車に侵入したりしさえします。

本の中で著者はこの理論とコードの類似点を書いています。このようなコードを見つけたら、停止して、まったく同じ質問を自問します。

答えは「いいえ」です。

この壊れたウィンドウ-私たちの場合は悪いコード-を離れると、誰もが壊れたウィンドウを残してしまうという効果が生まれます。

そしてある日、コードは崩壊します。

Clean CodeとClean Coderのコピーを全員に渡します。

そして、あなたが主題にいる間、TDDのコピーも良いものです。

はい、どうぞ。構造！=スタイル

あなたはスタイルではなく構造について話している。構造は一般に、組織への適切性ではなく、特定の問題への適切性のために選択されるため、スタイルガイドラインは（通常）構造を規定しません。

注意してください

自分には発生しなかったかもしれない他の領域でマイナスの結果を引き起こしていないことを確認してください。例えば、

• 既存のコードとの類似点をなくしたため、diffやコードのマージを複雑にしないでください。
• 例外フローが正しくバブルし、スタックトレースが読みにくいナンセンスの巨大な山で汚染されていないことを確認してください。
• 直接呼び出された場合に問題を引き起こす可能性のあるパブリックエントリポイントを誤って公開しないようにしてください（マップに配置したり、エクスポートしたりしないでください）。
• グローバルな名前空間を散らかさないでください。たとえば、小さな関数がすべて、関数ローカルスコープで以前に宣言された何らかのグローバルコンテキストを必要とする場合などです。
• 必ずログを確認し、コードで生成されたログが、触れていないコードのログと絡み合って混乱するかどうか、サポートチームにいるかどうかを自問してください。
• 既存のスタイルに準拠していることを確認してください。たとえば、旧式のハンガリー語表記を使用していて、目が出血する場合でも、一般的なコードベースと一貫性を保ちます。ハンガリーの表記法を読むよりも苦痛なのは、誰が何を書いたかに応じて、12種類の表記法を使用するコードを読むことだけです。

穏やかな

あなたはチームの一員であり、優れたコードは重要ですが、休暇中に書いた内容をチームメンバーが維持できることも非常に重要です。古いスタイルに慣れている人にとって意味のあるフローに固執するようにしてください。あなたが部屋で一番賢い人だからといって、みんなの頭の上で話し合うべきだとは限りません！

私はこれをコードの慣例とは思わない。私はこれを、理解しやすい保守可能なコードの書き方を理解していない誰かと見ています。300行の関数が許容される理由を理解しようとしながら、これを行うことの利点をチームに提案し、教育するときに、コードをさまざまな関数に分割します。私は彼らの推論を聞いてとても興味があります。

答えはコードレビューにあります。

本当の問題は、適切にファクタリングされたコードを提出すれば、それを使って喜んで作業できるのはあなただけになるかどうかです。

私は、ここにいるほとんどの人と同じように、300行の機能は憎むべきものだと信じています。ただし、Windexを埋め立て地に持ち込むことはあまり役に立ちません。問題はコードではなく、コーダーです。

ただ正しいだけでは十分ではありません。このスタイルで人々を売る必要があります。少なくともそれを読んで。あなたがこの貧しい人のようになっていない場合：あなたのスキルがあなたの同僚よりもはるかに高いために解雇されます

小さく始めます。周りに尋ねて、他の誰かがより小さな機能を好むかどうか調べてください。コードベースをよく調べて、誰が最も小さいコードを書いているかを把握できるかどうかを確認します（最もuいコードが最も古いコードであり、現在のコーダーがより良いコードを書いていることがわかります）。これについて彼らに話し、あなたが同盟国を持っているかどうか確かめてください。同じように感じている他の人を知っているかどうか尋ねます。小さな機能を嫌う人を知っているかどうか尋ねます。

この小さなグループを集めて、変更について話し合ってください。書きたい種類のコードを見せてください。彼らがそれを読むことができることを確認してください。異議を真剣に受け止めます。変更を加えます。コードを承認してください。あなたは今、あなたの背後にある会議の力を持っています。これらのいくつかを追加すると、紹介した新しいスタイルを明示的に受け入れる1ページのドキュメントを作成できます。

会議は驚くほど強力なものです。彼らは影響力を生み出すことができます。Cloutは、この運動に反対する人々と戦うために使用するものです。そして、これがこの時点でのことです。ムーブメント。あなたは現状を改善する権利のために戦っています。人々は変化を恐れます。スウィートトーク、カジョール、プロッドが必要です。しかし、少し運が良ければ受け入れられるようになります。

時々、あなたは流れに行かなければなりません。

あなたが言ったように、あなたは既存の動作中のコードベースに関数を実装することを任されました。

混乱に関係なく、私はそれをきれいにしたいということを理解しています。しかし、ビジネスの世界では、コードをリファクタリングする機会が常にあるとは限りません。

私はあなたがするように頼まれたものだけを実行し、先に進むと言うでしょう。

リファクタリングや書き直しの価値があると思う場合は、チームと議論するためにそれを持ち出す必要があります。

慣行が悪いという声明を出す前に、まず、大きな方法の理由と悪いと思われる他の慣行を理解することへの一歩を踏み出します。

次に、テストカバレッジが非常に高いか、または非常に高いことを確認する必要があります（主要なリファクタリングを行わずに取得できる場合）。そうでない場合は、コードを作成していなくても、カバレッジを非常に高くするように努力します。これは信頼関係を築くのに役立ち、あなたの新しいチームはあなたをより真剣に受け止めます。

これらの基盤をカバーしたら、彼らの正しい心の誰もあなたに挑戦しません。ボーナスアイテムとして、いくつかのマイクロベンチマークを実行すると、ケースに追加されます。

多くの場合、あなたの言い方はコード文化を変えることに大いに役立ちます。例でリード。さらに良いことに、あなたが書くことができるコードを待ちます-それとビオラから地獄をリファクタリングしてユニットテストします-あなたは聞かれます。

この種の質問は、基本的には「チームメイトを読んでください」です。インターネット上のランダムな人々はそれを行うことができないので、あなたが得るすべての答えはコーディングスタイルについての人々の個人的な意見です。コンセンサスはより短い方法が望ましいですが、あなたはすでに自分でそう考えているようですので、それを再度述べる必要はありません。

そのため、現在のコードベースは、あなたが好むものとは異なるコーディングスタイルを使用しているようです。あなたは何をするべきか？最初に把握する必要があります：

1. これは、現在のチームがサポートしている意図的な設計決定ですか？
2. 彼らはあなたにこのスタイルに従うことを望んでいますか？

見つける方法は1つしかありません。尋ねます。

長い機能を持つ理由は複数あります。チームは、長い機能が複数の短い機能よりも優れていると考えているためかもしれません。また、レガシーコードであり、チームは新しいコードがよりクリーンなデザインに従うことを好むためかもしれません。したがって、チームと話をせず、彼らの理由を理解しないと、どちらの選択でも開発者としてトラブルに巻き込まれる可能性があります。

「スタイル」にはさまざまなレベルがあります。

1つのレベルでは、通常はコーディング規約の一部であり、これは空白、空白行、角括弧、および名前の付け方（大文字と小文字の組み合わせ、アンダースコアなど）を配置する場所を意味します。

別のレベルはプログラミングモデルです。静的モデルの回避、抽象クラスのインターフェイスの使用、依存関係の公開方法、難解な言語機能の回避などがあります。

次に、プロジェクトで使用されているライブラリとフレームワークがあります。

関数サイズに最大制限がある場合があります。しかし、最小限の制限はめったにありません！だから、あなたはこれらの事柄のどれが重要だと考える力を見つけ、それを尊重しようとするべきです。

チームが既存のコードのリファクタリングに不利であるかどうかを調べる必要があります。リファクタリングは、可能であれば新しいコードの追加とは別に行う必要があります。

ただし、既存のコードをリファクタリングしたくない場合でも、追加する新しいコードの抽象化でいくつかのレイヤーを導入できる場合があります。つまり、時間の経過とともに、より良いコードベースを開発し、それのメンテナンスが必要です。