コーディングルールの怪しい伝説

1 ：09/08/08 〜 最終レス ：11/12/12

自転車置場にようこそ。
巷で流布しているコーディングルールに関するうわさを検証するスレ。
よくあるやつだと、Cライクな言語のif文で、一行でも波括弧を省略するなって話がある。
↓こういうやつ。
×
if (n == 0)
n = 100;
○
if (n == 0) {
n = 100;
}
ぱっと思いついた有名プロダクツのソースをかいつまんで見てみたら、
括弧省略なしで統一されているのってeclipseくらいだけだった。
机上の空論ではなくて、実践的にコードを書いてる人は、こんな
ルールでバグが減ったり保守性があがることはないって知ってるんだよね。
×
linux, git, postgresql, subversion, firefox, python
apache, vim, ruby, gimp, OpenOffice, jdkのライブラリのソース
○
eclipse

2 ：

マクロの使い方によっては中括弧がないと意図しない動作になったりする。

3 ：

まあ、それはマクロの問題だよね。

4 ：

このルールは加筆されうるコードに関して意味をなすから、
加筆されるわけがないコードなら意味が無い。
業務レベルだとその判断も出来ない奴が多いから必要だと思うね。

5 ：

× 実践的にコードを書いてる人
○ 「とりあえず動けばおｋ」で書いてる人

6 ：

1文字変数を使うなってのもあるな。
使っていいのはループカウンタのi,j,kだけとか。
バリバリ書いて実績を上げてる人は、ふつーに一文字変数使ってる。

7 ：

>>5
>>1 の人たちは「お前らヘタクソだからカッコ省略するなよ」って言われるような
ひとより1000倍くらいしっかり書いてるよ。
(ヘタクソが省略しないから、なにがどうなるとは思えないけど)

8 ：

>>6
俺も原則使わないよう指導するな。
バリバリ書いて実績を上げてる人＝一文字変数使ってる人ではない。

9 ：

>>8
バリバリ系の人は、1文字変数をつかってもコードの質は落ちないって
知ってるから、使うんだと思うよ。

10 ：

javaのソースで、比較で定数を左にもってくるってを実践してるやついるな。
これは意味わかってやってるのか。
bool変数以外はミスって代入になっても、エラーになるだろ。

11 ：

意味分かってないってか、Javaの言語仕様を理解してない奴に多いな。
そしてそういう奴に限ってマネージド言語はおかしいとかわめき出す。

12 ：

>>9
3ヶ月立ったら自分のコードも他人のコードって奴だ。
変数の寿命が短く、一目で目的が分かる場合でもなければ”質は落ちる”

13 ：

>>12
質が落ちるような使いかたしなければいいじゃん。

14 ：

こういう話で、バリバリ書いてる人のコードを引き合いにだすと、
「いや、ヘタクソには有効なスタイルなんだ」って話になりがちだけど、
いいコードにうまい人むけも、ヘタクソ向けもないよ。
うまい人は、だいたい素直なコード。
ヘタほど、定数を左にもってくるとか、ループカウンタにiを避けて、nLoopとか使っちゃうとか
技巧に走ってかえって失敗してる印象。

15 ：

>>14
そんなヘタクソにルール無しで書かせたら、もっと酷いことになるよ

16 ：

サブルーチンの行数も怪しい伝説だな。
短ければ短いほどいいとか。
このまえも、某有名人のブログをみてたら、一画面に収まるようにしろって書いてあったし。
それも昔の端末の画面サイズで2,30行以下にしろとか。
コードコンプリートにサブルーチンの行数とバグの数のIBMの調査が載ってるけど、
200行以下のサブルーチンの場合は、行数がすくないほど、一行あたりのバグの数が
増えるって結果だった。
100行のサブルーチンひとつより、10行のサブルーチン10個のほうがバグが多いって結果。

17 ：

>>15
だめなルールを守らせても、ヘタクソの質は変わらなくて、そうでない人がやりにくくなるだけ。

18 ：

>>17
そんな人材教育に失敗してる環境の理論はいらない。

19 ：

>>16
C言語はOOP言語に比べて関数の粒度が大きい方がいいと思う。
C言語でOOをやると可読性(IDE込み)の限界で、大雑把にしないと保守しにくい場面があるし。

20 ：

いま、javaで、文字列の連結はStringBuffer()を使えってコーディングルールで書かされてる。
+で連結は禁止。
無意味だし、面倒だし、読みにくい。
そのルール作ったやつのコードを見てみたら、
if (s.substring(i, i+1).equals(",")) みたいのをループでまわして、文字列を最初から最後まで舐めてるのな。
仮に + 連結の最適化がなくても、これのムダ具合に比べたらかわいいもんだろ。

21 ：

そんなに変で生産性を下げるルールならコーディングに入る前に話し合って変えればいいんじゃないの？

22 ：

>>18
だから、書き方に、うまい人向けやヘタクソ向けはないって言ってるじゃん。
それを言うならヘタクソを想定してるルールがある時点で、すでに失敗してるだろ。

23 ：

>>20
1.4.2から5.0に移った際の互換性問題に過剰反応してるんだろうな。

24 ：

>>14
OOの理屈が理解で来てれば、iとnLoopに違いは無いと分かるんだろうけどな。
コーディングとソフトウェアデザインのスキルは別物と理解させるのはシンドイ orz

25 ：

C で、文字列を走査する処理で、文字列の長さをsizeof でとっていて、
文字列の終わりを越えて、ごみが入ってるところまで見にいってるって
古いコードがあって「これ、ダメですよね、ついでに修正します? 」みたいな
話をしてたら、相手がポロリと「うわ、ダセ、クリアもしてないよな?」と。
いや、文字列を入れる配列は全部memset()でクリアって流儀のコードは
幾度となく見てるけど、それはそれでダメ臭が。

26 ：

つか、指がもう自然に括弧付きで書くようになってる。
いちいち「この場合は括弧無しでもおkだから括弧省略」とか考えるの面倒くさいし。

27 ：

>>9
自分がノリノリで書いてる時はいいんだよ。
ただ、他人がそのコード見たときに「なに、この変数名？」って思って
ごっそり書き換えられるのがオチだけどな。

28 ：

C++やjavaのように変数を関数の途中で宣言できる言語でも、
Cのように、関数の先頭で全部宣言するのがいいスタイルって
信じてる人も少なからずいる。
あと、これとあわせ技で、とりあえず宣言時に0とかnullで初期化
しとくとか。
これをやると、本当の初期化を忘れたときに、コンパイラの警告が
でなくなる。

29 ：

>>27
一文字変数のほうがすっきりするところは一文字変数で。
一文字だとわからないところは、ちゃんとした名前で。
このくらいの書き分けはノリノリの状態でもできるでしょ。
というか、コードを改悪されちゃうのを見越して、最初からそれに合わせて書くってこと?

30 ：

>28
初期化忘れはアプリの動作がちょっと変になる程度で済むが、
ぬるぽは不正終了に直結し易い。
開発時には後者の方が嬉しいが（問題が発覚し易いから）、
リリース後は前者の方が無難。

31 ：

>>29
ノリノリのときは、頭がクリアだからaから順番に変数名にしてるようなコードでも
すらすらと書けちゃうんだよ。
ただ、そんなコードは後から修正されちゃうけどね。

32 ：

プログラマーはコーディングは好きだがドキュメント作りは嫌いである。
∴　ソフトウェアデザインは浸透しない

33 ：

コーディングスタイルの話で、そんな書き方ないだろって人でも、
「自分は何十人もの部隊を率いてこのコーディングルールでやってきて実績をあげてる」とか
言って、正しいと主張したりするわけですよ。
どういう仕事か明かしてくれたらまた話は別だけど、匿名でそんなこと言われても、
どういう実績をあげてるか確認しようがないわけですよ。
(さらに言えば実績といってもCOBOLのスタイルをそのままJavaに持ち込んで仕事を
してるような人でも、実績があると自負してたりするだろうけど、それは置いといて)
で、誰もが認める実績と、確認できるコーディングスタイルを元に、有効なそれを
語ろうと思って、>>1 のような例をあげているわけだけど、その例をどう考えるか触れないで
「波カッコ省略はよくない」ってただ言い返してもしょうがないと思うわけですよ。
実際、波カッコ省略で、そこらへんのPGよりいい仕事をしてるわけだから。
「それは、スキルが高いから、そういう書き方でもいいんだ」とか、
「そのサンプルは偏ってるだろ」とか、
「実はそれらは品質低いよ」とか、
「業務とかとはポリシーが違うね」とか、
なんでもいいんで、ただ言い返すだけじゃなくてそこらへんのポイントに反論ないと、
議論が深まらないんじゃないの?

34 ：

>>31
修正されずに残ってるよ。　>>1 の例とか。

35 ：

これはイタズラ者の>>1にまんまと釣られたんじゃないかな

36 ：

>>1
これ見る度にTest-RTの不具合思い出すわ

37 ：

>>1
それはな、
「子供のうちは省略するな、大人になったら省略しても良い」
ってことだよ。

38 ：

守破離ってやつだな。

39 ：

要するに>>39みたいな馬鹿に合わせるって事だな

40 ：

自己紹介乙。

41 ：

>>39が名言を吐いたと聞いて

42 ：

今>>39がいいこと言った！

43 ：

未だにシステムハンガリアン押し付けてくるところがあるんだが…

44 ：

それがC言語なら必要じゃないの？
void*みたいなダウンキャストがあると特に。

45 ：

Linuxのカーネルも *BSDのカーネルも OpenSolaris のカーネルも………
システムハンガリアン等と言う役に立たないものは使っていない

46 ：

ああ、>>44みたいなときに使うプレフィクスはアプリケーションハンガリアンって言うのね。
システムハンガリアンだけ悪ってのなら、俺も賛成する。

47 ：

void*にダウンキャストするからって、プレフィックスとかいるか？

48 ：

型が決まらないからvoid*なんだろ

49 ：

どんなポインタでも受け付けるからvoid*型と考えるのが普通。

50 ：

MFCはシステムハンガリアンが標準ですよ？＾＾

51 ：

そらMSはハンガリアンの総本山だからな。
そのMSでさえ、ハンガリアンを捨て始めてるし。

52 ：

ハンガリアンも根強いな。
でも、俺のような底辺ITドカタの周囲でもハンガリアンはやめようって流れになってる。

53 ：

ハンガリアンという6文字だけの言葉を使う人からは離れたほうがよい
その人はアプリケーションハンガリアンとシステムハンガリアンの違いを考えたことがない人だからだ
これの違いを考えたことがないということは、つまりアプリケーションハンガリアンの意義を知らないということだからだ
どっちも書くときに死ぬほどめんどくさいというのは間違いないことだが、
アプリケーションハンガリアンにはめんどくさいことをしてでも書くだけの一定の価値がある

54 ：

アプリケーションハンガリアン記法の唯一無二にして絶対の弱点は
「日本人には適切なプレフィクスを作れない」
だと思う今日このごろ
結局長くなって「慎重な変数名・メソッド名」の域を出ないシロモノに

55 ：

double<Dim = Length, Range = (-10, 100)> x
こう書けたらいいの?

56 ：

断りなくハンガリアンって言ったらシステムハンガリアンでいいだろ。
アプリケーションなんとかって言ってるやつは、最近知って揚げ足をとりたくてしかたないやつ。
昔の「HPってなに?」とか煽って喜んでた連中と同じ。

57 ：

WinのC/C++で、ネットとかで初心者に文字列は_T()で囲むようにとか
えらそうにアドバイスしてるやつうぜえ。
そんな無意味なもん使わせるな。

58 ：

とまあかようにプログラマとそうでない人が別れるのが夏
実際に議論をしたことがあるなら丸わかりなことを脳内で収めるから

59 ：

>>53
アプリケーションハンガリアンって「適切な変数名を付けましょう」って以上のことを
言ってないからなぁ。あれに感心する奴は、いままでどんなコード書いてきたんだと。
さらに言えば、プレフィックス(ハンガリアン記法)を強制する必要性も薄いよね。
Wikipediaの例で言えば、
dolIncomeじゃなくて
incomeInDolでいいわけだし。

60 ：

>>59
接辞語を前につけるかあとにつけるかなんて、根本に何ら影響しないことだろ。

61 ：

>60
コード補完使ってる場合は、前に付いてた方が有難い。
grepの時も前に付いてる方が便利な気がする。

62 ：

//**********************************************
// 見出し1
//**********************************************
　　//==========================
　　// 見出し2
　　//==========================
　　　　//-----------------
　　　　// 見出し3
　　　　//-----------------

63 ：

元のコードはコメントアウトして、絶対に削除するなが、なんだかんだと一番強烈。

64 ：

カッコ省略をカッコ省略なしにするプログラムを作ればいいじゃん

65 ：

既にあるんだから、わざわざ作る必要なし。

66 ：

組み込み向けだが、検証ネタに。
バグを生まないコーディング法、10個の規則でソフト開発を効率化
http://eetimes.jp/article/23004/
続・バグを生まないコーディング法
http://eetimes.jp/content/3107

67 ：

>>6
n て変数使っていてレビューで書き直しを命じられたから、numってしたらOKだった。
どういう意味があるんだってｵﾓﾀよ。

68 ：

grepで探し辛いだろ。
そのコードが色んな香具師の手でカオス化していき、
再設計しようって段階になった時、影響範囲を調べるのに
nとnumとじゃできる事の幅が違うぞ。
numならnum、number、etcを一気に洗い出せるが、nではそうもいかない。
…まぁ考え過ぎだ罠。

69 ：

>>67
なにか基準があっただけなんだから気にスンナ。

70 ：

>>68
num, numberという変数の影響範囲をgrepで探さないといけないようなコードは、
別のコーディングルールを適応した方がいいと思う。

71 ：

>>68
グローバル変数やクラスのメンバ変数のような
スコープの広い変数ならきちんとした名前をつけるべきだが
スコープ狭いローカル変数なら、たいして問題にならない。
１０００行くらいある関数なら別だけどｗ

72 ：

C++ならマクロもあるし納得
Javaでgrepしてるのは納得できない

73 ：

いまどきのIDEならgrepなんかより高度な検索機能で
変数全部洗い出してくれるよ。

74 ：

変数使ってる所洗い出したかったら、その変数定義をコメントアウトしてみるのが一番早い。

75 ：

2009年にjavaでgrep使う奴いる事に驚愕した

76 ：

>>75
俺のとなりではJavaをメモ帳で書いてるぞ

77 ：

>>75
いちいち検索窓開くよりそっちの方が早いもん。
IDEだとIDE管理外のソースは検索してくれないし。

78 ：

int a = 0;
if( a != 0 );
a+=1;//aが０でなければaに１を加算
if( a == 0 )
{
return true;
}
else
{
return false;//なぜかここが実行される
}

79 ：

プログラムは正しいですよ。

80 ：

;

81 ：

いや、そういう問題じゃないだろ。

82 ：

プログラムが正しければ、コメントが間違っているしかないじゃないか
何が問題なんだ？

83 ：

後半は
if( a == 0 )
return true;
else
return false;//なぜかここが実行される
にするべきだな。

84 ：

int a = 0;
if( a != 0 );
a+=1;//aが０でなければaに１を加算
if( a == 0 );
{
return true;
}
else
{
return false;//なぜかここが実行される
}
こうすればコメント通りの結果になると思う

85 ：

どんなコーディングルールだよw

86 ：

>84
これはひどい、もう一度その言語の規格書読み直した方がいい
ああ、俺様言語か、ごめん

87 ：

すまん、これはさすがに通らんわ

88 ：

int a = 1;
if( a != 1 );
a=0;//aが１でなければaに０を代入
if( a = 1 )
{
return true; //期待通りここが実行される
}
else
{
return false;
}
これなら、ちゃんと動く。

89 ：

int a = 0;
if( a != 1 );
a=0;//aが１でなければaに０を代入
if( a = 1 )
{
return true; //期待通りここが実行される
}
else
{
return false;
}
にするべきだな。

90 ：

return true; // 期待通りにここが実行される

91 ：

最初のif文の最後のセミコロンが不要なんだろうと思ったが
お前らを見てると自分が間違えてるような気がしてくる

92 ：

簡単すぎてネタにならんだろ！

93 ：

1の責任だとは思うが、どういう方向の話題をしたいのかがよく分からん。

94 ：

//================================================
// 用途: ○○を××する
// return : true=>成功、false=>失敗
// <in>　 int nHoge => うんたらの値
// <in> char *szFuga => かんたらの文字列
// <in, out> void *pData => 追加データへのポインタ
//================================================
↑前に居た会社で関数にこういうコメント付ける規則があったんだけど、
const付ける習慣が無かった。constを徹底してればinとかoutとか書く
必要無いと思うんだけど・・・経験浅いから自信ない(´･ω･`)

95 ：

こういうのは型で保証できればいいんだけどね…

96 ：

>>94
その認識で合ってるよ。

97 ：

>>94
自動ドキュメント作成ツールでも使っているんじゃないの
typedef T *S; const S s;とconst T *t;は意味が違うんだよなぁ
私はdoxygenスタイルでいつも書いている

98 ：

>>94
コメントに罫線っていうか飾りをつけると一気に素人くさいコードに
なっちゃうけど、大好きな人っていっぱいいるよね。
C#で仕事したとき、そういうコーディングルールを決められそうになったから、
C#は標準のコメントの書き方ありますよって言って、それなら、それを採用
しようってことになったんで、なんとか回避できたと思ってたら、できあがった
コーディングルールをみたら↓みたいな感じになってた。
/// <summary>
/// ***********************************************************
/// 値を加算する
/// ***********************************************************
/// </summary>
/// <param name="val"></param>
/// <returns></returns>
public int Plus(int val)

99 ：

おまけに、ドキュメントはExcelとかw

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 削除依頼 ▲
・　次のスレ
例外機構を考察するスレ
【緊急アンケート】ム板でiPhone使ってる奴の数→
攻守最強のプログラミング言語は？
コンピュータ基本知識