Loading article…
コーディング規約は、特定のプログラミング言語に関する一連のガイドラインであり、その言語で記述されたプログラムの各側面について、プログラミングスタイル、プラクティス、および方法を推奨します。これらの規約は通常、ファイル構成、インデント、コメント、宣言、ステートメント、空白、命名規則、プログラミングプラクティス、プログラミング原則、プログラミングの経験則、アーキテクチャのベストプラクティスなどを網羅しています。これらは、ソフトウェアの構造的品質に関するガイドラインです。ソフトウェアプログラマーは、ソースコードの可読性を向上させ、ソフトウェアの保守を容易にするために、これらのガイドラインに従うことを強く推奨します。コーディング規約は、ソフトウェアプロジェクトの人間の保守担当者とピアレビュー担当者にのみ適用されます。規約は、チーム全体または会社全体が従う文書化された一連のルールとして形式化されている場合もあれば、[ 1 ]個人の習慣的なコーディングプラクティスのように非公式な場合もあります。コーディング規約はコンパイラによって強制されません。
ソフトウェア保守のコスト削減は、コーディング規約に従う最もよく挙げられる理由です。Javaプログラミング言語のコーディング規約の導入セクションで、Sun Microsystemsは次のような理由を挙げています。[ 2 ]
プログラマーにとって、コーディング規約は様々な理由から重要です。
- ソフトウェアのライフサイクルコストの40%～80%はメンテナンスに費やされる。[ 3 ]
- ソフトウェアのほとんどは、そのライフサイクル全体を通してオリジナル開発者によって保守されることはない。
- コーディング規約はソフトウェアの可読性を向上させ、エンジニアが新しいコードをより迅速かつ徹底的に理解することを可能にする。
- ソースコードを製品として出荷する場合は、他の製品と同様に、適切にパッケージ化され、クリーンな状態であることを確認する必要があります。
ソフトウェアのピアレビューでは、ソースコードを読むことが頻繁に行われます。この種のピアレビューは、主に欠陥検出を目的としています。定義上、コードがレビューに提出される前にソースファイルを読んでいるのは、そのコードの作成者のみです。一貫したガイドラインに従って書かれたコードは、他のレビュー担当者が理解しやすく、習得しやすいため、欠陥検出プロセスの効率が向上します。
たとえ元の開発者にとっても、一貫性のあるコーディングで書かれたソフトウェアは保守性を向上させます。コードが最初に書かれた後、なぜ特定のコードが特定の方法で書かれたのかという正確な理由を、開発者が覚えているとは限りません。コーディング規約は、その助けとなります。空白を統一的に使用することで可読性が向上し、ソフトウェアを理解するのにかかる時間を短縮できます。
高品質なコードを生成するために特別に設計されたコーディング規約が正式に採用された場合、それはコーディング標準となります。特定のスタイルは、それが広く採用されているかどうかに関わらず、必ずしも高品質なコードを生み出すとは限りません。
複雑さはセキュリティに不利な要因である。[ 4 ]
複雑性の管理には、プロジェクト開発中に記述するコード量を最小限に抑えるという基本原則が含まれます。これにより、不要な作業が削減され、初期段階と後工程の両方で不要なコストを削減できます。なぜなら、コード量が少なければ、アプリケーションの作成だけでなく、保守作業も少なくて済むからです。
複雑さは、設計段階（プロジェクトのアーキテクチャ設計）と開発段階（よりシンプルなコードの作成）の両方で管理されます。コードを基本的かつシンプルに保つことで、複雑さは最小限に抑えられます。多くの場合、これはコードをできるだけ「物理的」に保つこと、つまり、抽象度を低く抑え、非常に直接的な方法でコーディングすることです。これにより、読みやすく理解しやすい最適なコードが生成されます。また、単純な作業に複雑なツールを使用しないことで、複雑さを回避することもできます。
コードが複雑になればなるほど、バグが発生する可能性が高くなり、バグを見つけるのが難しくなり、隠れたバグが存在する可能性も高くなります。
リファクタリングとは、ソフトウェアの保守作業の一つで、ソースコードを修正して可読性や構造を改善する作業を指します。ソフトウェアは、初回リリース後にチームが定めたコーディング標準に準拠させるためにリファクタリングされることがよくあります。ソフトウェアの動作を変更しない変更はすべてリファクタリングとみなすことができます。一般的なリファクタリング作業としては、変数名の変更、メソッド名の変更、メソッドやクラス全体の移動、大きなメソッド（または関数）をより小さなメソッド（または関数）に分割することなどが挙げられます。
アジャイルソフトウェア開発手法では、定期的な（あるいは継続的な）リファクタリングを計画し、それをチームのソフトウェア開発プロセスの不可欠な部分としています。[ 5 ]
コーディング規約により、プログラマーは、ソースコードを実行可能ファイルにコンパイルする以外の目的で処理するシンプルなスクリプトやプログラムを作成できます。ソフトウェアのサイズ（ソースコードの行数）を数えることは、現在のプロジェクトの進捗状況を追跡したり、将来のプロジェクトの見積もりの基準を設定したりするためによく行われる方法です。
一貫したコーディング規約は、結果として測定結果の一貫性を高めることにつながります。ソースコードのコメント内には、ドキュメント処理のために特別なタグがよく使用されます。代表的な例として、 javadocとdoxygenが挙げられます。これらのツールは一連のタグの使用法を指定しますが、プロジェクト内でのタグの使用方法は慣例によって決定されます。
コーディング規約は、既存のソフトウェアを処理する新しいソフトウェアの作成を簡素化します。静的コード解析の利用は1950年代以降、着実に増加してきました。この種の開発ツールの成長の一部は、開発者自身の成熟度と技術力の向上（および現代の安全性とセキュリティへの重視）によるものですが、プログラミング言語自体の特性にも起因しています。
すべてのソフトウェア開発者は、時には複雑な多数の命令を整理および管理するという問題に取り組まなければなりません。ごく小規模なソフトウェアプロジェクトを除き、ソースコード（命令）は個別のファイルに分割され、多くの場合、複数のディレクトリにまたがっています。プログラマーが密接に関連する関数（動作）を同じファイルにまとめ、関連するファイルをディレクトリにまとめるのは自然なことでした。ソフトウェア開発が、純粋に手続き的なプログラミング（ FORTRANに見られるような）から、よりオブジェクト指向的な構造（ C++に見られるような）へと移行するにつれて、単一の（パブリック）クラスのコードを単一のファイルに記述することが慣例となりました（「1 ファイルにつき 1 クラス」の慣例）。[ 6 ] [ 7 ] Java はさらに一歩進んでおり、Java コンパイラは、1 ファイルに複数のパブリック クラスが見つかった場合、エラーを返します。
ある言語の慣習が、別の言語では必須となる場合がある。言語の慣習は、個々のソースファイルにも影響を与える。ソースコードを処理するために使用されるコンパイラ（またはインタプリタ）はそれぞれ固有のものである。コンパイラがソースに適用するルールによって、暗黙の標準が作られる。たとえば、Python コードは、例えば Perl よりもはるかに一貫してインデントされている。これは、空白（インデント）がインタプリタにとって実際に意味を持つためである。Python は、関数を区切るために Perl が使用する中括弧構文を使用しない。インデントの変更が区切り文字として機能する。[ 8 ] [ 9 ] Perl や C/C++ と同様の中括弧構文を使用して関数を区切るTclでは、C プログラマーにとってかなり合理的と思われる以下の記述は許可されていない。
i = 0とし、i < 10の間、 i の二乗を計算し、 i をインクリメントする。その理由は、Tcl では、C や Java のように関数を区切るためだけに波括弧が使われるわけではないからです。より一般的には、波括弧は単語をまとめて 1 つの引数にするために使用されます。[ 10 ] [ 11 ] Tcl では、whileという単語は条件とアクションの2 つの引数を取ります。上記の例では、while には 2 番目の引数であるアクションがありません(Tcl ではコマンドの終了を区切るためにも改行文字が使用されるため)。
コーディング規約は数多く存在します。多くの例と解説については、 「コーディングスタイル」を参照してください。一般的なコーディング規約は、以下の分野を網羅している場合があります。
コーディング標準には、 CERT Cコーディング標準、MISRA C、高信頼性C++などがあります。