プログラミング スタイル(コーディング スタイルとも呼ばれる) は、ソース コードの記述で使用される規則とパターンを指し、一貫性があり読みやすいコードベースを実現します。これらの規則には、インデント、命名規則、大文字化、コメントなどの側面が含まれることがよくあります。一貫性のあるプログラミング スタイルは、特に共同作業環境において、コードの読みやすさと保守性に有益であると一般に考えられています。
コードベース全体で一貫したスタイルを維持することで、読みやすさとソフトウェアのメンテナンスのしやすさが向上します。これにより、開発者は他の人が書いたコードをすぐに理解でき、変更中にエラーが発生する可能性が減ります。標準化されたコーディング ガイドラインに従うことで、チームは統一されたアプローチに従うようになり、コードベースの管理と拡張が容易になります。多くの組織やオープンソースプロジェクトでは、コラボレーションを促進し、認知負荷を軽減するために、特定のコーディング標準を採用しています。
スタイル ガイドラインは、特定の書式設定と命名規則を規定するコーディング規約と呼ばれるドキュメントで形式化できます。これらの規約は、プログラミング言語の公式標準によって規定される場合もあれば、チームやプロジェクト内で内部的に開発される場合もあります。たとえば、 PythonのPEP 8 は、 Python コードの記述に関するベスト プラクティスを概説した、広く認知されているスタイル ガイドです。一方、 CやJavaなどの言語には、正式に文書化されているか、規約によって遵守されている業界標準がある場合があります。
オートメーション
コーディング スタイルの遵守は、事前定義されたガイドラインに従ってコードをフォーマットする自動化ツールによって強制できます。これらのツールは、スタイルの一貫性を維持するために必要な手作業を削減し、プログラマーがロジックと機能に集中できるようにします。たとえば、BlackPython やclang-formatC++ などのツールは、指定されたコーディング標準に準拠するようにコードを自動的に再フォーマットします。
スタイルガイドライン
コーディング スタイルの一般的な要素は次のとおりです。
- インデントと空白文字の使用– 一貫したブロック構造を保証し、読みやすさを向上させます。
- 命名規則–変数、関数、クラスの命名方法を標準化します。通常は、言語に応じて、キャメルケース、スネークケース、またはパスカルケースに従います。
- 大文字化– 言語構文に従って、キーワードと識別子を大文字にするか小文字にするかを指定します。
- コメントの使用– コードの実行に影響を与えずに、コード内のコンテキストと説明を提供します。
インデント
インデント スタイルは、制御フローやコード ブロックの識別など、さまざまな方法で読者を支援します。一部のプログラミング言語では、インデントはコード ブロックを区切るために使用されるため、スタイルの問題ではありません。空白を無視する言語では、インデントが読みやすさに影響する可能性があります。
たとえば、よく使用されるスタイルでフォーマットすると次のようになります。
if (時間< 24 &&分< 60 &&秒< 60 ) { return true ; } else { return false ; }
おそらくフォーマットが不十分です:
if (時間< 24 &&分< 60 &&秒< 60 ) { return true ;} else { return false ;}
注目すべきインデントスタイル
モデュリク
ModuLiq ゼロ インデント スタイルは、インデントではなく空行でグループ化します。
例:
if (時間< 24 &&分< 60 &&秒< 60 )はtrueを返します。
それ以外の場合は
falseを返します。
ルア
Lua では、従来の中括弧や丸括弧は使用されません。代わりに、条件文の式の後には が続きthen、ブロックは で閉じられる必要がありますend。
時間 < 24 、 分 < 60 、 秒 < 60 の場合はtrueを返し、それ
以外の場合はfalseを返します。終了
Lua ではインデントはオプションです。and、、orはnot論理演算子として機能します。
パイソン
Python はオフサイドルールに依存しており、インデントを使用して制御構造を示して実装するため、括弧 (つまり、{および}) は不要です。ただし、インデントされたコードをコピーして貼り付けると、貼り付けたコードのインデント レベルがターゲット行のインデント レベルと同じではない可能性があるため、問題が発生する可能性があります。このような手作業による再フォーマットは面倒でエラーが発生しやすいですが、一部のテキスト エディターと統合開発環境(IDE) には、これを自動的に行う機能があります。また、空白を削除するフォーラムや Web ページに投稿されたときにインデントされたコードが使用できなくなるという問題もありますが、コードを "<pre> ... </pre>" ( HTMLの場合)、"[code]" ... "[/code]" ( bbcodeの場合) などの空白を保持するタグで囲むことができる場合は、この
問題を回避できます。
時間 < 24 かつ 分 < 60 かつ 秒 < 60の場合:
Trueを返し、 そうでない場合: Falseを返します。
Python ではブロックはコロン ( :) で始まります。
Pythonプログラマーは、PEP8として知られる一般的に認められたスタイルガイドに従う傾向があります。[1] PEP8への準拠を自動化するように設計されたツールがあります。
ハスケル
Haskell には、Python と同様に、オフサイドルールがあります。Haskell には、ブロックを定義するためにインデントが意味を持つ 2 次元構文があります (ただし、代替構文では中括弧とセミコロンを使用します)。
Haskell は宣言型言語であり、ステートメントはありますが、Haskell スクリプト内には宣言があります。
例:
c_1 = 1、c_2 = 2とし、f x y = c_1 * x + c_2 * yとする。
1行で次のように記述できます。
f x y = c_1 * x + c_2 * yにおいて、{ c_1 = 1 ; c_2 = 2 }とします。
Haskell では、拡張テキストでコードの起源を説明する文芸的プログラミングの使用が推奨されています。文芸的 Haskell スクリプト (lhs拡張子で命名) では、コードとしてマークされたブロックを除いてすべてがコメントです。プログラムはLaTeXで記述でき、その場合、code環境がコードであるものをマークします。また、アクティブなコード段落の前後に空行を入れ、各コード行を大なり記号とスペースで始めることで、アクティブなコード段落をマークできます。以下は、LaTeX マークアップを使用した例です。
関数\ verb + isValidDate + は日付が有効かどうかをテストします\ begin { code } isValidDate :: Date -> Bool isValidDate date = hh >= 0 && mm >= 0 && ss >= 0 && hh < 24 && mm < 60 && ss < 60ここで、( hh 、mm 、ss ) = fromDate date \ end { code }この場合、オーバーロードされた関数は\ verb + fromDate :: Date -> ( Int 、Int 、Int ) + であることに注意してください。
プレーンテキストを使用した例:
isValidDate関数は日付が有効かどうかをテストします
> isValidDate :: Date -> Bool > isValidDate date = hh >= 0 && mm >= 0 && ss >= 0 > && hh < 24 && mm < 60 && ss < 60 > where ( hh , mm , ss ) = fromDate date
この場合、オーバーロードされた関数はfromDate :: Date -> ( Int , Int , Int )であることに注意してください。
垂直方向の配置
一部のプログラマーは、タイプミスによって発生したバグをより目立たせることができるとして、類似の要素を垂直に(表形式や列形式で)並べることが有益であると考えています。
たとえば、非整列の場合:
$search = 配列( 'a' 、 'b' 、 'c' 、 'd' 、 'e' );
$replacement = 配列( 'foo' 、 'bar' 、 'baz' 、 'quux' );
$値 = 0 ;
$別の値 = 1 ;
$さらに別の値 = 2 ;
整列:
$search = 配列( 'a' 、 'b' 、 'c' 、 'd' 、 'e' );
$replacement = 配列( 'foo' 、 'bar' 、 'baz' 、 'quux' );
$値 = 0 ;
$別の値 = 1 ;
$さらに別の値 = 2 ;
整列されていないコードとは異なり、整列されたコードでは、対応する要素があるため、検索値と置換値が関連していることを意味します。検索には置換値よりも 1 つ多い値があるため、これがバグである場合は、目視検査で発見される可能性が高くなります。
垂直配置の欠点として挙げられるものは次のとおりです。
- 行間の依存関係により、メンテナンスの負荷が発生します。たとえば、長い列値が追加され、より広い列が必要になる場合、表のすべての行を変更する必要があり (表形式を維持するため)、これは大きな変更となり、後日変更を確認して理解するための労力が増加します。
- 脆弱性: プログラマーが変更を加える際にテーブルを正しくフォーマットしないと、整列されていないコードよりも読みにくい視覚的な混乱が生じます。名前の変更などの単純なリファクタリング操作によって、フォーマットが壊れることがあります。
- 保守に多くの労力がかかるため、識別子の名前を改善するなど、プログラマーが有益な変更を行うことを躊躇する可能性がある。なぜなら、そうすることはかなりのフォーマット作業を必要とするからである。
- プロポーショナルフォントではなく固定幅フォントを使用する必要がある
位置合わせの維持は、サポートを提供するツール (弾性タブストップなど) によって軽減できますが、そのようなツールへの依存が生じます。
たとえば、「$replacement」を「$r」に、「$anothervalue」を「$a」に名前変更する単純なリファクタリング操作の結果は次のようになります。
$search = 配列( 'a' 、 'b' 、 'c' 、 'd' 、 'e' );
$r = 配列( 'foo' 、 'bar' 、 'baz' 、 'quux' );
$value = 0 ;
$a = 1 ;
$yetanothervalue = 2 ;
整列されていない書式設定では、これらの変更によって、それほど劇的、矛盾的、または望ましくない影響が生じることはありません。
$search = 配列( 'a' 、 'b' 、 'c' 、 'd' 、 'e' );
$r = 配列( 'foo' 、 'bar' 、 'baz' 、 'quux' );
$value = 0 ;
$a = 1 ;
$yetanothervalue = 2 ;
空白
フリーフォーマット言語は、空白文字(スペース、タブ、改行)を無視するため、プログラマーはコードの意味に影響を与えることなく、さまざまな方法でコードを自由にスタイル設定できます。通常、プログラマーは読みやすさを向上させると考えられるスタイルを使用します。
以下の 2 つのコード スニペットは論理的には同じですが、空白が異なります。
int i ; for ( i = 0 ; i < 10 ; ++ i ){ printf ( "%d" , i * i + i ); }
対
int i ; for ( i = 0 ; i < 10 ; ++ i ) { printf ( "%d" , i * i + i ); }
空白スペースにタブを使用することは議論の余地があります。環境によってタブ ストップが異なり、タブとスペースが混在して使用されるため、配置の問題が発生します。
たとえば、あるプログラマーはタブ ストップを 4 にすることを好み、ツールセットをそのように構成し、これを使用してコードをフォーマットします。
int ix ; // 配列をスキャンするインデックスlong sum ; // 合計の累算器
別のプログラマーはタブ ストップを 8 にすることを好み、そのツールセットもそのように構成されています。別の人が元のプログラマーのコードを調べると、読みにくいと感じるかもしれません。
int ix ; // 配列をスキャンするインデックスlong sum ; // 合計の累算器
この問題に対する広く使用されている解決策の 1 つは、タブを位置合わせに使用することを禁止するか、タブ ストップを設定する方法のルールを設定することです。タブは、一貫して使用され、論理的なインデントに制限され、位置合わせに使用されない限り、正常に機能することに注意してください。
class MyClass { int foobar ( int qux , // 最初のパラメーターint quux ); // 2 番目のパラメーターint foobar2 ( int qux , // 最初のパラメーターint quux , // 2 番目のパラメーターint quuux ); // 3 番目のパラメーター};
参照
- MISRA C – Cプログラミング言語のソフトウェア開発標準
- 命名規則(プログラミング) – ソースコードとドキュメント内のエンティティに名前を付けるための一連の規則
参考文献
- ^ 「PEP 0008: Python コードのスタイル ガイド」. python.org.
