Difference between revisions of "Code Style (日本語)"

(work in progress...)
 
m (Done.)
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Introduction ==
+
== はじめに ==
  
''"Every second spent enforcing code style is a waste of time".'' -- Someone, at some point
+
''"コードスタイルの強制とは時間が毎秒無駄になります"'' -- ある時、誰かによれば。
  
Status: '''FALSE'''
+
状態: '''誤り'''
  
When I encounter really pretty code in the open-source world (and the closed-source world for that matter), I'm a lot more confident that the software has real quality. Of course, from case to case, this may actually not be true, and the style might lie to me, but the important thing is that it ''appears'' to have high quality to people. On the other hand, if I encounter code which appears to be shit (although it might really be of excellent quality), it's tempting for me to try and find some alternative. So while enforcing code style might ''technically'' be a waste of time, it's psychologically. Also, if you ever intend to use LÖVE as a reference when applying for a job (I've done that), there is a slight chance they will take a ten second look on the code. Even if they are advanced enough to evaluate the code properly, they will not be immune to good (nor bad) style.
+
オープンソースの世界 (クローズドソースの世界に関しても) 本当にうつくしいソースに出会うとき、ソフトウェアが素晴らしい品質がであることをいつも確信しています。もちろん、時と場合によりますので、これは実のところ正確ではないかもしれませんし、スタイルは嘘をつくこともありますが、人々にとって高品質にであることが重要であると''思います''。これに反して、酷いコードに出会ってしまったときは (本当に素晴らしい品質があるかもしれませんが)、ある選択肢を試して発見することに関しては魅力的です。
 +
心理的に、コードスタイルの実施は''技術面''において時間の無駄かもしれません。また、作業時 (それを完了したとき)に LÖVE を基準として使用するつもりならば、コードに 10 秒間の探索をするだろうという僅かな見込みがあります。たとえ適切にコードを評価するための十分な技能があるとしても、良い (または悪い) スタイルに免疫がないものと思われます。
  
'''Therefore''', because I'm such a fucking drone, I'm going to refactor some code here and there (or everywhere) to make things more beautiful. And since I'm potentially fucking up everything anyway, I thought we could decide on a coding style that the majority likes. It's unlikely that we all agree on everything ... but hopefully everyone will accept the decision of the majority.
+
'''したがって'''、このような酷い怠け者であるため、コードの一部をよりうつくしくするためにあちこち (またはどこであろうと)、コードのリファクタリングを行います。とにかく、あらゆることが潜在的に酷いので、大多数が好むであろうコードスタイルを決定できたと思います。これらすべてを全員が認めることはないでしょう……が。大多数の皆さんが決定を認めていただけることを望みます。
  
 
== Namespaces ==
 
== Namespaces ==
  
'''Namespace 本文は字下げしないでください。'''
+
'''Namespace 本文の字下げはしないでください。'''
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
namespace love
 
namespace love
Line 51: Line 52:
 
'''先頭一文字目の英字は大文字にしてください。'''
 
'''先頭一文字目の英字は大文字にしてください。'''
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
class Foo
 
class Foo
Line 73: Line 74:
 
見てわかる通り最初に "API" があることは意味のあることです。これは、通常において読者がとにかく最初に知りたいことであるからです。
 
見てわかる通り最初に "API" があることは意味のあることです。これは、通常において読者がとにかく最初に知りたいことであるからです。
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
class Foo
 
class Foo
Line 93: Line 94:
 
</source>
 
</source>
  
'''For multiple inheritance, each class should appear on its own line.'''
+
'''多重継承では、各クラスは別々の行に記述してください。'''
  
Each line should ''start'' with the colon or comma. My experience is that this is the most flexible style with respect to diffs and #ifdeffery.
+
各行はコロンまたはカンマで''始めて''ください。私の経験において、これが diff コマンドと ifdeffery に関して最も柔軟性があるスタイルです。
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
class Foo : public Bar
 
class Foo : public Bar
Line 119: Line 120:
 
== 初期化指定子リスト ==
 
== 初期化指定子リスト ==
  
'''Like inheritance lists, each initialization on its own line.'''
+
'''継承リストと同様に、初期化指定子は別々の行に記述してください。'''
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
Foo::Foo()
 
Foo::Foo()
Line 141: Line 142:
 
'''関数およびメソッドにはキャメルケースを使用してください。'''
 
'''関数およびメソッドにはキャメルケースを使用してください。'''
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
int doomFist(int where);
 
int doomFist(int where);
Line 152: Line 153:
 
</source>
 
</source>
  
'''Parentheses should appear directly after the name, with no space in between.'''
+
'''括弧は間にスペースを挟まず名前の直後に記述してください。'''
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
int doomFist(int where);
 
int doomFist(int where);
Line 164: Line 165:
 
</source>
 
</source>
 
    
 
    
'''There must be no unnecessary space immediately after the open-paren and immediately before the close-paren.'''
+
'''開括弧の直後および閉括弧の直前には余計なスペースを記述しないでください。'''
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
int doomFist(int where);
 
int doomFist(int where);
Line 176: Line 177:
 
</source>
 
</source>
  
'''One-liners like getters and setters can be inlined in the class declaration. (More-than-one-liners should however not be inlined).'''
+
'''クラス宣言においてゲッターとセッターは一行記法 (One-liner) によりインライン化できます (一行以上ならばインライン化しないでください)'''
  
'''RECOMMENDED:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
class Foo
 
class Foo
Line 190: Line 191:
 
</source>
 
</source>
  
'''DISCOURAGED:'''
+
'''非推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
class Foo
 
class Foo
Line 212: Line 213:
 
</source>
 
</source>
  
== Control blocks ==
+
== 制御ブロック ==
  
'''Control blocks should have a space between the keyword the parenthesized''' expression. This differentiates control statements visually from function calls.
+
'''制御ブロックはキーワードと式括弧の間を空けて記述してください。'''これは関数呼び出しからの制御文を視覚的に区別しやすくするためのです。
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
if (foo)
 
if (foo)
Line 228: Line 229:
 
</source>
 
</source>
  
'''Braces should normally be omitted if they can. (Saves vertical space).'''
+
'''可能であれば、通常は括弧を省略してください (縦方向の空間を残しておくためです)'''
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
if (foo)
 
if (foo)
Line 244: Line 245:
 
</source>
 
</source>
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
if (foo)
 
if (foo)
Line 268: Line 269:
 
</source>
 
</source>
  
'''Braces should appear on the next line.'''
+
'''括弧は次行に記述してください。'''
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
if (foo)
 
if (foo)
Line 287: Line 288:
 
</source>
 
</source>
  
== Pointer affinity ==
+
== ポインタの類似性 ==
  
'''For pointers and references, the asterisk/ampersand should appear next to the variable name.'''
+
''ポインターと参照において、アスタリスクおよびアンパサンドは変数名側に記述してください。''
  
This makes it consistent with dereferencing (*foo), and is preferred by most LÖVE devs.
+
これは間接参照 (*foo) との整合性を保つためであり、ほとんどの LÖVE 開発者の間では好まれている記法です。
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
int *foo;
 
int *foo;
Line 308: Line 309:
 
</source>
 
</source>
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
int *get_int_ptr();
 
int *get_int_ptr();
Line 323: Line 324:
 
</source>
 
</source>
  
== Spaces vs Tabs ==
+
== スペース vs タブ ==
  
I personally prefer tabs, but I know I'm the only person in the world. We will probably end up with spaces, in which case I suggest 4 spaces per level.
+
筆者個人としてはタブのほうが好みですが、それは世界中で筆者だけであることがわかっています。結局はスペースを選択するでしょう。よって、その場合は1つのレベルに対して4文字のスペースの使用を提案します。
  
EDIT: I was wrong, everyone (who has so far given a damn) has preferred tabs. In that case, let me specify a more advanced indentation guideline for the truly l33t, hardcore, and handsome.
+
追記: 筆者の考えは間違っておりました。これまでのところ関心を持った方々はタブを好まれています。この場合、ハッカー風 (訳注: l33t - 本来の意味です) の本格的かつ正確で先進的なインデントのガイドラインを指定させていただきます。
  
MIXED TABS AND SPACES (*monocle pops*)
+
タブとスペースの併用 (*モノクルポップス*)
  
'''Use tabs for normal indentation.'''
+
'''通常はインデント (字下げ) ではタブを使用してください。'''
  
I.e. when indicating scope.
+
すなわち、有効範囲 (スコープ) を示すためです。
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
if (foo)
 
if (foo)
Line 351: Line 352:
 
</source>
 
</source>
  
'''Use spaces for alignment.'''
+
'''整列にはスペースを使用してください。'''
  
If you ''really'' want to align stuff, then the important thing to keep in mind is that the alignment should not break if the viewer is using a tab-size that's different from yours. So, in this example, we're aligning stuff:
+
''本当''に整列を必要とするならば、考慮すべき重要なことは、あなたが使用しているビューアソフトとは異なる1タブ当たりの幅が使用されている場合には、整列を破綻しないようにすることです。そのため、この用例では、内容を整列しています:
 
<source lang="cpp">
 
<source lang="cpp">
 
if (foo)
 
if (foo)
Line 364: Line 365:
 
</source>
 
</source>
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
if (foo)
 
if (foo)
Line 386: Line 387:
 
</source>
 
</source>
  
However, use alignment sparingly, because it makes a lot of diff noise when you add something that's longer than the currently longest thing, and you have to realign everything. So the best option is actually:
+
しかしながら、現時点で最長のものに長いものを追加すると、 diff コマンドを使用したときに不必要な情報を生成してしまうため整列は控え目に使用してください。それでも実際には最良の選択肢です:
  
== Trailing whitespace ==
+
== 末尾のスペース ==
  
'''Trim all trailing whitespace.'''
+
'''末尾のスペースを削除してください。'''
  
Tabs and spaces before a newline character increase the noise in commits and the source code.
+
改行文字の前にタブおよびスペースがあるとコミット時にソースコードの不要情報が増えてしまいます。
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
<tab>foo();
 
<tab>foo();
Line 408: Line 409:
 
</source>
 
</source>
  
== Documentation blocks ==
+
== ドキュメンテーションブロック ==
  
'''Asterisks should be aligned vertically.'''
+
'''アスタリスクは垂直方向に整列してください。'''
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
/**
 
/**
  * Short description.
+
  * 手短な説明。
 
  *
 
  *
  * @param foo The foo that goes in the bar.
+
  * @param foo bar には foo が入ります。
  * @param bar The bar the foo foes into.
+
  * @param bar bar foo の反対です。
 
  */
 
  */
 
int foz(int foo, int& bar);
 
int foz(int foo, int& bar);
Line 426: Line 427:
 
<source lang="cpp">
 
<source lang="cpp">
 
/**
 
/**
* Short description.
+
* 手短な説明。
 
*
 
*
* @param foo The foo that goes in the bar.
+
* @param foo bar には foo が入ります。
* @param bar The bar the foo foes into.
+
* @param bar bar foo の反対です。
 
*/
 
*/
 
int foz(int foo, int& bar);
 
int foz(int foo, int& bar);
Line 435: Line 436:
  
  
If you agree to this, and you also agree that we're using tabs. You're agreeing that tabs and spaces be mixed (although in a very defined way). For a function declaration that's indented one block, you would type something like:
+
これに認める場合は、さらにタブを使用することにも認めてください。タブとスペースの併用も認めます (非常に明確なことです)。 1ブロックのインデントで記述を行う関数の宣言では、このように入力します:
  
 
   <tab>/**
 
   <tab>/**
   <tab><space>* Short description.
+
   <tab><space>* 手短な説明。
 
   <tab><space>*
 
   <tab><space>*
   <tab><space>* Long description.
+
   <tab><space>* 長めの説明。
 
   <tab><space>*/
 
   <tab><space>*/
  
 
== #includes ==
 
== #includes ==
  
'''システムインクルードではないものはダブルクォートを使用してください。'''
+
'''システムインクルードではないならば、ダブルクォートを使用してください。'''
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
#include "common/config.h"
 
#include "common/config.h"
Line 463: Line 464:
 
C スタイルのキャストを使用しているときに何のために何をしているのかを忘れないようにしてください。
 
C スタイルのキャストを使用しているときに何のために何をしているのかを忘れないようにしてください。
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
Foo *foo = (Foo *) bar;
 
Foo *foo = (Foo *) bar;
Line 479: Line 480:
 
'''NULL または 0 よりも nullptr にしてください。'''
 
'''NULL または 0 よりも nullptr にしてください。'''
  
'''YES:'''
+
'''推奨:'''
 
<source lang="cpp">
 
<source lang="cpp">
 
foo = nullptr;
 
foo = nullptr;
Line 490: Line 491:
 
bar = 0;
 
bar = 0;
 
</source>
 
</source>
 +
 +
 +
== そのほかの言語 ==
 +
{{i18n|Code Style}}

Latest revision as of 14:25, 17 May 2017

はじめに

"コードスタイルの強制とは時間が毎秒無駄になります"。 -- ある時、誰かによれば。

状態: 誤り

オープンソースの世界 (クローズドソースの世界に関しても) 本当にうつくしいソースに出会うとき、ソフトウェアが素晴らしい品質がであることをいつも確信しています。もちろん、時と場合によりますので、これは実のところ正確ではないかもしれませんし、スタイルは嘘をつくこともありますが、人々にとって高品質にであることが重要であると思います。これに反して、酷いコードに出会ってしまったときは (本当に素晴らしい品質があるかもしれませんが)、ある選択肢を試して発見することに関しては魅力的です。 心理的に、コードスタイルの実施は技術面において時間の無駄かもしれません。また、作業時 (それを完了したとき)に LÖVE を基準として使用するつもりならば、コードに 10 秒間の探索をするだろうという僅かな見込みがあります。たとえ適切にコードを評価するための十分な技能があるとしても、良い (または悪い) スタイルに免疫がないものと思われます。

したがって、このような酷い怠け者であるため、コードの一部をよりうつくしくするためにあちこち (またはどこであろうと)、コードのリファクタリングを行います。とにかく、あらゆることが潜在的に酷いので、大多数が好むであろうコードスタイルを決定できたと思います。これらすべてを全員が認めることはないでしょう……が。大多数の皆さんが決定を認めていただけることを望みます。

Namespaces

Namespace 本文の字下げはしないでください。

推奨:

namespace love
{
namespace graphics
{

class Foo
{
public:
  /* ... */
};

} // graphics
} // love

禁止:

  
namespace love
{
  namespace graphics
  {

      class Foo
      {
      public:
          /* ... */
      };

  } // graphics
} // love

クラス宣言

先頭一文字目の英字は大文字にしてください。

推奨:

class Foo
{
};

禁止:

class foo
{
};

class FOO
{
};

ブロックの可視性は徐々に狭くなる順にしてください。

見てわかる通り最初に "API" があることは意味のあることです。これは、通常において読者がとにかく最初に知りたいことであるからです。

推奨:

class Foo
{
public:
protected:
private:
};

禁止:

class Foo
{
private:
protected:
public:
};

多重継承では、各クラスは別々の行に記述してください。

各行はコロンまたはカンマで始めてください。私の経験において、これが diff コマンドと ifdeffery に関して最も柔軟性があるスタイルです。

推奨:

class Foo : public Bar
{
};

class Foo
  : public Bar
  , public Foz
{
};

禁止:

class Foo : public Bar, public Foz
{
};

初期化指定子リスト

継承リストと同様に、初期化指定子は別々の行に記述してください。

推奨:

Foo::Foo()
  : bar(0)
  , foo(1)
{
}

禁止:

Foo::Foo() : bar(0) , foo(1)
{
}

関数・メソッド

関数およびメソッドにはキャメルケースを使用してください。

推奨:

int doomFist(int where);

禁止:

int DoomFist(int where);
int doom_fist(int where);

括弧は間にスペースを挟まず名前の直後に記述してください。

推奨:

int doomFist(int where);

禁止:

int doomFist (int where);

開括弧の直後および閉括弧の直前には余計なスペースを記述しないでください。

推奨:

int doomFist(int where);

禁止:

int doomFist( int where );

クラス宣言においてゲッターとセッターは一行記法 (One-liner) によりインライン化できます (一行以上ならばインライン化しないでください)。

推奨:

class Foo
{
public:
  void setBar(int bar) { this->bar = bar; }
  int getBar() const { return bar; }
private:
  int bar;
};

非推奨:

class Foo
{
public:
  void setBar(int bar);
  int getBar() const;
private:
  int bar;
};

void Foo::setBar(int bar)
{
  this->bar = bar;
}

int Foo::getBar() const
{
  return bar;
}

制御ブロック

制御ブロックはキーワードと式括弧の間を空けて記述してください。これは関数呼び出しからの制御文を視覚的に区別しやすくするためのです。

推奨:

if (foo)
  /* ... */;

禁止:

if(foo)
  /* ... */;

可能であれば、通常は括弧を省略してください (縦方向の空間を残しておくためです)。

推奨:

if (foo)
  bar();

禁止:

if (foo)
{
  bar();
}

推奨:

if (foo)
  bar();
else
{
  foz();
  baz();
}

禁止:

if (foo)
{
  bar();
}
else
{
  foz();
  baz();
}

括弧は次行に記述してください。

推奨:

if (foo)
{
  bar1();
  bar2();
}

禁止:

if (foo) {
  bar1();
  bar2();
}

ポインタの類似性

ポインターと参照において、アスタリスクおよびアンパサンドは変数名側に記述してください。

これは間接参照 (*foo) との整合性を保つためであり、ほとんどの LÖVE 開発者の間では好まれている記法です。

推奨:

int *foo;
int &bar;

禁止:

int* foo;
int& bar;

int * foo;
int & bar;

推奨:

int *get_int_ptr();
int &get_int_ref();

禁止:

int* get_int_ptr();
int& get_int_ref();

int * get_int_ptr();
int & get_int_ref();

スペース vs タブ

筆者個人としてはタブのほうが好みですが、それは世界中で筆者だけであることがわかっています。結局はスペースを選択するでしょう。よって、その場合は1つのレベルに対して4文字のスペースの使用を提案します。

追記: 筆者の考えは間違っておりました。これまでのところ関心を持った方々はタブを好まれています。この場合、ハッカー風 (訳注: l33t - 本来の意味です) の本格的かつ正確で先進的なインデントのガイドラインを指定させていただきます。

タブとスペースの併用 (*モノクルポップス*)

通常はインデント (字下げ) ではタブを使用してください。

すなわち、有効範囲 (スコープ) を示すためです。

推奨:

if (foo)
{
<tab>bar();
}

禁止:

if (foo)
{
<space><space><space><space>bar();
}

整列にはスペースを使用してください。

本当に整列を必要とするならば、考慮すべき重要なことは、あなたが使用しているビューアソフトとは異なる1タブ当たりの幅が使用されている場合には、整列を破綻しないようにすることです。そのため、この用例では、内容を整列しています:

if (foo)
{
    int a_var      = 1;
    int anoter_var = 2;
    int moar       = 3;
    int doom       = 4;
}

推奨:

if (foo)
{
<tab>int a_var<space * 6>= 1;
<tab>int anoter_var<space>= 2;
<tab>int moar<space * 7>= 3;
<tab>int doom<space * 7>= 4;
}

禁止:

if (foo)
{
<tab>int a_var<tab * 2>= 1;
<tab>int anoter_var<tab>= 2;
<tab>int moar<tab * 2>= 3;
<tab>int doom<tab * 2>= 4;
}

しかしながら、現時点で最長のものに長いものを追加すると、 diff コマンドを使用したときに不必要な情報を生成してしまうため整列は控え目に使用してください。それでも実際には最良の選択肢です:

末尾のスペース

末尾のスペースを削除してください。

改行文字の前にタブおよびスペースがあるとコミット時にソースコードの不要情報が増えてしまいます。

推奨:

<tab>foo();

<tab>bar();

禁止:

<tab>foo();
<tab>
<tab>bar();

ドキュメンテーションブロック

アスタリスクは垂直方向に整列してください。

推奨:

/**
 * 手短な説明。
 *
 * @param foo bar には foo が入ります。
 * @param bar bar は foo の反対です。
 */
int foz(int foo, int& bar);

禁止:

/**
* 手短な説明。
*
* @param foo bar には foo が入ります。
* @param bar bar は foo の反対です。
*/
int foz(int foo, int& bar);


これに認める場合は、さらにタブを使用することにも認めてください。タブとスペースの併用も認めます (非常に明確なことです)。 1ブロックのインデントで記述を行う関数の宣言では、このように入力します:

 <tab>/**
 <tab><space>* 手短な説明。
 <tab><space>*
 <tab><space>* 長めの説明。
 <tab><space>*/

#includes

システムインクルードではないならば、ダブルクォートを使用してください。

推奨:

#include "common/config.h"

禁止:

#include <common/config.h>

キャスト

C スタイルのキャストを使用してください。

C スタイルのキャストを使用しているときに何のために何をしているのかを忘れないようにしてください。

推奨:

Foo *foo = (Foo *) bar;

禁止:

Foo *foo = (Foo*)bar;
Foo *foo = (Foo*) bar;
Foo *foo = (Foo *)bar;

null 文

NULL または 0 よりも nullptr にしてください。

推奨:

foo = nullptr;
bar = nullptr;

禁止:

foo = NULL;
bar = 0;


そのほかの言語