コーディング規約

コーディング規則は、特定のプログラミング言語のガイドラインのセットであり、その言語で書かれたプログラムの各側面のプログラミングスタイル、プラクティス、およびメソッドを推奨します。これらの規則は通常、ファイルの編成、インデント、コメント、宣言、ステートメント、空白、命名規則、プログラミング慣行、プログラミング原則、プログラミングの経験則、アーキテクチャのベストプラクティスなどを対象としています。これらはソフトウェア構造の品質に関するガイドラインです。ソフトウェアプログラマは、ソースコードの可読性を向上させ、ソフトウェアのメンテナンスを容易にするために、これらのガイドラインに従うことを強くお勧めします。コーディング規約は、ソフトウェアプロジェクトの人間のメンテナーとピアレビューアーにのみ適用されます。規則は、チームまたは企業全体が従う文書化された一連の規則で正式に定式化される場合があります。コーディング規則はコンパイラーによって強制されません。

ソフトウェアメンテナンス

ソフトウェアメンテナンスのコストを削減することが、コーディング規約に従う最もよく挙げられる理由です。 Javaプログラミング言語のコード規則の紹介で、Sun Microsystemsは次の理論的根拠を提供します。

コードの規則は、いくつかの理由でプログラマーにとって重要です。

• ソフトウェアのライフタイムコストの40％〜80％はメンテナンスに費やされます。
• オリジナルの作者によってソフトウェアが一生維持されることはほとんどありません。
• コードの規則により、ソフトウェアの可読性が向上し、エンジニアは新しいコードをより迅速かつ完全に理解できるようになります。
• ソースコードを製品として出荷する場合は、作成する他の製品と同じようにパッケージ化され、クリーンであることを確認する必要があります。

品質

ソフトウェアピアレビューには、ソースコードの読み取りが頻繁に含まれます。このタイプのピアレビューは、主に欠陥検出アクティビティです。定義により、コードがレビューのために送信される前に、コードの元の作成者のみがソースファイルを読み取りました。一貫したガイドラインを使用して記述されたコードは、他のレビュアーが理解し、同化するのが容易であり、欠陥検出プロセスの有効性が向上します。

原作者でさえ、一貫してコーディングされたソフトウェアは保守性を容易にします。特定のコードが最初に記述された後、特定のコードが特定の方法で記述された理由の正確な理論的根拠を個人が覚えているという保証はありません。コーディング規約が役立ちます。空白を一貫して使用すると、読みやすさが向上し、ソフトウェアを理解するのにかかる時間が短縮されます。

コーディング規約が高品質のコードを生成するために特別に設計され、正式に採用された場合、それらはコーディング標準になります。特定のスタイルは、一般的に採用されているかどうかに関係なく、高品質のコードを自動的に生成しません。

複雑さはセキュリティに反する要因です。

複雑さの管理には、次の基本原則が含まれます。プロジェクト開発中に、このプロジェクトが必要最小限のコードで実装されているかどうかを尋ねる必要があります。そうでない場合は、不要な作業が行われ、前もって下流の両方の不要なコストが発生しています。

複雑さは、設計段階（プロジェクトのアーキテクチャー）と開発段階（使用されるコーディング）の両方で管理されます。コーディングが基本的かつシンプルに保たれていれば、複雑さは最小限に抑えられます。非常に多くの場合、これはコーディングを可能な限り「物理的」に保ちます-非常に直接的で、高度に抽象的ではない方法でコーディングします。これにより、読みやすく追跡しやすい最適なコードが生成されます。

コードが複雑になるほどバグが発生する可能性が高くなり、バグを見つけるのが難しくなり、隠れたバグが発生する可能性が高くなります。

リファクタリング

リファクタリングとは、ソースコードを変更して読みやすくしたり、構造を改善したりするソフトウェアメンテナンスアクティビティのことです。ソフトウェアは、多くの場合、最初のリリース後にチームの規定のコーディング標準に準拠するようにリファクタリングされます。ソフトウェアの動作を変更しない変更は、リファクタリングと見なすことができます。一般的なリファクタリングアクティビティは、変数名の変更、メソッドの名前変更、メソッドまたはクラス全体の移動、大きなメソッド（または関数）の小さなものへの分割です。

アジャイルソフトウェア開発方法論は、定期的な（または継続的な）リファクタリングを計画し、チームソフトウェア開発プロセスの不可欠な部分にします。

タスクの自動化

コーディング規約により、ソースコードを実行可能ファイルにコンパイルする以外の目的でソースコードを処理することを目的とした単純なスクリプトまたはプログラムを作成できます。ソフトウェアのサイズ（コードのソース行）をカウントして、現在のプロジェクトの進行状況を追跡したり、将来のプロジェクトの見積もりの​​ベースラインを確立したりするのが一般的です。

一貫したコーディング標準により、測定の一貫性が向上します。ソースコードコメント内の特別なタグは、ドキュメントの処理によく使用されます。2つの注目すべき例は、javadocとdoxygenです。ツールは一連のタグの使用を指定しますが、プロジェクト内での使用は慣例により決定されます。

コーディング規約により、既存のソフトウェアを処理することを目的とする新しいソフトウェアの作成が簡単になります。静的コード分析の使用は、1950年代から一貫して増加しています。このクラスの開発ツールの成長の一部は、開業医自身の成熟度と洗練度の向上（および、安全性とセキュリティに対する現代の焦点）に起因しますが、言語自体の性質にも起因します。

言語要因

すべてのソフトウェア開業医は、多くの場合に複雑な指示を整理および管理する問題に取り組む必要があります。最小のソフトウェアプロジェクトを除くすべてのプロジェクトでは、ソースコード（命令）が個別のファイルに分割され、多くのディレクトリ間で頻繁に分割されます。プログラマが密接に関連する機能（動作）を同じファイルに収集し、関連するファイルをディレクトリに収集するのは自然でした。ソフトウェア開発が純粋に手続き型のプログラミング（FORTRANなど）からよりオブジェクト指向の構造（C ++など）に移行するにつれて、単一のファイル（単一の（パブリック）クラスのコードを記述する習慣になりました。 「ファイルごとに1つのクラス」規則）。 Javaはさらに一歩進んでいます。ファイルごとに複数のパブリッククラスが見つかった場合、Javaコンパイラはエラーを返します。

ある言語の規約は、別の言語の要件になる場合があります。言語規則は、個々のソースファイルにも影響します。ソースコードの処理に使用される各コンパイラ（またはインタープリター）は一意です。コンパイラがソースに適用するルールにより、暗黙的な標準が作成されます。たとえば、Pythonコードは、Perlなどよりも一貫してインデントされています。これは、インタープリターにとって空白（インデント）が実際に重要だからです。 Pythonは、関数を区切るためにPerlが使用するブレース構文を使用しません。インデントの変更はdelimiters.Tclとして機能します。TclはPerlまたはC / C ++に類似したブレース構文を使用して関数を区切っていますが、Cプログラマーにとってはかなり合理的と思われる以下を許可しません。

その理由は、Tclでは、CまたはJavaのように関数を区切るためだけに中括弧が使用されないためです。より一般的には、中括弧を使用して、単語を1つの引数にグループ化します。 Tclでは、 単語 whileは条件とアクションの 2つの引数を取ります。上記の例では、 一方が第2引数が欠落している、その作用 （Tclは、コマンドの終わりを区切るために改行文字を使用しているため）。

一般的な慣例

多数のコーディング規則があります。多数の例と説明については、 コーディングスタイルを参照してください。一般的なコーディング規則は、次の領域をカバーする場合があります。

• コメント規約
• インデントスタイルの規則
• 行の長さの規則
• 命名規則
• プログラミングの実践
• プログラミングの原則
• プログラミングスタイルの規則

コーディング標準には、CERT Cコーディング標準、MISRA C、高整合性C ++が含まれます。