1

既存のプロジェクトに追加するときは、一貫したスタイルを維持することが重要です。しかし、プロジェクトとライブラリの標準の間に明確な違いがあるときに、新しいプロジェクトのライブラリから大幅にサブクラス化する場合はどうでしょうか。

私は特定のコーディングスタイルのプロジェクトに取り組んでいます。特に、それらのクラス内のクラスとメソッドの名前付け方法に関してはそうです。ただし、プロジェクトの1つのモジュールであるUIは、外部ライブラリに大きく依存しており、このモジュールのほとんどのクラスはこのライブラリをオーバーロードします。この場合、Qtですが、何でもかまいません。

このような状況では、APIで使用されるスタイルに固執するか、プロジェクトのスタイルを新しい関数に使用する方がよいでしょうか。例として、QtはcamelCase関数宣言にを使用しますが、このプロジェクトはを使用しUpperCaseます。次のようなことを考えてみてください。

class MyNewWidget : public QWidget {
    Q_OBJECT
public:
    void setVisible(bool visible); // QWidget override
    void SetNewFeature(std::string feature_key); // New function

    bool visibility() const; // I know you can't override that, but bear with me
    std::string GetNewFeature() const; // propertyName() vs GetPropertyName()
};

これは、を使用するSTLからのサブクラス化と同じように感じますlower_case。その場合、少なくともいくつかの例で規則に従うのにはいくつかの正当な理由があります。たとえば、typedefiteratorを実行する場合や、begin//関数をetalで使用できるようにする場合などです。endswap<algorithm>

しかし、私はこれの壁にいます。

4

1 に答える 1

0

可能な場合は、クラス/ファイル/モジュールごとに単一のスタイルを維持するように努めます。メソッドの名前を考えようとしているときに困難が生じます。他の人に止めて考えさせることができないほど、良い結果が得られます。もちろん、優れたIDE/エディタでケースを修正する必要があります。

もう1つのオプションは、継承よりも構成を優先することです。これは、内部でQtメソッドに委任するプロジェクトスタイルを使用して新しいメソッドを作成することを意味します。それがまったく懸念される場合は、QtAPIに縛られないという追加の利点があります。

于 2012-07-09T01:31:01.957 に答える