PEP: 7
Title: Cソースコードのスタイルガイド
Version: $Revision: 1.2 $
Author: guido@python.org (Guido van Rossum)
Status: Active
Type: Informational
Created: 05-Jul-2001
Post-History:

始めに

    この文書は、PythonのCによる実装をなすCのソースコードの書法の様式を与える。
    Python プログラムのスタイルに対するガイドラインを規定するPEP[1]も併せて参照していただきたい。
    This document gives coding conventions for the C code comprising
    the C implementation of Python.  Please see the companion
    informational PEP describing style guidelines for Python code[1].

    規則は破られるためにあるということに注意していただきたい。以下の二つの理由がある場合には、
    個々のルールが破られることが妥当となる事もある。:
    Note, rules are there to be broken.  Two good reasons to break a
    particular rule:
    (1) 規則を適用することによって、このスタイルガイドに従うソースコードを読むことになれている人にとっても、
     読みにくいソースコードとなってしまう場合。
   (2) (歴史的な事情によって)このルールにしたがっていない既存のソースコードとの一貫性を保つ必要がある場合。
   もっともこの場合には、誰かの汚いコードをきれいにするよいチャンスでもあるけれど。
   (1) When applying the rule would make the code less readable, even
        for someone who is used to reading code that follows the rules.

    (2) To be consistent with surrounding code that also breaks it
        (maybe for historic reasons) -- although this is also an
        opportunity to clean up someone else's mess (in true XP style).


C方言

   - ANSI/IOS 標準 C(1999標準)に従うこと。
   - Use ANSI/ISO standard C (the 1989 version of the standard).

   - GCC拡張を使わない。(つまり、複数行に渡る文字列を継続を示すバックスラッシュを使わないで書くこと)
   - Don't use GCC extensions (e.g. don't write multi-line strings
      without trailing backslashes).
   - すべての関数の宣言と定義は完全なプロトタイプをもつこと。(つまり、すべての引数の型が指定されていること)
    - All function declarations and definitions must use full
      prototypes (i.e. specify the types of all arguments).
    - Never use C++ style // one-line comments.
    - C++式の // 一行コメントを決して使わないこと。

    - No compiler warnings with major compilers (gcc, VC++, a few
      others).
    - 主要なコンパイラ(gcc, VC++, その他)で警告メッセージが出ないこと。

ソースプログラムの配置

    - Use single-tab indents, where a tab is worth 8 spaces.
    - ソースのインデントには、タブ一つを使う。タブは八個の空白に等しいとする。
    - No line should be longer than 79 characters.  If this and the
      previous rule together don't give you enough room to code, your
      code is too complicated -- consider using subroutines.
    - 一行あたりの文字数が79文字を越えないこと。この規則と一つ前の規則では、コードを記述する
      十分な場所がないとすると、そのコードは複雑過ぎる。このような場合にはサブルーチン化を検討すること。

    - No line should end in whitespace.  If you think you need
      significant trailing whitespace, think again -- somebody's
      editor might delete it as a matter of routine.
    - 行は空白文字で終わってはいけない。もし、行末の空白文字がどうしても必要な場合には、
   もう一度考え直してみよう。いずれにせよ誰かのエディタはそれらの空白文字をいつもの作業として
     とり除いてしもうかもしれない。

    - Function definition style: function name in column 1, outermost
      curly braces in column 1, blank line after local variable
      declarations.
    - 関数定義の書法:関数名は行頭から始める。関数本体を囲む"{"も行頭から始める。
      ローカル変数の宣言のあとには、空行を挿入する。

        static int
        extra_ivars(PyTypeObject *type, PyTypeObject *base)
        {
                int t_size = PyType_BASICSIZE(type);
                int b_size = PyType_BASICSIZE(base);

                assert(t_size >= b_size); /* type smaller than base! */
                ...
                return 1;
        }

    - Code structure: one space between keywords like 'if', 'for' and
      the following left paren; no spaces inside the paren; braces as
      shown:
    - ソースプログラムの構造:"if", "for" などの予約語と続く左カッコ"(","{"の間には一文字の空白を入れる。
   カッコやブレースの中には空白を入れない。例:

        if (mro != NULL) {
                ...
        }
        else {
                ...
        }

    - The return statement should *not* get redundant parentheses:
    - return文には余分なカッコをつけない事。

        return Py_None; /* correct */
        return(Py_None); /* incorrect */

    - Function and macro call style: foo(a, b, c) -- no space before
      the open paren, no spaces inside the parens, no spaces before
      commas, one space after each comma.
    - 関数、マクロ呼出 :foo(a, b, c) 関数名と左カッコおよび左カッコと最初の引数の間には空白をいれない。
      コンマ","の前には空白をいれない。コンマの後には夫々一つの空白を入れる。

    - Always put spaces around assignment, Boolean and comparison
      operators.  In expressions using a lot of operators, add spaces
      around the outermost (lowest-priority) operators.
    - 代入、論理演算子、比較演算子の前後には空白を入れる。たくさんの演算子を使う式では、(最低の優先度を持つ)
      一番外側のカッコの周りにスペースを追加する。
    - Breaking long lines: if you can, break after commas in the
      outermost argument list.  Always indent continuation lines
      appropriately, e.g.:
    - 行の分割: 可能であれば、いちばん外側の引数リストのコンマの後で、改行する。継続行は常に
   ふさわしくインデント付けされていること。

        PyErr_Format(PyExc_TypeError,
                     "cannot create '%.100s' instances",
                     type->tp_name);

    - When you break a long expression at a binary operator, the
      operator goes at the end of the previous line, e.g.:
    - 二項演算子のところで、長い式を分割するさいには、演算子が行末に来るように分割する。:

        if (type->tp_dictoffset != 0 && base->tp_dictoffset == 0 &&
            type->tp_dictoffset == b_size &&
            (size_t)t_size == b_size + sizeof(PyObject *))
                return 0; /* "Forgive" adding a __dict__ only */

    - Put blank lines around functions, structure definitions, and
      major sections inside functions.
    - 関数定義、構造体定義、関数本体中の主要なセクションのまわりには空白行を挿入する。

    - Comments go before the code they describe.
    - コメントはそれが説明するコードの前におくこと。

    - All functions and global variables should be declared static
      unless they are to be part of a published interface
    - すべての関数と大域変数は、それらが公開されたインターフェイスの一部で無いかぎりは、
      静的(static)宣言されていること。
    - For external functions and variables, we always have a
      declaration in an appropriate header file in the "Include"
      directory, which uses the DL_IMPORT() macro, like this:
    - 外部関数と外部変数は、includeディレクトリ中の適当はヘッダファイルに宣言が含まれていること。
   またこの宣言はDL_IMPORT()マクロを使用していること。

        extern DL_IMPORT(PyObject *) PyObject_Repr(PyObject *);

名前付け規則

    - 公開された関数名にはPyプリフィックスを使う。静的な関数にPyプリフィックスを使ってはならない。
      Py_プリフィックスは大域的なサービス、Py_FatalErrorなどに予約されている。
   特定の一塊の関数(たとえばあるオブジェクト型のAPIなど)は長いプリフィックスを使う。例えば、ストリング型の
      オブジェクトに対するPyStrig_の様に。
      Use a Py prefix for public functions; never for static
      functions.  The Py_ prefix is reserved for global service
      routines like Py_FatalError; specific groups of routines
      (e.g. specific object type APIs) use a longer prefix,
      e.g. PyString_ for string functions.

    - Public functions and variables use MixedCase with underscores,
      like this: PyObject_GetAttr, Py_BuildValue, PyExc_TypeError.
    - 公開された関数と変数ではアンダースコア"_"と大文字・小文字を混ぜた名前を使う。
       例:PyObject_GetAttr, Py_BuildValue, PyExc_TypeError.
   - Occasionally an "internal" function has to be visible to the
      loader; we use the _Py prefix for this, e.g.: _PyObject_Dump.
   - 内部的な関数の名前をloaderに通知する必要がある場合には、それらn関数に_Pyプリフィックスを使う。
    - Macros should have a MixedCase prefix and then use upper case,
      for example: PyString_AS_STRING, Py_PRINT_RAW.
    - マクロ名はアンダースコア、大文字・小文字からなるプリフィックスに続いて、大文字だけからなる名前が続く。
       例: PyString_AS_STRING, Py_PRINT_RAW.



参考文献

    [1] PEP 8, Pythonプログラムのコーディング規則, van Rossum, Warsaw
        http://www.python.org/peps/pep-0008.html


Copyright

    This document has been placed in the public domain.