字下げスタイル
字下げスタイル(じさげスタイル)またはインデントスタイル(英: indent style)とは、プログラミングにおいてプログラムの構造を明らかにするために、コードのブロックの字下げをどうするかを決めたものである。本項ではC言語やそれに類似した言語を主に扱うが、他のプログラミング言語(特に括弧を使用してブロックを記述する言語)にも適用可能である。字下げスタイルはプログラミング作法の一部である。
概要
字下げは大半のプログラミング言語では必須ではない。むしろ、プログラマは他の読者、あるいは自分自身にプログラムの構造を見やすく伝えるために字下げを行う。特に字下げは、条件分岐やループといった制御構造を明示するために使われる。なお一部の言語(PythonやOccam)では、括弧やキーワードではなく字下げで構造を定義する。これはオフサイドルールと呼ばれ、字下げはコンパイラやインタプリタの解釈に影響を与え、見やすさやスタイルを超える意味を持つ。
文における中括弧の配置
字下げスタイルの主な違いは、複数の文で構成される制御の並びにおける中括弧の配置にある。以下の表は各スタイルの配置を示したもので、関数宣言における配置とは異なる場合がある。一貫性を持たせるため、各スタイルで好まれる字下げの深さに関わらず、ここでは4スペースで統一している。
括弧の配置 | スタイル |
---|---|
while (x == y)
{
something();
somethingelse();
}
|
オールマン |
while (x == y) {
something();
somethingelse();
}
|
K&R |
while (x == y)
{
something ();
somethingelse ();
}
|
GNU |
while (x == y)
{
something();
somethingelse();
}
|
ホワイトスミス |
while (x == y)
{ something();
somethingelse();
}
|
Horstmann |
while (x == y)
{ something()
; somethingelse()
;
}
|
Haskell |
while (x == y)
{ something();
somethingelse(); }
|
Pico |
while (x == y) {
something();
somethingelse();
}
|
ラトリフ |
while (x == y)
{ something();
somethingelse(); }
|
Lisp |
タブ、スペース、文字数
字下げの大きさもスタイルによって様々である。多くの初期のプログラムは字下げにタブ文字を使っていた。これは、単純であり、ソースファイルの大きさを無駄に大きくしないという利点があった。しかし同時に、定義が異なる環境でソースファイルをやり取りすると混乱が生じることがあった。例えば、UNIXのエディタでのタブ文字の長さが一般に空白文字8個分である一方、macOSでは4文字分である。そのため、最近のプログラミング向けエディタでは任意のサイズの字下げが可能で、空白文字とタブ文字を適当に混在させられることが多い。また、字下げをそもそも空白文字のみで行うこともある。
ツール
字下げスタイルやタブ文字の長さを自動的に調節するプログラムも存在する。例えば、UNIX系オペレーティングシステムによく搭載されているプログラムとして indent
がある。このようなプログラムは、その作者が一般的と考えた字下げスタイルが自分の字下げスタイルに合っている場合には有効であるが、自分の字下げスタイルと違っている場合には余計に不満が出てくる場合もある。
スタイル
K&Rのスタイル
K&Rスタイル (あるいは、カーネルスタイル)とは、ブライアン・カーニハンとデニス・リッチーの著書でK&Rこと『プログラミング言語C』で使われた字下げスタイルであり、C言語で一般に使われている。C11 の仕様書 ISO/IEC 9899:2011 のサンプル、UNIXカーネル、Linuxカーネルはこのスタイルでソースコードが書かれている。Objective-C、C++ などでは、それほど一般的ではない。このスタイルでは、ブロック開始の中括弧を制御文と同じ行に置き、ブロック内の文を字下げして記し、ブロックを閉じる中括弧を制御文と同じ字下げ位置に戻して記す(その行は中括弧が先頭になる)。関数はそれとは異なり、関数の定義の最初の中括弧は宣言の次の行の先頭に記され、宣言と同じ字下げレベルとなる(これは次の例で示すように、ANSI標準より前の構文のせいでもある(K&Rの初版の中のコードはこのような構文で書かれていた)。行頭の中括弧で関数本体の先頭を検出しているツール等があったため、標準化後や他のスタイルのコードでもここだけは同じにしていることも多い)。
int main(argc, argv)
int argc;
char *argv[];
{
...
while (x == y) {
something();
somethingelse();
if (some_error)
do_correct(); // K&Rでは単独の文しかないブロックには中括弧を付けていない。
else
continue_as_usual();
}
finalthing();
...
}
プログラミング言語C は、プログラミングにこのスタイルを推奨しているわけではない。次で述べるように、スタイルを選んだら一貫して使うように、とのみ述べている。単に同書に印刷されているプログラムリストがこのスタイルであるというだけであり、書籍としてのレイアウト上の都合による点がある(特に波括弧の手前に改行を入れない点など)とも言われる[注釈 1]。
同書自身による注意をここに引用する:
中括弧の位置はあまり重要ではないが、それに信念を持っている人々も多い。我々はある一般的なスタイルを選択した。あなたは自分に合ったスタイルを選んで、一貫してそれを使えばよい。 — Brian W. Kernighan and Dennis M. Ritchie、プログラミング言語C
これは字下げスタイルにこだわる人々への戒めでもある。著者の1人デニス・リッチーはC言語の設計開発者でもあるが、彼がこの字下げスタイルの支持者というわけでもない。
初期のC言語では、引数の型は行を分けて書かなければならなかった (関数ヘッダの直後)。
/* ISO標準化以前の関数プロトタイプ宣言がなかった時代の、オリジナルのC言語で使われていたスタイル */
int main(argc, argv)
int argc;
char *argv[];
{
...
}
1TBS(OTBS)
"The One True Brace Style"(真の中括弧スタイル)(1TBS あるいは OTBSと略される[1])はK&Rと非常に類似している。
このスタイルの支持者によれば、ブロック開始の中括弧は新たな行に置く必要はなく、最後の中括弧は概念的に対応する文と同じ位置まで上げるのだという。このスタイルの欠点は、ブロックの最後の中括弧が行を新たに必要とする点であるが、if/else や do/while ではこれが部分的に改善される。
if (x < 0) {
printf("Negative");
negative(x);
} else {
printf("Positive");
positive(x);
}
このスタイルのソースコードはブロック開始の中括弧を探すのが困難と言われるが、字下げが始まった位置は見れば明らかなので、その上の行の最後に中括弧があることは明らかである。
このスタイルができた当時、端末の行数はわずか24行であったため、ブロック開始の中括弧に1行を割くことで見える範囲が狭まることを嫌ったと考えられる。上の例でも明らかなように、if...else if...[etc.]...else といったコードでは、中括弧ごとに新たな行を消費するよりも多くの内容が少ない行数で表示できる。
AppleのXcodeはこのスタイルをデフォルトで使っている。
Linuxカーネル
LinuxカーネルのスタイルはK&Rスタイルから若干異なっており、Linuxカーネル全体で一貫して使われていることでよく知られている。[2]リーナス・トーバルズは全てのコントリビューターがこれに従うよう強く推奨している。このスタイルはK&Rから多くの要素を引き継いでいる。
このカーネルスタイルはタブを字下げに使い、タブ幅は8文字とされる。関数ヘッダに続く行の先頭で関数の括弧を開く。それ以外の場合は対応する文と同じ行の末尾で括弧を開く。switch
文のラベルは囲んでいるブロックに合わせる (字下げのレベルは1段階のみ)。複合文 (if、while、do-whileなど) が単一の文を持つ場合は括弧を付けない。ただしif-else
のいずれか片方のブロックが括弧を必要とする場合は、両方のブロックを括弧で囲む。1行の長さは80文字に制限されるが、現在は100文字まで緩和されており、元の制限を守ることは今でも推奨されている。
Linuxカーネルスタイルでは「もし条件文の片方が単一の文である場合は、両方に括弧を使う」とされている。
int power(int x, int y)
{
int result;
if (y < 0) {
result = 0;
} else {
result = 1;
while (y-- > 0)
result *= x;
}
return result;
}
強制括弧
スコープ内に1文しかない場合でも常に括弧を付けるべきだと主張する人もいる。1文だけであってもif、else、whileに常に括弧を付けることで、コードのどこかに新しい行を挿入しても常に安全である(挿入によって実行の流れがソースコードの字下げ一致しなくなることがない)。
代償として、各ブロックの最後に余分な1行が必要となる。
Java/ECMAScript
Java言語ではサン・マイクロシステムズが1995年(最終改訂は1999年4月20日)に発表した公式のコーディング規約「Code Conventions for the Java Programming Language」[3]に沿って書かれることが多い。これは、K&Rスタイルをベースに、クラス定義やメソッド定義の最初の中括弧を次の行に置いたりしない物である。また、ActionScriptやJavaScriptといったECMAScript派生言語でも一般的にJava言語コーディング規約に類似した書き方がされることが多い。
class Test {
public static void main(String[] args) {
if (args.length > 0) {
} else {
}
}
}
ストロヴストルップ
ストロヴストルップ・スタイルはビャーネ・ストロヴストルップがC++で使ったK&Rスタイルで、ストラウストラップのプログラミング入門 C++によるプログラミングの原則と実践やThe C++ Programming Languageといった彼の著書で使われている[4]。
前述のスタイルと異なり、cuddled else (elseの前後に}と{を置くスタイル) を使わない。したがってストロヴストルップ式では次のようになる[4]。
if (x < 0) {
puts("Negative");
negative(x);
}
else {
puts("Non-negative");
nonnegative(x);
}
ストロヴストルップはK&Rスタイルをクラスに拡張しており、次のように表記される。
class Vector {
public:
Vector(int s) :elem(new double[s]), sz(s) { } // Vectorのコンストラクタ
double& operator[](int i) { return elem[i]; } // インデクサ
int size() { return sz; }
private:
double * elem; // 要素へのポインタ
int sz; // 要素数
};
ストロヴストルップはpublic:
とprivate:
を字下げしない。またこのスタイルでは、関数の次の行で括弧を開く一方で、クラスについてはクラス名と同じ行の中で括弧を開いている。
ストロヴストルップ式では短い関数を1行にまとめてしまうことを許している。ストロヴストルップのスタイルはEmacsで利用できる名前付き字下げスタイルである。ストロヴストルップはC++でもK&R由来のスタイルを使うことを推奨しており、彼の最近の著書であるC++ Core Guidelinesで言及されている[5]。
BSD/KNFスタイル
Kernel Normal Form とも呼ばれるスタイルで、BSD系オペレーティングシステムでよく使われている。主にカーネルコードで使われているが、ユーザーランドのコードでもよく使われている。これは基本的にはベル研究所のUnixバージョン6と7で用いられた、きちんと文章化されたK&Rである[6]。
SunOSのカーネルとユーザーランドでも同様のスタイルが使われる[6]。KNFと同様に、AT&Tのスタイル仕様書に基づいており、ビル・ジョイNormal Formと呼ばれることがある[7]。SunOSのガイドラインは1996年に発行されており、ANSI Cについての言及がある。ソースコードの字下げが正しいかどうかはビル・シャノンが開発したcstyleで調べることができる[6][7][8]。
ハードタブ(viでは ts)は一般に8文字ぶんの幅だが、ソフトタブはその補助として定義され(vi では sw)、通常4文字幅とされている。
ハードタブはブロックを示すのに使われ、ソフトタブは文が1行に収まらずに折り返さなければならないときに使われる。
さらに言えば、関数呼び出しでは括弧の前に空白を置かないが、C言語の構文 if、while、do、switch、return は括弧の前に空白を置く(return 文で値を返すとき括弧を使用)。
以下はその例である:
while (x == y) {
something();
somethingelse();
}
finalthing();
if (data != NULL && res > 0) {
if (!JS_DefineProperty(cx, o, "data", STRING_TO_JSVAL(
JS_NewStringCopyN(cx, data, res)), NULL, NULL,
JSPROP_ENUMERATE)) {
QUEUE_EXCEPTION("Internal error!");
goto err;
}
PQfreemem(data);
} else {
if (!JS_DefineProperty(cx, o, "data", OBJECT_TO_JSVAL(NULL),
NULL, NULL, JSPROP_ENUMERATE)) {
QUEUE_EXCEPTION("Internal error!");
goto err;
}
}
static JSBool
pgresult_constructor(JSContext *cx, JSObject *obj, uintN argc,
jsval *argv, jsval *rval)
{
QUEUE_EXCEPTION("PGresult class not user-instanciable");
return JS_FALSE;
}
BSD/オールマンのスタイル
BSD/オールマン・スタイル (Allman style) もよく使われる。これはBSDで数多くのユーティリティを開発したエリック・オールマンの名が由来である (上述のBSD KNFスタイルと混同されないようにされたし)。
このスタイルでは、制御文の後の中括弧を次の行に置き、制御文と同じ字下げ位置とする。ブロック内の文は次のレベルに字下げされる[9]。
while (x == y)
{
something();
somethingelse();
}
finalthing();
これはPascalやTransact-SQLの標準的な字下げに似ていて、中括弧が "begin" や "end" といったキーワードと同じように扱われている。
(* オールマン式の字下げをPascalで記述した場合の例 *)
procedure dosomething(x, y: Integer);
begin
while x = y do
begin
something();
somethingelse();
end;
end;
このスタイルの利点は、ブロックの前後が中括弧しかないほとんど空白の行で囲まれているため、非常にわかりやすい点である。また、対応する中括弧が同じ字下げ位置に必ず来るので、その対応も目で追いやすい。またブロックの形がコードのブロックと、対応する制御文を区別する。制御文やコードブロックをコメント化するなど、コードのリファクタリングをする際に括弧の位置によるエラーを引き起こしにくくなる。また括弧の配置は一番外側の関数定義の配置と一貫性がある。
例えば以下コードは文法的に正しい。
// while (x == y)
{
something();
somethingelse();
}
これも同様。
// for (int i=0; i < x; i++)
// while (x == y)
if (x == y)
{
something();
somethingelse();
}
さらに条件付きコンパイルでも使える。
int c;
#ifdef HAS_GETCH
while ((c = getch()) != EOF)
#else
while ((c = getchar()) != EOF)
#endif
{
do_something(c);
}
このスタイルは、制御文とブロックを分離することで可読性を向上させることを目的としており、一度に表示できるコードの量は二の次となっている。
Microsoft Visual Studio(Microsoft Visual C++)は、このスタイルをデフォルトで使っている。
Allman-8
Allman-8はK&Rの亜種であるLinuxカーネルの80文字制限と8文字のタブ記号に従ったもので、アメリカの教育現場でよく使われている。このスタイルはプロジェクター使用時の可読性を向上させる。また字下げ幅と桁数制限により、深すぎるネストが一目でわかるようになる。こうした利点は初心者や学習者が複雑なコードを自然に避けるように仕向けるのに役立つ。
C#
C#言語について、マイクロソフトは「C# のコーディング規則」[10]を公開しており、このレイアウト規則はBSD/オールマンのスタイルに基づいている。
if ((val1 > val2) && (val1 > val3))
{
something();
}
ホワイトスミスのスタイル
ホワイトスミス・スタイルはあまり有名ではない。ウィッシャート・スタイルとも呼ばれ、もともとは世界初の商用Cコンパイラであるホワイトスミス・コンパイラで、ドキュメントに使われていた。またこれは初期のWindows業界でもよく使われ、Programmer's Guide to Windows (Durant、Carlson、Yao共著)、Programming Windows (Petzold著)、Windows 3.0 Power Programming Techniques (Norton、Yao共著)などのような人気のWindowsプログラミング書籍でも使われた。
このスタイルでは制御文の後の中括弧を次の行に置くが、このときに字下げする。ブロック内の文は中括弧と同じ字下げレベルに書かれる。
while (x == y)
{
something();
somethingelse();
}
finalthing();
このスタイルの利点はBSD/オールマン・スタイルと同じで、ブロックと制御文が明確に分離される点である。また、中括弧とその中の文を同じ字下げレベルにすることで概念的にこれらが1つの文と同じであることを強調する。さらに、中括弧が文法的には while 文などの一部ではなく、複合文の一部であることも強調している。
欠点は中括弧が目立たない点である。ただし、中括弧だけで1つの行となっているため、目立つか目立たないかは意見の分かれるところでもある。
if (data != NULL && res > 0)
{
if (!JS_DefineProperty(cx, o, "data", STRING_TO_JSVAL(JS_NewStringCopyN(cx, data, res)), NULL, NULL, JSPROP_ENUMERATE))
{
QUEUE_EXCEPTION("Internal error!");
goto err;
}
PQfreemem(data);
}
else if (!JS_DefineProperty(cx, o, "data", OBJECT_TO_JSVAL(NULL), NULL, NULL, JSPROP_ENUMERATE))
{
QUEUE_EXCEPTION("Internal error!");
goto err;
}
else if
は文として扱われ、プリプロセッサの#elif
と統一感がある。
GNUスタイル
BSD/オールマンやホワイトスミス・スタイルと同様、GNUスタイルでも中括弧だけで行を構成する。中括弧は空白2個ぶん字下げされ、その中の文はさらに空白2個ぶん字下げされる。ただし関数定義では字下げしない[11]。
リチャード・ストールマンが広めたスタイルであり、LISPのコードを書いた経験がベースにあると考えられる[12]。Lispではブロックに相当するもの (progn) はファーストクラスのデータ要素であり、新たな字下げレベルを与えることで強調できるが、Cではブロックは単なる構文である。このスタイルは1960 - 1970年代にあるALGOLやXPLの書籍にも見られる[13][14]。字下げとは直接関係ないが、GNUスタイルでは関数呼び出しの括弧の前にも空白を置く。
static char *
concat (char *s1, char *s2)
{
while (x == y)
{
something ();
somethingelse ();
}
finalthing ();
}
利点はBSD/オールマンやホワイトスミスと同様で、かつホワイトスミスの欠点とされた「中括弧が目立たない」という問題にも対処している。
GNU EmacsエディタやGNUのindentコマンドでは、デフォルトでこのスタイルでの字下げを行う。GNU関係者はほぼ全てこのスタイルを使っているが、GNU以外でも一部で使われている。
GNU Emacs を使わない場合や、類似のカスタマイズ可能なエディタを使えない場合、エディタによる自動字下げではこのスタイルはなかなか対応できない。
ホルストマン・スタイル
1997年にケイ・S・ホルストマンが執筆したComputing Concepts with C++ Essentialsではオールマン・スタイルの亜種が使われており、ブロックの頭で括弧を開き、同じ行に最初の文を置いている。このスタイルはイェンセンとルイスが書いたPascal User Manual and Report[15]でも使われている。
while (x == y)
{ something();
somethingelse();
//...
if (x < 0)
{ printf("Negative");
negative(x);
}
else
{ printf("Non-negative");
nonnegative(x);
}
}
finalthing();
このスタイルではオールマンの長所である読みやすさを重視した括弧の縦の並びを維持し、ブロックを識別しやすくしつつ、K&Rスタイルのような1行を節約できる一挙両得のスタイルである。しかし2003年の改版では全面的にオールマン・スタイルが採用された[16]。
Picoスタイル
Picoという言語で、その開発者も一般に使っているスタイルは、これまでに説明したどのスタイルとも異なっている。Pico には return 文がなく、文の終わりを示す記号としてではなく文と文の分離記号としてセミコロンが使われていることから、次のようなスタイルが生まれた[17]:
stuff(n):
{ x: 3 * n;
y: doStuff(x);
y + x }
その利点と欠点は、画面表示量を重視するK&Rスタイルに近い。また、どちらの中括弧も独立した行になっていないという点でK&Rスタイルよりも一貫性があるとも言える。
ラトリフのスタイル
C・ウェイン・ラトリフは著書Programmers at Work[18]で以下のスタイルについて書いている。スタイルは1TBSとほぼ同じだが、閉じ括弧はネストしたブロックの字下げと同じ位置になる。ラトリフはdBase-IIと-III、4GLなどの人気ソフトのオリジナル版のプログラマ。このスタイルは元々はDECで仕様化されていた。バナー式とも呼ばれる[19]。ブロックのヘッダ部だけを字下げレベルで特別に目立たせるスタイルである。ちょうど、K&Rスタイルでブロックの終わりの中括弧の字下げレベルを戻さないスタイルである。
// Cの例
for (i = 0; i < 10; i++) {
if (i % 2 == 0) {
doSomething(i);
}
else {
doSomethingElse(i);
}
}
マークアップ言語では次のようになる。
{|
|-
| lots of stuff...
more stuff
|| alternative for short lines || etc.
|}
{|
|-
... etc
|}
Lispスタイル
さらに、終わりの中括弧を別の行にしない書き方もある。このスタイルでは中括弧はブロックの識別の役に立たないが、情報のない行を省くという利点もある。Lispで非常に一般的であるためLispスタイルと呼ぶことができるほか、Pythonスタイルとも呼べる。Pythonには括弧はないが、以下のコードブロックが示すように、レイアウトは非常に似ている。Pythonではレイアウトは言語の一部であり、オフサイドルールと呼ばれる。
for(i = 0; i < 10; i++) {
if(i % 2 == 0) {
doSomething(i); }
else {
doSomethingElse(i); } }
// Cの例
for (i = 0; i < 10; i++)
{if (i % 2 == 0)
{doSomething(i);}
else
{doSomethingElse(i);
doThirdThing(i);}}
# Pythonの例
for i in range(10):
if i % 2 == 0:
do_something(i)
else:
do_something_else(i)
do_third_thing(i)
;; Lispの例
(dotimes (i 10)
(if (= (rem i 2) 0)
(do-something i)
(progn
(do-something-else i)
(do-third-thing i))))
Haskellスタイル
Haskellでは中括弧とセミコロンを利用でき、中括弧の配置は任意である[20]。以下の2つの例はいずれもコンパイラに同一のコードとして扱われる。
braceless = do
text <- getContents
let
firstWord = head $ words text
bigWord = map toUpper firstWord
putStrLn bigWord
braceful = do
{ text <- getContents
; let
{ firstWord = head $ words text
; bigWord = map toUpper firstWord
}
; putStrLn bigWord
}
その他
ある状況では、ブロックの境界を見失う危険性が生じる。制御構造が複雑で何重にも入れ子になっているときに起きやすい。そのようなコードをスクロールしながら見ていて、制御構造のつながり方を見失うのである。
始まりの中括弧を数えることで制御構造を確認する場合、K&Rなどのスタイルでは、制御構造と中括弧が見た目で分離されていないため、問題が発生しやすい。字下げレベルを手掛かりとする場合は、K&Rスタイルなどの方がブロックを表示する行数が少なくなるため、可読性が増す。
for文などで制御構造を見失うのを防ぐため、ハードタブの8文字幅などの大きな字下げを使ったり、大きな関数をもっと読みやすい小さな関数に分割したりする。Linux ではK&Rスタイルに加えて、そのような手法を使用している。
別の方法として、閉じる側の中括弧の行に以下のようなコメントを加える:
for ( int i = 0 ; i < total ; i++ ) {
foo(bar);
} //for ( i )
if (x < 0) {
bar(foo);
} //if (x < 0)
しかし、この方法では同じコードをソース内の2ヶ所に記述しているため、修正を行う際に問題となる。
折りたたみ機能のあるエディタを使うという手法もあり、ある字下げレベル以降のブロックを隠して表示するなどの機能が使える。
参考文献
脚注
注釈
- ^ 日本語版ではそうなっていないが、同書の原書はレイアウトに気が配られている。
出典
- ^ “1TBS”. 2022年4月15日閲覧。
- ^ このスタイルについての詳細はここで詳しく示されているkernel.org.
- ^ Code Conventions for the Java Programming Language: Contents
- ^ a b Stroustrup, Bjarne (September 2010). “PPP Style Guide”. 2022年4月15日閲覧。
- ^ “C++ Core Guidelines”. GitHub. 3 November 2018閲覧。
- ^ a b c Shannon, Bill (19 August 1996). “C Style and Coding Standards for SunOS”. Sun Microsystems, Inc. 15 June 2019閲覧。
- ^ a b “DTraceToolkit Style Guide”. 6 February 2015閲覧。
- ^ “cstyle.pl”. illumos-gate. Sun Microsystems, Inc. (9 September 1998). 6 February 2015閲覧。
- ^ “indent style”. The on-line hacker Jargon File (2003年12月29日). 2022年3月20日閲覧。
- ^ C# のコーディング規則 - C# プログラミング ガイド | Microsoft Docs
- ^ “Formatting Your Source Code”. GNU Coding Standards. 6 June 2016閲覧。
- ^ Stallman, Richard (28 October 2002). “My Lisp Experiences and the Development of GNU Emacs (Transcript of speech at the International Lisp Conference)”. 6 June 2016閲覧。
- ^ R. Baumann, M. Feliciano, F. L. Bauer, and K. Samuelson, Introduction to Algol, 1964, https://archive.org/details/introductiontoal00baum
- ^ W. M. McKeeman, J. J. Horning, and D. B. Wortman, A Compiler Generator, 1970, https://archive.org/details/compilergenerato00mcke
- ^ Jensen, Kathleen; Wirth, Niklaus (1974). PASCAL User Manual and Report. Springer-Verlag
- ^ Horstmann Style Guide
- ^ Ohno, Asako (2013). “学生のコーディングスタイルにばらつきがあることを前提に、模範となるコーディングスタイルを教えるための方法論”. 2013 IEEE Frontiers in Education Conference (FIE): 1908–1910. doi:10.1109/fie.2013.6685167. ISBN 9781467352611.
- ^ Lammers, Susan (1986). Programmers at Work. Microsoft Press. ISBN 978-0-914845-71-3
- ^ “Artistic Style 2.05 Documentation”. Artistic Style. 24 April 2015閲覧。
- ^ “The Haskell 98 Report”. haskell.org. 3 March 2016閲覧。