[Anthy-dev 2581] Re: A coding style proposal for uim (was Re: コミットポリシーに関して)

Back to archive index

Jun Inoue jun.l****@gmail*****
2005年 10月 23日 (日) 18:19:20 JST


誰も反応しないので私なりの見解を。といっても基本的に変数名が小文字だと幸
せな人なので「これはやりすぎ」みたいなのがいくつかあるだけですが。

On Sat, 08 Oct 2005 10:56:57 +0900
YamaKen <yamak****@bp*****> wrote:

> /* Enum types are capitalized.  No comma on the last element. */
> enum EnumType {
>   ONE,
>   TWO
> } et;

型名を capitalize するのは統一性に欠ける。列挙型であることを明示したいな
ら typedef しなければいい。
enum enum_type {
  ONE,
  TWO
} et;
とするべき。


>   /*
>    * Separate variable declaration block and subsequent codes by a blank
>    * line, and DO NOT initialize variables in the declarations. This makes
>    * an abstract about what this function does, in combination with the
>    * function name, at a glance.

大賛成。


>   /*
>    * Use `!' for tests even if it's not a boolean.
>    * E.g. use "if (!*p)", not "if (*p == '\0')".
>    *      use "if (!p)",  not "if (p == NULL)".
>    *
>    * Developers should aware of type of the variable without such explicit
>    * type-specific comparison.
>    *
>    * The heart of the C language is that all primitive types define zero
>    * as the false value, and it can directly be a boolean conition. Making
>    * it obsolete is an excessive anti-incorrectness movement of C++-ism, I
>    * think.
>    */

ダウト。数値の大小比較の special case に 0 が登場するときは == 0 とした
方が意味的にも、視覚的にも正確。例: strcmp(), memcmp()

それからヤマケンさんが挙げている例は、いずれも「0 である場合」「0 でない
場合」の二つで大きな隔たりがあるけど、「0 以外のどれであるか」によって定
性的な差は出ない。そういう意味で if(*p) / if (p) は boolean test です。
この場合は私はどっちでもいい。むしろ if (p) でサボりたいときもあれば、
for (p = a[0]; p != NULL; p++) みたいに条件を目立たせたいときもある。
どっちで書かなくてはいけない、というのを決める意義は無いと思う。

ただしはっきりと boolean test なものは比較無しがいい。
if (isdigit(c) != 0) は無意味。


>   best_score = 0;
>   for (candidate = *candidates; candidate; candidates++) {
>     score = 0;
>     for (cp = candidate; *cp; cp++) {
>       if (*cp == ' ')
>         score = -1;
>     }
>     /*
>      * An inequality expression should always be written as
>      * (lesser < greater) order regardless of which side is the
>      * subject. It helps visualizing the numeric positions as a number
>      * line in an intuitive interpretation, especially in a range
>      * comparison as follows.
>      *
>      * Ruby: (worst..best) === n
>      * C:    (worst <= n && n <= best)
>      */
>     if (0 <= score)
>       score = (*evaluate)(candidate);
>     if (best_score <= score)
>       selected = candidate;
>   }

反対。
if (a > 0)
  positive;
if (a < 0)
  negative;
else
  perror(NULL);
みたいに、処理を切り分ける判断の主体をはっきりさせて書いた方がわかりやす
い。こともある。主体がころころ場所を変わらない方が機械的に条件式を認識で
きる。一方で、単純な一変数の判定でない場合は数直線的に並べた方がいいこと
もある。どっちか一方に固定するのは良くない。
ところで C0 <= x && x <= C1 は云わずもがなかと。


>    * Use `!' for tests even if it's not a boolean.
>    * E.g. use "if (!*p)", not "if (*p == '\0')".
>    *      use "if (!p)",  not "if (p == NULL)".

Duplicate.


>    * DO NOT cast a pointer in C++-style.
>    * E.g. use "(int *)p", not "(int*)p"

やりすぎ。どっちの表記も意味を正確にあらわしてるし、どっちで書いても間違
いにもつながらないし、どうせ () の方が視覚的にも優先度が高い。


>    * Do not use C++ style '0' for a NULL pointer.

何故? if (fp) 式の記述を許してるんだから当然 NULL == 0 は意識するでしょ
う。


>   /* Second level indents are also two spaces. */
>   while (cnt < 20)
>     z = a + really + long + statement + that + needs + two lines +
>       gets + indented + four + spaces + on + the + second +
>       and + subsequent + lines;

s/two lines/two + lines/   s/four/two/   :p


>   /*
>    * a return statement at end of a function should be separated by a
>    * blank line.

意味ないと思います。特に反対でもありませんが。


最後に独り言:
GNU style indentation がいーなー

-- 
Jun Inoue
jun.l****@gmail*****



Anthy-dev メーリングリストの案内
Back to archive index