variables - 元のプログラマーの命名規則に従っていますか?

Question

簡単な更新を行うために誰かからプロジェクトを引き継ぐ場合、命名規則に従いますか? 前のプログラマーがハンガリアン記法をいたるところで使用していたプロジェクトを受け取ったところです。私たちのコア製品には命名基準がありますが、何年にもわたって多くの人がカスタムレポートを作成し、好きなことをしてきました.

ただし、既にコード内にあるすべての変数名を変更する時間はありません。

命名規則を続けるために、読みやすさを重視しています。

score 26 · Accepted Answer

はい、そうです。後継者がフォローしやすくなります。理解するのが本当に難しい場合は、コードを少し整理して読みやすくします。

score 5 · Accepted Answer

既存のすべてのコードを標準に変更していない場合は、それらのファイルを変更している限り、元の規則に固執することをお勧めします。同じファイルに 2 つのスタイルのコードを混在させると、一貫したコードスタイルが持つ利点がすべて失われ、次の担当者は常に「この関数を書いたのは誰か、この関数は何と呼ばれるか - FooBar() または fooBar( )?」

サードパーティのライブラリをインポートする場合、この種のことはさらに複雑になります。それらを書き換えたくはありませんが、それらのコードスタイルが自分のものと一致しない可能性があります。最終的には、いくつかの異なる命名規則を使用することになります。「私たちのコード」と「彼らのコード」の間に明確な線を引くのが最善です。

score 5 · Accepted Answer

そのコードが内部的に一貫している限り、著者が書いたままのコードを残すことは問題ないという提案に同意します。一貫性がないためにコードを理解するのが難しい場合は、将来のメンテナー (おそらくあなた) に対して、より明確にする責任があります。

不適切な名前の変数を使用しているなどの理由で関数が何をするかを理解するのに 40 時間を費やした場合は、明確にするためにリファクタリング/名前の変更/コメントの追加/状況に応じて適切なことを行う必要があります。

とはいえ、唯一の問題が、著者が使用したほとんど一貫したスタイルが、会社の標準やあなたが慣れ親しんでいるものとは異なるということであれば、すべての名前を変更するのに時間を無駄にしていると思います. また、元の作成者がコードを認識できなくなるため、まだ質問できる場合は、専門知識のソースを失う可能性があります。

score 3 · Accepted Answer

多くの場合、スタイルガイドに準拠するためだけにコードベースを大幅に変更することは、ほとんど付加価値のない新しいバグを導入する方法にすぎません。

これは、次のいずれかを行う必要があることを意味します。

作業中のコードをガイドラインに準拠するように更新します。
コード内の規則を使用して、将来の保守作業を支援してください。

私は 2. をお勧めしますが、ハンガリアン記法は私の目を出血させます :p.

score 3 · Accepted Answer

他の人が書いたコードを維持していて、他の人があなたの後に維持しようとしている場合は、関係者全員に対して不当な変更を加えないようにする義務があります。彼らがソースコード管理システムにアクセスして変更内容を確認する場合、取り組んでいた問題を修正するために何が必要であったかを確認する必要があります。お気に入りのブレースマッチング規則に適合します。

もちろん、元のコードが本当にひどい場合は、すべての賭けが無効になります。

score 2 · Accepted Answer

はい。私は実際にこれを標準ドキュメントに書きました。私は現在の会社で作成しました：

既存のコードは、他のすべての標準および慣行に取って代わります (それらが業界全体の標準であるか、このドキュメントに記載されているものであるかに関係なく)。ほとんどの場合、次の 2 つの理由から、同じファイル内の既存のコードと一致するようにコードをカメレオンする必要があります。

単一のモジュール/ファイル内に複数の異なるスタイル/パターンを持たないようにする (標準の目的に反し、保守性を妨げる)。
既存のコードをリファクタリングする作業は、不必要にコストがかかる傾向があります (時間がかかり、新しいバグの導入を助長します)。

score 2 · Accepted Answer

一般的に、はい、このシナリオでは、標準よりも規則と読みやすさを優先します。誰もその答えを好きではありませんが、コードを長期的に保守可能に保つために行うのは正しいことです.

優れたプログラマーがコードを読むとき、少なくともソースファイル内で変数名が一貫している限り、変数名を解析し、頭の中でいくつかを追跡できるはずです。しかし、その一貫性を崩すと、コードを読んでいるプログラマーが何らかの認知的不協和に苦しむことになり、追跡するのが少し難しくなります。それはキラーではありません - 優れたプログラマーはそれを乗り越えますが、彼らはあなたの名前を呪い、おそらくあなたをTheDailyWTFに投稿します.

score 2 · Accepted Answer

変数の命名規則を混在させるよりもコードの一貫性を維持し (一貫して醜い場合でも)、コードを読みやすくするため、私は確かに同じ命名規則を使用し続けます。人間の脳はパターン認識が得意なようで、そのパターンを不当に破って脳に変化球を投げつけたくはありません。

そうは言っても、私はハンガリーの記譜法の一部ではありませんが、それがあなたが取り組まなければならないものなら...

score 2 · Accepted Answer

ファイルまたはプロジェクトが一貫したスタイルを使用して既に記述されている場合は、既存のスタイルと競合/矛盾していても、そのスタイルに従うようにしてください。コードスタイルの主な目標の 1 つは一貫性です。そのため、(それ自体で) 既に一貫しているコードに別のスタイルを導入すると、その一貫性が失われます。

コードの記述が不十分で、それを理解するためにある程度のクリーンアップが必要な場合は、スタイルのクリーンアップがより適切なオプションになりますが、絶対に必要な場合 (特に単体テストがない場合) にのみ行う必要があります。予想外の重大な変更を導入する可能性。

score 2 · Accepted Answer

はいぜったいに。元のプログラマーの命名規則に従うことが望ましいとは思えない 1 つのケースは、元のプログラマー (またはそれ以降コードを変更した後続の開発者) が一貫した命名規則に従わなかった場合です。

score 1 · Accepted Answer

残念ながら、ほとんどの場合、答えはイエスです。ほとんどの場合、コードは適切な規則に従っていないため、先例に従うのは困難です。しかし、読みやすくするために、流れに沿って進むことが必要な場合があります。

ただし、既存のコードの多くをリファクタリングして「臭い」を改善できるほど小さなアプリケーションである場合は、そうします。または、これが大規模な書き直しの一部である場合は、現在のコーディング標準でコーディングを開始します。しかし、これは通常は当てはまりません。

score 1 · Accepted Answer

命名を含め、コードにすでに一貫したスタイルがある場合は、それに従うようにします。以前のプログラマーが一貫していなかった場合は、会社の標準を自由に適用するか、会社の標準がない場合は私の個人的な標準を適用します。

どちらの場合でも、私が行った変更をコメントでフレーミングしてマークしようとします。今日の CVS システムでは、これが行われないことが多いことはわかっていますが、それでもやりたいと思っています。

score 1 · Accepted Answer

個人的には、変数の命名スキームが異なるプロジェクトを引き継ぐときはいつでも、前のプログラマーが使用していたものと同じスキームを維持する傾向があります。私が異なる唯一のことは、追加する新しい変数に対して、変数名の前にアンダースコアを付けることです。このようにして、ソース履歴に移動してバージョンを比較しなくても、変数とコードをすばやく確認できます。しかし、単に読めないコードやコメントを継承することになると、通常はそれらを調べて、すべてを書き直すことなく、できる限りクリーンアップします（そうなりました）。組織化は、拡張可能なコードを持つための鍵です!

score 1 · Accepted Answer

コードを読むことができれば、それが読めない場合は同じ規則を採用しようとしますとにかくリファクタリングする必要があり、したがってそれを変更する必要があります

score 1 · Accepted Answer

依存します。私が新しいアプリを構築していて、古いアプリからコードを盗み、変な変数名を付けている場合は、それを自分のアプリに取り込んだらリファクタリングします。

score 1 · Accepted Answer

はい.. 2 つの大幅に異なるスタイルを持つアプリケーションに足を踏み入れるよりもイライラすることが少しあります。私が最近取り組んだあるプロジェクトには、ファイルを操作する 2 つの異なる方法、画面を実装する 2 つの異なる方法、2 つの異なる基本構造がありました。2 番目のコーダーは、新しい機能を、メインコードから呼び出される dll の一部にすることさえしました。メンテナンスは悪夢のようなもので、あるセクションで適切なセクションで作業していたときに、パラダイムと希望の両方を学ばなければなりませんでした。

score 1 · Accepted Answer

ローマにいるときは、ローマ人がするようにしなさい。

(「iArrayIndex++」などのインデックス変数名を除きます。その愚かさを容認するのはやめてください。)

score 1 · Accepted Answer

外科的処置としてバグ修正を行うことを考えています。入って、できるだけ邪魔をしないで、直して、出て、そこにいる痕跡をできるだけ残さないでください。

score 1 · Accepted Answer

私はそうしていますが、残念ながら、私の前にこのルールに従わなかった開発者が何人かいたので、いくつかの命名規則から選択できます。

しかし、時には物事を正すための時間が得られるので、最終的には素晴らしくきれいになります。

score 0 · Accepted Answer

既存のアプリに基準があるなら、それに従うのが一番だと思います。標準がない場合 (タブとスペースが混在し、中かっこがいたるところに... 恐ろしい)、私は自分が最善だと思うことを行い、通常は既存のコードを書式設定ツール (Vim など) を介して実行します。首尾一貫したスタイルがあれば、既存のコードの大文字と小文字のスタイルなどを常に維持します。

この規則に対する私の唯一の例外は、誰かが私の頭に銃を持っていない限り、ハンガリー語表記を使用しないことです. 既存のものの名前を変更するのに時間はかかりませんが、新しく追加するものにはハンガリーの疣贅はありません.

variables - 元のプログラマーの命名規則に従っていますか?

20 に答える 20

Related

Reference