質問

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

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

単に命名規則を継続するために、読みやすくする傾向があります。

役に立ちましたか?

解決

はい、できます。それはあなたの後にそれを継承する人々がフォローしやすくします。理解するのが本当に難しい場合は、コードを少しクリーンアップして読みやすくします。

他のヒント

作成者が書いたとおりにコードを残すことは問題ありませんそのコードが内部的に一貫している限り。矛盾のためにコードを追跡するのが難しい場合、あなたは将来のメンテナー(おそらくあなた)が明確にする。

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

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

既存のすべてのコードを標準に変更していない場合は、それらのファイルを変更している限り、元の規則を守ってください。同じファイルに2つのスタイルのコードを混在させると、一貫したコードスタイルが持つ利点が失われ、次の人は常にこの関数を書いたのは誰なのか、FooBar()またはfooBarと呼ばれることを自問する必要があります()?"

サードパーティのライブラリをインポートする場合、この種のことはさらにトリッキーになります-書き直したくはありませんが、コードスタイルはあなたのものと一致しないかもしれません。したがって、最終的には、いくつかの異なる命名規則になります。「コード」と「コード」の間に明確な線を引くのが最善です。および「自分のコード」。

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

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

  1. 作業中のコードを更新して、作業中のガイドラインに適合させます。

  2. コード内の規則を使用して、将来の保守作業を支援します。

2。をお勧めしますが、ハンガリー記法では目が出血します:p。

他の人が書いたコードを保守し、他の人があなたの後に保守しようとしている場合は、関係のあるすべての人に無償の変更を加えないようにしてください。ソースコード管理システムにアクセスして変更内容を確認すると、作業中の問題を修正するために必要なものが表示されるはずです。お気に入りのブレースマッチング規則に適合します。

もちろん、元のコードが本当にひどい場合、すべての賭けはオフです。

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

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

コードの一貫性を維持し(一貫してい場合でも)、変数の命名規則を混在させるよりも読みやすくするため、同じ命名規則を引き続き使用します。人間の脳はパターン認識が得意であるように思われますが、パターンを無意識に壊して脳にカーブボールを投げたくありません。

とはいえ、私はハンガリー記法のほんの一部ではありませんが、もしそれがあなたが使用しなければならないのであれば...

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

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

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

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

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

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

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

コードを読み取れる場合、同じ規則を使用する(試してみる) とにかく読み込めない場合は、リファクタリングする必要があるため、(そのようなものに応じて)かなり変更する必要があります

依存。新しいアプリを構築し、クラップス変数の命名を使用してレガシーアプリからコードを盗む場合、アプリに組み込んだらリファクタリングします。

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

ローマ人がそうするように、ローマにいるとき。

(インデックス変数名を除く、例えば" iArrayIndex ++"。そのイディオニを容認するのをやめる。)

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

しかし、残念ながら、このルールに準拠していない私の前のいくつかの開発者がいるので、いくつかの命名規則を選択できます。

しかし、時には物事をまっすぐにする時間があるので、最終的にはきれいできれいになります。

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

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

残念ながら、ほとんどの場合、答えはイエスです。ほとんどの場合、コードは適切な規則に従っていないため、前例に従うことは困難です。ただし、読みやすくするために、フローを使用する必要がある場合があります。

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

既存のアプリに標準がある場合、それに従うことをお勧めします。標準が存在しない場合(タブとスペースが混在し、どこにでも中括弧が...恐ろしい)、私は自分が最善だと思うことを行い、一般に既存のコードをフォーマットツール(Vimなど)で実行します。一貫したスタイルがあれば、既存のコードの大文字化スタイルなどを常に保持します。

この規則の私の唯一の例外は、誰かが私の頭に銃を持っている場合を除き、ハンガリー記法を使用しないことです。時間をかけて既存のものの名前を変更することはしませんが、新しく追加したものにはハンガリー語のいぼはありません。

scroll top