*develop.txt*	For Vim バージョン 9.1.  Last change: 2025 Nov 09


		  VIM リファレンスマニュアル	by Bram Moolenaar


Vimの開発						*development*

この文書は、Vimの更なる開発に参加しようという人にとって重要である。

1. 設計上の目標		|design-goals|
2. 決定事項		|design-decisions|
3. 想定していること	|design-assumptions|
4. コーディングスタイル	|coding-style|
5. ポリシー		|design-policy|

ソースコードの概要については "src" ディレクトリのREADME.txtを見てください。

Vimはオープンソースソフトウェアです。誰でもVimの開発に協力できます。パッチを送
る時はなるべく "unified diff" 形式 ("diff -u" で作る) でお願いします。
GitHub上でプルリクエストを作ることも可能ですが、必須ではありません。
http://vim.wikia.com/wiki/How_to_make_and_submit_a_patch も見てください。

==============================================================================
1. 設計上の目標						*design-goals*

重要度の順に従って書かれている(大雑把であるが)。

かなりの項目が矛盾していることを注意しておく。これは故意である。それらの間で、
バランスを取っていかねばならない。


☆Vimは... Vi互換である					*design-compatible*

何より、VimはViの気軽な置き換えとして使うことができるべきである。ユーザーが望
むなら、Vimは、オリジナルのViとの区別がほとんど付かない互換モードで使うことが
できる。

例外:
- 明白なViのバグをVimに再現しない。
- Viには異なるバージョンが存在する。私はバージョン3.7(6/7/85)を参考として
  使っている。しかし、他のバージョンのサポートも可能な限り取り込まれる。
  POSIXにおけるViのパートは、決定的な資料とは考えない。
- Vimは新しいコマンドを持つため、Viにないコマンドを入力しても機能してしまう
  場合がある。
- VimはViの持っていない多くの特徴を持つ。VimからViへ戻ることは問題を引き起こ
  すが、これは避けられないことである。
- いくつかの事柄はめったに使われた例がない(オープンモード、クラッシュ時の
  e-mailの送信、など)。これらは、誰かが何らかの理由でそれを入れるべきだと考
  え、さらにその機能が働き過ぎない場合に限って取り入れられる。
- いくつかの項目に関しては、Vi互換を保つべきかどうか、議論の余地がある。これ
  らに関しては、オプションフラグが作られるだろう。


☆Vimは... 改良されている				*design-improved*

Vimの改良点は、それをよりよいViにすべきであって、まったく違ったエディタに
してしまってはならない。拡張は "Viの精神" に従って行われる。
- 可能な限りキーボードを使う。マウスは私たちの持たぬ第３の手を必要とする。
  多くの端末はマウスを備えていない。
- それでもマウスを使うようであれば、キーボードに切り替える必要をなくす。
  マウスとキーボードの操作の混在を避けよ。
- コマンドとオプションを矛盾なく追加せよ。でなければ、それらを見つけ出し、思い
  出すのに、人々は苦労を強いられるだろう。後々、さらにコマンドやオプションが
  追加されることを忘れてはならない。
- 特性は、人々が知らなければ役に立たない。目立たない特性は追加しない、あるいは、
  少なくともその特性が存在するというヒントをドキュメントに追加すること。
- CTRLや他の修飾子の使用は最小限に留めよ、これらはタイプしにくい。
- 多くの初心者、不慣れなVimユーザーがいる。Vimを使いはじめること、そしてより多
  くを学んでいくことが、簡単にできるようにせよ。
- 特性は限りなく追加できる。新しく追加される特性は、(1)ユーザーが求めているこ
  と、(2)実装にどれほどの労力が必要か、そして(3)誰かが実際に実装している、と
  いったことに基づいて選択される。


☆Vimは... マルチプラットフォーム			*design-multi-platform*

Vimは、可能な限り、多くのプラットフォーム上の多くのユーザーの助けでありたい。
- 多くの種類の端末をサポートする。最低限の要求は、カーソルの配置機能と画面の
  クリアである。コマンドはたいていのキーボードが持つキーのみを使う。マッピン
  グには、キーボード上の全てのキーを使うことができる。
- 多くのプラットフォームをサポートする。必要条件は、誰かがそのプラットフォーム
  上でVimの開発をしたいと考えること、それによってコードに混乱をきたさないこと、
  である。
- 多くのコンパイラとライブラリをサポートする。全ての人が、他のコンパイラや
  GUIライブラリをインストールできるわけではないからである。
- 人々は、あるプラットフォームから別のプラットフォームへ、そしてGUIから端末
  バージョンへ移行する。特性は全てのバージョン、あるいは、少なくとも理に叶った
  労力でできる限りのバージョンで、提供されるべきである。ユーザーが能率的に仕事
  を仕上げるために、プラットフォームを切り替えねばならないような事態は避けたい。
- いくつかのプラットフォームでは実現できない、または、ただひとつのプラット
  フォームでしか実現できないような特性も、実装できないというわけではない。[こ
  れは前項と故意に矛盾するものであり、両者の間でバランスが取られる。]


☆Vimは... 文書化されている				*design-documented*

- 文書化されていない特性は、役に立たない。新しい特性を含んだパッチには、必ず
  ドキュメントが含まれているべきである。
- ドキュメントは、わかりやすく、理解できるものであるべきだ。例を使うことが推
  奨される。
- 文章を不必要に長くしてはならない。短い文章は、その項目を見つけやすくする。


☆Vimは... 高速で小さいサイズ				*design-speed-size*

Vimを使うことで、システムリソースに大打撃を与えてはならない。Vimを小さく、
速く保つこと。
- コンピュータは年毎により速く、大容量になっている。Vimも成長しうるが、コン
  ピュータの成長速度より速くなってはならない。Vimを古いシステム上でも使える
  よう保つ必要がある。
- 多くのユーザーは、Vimを頻繁にシェルから立ち上げる。起動は短時間でなくてはな
  らない。
- コマンドは能率的に働く必要がある。コマンドが消費する時間は、可能な限り短く
  あるべきだ。役に立つコマンドなら、多少時間がかかってもよい。
- Vimを、遅い接続を通して使う人がいることを忘れてはならない。通信にかかるオー
  バーヘッドは最小にすること。
- サイズがかなり大きく、多くの人によって使われるわけではない項目は、無効化で
  きる特性とすべきである。
- Vimは、他のいろいろな構成要素の中にある、ひとつのコンポーネントである。巨大
  なアプリケーションに変えてはならない、むしろ他のプログラムとよく協調するよう
  にせよ。


☆Vimは... 保守性が高い					*design-maintain*

- ソースコードは乱雑になってはならない。そして、信頼できるものでなくてはな
  らない。
- 読みやすくするため、すべてのファイルで同じレイアウトを取ること
  |coding-style|。
- 役に立つコメントをいれること！関数名と引数名を引用しても役に立たない。それ
  が何のためにあるのか説明すること。
- プラットフォーム独立のコードに多くの変更を加える必要をなくし、他のプラット
  フォームへの移植を簡単にできるようにすること。
- オブジェクト指向の精神を使う: データとコードを同じ場所に。コードの他の部分
  に関する知識は最小で済むように。


☆Vimは... 柔軟である					*design-flexible*

Vimは、そのユーザーに特定の作業パターンを強いるよりは、ユーザーの好むスタイル
での作業を支援すべきである。これは大きなインパクトをもつ項目(例えば、
'compatible' オプション)や、その他の詳細によって実現される。デフォルトは、多く
のユーザーがそのままのVimを楽しんで使えるように、慎重に選ばれている。コマンド
とオプションは、Vimをユーザーの希望と環境に調整するために使われる。


☆Vimは... こうではない					*design-not*

- Vim はシェルでもオペレーティングシステムでもない。Vim はターミナルウィンドウ
  を提供し、その中でシェルやデバッガを走らせることができる。例えば、ssh 接続越
  しにこれをすることが可能だ。しかし、このようなものにテキストエディタが必要な
  いなら守備範囲外だ (代わりに screen や tmux のようなものを使おう)。
  風刺を込めて曰く: "Vim は Emacs のように流し台以外ならなんでもかんでも取り込
  んでしまうようなことはしないが、Vim で流し台を洗うことはできるぞ。 ;-)"
  Vim と gdb を連携させる方法については |terminal-debugger| を参照。他の(古い)
  ツールは http://www.agide.org (リンク切れのようだ) と http://clewn.sf.net で
  見つけることができる。
- Vimは、全てのプラットフォームに渡って調和を欠くという代償を払って、見栄えを
  よくしようとする装飾的なGUIエディタではない。しかし、機能的なGUI特性は歓迎さ
  れる。


==============================================================================
2. 決定事項						*design-decisions*

折り畳み(folding)

同じバッファにいくつもの折り畳み状態を設定可能にする。例えば、あるウィンドウに
関数を折り畳んだ状態で表示し、他のウィンドウで関数の中身を表示するなど。

折り畳みはテキストを表示する方法である。テキストを変更すべきではない。したがっ
てバッファ内のテキストをウィンドウに表示する際のフィルタとして実行される。


ウィンドウの名前

"ウィンドウ" という単語は一般にいくつかの意味で使われている。スクリーン上のウィ
ンドウ、xtermのウィンドウ、Vimのバッファを表示するウィンドウなど。

混乱を避けるため、時にウィンドウと呼ばれる他の物には別の名前が付けられている。
ここに関連する物の概観を示す:

スクリーン(screen)	ディスプレイ全体。GUIでは例えば1024x768ピクセルの画
			面。Vimシェルはスクリーン全体を使うことも一部を使う
			こともできる。
シェル(shell)		Vimアプリケーション。スクリーン全体(例えばコンソール
			で実行した時)、あるいはその一部(xtermやGUI)。
ウィンドウ(window)	バッファの表示画面。Vimは複数のウィンドウを持つこと
			ができる。ウィンドウはコマンドラインやメニューバー、
			ツールバーなどといっしょに表示される。これらはシェル
			に納まる。


スペルチェック						*develop-spell*

Vim にスペルチェックを追加することになったとき、利用可能なスペルチェックのライ
ブラリやプログラムについて調査が行われた。その結果は残念なことに、Vim 内でスペ
ルチェックエンジンとして使えるものはないとわかった。これには様々な理由がある:

- マルチバイトエンコーディングをサポートしていない。1つのファイル内で複数の言
  語を使えるようにするために、少なくとも UTF-8 はサポートしていなければならな
  い。
  オンザフライな変換は常に可能とは限らない(iconv に対応している必要がある)。
- プログラムとライブラリに対して: それらをそのまま(as-is)使うには、Vim と別個
  にインストールしなければならない。これはたいてい不可能ではないが、難点である。
- パフォーマンス: いくつかのテストによると、スペルチェックを構文強調のようにオ
  ンザフライで(再描画中に)行うことは可能であった。しかし他のコードで使われたメ
  カニズムはもっと遅かった。例えば、Myspell はハッシュテーブルを使用する。ほと
  んどのスペルチェッカが使用している接辞圧縮を使うと遅くなった。
- aspell のような外部プログラムを使うには、通信メカニズムを用意しなければなら
  ない。これをポータブルな方法で行うのは複雑過ぎる(Unix だけなら比較的簡単だが、
  それでは十分ではない)。そしてパフォーマンスが問題になる(何回ものプロセス切替
  が行われる)。
- "Etten-Leur" や "et al." など、単語でない単語のサポートを欠いている。そのた
  めこれらの部分を OK とマークしなければならないが、そうすると信頼性が低下する。
- 地域や方言のサポートを欠いている。英語の単語をすべて受け付け、カナダ語でない
  単語を別に扱うことが難しくなる。
- 頻度が低い単語のサポートを欠いている。正しいがめったに使われないたくさんの単
  語が、よく使われる単語のスペルミスとみなされてしまう。
- スペル候補を作成するには速度はそれほど重要ではなく、他のプログラムやライブラ
  リをインストールすることは許容できる。しかし、単語リストが異なるとスペル候補
  が誤単語になってしまう。


スペル候補					*develop-spell-suggestions*

候補の作成には2つの基本的なメカニズムがある:
1. 誤った単語を少し変更して正しい単語とマッチするかチェックする。あるいは、正
   しい単語全てに対し、それを少し変更して誤った単語とマッチするかチェックする。
   変更とは、文字の削除・文字の挿入・2つの文字の交換などである。
2. 誤った単語と正しい単語のリストの両方に soundfolding (発音が近い単語を同じグ
   ループとみなすこと) を行って、そこでマッチを見つける。1番目のメカニズムと同
   様にいくつか変更をしてもよい。

最初のメカニズムはタイプミスを見つけるのにはよい。ハッシュテーブルの実験と、他
のスペルチェッカのソリューションを見ると、これにはtrie(ツリー構造の一種)が最適
であるとの結論になった。メモリ使用量の削減と、賢い変更を試みるということの両方
の面でである。例えば、文字を挿入するときは正しい単語につながる文字だけを試せば
よい。他の(ハッシュテーブルを使った)メカニズムは、単語のすべての位置で、ありう
るすべての文字を試さねばならない、また、ハッシュテーブルを使うには、単語の境界
が個別に認識されなければならないのに対し、trie はそれを要求しない。そのためメ
カニズムがより単純になる。

ある単語の発音は知っているがスペルを知らないという場合に soundfolding は有用で
ある。例えば、"dictionary" という単語を "daktonerie" と書いてしまうかもしれな
い。これを最初の方法で訂正しようとすると変更回数が非常に多くなってしまい、正し
いスペルを見つけるのは困難である。それに対し、これらの単語にsoundfoldingを行う
と "tktnr" と "tkxnry" になり、2文字しか違わない。

soundfoldの同値(音が似ている単語)により単語を見つけるには全てのsoundfolded
wordsのリストが必要である。どれが最良の方法かを探すための実験が行われた。案:
1. 修正候補を探すときに、その場でsound foldingを行う。つまり、正しい単語のtrie
   をたどりながら、各単語をsoundfoldingし、それがスペルミスしている単語からど
   れだけ異なるかをチェックする。これはメモリ効率の面でとても優れているが、時
   間は長くかかる。英語の場合、高速なPCで2秒ほどかかる。これは対話的な利用とし
   て受け入れられる。しかしいくつかの言語(ドイツ語、カタルニャ語など)に対して
   は10秒以上かかり、受け入れがたい。バッチ処理(自動訂正)に使うには全ての言語
   で遅すぎる。
2. soundfoldされた単語に対してtrieを使い、soundfoldingなしのときとまったく同じ
   ように検索できるようにする。そのためには、soundfoldされた各単語に対し、正し
   い単語のリストを記憶しておく必要がある。そうすると照合がとても高速になるが、
   1MB〜10MBのオーダーの大量のメモリを必要とする。ある言語の場合は元の単語のリ
   ストよりも多くなる。
3. 2番目の案と同様だが、接辞圧縮を使い、soundfoldした基本単語だけを保存するこ
   とによりメモリ消費量を減らす。これはAspellが採用している方法である。不利点
   は、誤った単語をsoundfoldする前に接辞を取り除いておかねばならないことである。
   そのため、単語の先頭・末尾における誤りに対しては対応できない。また、誤った
   単語が正しい単語から大きく異なるときは遅くなる。

我々が採用したのは、2番目のメカニズムを使い、別ファイルを使う方法である。こう
することによって、十分なメモリを持っているユーザーはとてもよい候補を得ることが
できるし、メモリが不足しているユーザーやスペルチェックだけで候補は出さなくてよ
いというユーザーはそれほどメモリを使わなくてすむ。


単語の頻度

候補をソートするにはどの単語が共通であるかを知ると役に立つ。理論的には単語の頻
度は単語とともに辞書の中に保持することができる。しかしそうすると単語につき回数
を保持しなければならない。これは単語ツリー圧縮を大いに劣化させる。また、全ての
言語に対して単語の頻度を保守するのは大変な作業である。
また、テキストに既に出てきている単語を優先するとよいだろう。このようにして特定
のテキスト内に表れる単語は候補の中で優先度が高くなる。

実装されたのは、表示中に単語を数えることである。ハッシュテーブルを使ってその単
語の回数を高速に検索する。回数は接辞ファイルでCOMMONアイテムにリストされている
単語から初期化される。そのため新規ファイルの編集を始めたときも機能する。

これは理想的ではない。Vimが長時間稼動しているほど回数は大きくなるためである。
しかし実用的には単語の回数を使わない場合に比べて注目に値するほどの改善である。

==============================================================================
3. 想定していること					*design-assumptions*

以下のセクションでは、すべての Vim コードとビルドツールが遵守する必要がある移
植性と互換性の制約を定義する。


MAKEFILES					*assumptions-makefiles*
						*POSIX.1-2001*

Vim のメイン Makefile は最大限の移植性を目指しており、POSIX.1-2001 の make で
定義された機能のみに依存し、それ以降の POSIX 標準や GNU/BSD 拡張は無視してい
る。具体的には、以下の点を避けている。

	- % パターンルール
	- POSIX.1-2001 外のモダンな代入 (`:=`, `::=`)
	- 特別なターゲット (`.ONESHELL`, `.NOTPARALLEL`, `.SILENT`, ...)
	- 順序のみの前提条件 (`|`) または自動ディレクトリ作成
	- GNU/BSD 条件文 (`ifdef`, `ifndef`, `.for`/`.endfor`, ...)

POSIX.1-2001 は従来のサフィックスルールのみをサポートしているため、別ディレク
トリに構築されるすべてのオブジェクトには明示的なルールが必要である。例:

	objects/evalbuffer.o: evalbuffer.c
		$(CCC) -o $@ evalbuffer.c

この冗長性により、同じ Makefile で、Linux、*BSD、macOS、Solaris、AIX、HP-UX、
および事実上すべての Unix 系 OS 上でデフォルトの `make` を使用して Vim を変更
せずにビルドできるようになる。

一部のプラットフォーム固有の Makefile (Windows、NSIS、Cygwin など) では、基本
的な make との互換性が不要な場合に、より高度な機能が使用されることがある。


☆C コンパイラ					*assumptions-C-compiler*
						*ANSI-C* *C89* *C90* *C95* *C99*

Vim は最大限の移植性 (|design-multi-platform| を参照) を目指しており、OpenVMS
VAX V7.3 では Compaq C V6.4-005 を使用してビルドする必要がある。

したがって、私たちが従う最新の ISO C 標準は次のとおりである:

	`C95` (ISO/IEC 9899:1990/AMD1:1995)

さらに、以下の `C99` の機能が明示的に許可される:
	- |style-comments| で要求される `//` コメント。
	- ブロック内に宣言とステートメントが混在。
	- 可変長マクロ `(..., __VA_ARGS__)`。
	- `enum` リストの末尾のコンマ。
	- `_Bool` 型 (`bool`、`true`、`false` 用)。
	- `__func__` 定義済み識別子。
	- `inline` 関数 (移植性のために `static inline` を使用)。
	- 複合リテラル `(type){ 初期化子リスト }`。
	- 論理ソース行は最大 4095 文字。

プラットフォーム固有のコードでは、そのプラットフォームでサポートされている新し
いコンパイラ機能が使用される場合がある。


☆変数のサイズ					*assumptions-variables*

型のサイズについては POSIX.1-2001 (SUSv3) に従う。これは実際には以下のことを意
味する:

	char_u	    8-bit unsigned
	int	    32-bit またはそれ以上の signed
	unsigned    32-bit またはそれ以上の unsigned


☆関数プロトタイプ				*assumptions-prototypes*

Vim では、ほとんどの内部関数プロトタイプに従来のヘッダーファイル（`.h`）を使用
していない。その代わりに、`src/proto/` ディレクトリ内にある個別の `.pro` ファ
イルを使用する構成になっており、各 `.c` ファイルに対応して 1 つの `.pro` ファ
イルが存在する。

従来の自己完結型ヘッダーファイルとは異なり、これらの `.pro` ファイルには、API
ドキュメント、構造体と列挙型の定義、その他の宣言は含まれず、関数のプロトタイプ
のみが含まれる。

`src/Makefile` にある `make proto` ターゲットは、Python スクリプト
proto/gen_prototypes.py を使ってほとんどの .pro ファイルを自動更新する。このス
クリプトは python3-clang モジュールに依存している。Note 一部の .pro ファイルは
手作業で編集されていることに注意。

==============================================================================
4. コーディングスタイル					*coding-style*

Vimのソースコードに変更を加える際、守るべきルールがある。ソースを読めるもの、
保守できるものとして保つため、これらのルールに従って欲しい。

このリストは完全ではない。より多くの例は、ソースコードを見て欲しい。

コードリポジトリには editorconfig ファイルが含まれており、配布されている
editorconfig プラグイン |editorconfig-install| と一緒に使用し、推奨スタイルに
従うようにすることができる。


☆変更する						*style-changes*

コードに変更を加える基本的なステップは:
1. GitHub からコードを取得する。これによりあなたが変更したコードをメインのコー
   ドベースに同期するのがより簡単になる (あなたの変更がメインのコードベースに
   含まれるようになるまで少しかかるかもしれない) 。
2. ドキュメントを調整する。最初にこれをやることで、あなたの行う変更がユーザー
   に与える影響について、おおまかな印象をもつことができる。
3. ソースコードに変更を加える。
4. 変更がリストされた項目に影響を与えていないか、../doc/todo.txtをチェックす
   る。
5. 新しい動作を検証し、将来的に問題が発生しないことを確認するために、
   src/testdir にテストを追加する。
6. "git diff" でパッチを作成する。
7. 変更点について付記し、できれば問題と解決策についても記載すること。説明と差
   分を添えて、|vim-dev| メーリングリストにメールを送信する。

些細な変更でない場合は、必ず github でプルリクエストを作成すること。これによ
り、テストスイートがトリガーされる。

PR は理想的には 1 つの論理的変更に対する 1 つのコミットを含めるべきである。た
だし、複数の論理的かつ独立した変更を 1 つの PR にまとめたい場合は、複数のコミッ
トを含めることができる。これにより、長い PR のレビューも容易になる。各コミット
メッセージには、変更の理由を必ず記載すること。これはレビュープロセスに非常に役
立つ。各コミットが異なる論理的変更を扱う場合、それらは Vim のリポジトリ内で別々
のパッチとして適用されることになる。

							*style-clang-format*
sound.c と sign.c は、配布された .clang-format ファイルに従って、
`clang-format` フォーマッタを使用して (半) 自動的にフォーマットできる。他のソー
スファイルはまだ .clang-format ファイルに対応していない。これは将来変更される
可能性があり、同様に再フォーマットされる可能性がある。


☆コメント						*style-comments*

関数本体内に複数行のコメントを入れないようにすること。関数が非常に複雑で、一部
を個別にコメントする必要がある場合は、関数の構造を再検討する必要がある。

ファイルヘッダーと関数の説明には以下を使用: >
    /*
     * Description
     */
<
その他すべてには以下を使用: >
    // comment
<


☆インデント						*style-indentation*

コードのインデントには 4 つのスペースを使用する。Vim を使用してソースを編集し
ている場合は、|modeline| があるため何もする必要はない。

他のエディタの場合は、リポジトリのルートに `.editorconfig` が提供される。

ソースファイル `sign.c` と `sound.c`、および新規ファイルでは、タブではなくス
ペースのみを使用する。また、新規ファイルにはインデントテストに合格するために、
`set et` を指定したモードラインを含める必要がある。


☆宣言							*style-declarations*

可能であれば、ガード内で `for` ループ変数を宣言する:
OK: >
    for (int i = 0; i < len; ++i)
<
間違い: >
    int i;
    for (i = 0; i < len; ++i)
<
常にデフォルト値を持つ変数を宣言する:
OK: >
    int n = 0;
    int *ptr = NULL;
<
間違い: >
    int n;
    int *ptr;
<

☆括弧							*style-braces*

すべての波括弧は改行しなければならない:
OK: >
    if (cond)
    {
	cmd;
	cmd;
    }
    else
    {
	cmd;
	cmd;
    }
<
間違い: >
    if (cond) {
	cmd;
	cmd;
    } else {
	cmd;
	cmd;
    }
<
OK: >
    while (cond)
    {
	cmd;
	cmd;
    }
<
間違い: >
    while (cond) {
	cmd;
	cmd;
    }
<
OK: >
    do
    {
	cmd;
	cmd;
    } while (cond);
<
または >
    do
    {
	cmd;
	cmd;
    }
    while (cond);
<
間違い: >
    do {
	cmd;
	cmd;
    } while (cond);
<

☆型							    *style-types*

説明的な型を使用すること。これらは src/vim.h や src/structs.h などで定義されて
いる。
Note すべてのカスタム型には "_T" という接尾辞が付けられることに注意

例: >
    linenr_T
    buf_T
    pos_T
<

☆空白と句読法						   *style-spaces*

関数名と括弧の間に空白はない:

OK:	func(arg);
間違い: func (arg);

`if`, `while`, `switch` 等の後には空白を入れること。

OK:	if (arg)	for (;;)
間違い:	if(arg)		for(;;)

コンマまたはセミコロンの後に空白を入れる:

OK:	func(arg1, arg2);	for (i = 0; i < 2; ++i)
間違い: func(arg1,arg2);	for (i = 0;i < 2;++i)

'=', '+', '/' 等の前後に空白を入れる。

OK:	var = a * 5;
間違い:	var=a*5;

似たような動作をグループ化するには、空行を使う。

OK: >
    msg_puts_title(_("\n--- Signs ---"));
    msg_putchar('\n');

    if (rbuf == NULL)
	buf = firstbuf;
    else
	buf = rbuf;

    while (buf != NULL && !got_int)
<
間違い: >
    msg_puts_title(_("\n--- Signs ---"));
    msg_putchar('\n');
    if (rbuf == NULL)
	buf = firstbuf;
    else
	buf = rbuf;
    while (buf != NULL && !got_int)
<

☆関数						*style-functions*

関数宣言は、戻り値の型を別のインデントされた行に記述して使用する:

OK: >
    int
    function_name(int arg1, int arg2)
    {
    }
<
間違い: >
    int function_name(int arg1, int arg2)
    {
    }
<

関数パラメータに意味のある名前を付ける。


☆共通関数を使う				 *style-common-functions*

よく使われる関数のうち、特別なVimバージョンを持つものがある。これらは理由あっ
て導入されたものなので、常にVimバージョンを使うように意識すること。

NORMAL NAME	VIM NAME	DIFFERENCE OF VIM VERSION
free()		vim_free()	NULLの解放をチェックする
malloc()	alloc()		アウトオブメモリの状況をチェックする
malloc()	lalloc()	alloc()に似ているが、long型の引数を持つ
strcpy()	STRCPY()	char_u *引数を、(char *)へキャストする
strchr()	vim_strchr()	スペシャルキャラクタを受け入れる
strrchr()	vim_strrchr()	スペシャルキャラクタを受け入れる
isspace()	vim_isspace()	128以上のキャラクタを扱うことができる
iswhite()	vim_iswhite()	Tabとスペースに対してのみTRUE
memcpy()	mch_memmove()	オーバーラップしたコピーを扱う
bcopy()		mch_memmove()	オーバーラップしたコピーを扱う
memset()	vim_memset()	全てのシステムで一定である


☆名前							*style-names*

関数の名前に31文字より長い名前は使えない。(VMSのために)

"delete" や "this" という名前の変数を使わないこと。C++で問題となる。

Vimができる限り多くのシステム上で走るという必要上、システムによってすでに定義
されている名前を使うことは避けねばならない。これは、問題となることが知られて
いる名前のリストである。名前はregexpパターンとして与えられている。

is.*()		POSIX, ctype.h
to.*()		POSIX, ctype.h

d_.*		POSIX, dirent.h
l_.*		POSIX, fcntl.h
gr_.*		POSIX, grp.h
pw_.*		POSIX, pwd.h
sa_.*		POSIX, signal.h
mem.*		POSIX, string.h
str.*		POSIX, string.h
wcs.*		POSIX, string.h
st_.*		POSIX, stat.h
tms_.*		POSIX, times.h
tm_.*		POSIX, time.h
c_.*		POSIX, termios.h
MAX.*		POSIX, limits.h
__.*		POSIX, system
_[A-Z].*	POSIX, system
E[A-Z0-9]*	POSIX, errno.h

.*_t		POSIX, for typedefs, *_T を使うこと。

wait		types.hとコンフリクトするため、関数の引数として使わない
index		グローバル宣言を覆い隠す
time		グローバル宣言を覆い隠す
new		C++の予約語

clear		Mac curses.h
echo		Mac curses.h
instr		Mac curses.h
meta		Mac curses.h
newwin		Mac curses.h
nl		Mac curses.h
overwrite	Mac curses.h
refresh		Mac curses.h
scroll		Mac curses.h
typeahead	Mac curses.h

basename()	GNU 文字列関数(GNU string function)
dirname()	GNU 文字列関数(GNU string function)
get_env_value()	Linux システム関数


☆その他						*style-various*

マクロ定義はすべて大文字にする: >
    #define SOME_THING
<

機能に関する定義は "FEAT_" で始める: >
    #define FEAT_FOO
<

'\"' を使わない、あるコンパイラはこれを扱えない。'"' はうまく機能する。

以下を使ってはならない: >
    #if HAVE_SOME
<
あるコンパイラはこれを扱えず、"HAVE_SOME" が定義されていないと訴える。
以下を使う >
    #ifdef HAVE_SOME
<
または >
    #if defined(HAVE_SOME)
<

☆スタイル						*style-examples*

１行に１つのステートメント。

間違い:	    if (cond) a = 1;

OK:	    if (cond)
		a = 1;

間違い:	    while (cond);

OK:	    while (cond)
		;

間違い:	    do a = 1; while (cond);

OK:	    do
		a = 1;
	    while (cond);


==============================================================================
5. ポリシー	*design-policy* *new-features* *deprecated-features*

新しいマイナーバージョン (例えば 9.2.0) またはメジャーバージョン (例えば 10.0)
がリリースされるまでの期間を開発サイクルと呼ぶ。開発サイクルでは、C コアへの変
更ごとに、特定のパッチリリースを参照できるように、人間が判読できる新しいパッチ
番号が付与される。典型的な開発リリースサイクルは数年続き、約 1500 ～ 2500 個の
パッチ番号が蓄積される。

リリース前に安定期間が告知される。この期間中は、明確なバグ修正、セキュリティ修
正、ドキュメントの変更、翻訳の更新、ランタイムファイルの更新 (後方互換性を損な
う変更を含まないこと) のみを受け付け、次期リリースの完成度を高めることに集中す
る。

新機能は開発サイクル内でのみ承認され、安定期間中は承認されない。サイクル中は新
機能の開発と変更が許可されるが、サイクル終了前に確定する必要がある。

マイナーリリースが作成されると、そのリリースに含まれる機能には後方互換性のない
変更は一切加えられなくなる。その後のパッチでは、Vim の C コアの互換性が維持さ
れることが期待される。ランタイムファイルは、ランタイムファイルのメンテナーが古
い動作を変更できるように、より柔軟に扱われる。

開発サイクル中に、機能が非推奨としてマークされる場合がある。非推奨機能は、コン
パイル時に適切なスイッチを使用して無効化できる。新しいリリースの後、非推奨機能
は次のサイクルで完全に削除される可能性がある。

 vim:tw=78:ts=8:noet:ft=help:norl:
