この記事には複数の問題があります。改善やノートページでの議論にご協力ください。

出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2023年2月）


独自研究が含まれているおそれがあります。（2023年2月）
出典検索?: "プログラミング作法" ? ニュース ・ 書籍 ・ スカラー ・ CiNii ・ J-STAGE ・ NDL ・ dlib.jp ・ ジャパンサーチ ・ TWL

プログラミング作法（英: programming style）の記事では、コンピュータ・プログラミングおよびプログラムのスタイル（書法）についての話題を述べる。この分野の古典は、1970年代の書籍『プログラム書法』（The Elements of Programming Style）である。古典であるがゆえにプログラミング言語も古く、例がもっぱらFORTRANであるため言語の設計の古さによる制限に由来する記述も多いが、本質（Elements）は不変・普遍である。

なお、『プログラミング作法』は "The Practice of Programming" という書籍の邦題、『ソフトウェア作法』[1]は "Software Tools" という書籍の邦題である。

あるプロダクトに見られるスタイルは、単にその作者の好みの問題という場合もあるし、何らかの「コーディング標準」や「コーディング規約」などと呼ばれるものによるものという場合もある。PythonのPEP-8、PHPのPEARのように、言語のメンテナらによる、標準的なガイドラインがある言語もある。
良いスタイルとは

よいスタイルを明確に定めるのは困難である。しかし、多くの合意が得られるであろう事柄はいくつか存在する。

字下げを含めたソースコードのレイアウト

演算子やキーワード（予約語）の前後での空白の使用

キーワードと変数名の区別の明確化

ユーザー定義識別子（関数名・変数名など）の選び方、作り方

適切なコメント

適切な制御構造の使用、自由度が高すぎる機能を乱雑に使用することの戒め（例えばgoto文）

などである。

いずれにせよ、良いスタイルが志向するのはプログラムの明瞭な表現である。従ってどんな言語のどんな流儀においても、

間違ったプログラムが明らかに間違って見える

正しいプログラムはその正しさを検証する事が容易となる

といったような、基本的な理念が共有される。
見た目

ここでは主にソースコードの見た目を扱う。ソースコードの見た目は、経験の違いなどによる主観も入ってくるが、概ねメンテナンス性や可読性（読みやすさ）に影響する。

見た目に含まれるうち、フォーマットに関するものは、ガイドラインではなくルールとして、何らかのプログラムによる自動整形に任せてしまう場合もある。その場合、命名法などが残りの関心事となる。プログラムにソースコードのフォーマットを任せてしまうのは、時間の節約の他、ある程度より開発の規模が大きい場合の統一が極めて容易という利点もある。ただし、理由があって変則的なコードの場合に回避できるか、して良いか、など、議論が残る可能性は皆無ではない。またそのフォーマットを実行するツール自体の出来が悪いと、逆に問題になりうる（バグがある、カスタマイズ性が不十分など）。

また、以下の規則類の上位規則として、例えば「規則に従うと極端に行が長くなる」などといった理由が無い限りは、複数の流儀があるものについてはどの流儀を選んでもよいが、基本的に、一貫した書き方にせよ、というものがある。
空白類

太古のFORTRANでは空白類は、ほとんど全ての場合にあっても無くても同じであり、80桁のパンチカードに適切に並べることが重要だった。その後の言語では、「そこに空白が無ければ、トークンが連結してしまう」という場合には意味があるが、複数個の空白による位置の調整には特に意味が無く、また、改行も通常の空白と同様の扱い、という言語が増えた（ただし改行には、1行コメントの終了という重要な意味があることもある）。

積極的にインデントを利用するオフサイドルールを採用している言語もあるが、それらについてはここでは触れない（オフサイドルールの記事を参照）。

以下では、広義の空白類の扱いに関係する、各種のスタイルの話題を述べる。
字下げ

字下げスタイルは、制御構造やブロック（複文）を識別し易くする。PascalやC言語のように、構文規則上、begin ? end のキーワードや、波括弧{}でブロックの範囲が決まるフリーフォーマットの言語では、字下げスタイルは意味には無関係であるため、純粋に見た目の問題である。しかし一貫した論理的な見た目により、コードは読みやすくなる。次のコードを比較してみよう。
オールマン
if (hours < 24 && minutes < 60 && seconds < 60){ return true;}else{ return false;}
K&R
if (hours < 24 && minutes < 60 && seconds < 60) { return true;} else { return false;}
GNU
if (hours < 24 && minutes < 60 && seconds < 60) { return true; }else { return false; }