コーディング規約

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

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

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

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

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

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

品質

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

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

コーディング標準

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

複雑さの軽減

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

複雑さの管理には、次の基本原則が含まれます。プロジェクト開発中に記述されるコードの量を最小限に抑えます。これにより、不要な作業が防止され、先行および下流の両方で不要なコストが防止されます。これは、コードが少なければ、アプリケーションを作成するだけでなく、それを維持するための作業も少なくなるからです。

複雑さは、設計段階(プロジェクトのアーキテクチャーの方法)と開発段階(より単純なコードを使用することによる)の両方で管理されます。コーディングが基本的かつ単純に保たれている場合、複雑さは最小限に抑えられます。非常に多くの場合、これはコーディングを可能な限り「物理的」に保つことです。つまり、非常に直接的で、あまり抽象的ではない方法でコーディングします。これにより、読みやすく、理解しやすい最適なコードが生成されます。単純な作業に複雑なツールを使用しないことで、複雑さを回避することもできます。

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

リファクタリング

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

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

タスクの自動化

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

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

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

言語要因

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

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

 { $ i < 10 } {の間に i = 0に設定します  
     
 
    puts "$ i squared = [expr $ i * $ i]" incr i
 } 
      

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

一般的な規則

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

コーディング標準には、CERT Cコーディング標準MISRA C高整合性C++が含まれます。以下のリストを参照してください。

も参照してください

参考文献

  1. ^ 「EditorConfigは、開発者が異なるエディターとIDEの間で一貫したコーディングスタイルを定義および維持するのに役立ちます」EditorConfig
  2. ^ 「Javaプログラミング言語のコード規約:なぜコード規約があるのか​​」Sun Microsystems、Inc.1999-04-20。
  3. ^ Robert L. Glass:ソフトウェアエンジニアリングの事実と誤り; アディソンウェスリー、2003年。
  4. ^ トムギリス。 「複雑さはセキュリティの敵です」
  5. ^ ジェフリーズ、ロン(2001-11-08)。「エクストリームプログラミングとは?:設計の改善」XPマガジン。2006年12月15日にオリジナルからアーカイブされまし
  6. ^ ホフ、トッド(2007-01-09)。「C++コーディング標準:クラスファイルの命名」
  7. ^ FIFEコーディング標準
  8. ^ ヴァンロッサム、グイド(2006-09-19)。フレッドL.ドレイクジュニア(編)。「Pythonチュートリアル:プログラミングへの第一歩」Pythonソフトウェアファウンデーション。2008年9月28日にオリジナルからアーカイブされまし2014年8月17日取得
  9. ^ レイモンド、エリック(2000-05-01)。「なぜPythonなのか?」Linuxジャーナル。
  10. ^ Tcl開発者Xchange。「Tcl言語構文の要約」ActiveState。
  11. ^ Staplin、George Peter(2006-07-16)。「ブレースグループの前に改行を開始できないのはなぜですか」「TclerのWiki」。

コーディング標準のリスト

言語のコーディング規約

プロジェクトのコーディング規約

  1. ^ 「TIOBE-Cコーディング標準」tics.tiobe.com 2021-03-11を取得
  2. ^ 「C++コーディング標準」tics.tiobe.com 2021-03-11を取得
  3. ^ 「C#コーディング標準」tics.tiobe.com 2021-03-11を取得
  4. ^ 「TIOBE-Javaコーディング標準」tics.tiobe.com 2021-03-11を取得