転載元: http://blog.onlygrape.com/divcss/377
CSS コードをより効率的に記述するには?これは、多くの Web ページ作成者や開発者が懸念している問題です。おそらく、スタイル シートを即座に特定のパーセンテージまで削減することを保証できる魔法はありませんが、適切な CSS コーディングと構成スキルがあれば、より明確で効率的なコードを作成するのに役立ちます。当然、スタイル テーブル サイズも効率的に縮小されます。ダウンロード時間を短縮します。
1. 植字:
1. キーワードと演算子の間に適切なスペースを追加します。
2. 比較的独立したプログラムブロックの間に空行を追加します
3. 長いステートメント、式などは複数行で記述する必要があります。
4. レイアウトをきれいにし、ステートメントを読みやすくするために、新しい行を適切にインデントする必要があります。
5. 長い式は優先度の低い演算子で新しい行に分割し、演算子を新しい行の先頭に配置する必要があります。
6. ループや判定などに長い式やステートメントがある場合は、適切に分割する必要があります。
7. 関数やプロセス内のパラメータが長い場合は、適切に分割する必要があります。
8. 1 行に複数の短いステートメントを記述することはできません。つまり、1 行に 1 つのステートメントのみを記述します。
9. 関数やプロセスの先頭、構造体の定義、ループや判定などのステートメント内のコードはインデントする必要があります。
10. C/C++ 言語では、プログラム ブロックを区切るために中括弧「{」と「}」を使用します。「{」と「}」はそれぞれ排他的な行を占め、同じ列に配置する必要があります。 、それらを参照するステートメントと同じ列に配置する必要があります。ステートメントは左揃えになります。上記のインデント方法は、関数本体、クラスの定義、構造体の定義、列挙型の定義、および if、for、do、while、switch、および case ステートメント内のプログラムの先頭で使用する必要があります。 。
2. コメント
1. コメントはシンプルかつ明確である必要があります。
2. コードを書きながらコメントし、コードを修正し、同時に対応するコメントも修正して、コメントとコードの一貫性を確保します。
3. 必要に応じてコメントします。コメントの量は適度にします。注釈の内容は明確かつ簡潔である必要があり、注釈のあいまいさを防ぐために意味は正確である必要があります。コメントは、説明するコードの隣に配置してください。つまり、コメントの近接原則です。
4. コードに関するコメントは、下ではなく上に隣接して配置する必要があります。
5. データ構造のコメントはその下ではなく隣接して配置する必要があります。構造内の各フィールドのコメントはこのフィールドの右側に配置する必要があります。同じ構造内の異なるフィールドのコメントは整列して配置する必要があります。
6. 変数と定数に関するコメントは、それらの隣または右上に配置する必要があります。
7. グローバル変数には、関数の説明、値の範囲、どの関数またはプロシージャがアクセスするか、アクセス時の注意事項など、より詳細なコメントが必要です。
8. 各ソース ファイルの先頭には、ファイル名、作成者、モジュールの関数の説明、内部パーツ間の関係などの必要な注釈情報が必要です。このファイルと他のファイルなど）; 主要な機能またはプロセスのリスト、およびこのファイルの変更履歴など。
9. 各関数またはプロセスの前に、関数またはプロセスの関数の説明、呼び出し関係、呼び出された関係の説明などの必要な注釈情報が必要です。
3. 名前付け
1. 短い単語は「母音」を削除することで省略できます。
2. 長い単語は、式の動作を明確にするために括弧を使用できます。デフォルトの優先順位の使用を避けるためです。
3. ハンガリー語表記を使用します
4. 読みやすさ
1. 理解しにくい数字の使用を避け、意味のある記号に置き換えます。
2. わかりにくい、高度に専門的な文章は使用しないでください。
3. ソースプログラム内の密接に関連するコードは、可能な限り隣接する必要があります。
5. 変数
1. 不要なパブリック変数を削除します。
2. 複数の異なるモジュールまたは関数が同じパブリック変数を変更および作成できる現象を防ぐために、1 つのモジュールまたは関数のみが変更および作成でき、他の関連モジュールまたは関数はアクセスのみが可能なパブリック変数を構築します。
3. パブリック変数の意味、役割、値の範囲、関係を慎重に定義して明確にします。
4. パブリック変数と、このパブリック変数を操作する関数やプロシージャ (アクセス、変更、作成など) との関係を明確にします。
5. パブリック変数にデータを転送するときは、不当な値を代入したり、範囲外になったりしないように十分注意してください。
6. ローカル変数がパブリック変数と同じ名前を持つことを防止します。
7. 構造を理解しやすくし、スペースを節約し、誤用を減らすために、構造内の要素のレイアウトと順序を慎重に設計します。
8. 構造の設計では、前方互換性と将来のバージョンのアップグレードを考慮し、将来のアプリケーションに備えて余地を確保する必要があります (スペースの確保など)。
9. 特定の言語とコンパイラーがさまざまなデータ型を処理する方法の原則と関連する詳細に注意してください。
10. 初期化されていない変数の使用は固く禁止されています。変数を宣言するときに初期化します。
11. プログラミングの際は、データ型の強制変換に注意してください。
6. 関数とプロシージャ
1. 関数のサイズは 200 行未満に制限するようにしてください。
2. 関数は 1 つの関数だけを完了するのが最適です。
3. 単純な関数の関数を作成します。
4. 関数の機能は予測可能である必要があります。つまり、入力データが同じである限り、同じ出力を生成する必要があります。
5. 他の関数の内部実装に依存する関数は記述しないようにしてください。
6. 複数パラメータ関数の設計を避け、未使用のパラメータをインターフェイスから削除します。
7. 各パラメータの機能、値の範囲、パラメータ間の関係をコメントを使用して詳細に説明します。
8. 関数のすべてのパラメーター入力の有効性を確認します。
9. データ ファイル、パブリック変数など、関数のすべての非パラメータ入力の有効性を確認します。
10. 関数名は関数の機能を正確に説明する必要があります。
11. 関数の名前に意味のない動詞や不明瞭な動詞を使用することは避けてください。
12. ユーザーがエラー状態を簡単に無視できないように、関数の戻り値は明確かつ簡潔である必要があります。
13. 関数の機能を明確にし、(おおよそではなく) 正確に関数設計を実装します。
14. 関数自体内または関数間の再帰呼び出しを減らします。
15. リエントラント関数を作成する場合、グローバル変数が使用されている場合は、割り込みとセマフォ (つまり、P、V 操作) をオフにして保護する必要があります。
7. テスト容易性
1. コードを記述する前に、プログラムのデバッグとテストの方法と手段を事前に設計し、各種デバッグ スイッチとそれに対応する印刷機能などのテスト コードを設計する必要があります。
2. 結合テスト/システム結合デバッグを実施する前に、テスト環境、テストプロジェクト、テストケースを構築すると同時に、テスト効率を向上させるためにテストケースを注意深く分析および最適化する必要があります。
8. プログラムの効率
1. プログラミングするときは、コードの効率に常に注意を払います。
2. ソフトウェア システムの正確性、安定性、可読性、テスト容易性を確保しながら、コードの効率を向上させます。
3. コードの効率性をやみくもに追求することはできず、ソフトウェアの正確性、安定性、可読性、テスト容易性に影響を及ぼします。
4. プログラミングするときは、コードの効率に常に注意を払い、すべてを考慮する必要があります。
5. 頻繁に呼び出される関数や、非常に高いパフォーマンス要件がある関数は、慎重に構築するか、アセンブリに直接記述する必要があります。
6. システムデータ構造の分割と構成を改善し、プログラムアルゴリズムを最適化することで、スペース効率を改善します。
7. 複数のループでは、最もビジーなループを最も内側の層に配置する必要があります。
8. ループのネストレベルを最小限に抑えます。
9. ループ本体に判定文を含めないでください。ループ文は判定文のコードブロック内に配置する必要があります。
10. 除算の代わりに乗算やその他の方法、特に浮動小数点演算での除算を使用するようにしてください。
9. 品質保証
1. ソフトウェア設計プロセス中にソフトウェアの品質を構築します。コード品質保証優先原則
(1) 正確性とは、プログラムが設計で要求された機能を実現することを意味します。
(2) 安定性とセキュリティとは、プログラムの安定性、信頼性、安全性を指します。
(3) テスト容易性とは、プログラムが良好なテスト容易性を備えていなければならないことを意味します。
(4) 標準化/可読性。プログラムの記述スタイル、命名ルールなどが標準に準拠している必要があることを意味します。
(5) 全体効率とは、ソフトウェア システムの全体的な効率を指します。
(6) ローカル効率とは、特定のモジュール/サブモジュール/関数の効率を指します。
(7) 個人的な表現/個人的な都合。個人的なプログラミングの習慣を指します。
2. 自分のストレージスペースのみを参照してください。
3. すでに解放されたメモリ空間への参照を防止します。
4. プロセス/関数に割り当てられたメモリは、プロセス/関数が終了する前に解放される必要があります。
5. プロセス/関数に適用されたファイル ハンドル (ファイルを開くために使用) は、プロセス/関数が終了する前に閉じる必要があります。
6. メモリ操作が境界を越えないようにする。
7. 式がオーバーフローしているかアンダーフローしているかに常に注意してください。
8. プログラムで発生する可能性のあるさまざまなエラー状況に慎重に対処します。
9. システム動作の開始時に、初期化されていない変数が参照されないように、関連する変数と動作環境を初期化する必要があります。
10. システム運用の開始時に、システムにロードされたデータの整合性をチェックする必要があります。
11. 他のモジュールやシステムの関連する設定や構成を自由に変更することは固く禁じられています。
12. 他のモジュールとのインターフェースは自由に変更できません。
13. システムインターフェースを十分に理解した上で、システムが提供する機能を使用してください。
14. 紛らわしい演算子に常に注意してください。プログラミングが終了したら、これらの演算子を最初から最後までチェックする必要があります。
15. ハードウェアまたはオペレーティング システムに密接に関連するステートメントは使用せず、推奨される標準ステートメントを使用します。
16. 推奨事項: サードパーティが提供するソフトウェア開発ツールキットやコントロールを使用する場合は、次の点に注意してください:
(1) アプリケーションのインターフェース、使用環境、使用上の注意事項を十分に理解してください。
(2) その正しさをあまり信じないでください。
(3) 必要な場合を除き、見慣れないサードパーティのツール パッケージやコントロールを使用しないでください。
10. コードのコンパイル
1. コードを作成するときは、停電やハードディスクの損傷などによるコードの損失を防ぐために、必ずコードをいつでも保存し、定期的にバックアップしてください。
2. 同じプロジェクト グループ内では、同じエディターと同じ設定オプションを使用することが最善です。
3. 開発者が使いやすいようにソフトウェア システム ディレクトリを合理的に設計します。
4. コンパイラの警告スイッチをすべてオンにして、プログラムをコンパイルします。
5. 同じプロジェクトグループまたはプロダクトグループ内では、コンパイルスイッチのオプションを統一する必要があります。
6. ツール ソフトウェア (Visual SourceSafe など) を使用してコードのバージョンを維持します。
11. コードのテストとメンテナンス
1. 単体テストには少なくともステートメントの範囲が必要です。
2. 単体テストの開始時に、各ステートメントを追跡し、データ フローと変数の変化を観察する必要があります。
3. クリーンアップ、整理、または最適化されたコードはレビューおよびテストする必要があります。
4. コードのバージョンアップグレードは厳格なテストを受ける必要があります。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
