プログラミング作法（プログラミングさほう、）は、プログラムのソースコードを書くときの規則やガイドライン群を指す。この分野の古典は、1970年代の書籍『プログラム書法』（The Elements of Programming Style）である。時代が古いため、例はもっぱらFORTRANである。特定のプログラムで使われているプログラミング作法は、単にその作者の好みの問題という場合もあるし、企業や組織が開発したものなら、その組織の決めたコーディング標準やコーディング規約によるものという場合もある。プログラミング作法はプログラミング言語（あるいは言語ファミリ）に依存することが多いが、一部の規則は多くの言語に通用する。（例えば、C言語のソースコードで適切と思われる作法は、BASICのソースコードには通用しない、などといった事柄である）よい作法を明確に定めるのは困難である。しかし、多くのプログラミング作法に共通する要素はいくつか存在する。プログラミング作法の一部とされるのは、などである。いずれにせよ、良い作法が志向するのはプログラムの明瞭な表現である。従ってどんな言語のどんな流儀においても、といったような、基本的な理念が共有される。プログラミング作法は一般にソースコードの見た目を扱い、プログラムの可読性の向上を目指している。しかし、ソースコードのフォーマットを自動的に行うソフトウェアを使う場合、見た目に関してプログラマが気を使うべきは命名法・論理・高度な技法などということになる。実際、コンピュータにソースコードのフォーマットを任せると時間の節約になり、一種の宗教論争をしなくとも企業全体で1つの標準に従える。字下げスタイルは、制御フローやコードのブロックを識別し易くする。字下げによってコードの論理ブロックを識別するプログラミング言語では、字下げスタイルはプログラムの動作そのものに影響する。他の言語、特に括弧でブロックを示す言語では、字下げスタイルは動作には影響しない。しかし一貫した論理的な字下げスタイルを採用すると、コードが読みやすくなる。次のコードを比較してみよう。上の2つの例の方が最後の例よりも読みやすいと感じる人が多い。字下げスタイルは複数の構文が入れ子になっている場合に特に重要となる。もちろん、これらの例は読みやすさを比較するためにわざとこのように書かれており、次のような書き方がもっと簡単である（ただし、次のような書き方が出来ない言語も存在することに、注意が必要である）。Python は字下げを制御構造を示すのに使っており、正しい字下げは「必須」である。そうすることで括弧を不要とし、字下げスタイルも一定になるので、可読性が向上する。問題は Python のコードの一部を別の箇所にコピーする場合である。その場合、字下げレベルが不適切になる可能性が高い。これを手で直すのは手間がかかるが、一部のテキストエディタやIDEには自動的に字下げレベルを合わせる機能がある。また、Python のコードをウェブページなどに掲載する場合、空白を無視されると困ったことになる。ウェブページの場合、Python のコードは "codice_1" というHTMLタグで囲み、適切に表示されるようにする。Haskellも同様のオフサイドルールにより、ブロックを識別する。ただし Python とは異なり、Haskell では括弧とセミコロンを代わりに使うこともできる。隣接する行の桁位置を合わせると、誤字を見つけやすくなることがある。例えば次のコードを比較してみよう。後者の例では、前者の例で必ずしも明らかでなかった次の2点が明らかとなっている。言語によっては桁位置合わせで関連性を示すよりも、構造体などで明確に関連性を示したほうが良い。また、型がある言語では型と変数名が遠くなることから、その他コードに修正を加えた場合、関係の無い行にも修正が必要となるため、逆に悪い作法とされることも多い。あるいは、単に面倒ということもあり、実施されないこともある。自由形式言語では空白を完全に無視するものが多い。コードのレイアウトで空白をうまく使うのも、よいプログラミング作法の一部と見なされる。次のC言語のコードを比較してみよう。この2つのコードは、どちらがより良い表現と言えるのかはかなり個人差が大きい。空白を多めに取るスタイルでは、演算子の関係などは明瞭になるものの、一つの行としてのまとまりを欠く。「地の行では空白を入れるが、括弧内は詰める」といった折衷的なスタイルなどもあり得る。C言語ファミリでは、行の途中でのタブ文字使用の禁止が推奨される。なぜならテキストエディタの種類や設定によって、タブ文字をどういう幅で表示するかが異なるためである。もっとも、等幅フォントを使用しない作法では、タブ幅はもはやインデントレベル以外の意味を持たなくなるため、この限りではない。変数名を適切に選択するのがよい作法の要である。不適切な変数名はコードを読みにくくし、理解しにくくする。例えば次の擬似コードを見てみよう。変数名の選択方法がよくないため、この関数のコードは何をしているのか理解しにくい。しかし次のように変数名を設定すると、より分かりやすくなる。コードの意味が分かりやすくなった。すなわち「与えられた時刻情報が24時間制に合っているなら true、合っていないなら false を返す」である。適切な変数名の選択は、プログラム全体で一貫性を持った命名を行うことで、さらにその効果を高める。こうした統一的な命名規則としてはハンガリアン記法が有名である。プログラマによっては、上のようなブーリアン型の計算結果と判断が単純に対応した判断構造は、冗長すぎるし間違いやすいと考える。従って、計算結果そのものを次のように返すのがよいと考える人もいる。これらの違いは純粋にスタイルと構文上のことであって、最近のコンパイラはどちらの形式であっても同じオブジェクトコードを生成する。逆に前者の作法を好む場合もある。その理由としてデバッグの容易さが挙げられる。ブーリアン型の条件式の中で変数への代入も行われる場合、その計算後に変数の値をデバッガで確認したいとすると、前者の方が確認が容易である。後者では、その行の実行完了後に停止させると関数から抜けてしまっており、値を確認できない（命令単位のステップ実行なら確認可能）。ループの制御構造の論理的使用もよいプログラミング作法の一部である。適切なループ方法により可読性が向上する（命令型プログラミング言語の場合）。例えば、次の擬似コードを見てみよう。このコードは変数名や字下げは問題ないが、次のようにfor文を使った方がずっと読みやすい。多くの言語では、このようなパターンは次のように短縮できる。中括弧を多用する言語では、制御構造構文には中括弧を付与することを規約とするのが一般的である。これにより、次のように誤ってセミコロンをつけたときのような発見に時間のかかるバグを回避する。あるいは、次のようにループ内で実行する行を増やしたときも中括弧を予めつけておけば、バグを回避できる。さらにプリプロセッサが続く行を削除してしまった場合にも対応できる。行ごとに何らかのリストのアイテムを列挙する場合、アイテムとアイテムを分離する記号（セパレータ）を最後のアイテムにも付与するのがよいとされる（C言語のようにそのような書き方が文法的に間違っていない場合）。これにより、行の並べ替えをした場合やアイテムを追加した場合に、セパレータを入れ忘れることによるバグを回避する。

出典:wikipedia