問題タブ [coding-style]

私は多くの「ヘルパー」クラスを使用しています。これらのクラスには、コントローラーとアクションが共有機能のチャンクにアクセスできるようにする一連の静的関数が効果的に含まれています。

問題は、これらのファイルがモジュール/アプリケーション全体で必要な機能のダンプ グラウンドとして使用されていることです。その結果、サイズが 3k 行を超え、上部に約 50 のrequire_once宣言があります。

アプリケーションのビューがこれらのヘルパーから利用できる機能のごく一部を使用したくない場合は、必要なすべてのファイルを継承するため、アプリが肥大化することになります。

require_once必要に応じてファイルを含めると、これらのヘルパーから利用可能な機能を大量に使用する必要があるときに、必要なファイルに対して多数の呼び出しを行うことになり、それには独自のオーバーヘッド (頻度と相まって) があります。ファイル。

したがって、本質的に私の質問は、どこでバランスが取れているか、そして採用できるベストプラクティスはありますか?

ありがとう、

フルンガ

コーディング標準を公開する最良の方法は何ですか?またその理由は何ですか?

私のコーディング スタイルには、次のイディオムが含まれます。

これにより、たとえばコンストラクターで「super」を Base のエイリアスとして使用できます。

または、オーバーライドされたバージョン内の基本クラスからメソッドを呼び出す場合でも:

連鎖することもできます（ただし、その用途をまだ見つけていません）：

とにかく、「typedef super」の使用は非常に便利です。たとえば、Base が冗長であったり、テンプレート化されている場合などです。

実際のところ、super は C# だけでなく Java にも実装されています (私が間違っていない限り、"base" と呼ばれています)。しかし、C++ にはこのキーワードがありません。

だから、私の質問：

• このtypedefの使用は、使用するコードで非常に一般的/まれ/決して見られませんか?
• この typedef super の使用は OK ですか?
• 「スーパー」は良いことなのか、C++である程度標準化されるべきなのか、それともtypedefを介したこの使用はすでに十分なのか?

編集: Roddy は、typedef は非公開にする必要があるという事実に言及しました。これは、派生クラスがそれを再宣言しないと使用できないことを意味します。しかし、それはまた、super::super 連鎖を防ぐことになると思います (しかし、誰が泣くのでしょうか?)。

編集 2: "super" を大量に使用してから数か月が経ちましたが、Roddy の見解に心から同意します。「super」はプライベートであるべきです。私は彼の答えに2回賛成しますが、できないと思います。

私はしばらくの間 Ruby を使用してきましたが、大きなプロジェクトの場合、かなりの量のメモリを占有する可能性があることがわかりました。Ruby でメモリ使用量を削減するためのベスト プラクティスは何ですか?

• 各回答に 1 つの「ベスト プラクティス」を持たせ、コミュニティに投票してもらいます。

s の長い条件ifを複数の行に分割することがあります。これを行う最も明白な方法は次のとおりです。

アクションが条件に溶け込んでいるため、視覚的にあまり魅力的ではありません。ただし、4 つのスペースの正しい Python インデントを使用するのが自然な方法です。

私が使用している瞬間：

しかし、これはあまりきれいではありません。:-)

別の方法をお勧めできますか？

私たちは、開発チームで使用したいデザイン ガイドラインを作成する過程にあり、ASP.NET コントロールの命名方法について今日議論を始めました。私たちの良き友人、Label、TextBox、Button などについて話しています。

投票した次の 3 つの可能性を考え出しました: (例は、FirstName を入力/表示するための TextBox です)。

1. コントロール タイプをコントロール ID の接尾辞として追加します: [FirstName _TextBox] または [FirstName _tbx]
2. コントロール タイプをプレフィックスとしてコントロール ID [tbxFirstName] に追加します。
3. オプション 2 [lblTextBox] のように、コントロールの ID を FirstName に設定し、関連するフィールド (テキスト ボックスのラベルやバリデータなど) に名前を付けます。

最終的にオプション 2 を使用することにしました。オプション 1 ほど冗長ではなく、コントロールの名前の前にそれがどのコントロールであるかを指定するのが気に入っています。

私の質問は、マイクロソフトがこれらのプレフィックスのガイドラインをリリースしたかどうか、または私たちの決定についてコメントがあるかどうかです。

大規模な C/C++ プロジェクトに取り組んでいるとき、ソース ファイルまたはヘッダー ファイル内の#includeに関する特定のルールはありますか?

たとえば、次の 2 つの過剰なルールのいずれかに従うことを想像できます。

1. #includeは.hファイルでは禁止されています。必要なすべてのヘッダーを含めるのは、各.cファイル次第です。
2. 各.hファイルには、すべての依存関係が含まれている必要があります。つまり、エラーなしで単独でコンパイルできる必要があります。

どのプロジェクトにもトレードオフがあると思いますが、あなたのプロジェクトは何ですか? もっと具体的なルールはありますか？または、解決策のいずれかを主張するリンクはありますか?

私は最近、このJavaScriptコードに出くわしました。

このテストを書くために私がしたであろうので、私は興味をそそられました：

これは単なる文体の違いですか、それとも他のコードの作成者は私が知らない最適化について何か知っていますか？または、これを行う、または正規表現を使用しない別の正当な理由があるかもしれません...？

これを使用String.indexOf()するのは少し読みにくいように思えますが（ただし、正規表現にはかなり慣れています）、同等の正規表現を作成するよりも「優れている」場合がありますか？

「より良い」ことによって、より速くまたはより効率的になる可能性があります（ただし、明らかにそれはブラウザのJavaScriptエンジンに依存します）、または私が気付いていない他の理由。誰かが私を啓発できますか？

Google C++ スタイル ガイドの演算子のオーバーロードに関するセクションでは、演算子をオーバーロードしないことを推奨しています (「まれな特殊な状況を除く」)。具体的には、次のことを推奨しています。

特に、 クラスを STL コンテナーのキーとして使用できるようにするためだけにオーバーロードしoperator==ないでください。operator<代わりに、コンテナーを宣言するときに等値ファンクターと比較ファンクターの型を作成する必要があります。

そのようなファンクターがどのように見えるかについては少し曖昧ですが、私の主な質問は、なぜこれのために独自のファンクターを書きたいのですか? を定義operator<して標準std::less<T>関数を使用する方が簡単ではないでしょうか? 一方を他方よりも使用する利点はありますか？

既定のパラメーターを使用するクラス コンストラクターを使用することは良い習慣ですか、それとも別のオーバーロードされたコンストラクターを使用する必要がありますか? 例えば：

どちらのバージョンでも動作するようです。例:

どのスタイルが好みまたは推奨されますか?その理由は?