職場で確立された規則に従うためだけに、悪いコーディングスタイルに従うべきですか？
私は私の仕事で約1年働いています。私は主にCバックエンドからのメソッドを使用するGUIインターフェースで作業しますが、通常は戻り値を除いてそれらを処理する必要はありません。制限があるため、GUIはかなり合理的に構成されています。
プログラムのコマンドライン部分に関数を追加する必要があります。これらの関数のほとんどは、300行程度の長さであり、使用が困難です。特定のアラーム情報を取得するためにそれらの断片を収集しようとしていますが、整理しておくことが困難です。単一の長い関数でテストを行うことで、テストをより複雑にしています。
既存の関数のスタイルに従って、すべてを巨大な関数に保持する必要がありますか、それとも独自の関数にアラームをカプセル化する必要がありますか？
現在のコーディング規約に反するのが適切かどうか、または箇条書きをかじってコードをもう少し混乱させて自分で書くべきかどうかはわかりません。
要約すると、私は比較しています
showAlarms(){
// tons of code
}
に対して
showAlarms(){
alarm1();
alarm2();
return;
}
alarm1(){
...
printf(...);
return;
}
編集：みんなのアドバイスのおかげで、私はファクタリングされたコードを設計することを決め、彼らが何を望んでいるか尋ねます大きな機能。これにより、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行」と「使いにくい」は、不正なコードのIMHOの強力な兆候です。私の経験では、Cort Ammonの回答の例に匹敵する、より読みやすい方法でこのようなコードを実装できない「隠れた技術的理由」が存在することはほとんどありません。ただし、私はあなたがチームの責任者とこれについて話し合うべきであるCortに同意します-コードまたはこの「種類のスタイル」を変更できない理由を曖昧にするのではなく、物事を壊すことなくコードを安全にリファクタリングする方法を見つけるために。
番号。
本 Pragmatic Programmer の中で、著者は Broken Window Theory について語っています。
この理論は次のように述べています：
いくつかの壊れた窓のある建物を考えてみましょう。窓が修理されない場合、破壊者がさらにいくつかの窓を壊す傾向があります。結局、彼らは建物に侵入するかもしれません、そしてそれが空いているならば、おそらく内部で不法占拠者または軽い火になります。
または舗装を検討してください。ゴミがたまります。すぐに、より多くのごみが蓄積します。やがて人々は、テイクアウトのレストランからゴミ袋を残し始めたり、車に侵入したりすることさえあります。
本の中で著者はこの理論とコードの間の類似点を書いています。このようなコードを見つけたら、停止して、まったく同じ質問を自分に問いかけます。
そして答えは：いいえ
この壊れたウィンドウ（私たちの場合、悪いコード）を離れると、すべての人が壊れたウィンドウを残してしまうという効果が生まれます。
そして、ある日、コードは崩壊します。
Clean Code および Clean Coder のコピーを全員に渡してください。
そして、あなたが件名にいる間、 [〜＃〜] tdd [〜＃〜] のコピーも良いものです。
はい、どうぞ。構造！=スタイル
あなたはスタイルではなく構造について話している。構造は通常、組織に対する適切性ではなく、特定の問題に対する適切性のために選択されるため、スタイルガイドラインは（通常）構造を規定しません。
注意してください
あなたがあなたに発生しなかったかもしれない他の領域で否定的な結果を引き起こしていないことを確信してください。例えば、
- 既存のコードとの類似点をすべて消去したため、差分やコードのマージを複雑にしていないことを確認してください。
- 例外フローが正しくバブルアップし、スタックトレースが判読できないナンセンスの巨大な山で汚染されていないことを確認してください。
- 直接呼び出された場合に問題の原因となるパブリックエントリポイントを誤って公開していないことを確認してください（マップに配置したり、エクスポートしたりしないでください）。
- グローバル名前空間を乱雑にしないでください。小さな関数がすべて、関数ローカルスコープで以前に宣言されたある種のグローバルコンテキストを必要とする場合。
- 必ずログを確認し、コードに生成されたログが、触れていないコードのログと混ざり合っているとわかりにくい場合は、サポートチームにいるかどうかを自問してください。
- doが既存のスタイルに準拠していることを確認してください。彼らが昔ながらの ハンガリー語の表記 を使用していて目が出血する場合でも、一般的なコードベースとの整合性を保ちます。ハンガリー語の表記法を読むよりも辛いのは、誰が何を書いたかによって、さまざまな種類の表記法を使用するコードを読むことだけです。
穏やかな
あなたはチームの一員であることを忘れないでください。優れたコードは重要ですが、休暇中にあなたが書いたものをチームメンバーが維持できることも非常に重要です。古いスタイルに慣れている人にとって意味のある流れに固執するようにしてください。部屋で一番頭がいいからといって、みんなの頭の上で話をする必要があるわけではありません。
私はこれをコード規約とは考えていません。私はこれを、理解しやすいメンテナンス可能なコードの書き方を理解していない人だと考えています。チームが300行の関数が許容できると感じる理由を理解しながら、これを行う利点をチームに提案し、教育するときに、コードをさまざまな関数に分割します。彼らの推論を聞いてとても興味があります。
答えはコードレビューにあります。
本当の問題は、十分に因数分解されたコードを提出した場合、それを使用する意思のある唯一の人になるかどうかです。
私は、ここにいるほとんどの人々と同様に、300のライン機能は嫌悪するものだと信じています。ただし、Windexを埋め立て地に運んでも、それほど効果はありません。問題はコードではなく、コーダーです。
ただ正しいだけでは十分ではありません。このスタイルで人を売る必要があります。少なくともそれを読んで。あなたがこの貧しい人のようになっていない場合： あなたのスキルがあなたの同僚をはるかに超えているために解雇されました
小さなものから始めましょう。周りに尋ねて、誰かがより小さな機能を好むかどうかを調べてください。コードベースをよく調べて、最小のものを書いている人を見つけられるかどうかを確認してください（最も醜いコードが最も古いコードであり、現在のコーダーがより優れたコードを書いていることがわかるでしょう）。これについて彼らに話し、あなたが味方かどうか確かめてください。彼らが同じように感じる他の誰かを知っているかどうか尋ねます。小さな機能を嫌う人を知っているかどうか尋ねます。
この小さなグループを集めて、変更を加えることについて話します。作成するコードの種類を示します。彼らがそれを読むことができることを確認してください。異議を真剣に受け止めます。変更を加えます。コードを承認してもらいます。あなたは今、あなたの背後にある会議の力を持っています。これらのいくつかを追加して、導入した新しいスタイルを明示的に受け入れる1ページのドキュメントを作成できます。
会議は驚くほど強力なものです。彼らは影響力を生み出すことができます。クラウトは、この運動に反対する人々と戦うために使用するものです。これが現時点でのことです。ムーブメント。あなたは現状を改善する権利のために戦っています。人々は変化を恐れます。あなたは甘い話、カジョーレ、そして本番にする必要があります。しかし、少し運があれば、あなたは正しいことを受け入れられるように変えるでしょう。
慣行が悪いと発言する前に、まず私は、大きな方法や他の慣行が悪いと遭遇するかもしれない理由を理解するために一歩を踏み出します。
次に、テストカバレッジが非常に高いか、または非常に高いことを確認する必要があります（大きなリファクタリングなしで実行できる限り）。そうでない場合は、コードを記述していなくても、カバレッジを非常に高くするように努力します。これは信頼関係を築くのに役立ち、あなたの新しいチームはあなたをより真剣に受け止めます。
これらの拠点をカバーしたら、彼らの正しい心の誰もあなたに挑戦しません。ボーナスアイテムとして、いくつかのマイクロベンチマークを実行します。
多くの場合、それはあなたが言葉を言う方法は、コード文化を変えることに向かって長い道のりを行きます。模範を示す。または、さらに良いことに、記述できるコードが完成するまで待ってください-コードとビオラから地獄のリファクタリングとユニットテストを行います-聞こえてきます。
このタイプの質問は、基本的には「チームの仲間を読んでください」です。インターネット上のランダムな人々はそれを行うことができないので、あなたが得るすべての答えはコーディングスタイルについての人々の個人的な意見です。コンセンサスはより短い方法が望ましいですが、あなたはすでに自分でそう考えているようですので、それを再度述べる必要はありません。
したがって、現在のコードベースは、好みのコーディングスタイルを使用しているようです。あなたは何をするべきか？最初にあなたが理解する必要があります：
- これは、現在のチームがサポートする意図的な設計決定ですか？
- 彼らはあなたにこのスタイルを守って欲しいですか？
調べる方法は1つだけです。 質問。
長い機能を使用するには、いくつかの理由が考えられます。それは、長い関数は複数の短い関数よりも優れているとチームが信じているためかもしれません。また、これはレガシーコードであり、チームは新しいコードがよりクリーンなデザインに従うことを望んでいる可能性もあります。したがって、どちらかを選択すると、チームと話をせず、その理由を理解しないと、開発者として問題が発生する可能性があります。
時々あなたは流れに行かなければならない。
あなたが言ったように、あなたは既存の機能しているコードベースに関数を実装するように命じられました。
混乱に関係なく、私はそれを片付けるのが魅力的だと理解しています。しかし、ビジネスの世界では、常にコードをリファクタリングする機会があるとは限りません。
私はあなたに求められていることを実行し、次に進むと言います。
チームと話し合うために持ち出す必要があるよりも、リファクタリングまたは書き換えの価値があると感じた場合。
「スタイル」にはさまざまなレベルがあります。
1つのレベルでは、通常はコーディング規則の一部ですが、これは空白、空白行、角括弧、および名前の付け方（大文字と小文字、下線など）をどこに置くかを意味します。
別のレベルでは、プログラミングモデルがあります。静的モデルの回避、抽象クラスでのインターフェイスの使用、依存関係の公開方法、難解な言語機能の回避などです。
次に、プロジェクトで使用されているライブラリとフレームワークがあります。
場合によっては、関数サイズに最大制限があります。しかし、めったに最低限の制限はありません！だから、あなたはこれらのことのどれが重要であると考えられる力を見つけ出し、それを尊重するように努めるべきです。
チームが既存のコードのリファクタリングに不利であるかどうかを確認する必要があります。これは、可能な場合は新しいコードを追加することとは別に行う必要があります。
ただし、既存のコードをリファクタリングしたくない場合でも、追加した新しいコードの抽象化にいくつかのレイヤーを導入できる可能性があります。つまり、時間の経過とともに、より優れたコードベースを開発し、古いコードを次のように移行できます。それのメンテナンスが必要です。