ヘタなコードの書き方

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

基礎編
    * サブルーチン(関数)を長くする。数百行以上。
    * コピペ多用
    * ネストを深くする
    * フラグを多用する
    * マジックナンバーを使いまくる
    * 識別子(変数名、関数名)は意味不明に
    * グローバル変数つかいまくり
まとめサイト
http://www34.atwiki.jp/hetacode/
↓以下、応用編、上級者編

2 ：

クラスの数だけインターフェースがある

3 ：

if (success == true) ・・・
とか、bool値のリテラルとの比較があると、コードが素人くさくなる。
(if (success != false) みたいにfalseとの比較ならいいとかって話じゃなくてね)

4 ：

/*************************************************
 *
 *
 *
 *************************************************/
サブルーチンごとに、先頭に、こういう罫線を囲んだコメントがついてるとか。
ひどくなると、サブルーチンの途中でもがんがん入れてある。

5 ：

if not notNullCheck(notNullFlg) then

6 ：

' <<<------------ 初期化 ------------>>>
 ：
 ：
' <<<------------ DB更新 ------------>>>
 ：
コメントにいらん飾りを入れる

7 ：

基礎編
見れば分かるコメントを入れる
fp = fopen(path, "r"); // ファイルオープン
return hogeLength; // hogeの長さを返す
 

8 ：

言語依存なものばかりだな

9 ：

グローバル変数の応用編
size = **;
func(table);
配列は引数で渡してるのに、配列に入ってるデータの個数はグローバル変数で渡すとかってコードを見たときは、
鳥肌たった。

10 ：

Java、C++ あたりのサブルーチンの途中でも変数宣言できる言語でも、宣言は全部サブルーチンの
先頭で行う。

11 ：

引数が３０個以上ある関数

12 ：

// ADD START M.YAMADA 2008/4/15
 :
 :
// ADD END
変更履歴みたいなコメントが大量にあるとか、変更前のコードとか削除したコードを消さずに
コメントアウトして残してあるとか。

13 ：

>>12
それは言語の責任ではないしコードの問題でもない
バージョン管理システムに類するものの有無の問題だ

14 ：

・ 暗黙の型変換(キャスト)
・ 省略可能な{}を省略してしまう(K&R)
・ 難解な演算子の使用法
　 (例) o = --o - o--;

15 ：

int xxx = 0;
int xxxx = 0;
int xxxxxx = 0;
int xxxxxxx = 0;
↑こういうのじゃなくて
int xxx       = 0;
int xxxx      = 0;
int xxxxxx   = 0;
int xxxxxxx = 0;
↑こういういちいち桁を揃えてるほうが素人っぽく見える

16 ：

>>13
コードの問題です。
コードの書き方と環境の問題は切り離せません。

17 ：

・インデントがずれてる。
・関数が長い(制御のブロックが長い)
・削除せずにコメントアウトしてコードを残してる
のコンボで、どうしようもないコードをいじったことがある。
制御ブロックの最後の } がどこに対応してるか、目で追うのが大変すぎるから、
エディタの対応する括弧に飛ぶ機能を使おうとしたら、
// if (hoge > 100) {  // DEL M.YAMADA 2000/10/10
if (hoge > 200 {  // MODIFY M.YAMADA 2000/10/10
みたいなコードが途中に何行もあって、それも使えないでやんの。

18 ：

>>14
>　 (例) o = --o - o--;
これは、下手なコードと言うよりバグだろ。

19 ：

>>17
それは自動整形に通せよ
インデントのズレ修正とコメント削除はできるだろ

20 ：

>>17
コメント内の括弧を対応させようとする間抜けなエディタを使うのを止めたらいい。

21 ：

Cで。
文字列はかならず memset() で初期化。
かつ NULL を使うと上級者。
memset(s, NULL, sizeof s);

22 ：

>>20
素のviしかない環境で作業させられた。
つか、ふだんそういう機能が必要になる局面がないんで、つかってるエディタが、言語の
コメントを意識するかとか、考えたこともないけど。

23 ：

>>19
しょうがないから、コメントとか、大量のデバッグprintはいったん削除して作業した。
勝手にコメントを削除していいような空気でなかったんで、動作確認したら、
変更箇所をもとのソースに書きもどしたけど。

24 ：

>>22
それは作業環境の改善を要求するべきだったね。とりあえずvimかemacs入れてもらうとか。
少なくともSyntax Coloringするエディタは言語のコメントを意識してるかな。

25 ：

>>22-23
それならばスレ違い

26 ：

if (cond)
  return true;
else
  return false;

27 ：

職場の年寄りがVB.NETで仕事してるけど、やっぱ変数名は intHoge とか lngHoge とかやってる。
打ち合わせで、ハンガリアンやめましょー、みたいな話がでて、そうしようみたいになってたと思うけど、
伝わってなかったか。
ほかの人も、MSのクラスライブラリの作成ガイドラインみたいな文章に沿いましょうみたいな話に
なってたはずだけど、なぜか定数値だけは、HOGE_MAX みたいな、Cのスタイルにこだわってたし。

28 ：

>>27
ああ、あるな。

29 ：

やる気の低下で1週間とか放置することがあるから汚いコードとは思いつつコメントだけは多めに入れてある

30 ：

後で大変なことになるぞーと思いつつ、バカが考えたコーディング規約厳守だから俺にはどうにも出来ないorz

31 ：

checkをchkとか、countをcntとか、単語を省略すると一気に素人くさいコードになるな。
とくにcntは、ネイティブはぜったいやらない省略。

32 ：

じゃあこれらは何かの間違いか全部非英語圏の人間の書いたコードだな
ttp://www.google.com/codesearch?q=cnt&hl=en

33 ：

contine なんだかcontrolなんだかcountなんだかワカンネーよ

34 ：

continueだったorz

35 ：

少なくとも1ページ目に出てるのは contine でも control でもなさそうだ

36 ：

ならば問う、cntの正体とはは何だね？明智君

37 ：

変数名が hogeInfo とか hogeData もヘタクソ臭が。

38 ：

>>37
LCCなんて時代錯誤は捨ててアンダーバーで区切るべきだよな

39 ：

if (...) {
　...
}
// なにやら
// 非常に
// 長ったらしい
// 説明と
// 空白行
// の後に...
else if (..) {
↑ってうぉ？！繋がってんのかよ！！！

40 ：

>>38
infoとかdataじゃ分かりにくいって話じゃないのかこれ。

41 ：

hogeってそのまま書いてあるのか。そりゃひどいな。

42 ：

わかりにくいっていうか、変数なんてデータが入ってるもんなんだから、いちいちDataなんてつけないでいいだろってツッコミ。

43 ：

こういうコードは頭痛が痛いな。

44 ：

>>42
かと言って例えば受信データを入れる変数を Receive にするのはもっとまずいと思うが。

45 ：

>>42
もしくはdataじゃなくてnameとかlengthとか
意味がありそうな単語を付けるとかかな。

46 ：

だから言語実装依存の話なんかしたって意味ねーんだよ

47 ：

名前や長さというのは名前ではなく所属クラス自体に持たせる情報だな
クラスがあればだが
クラスが無い場合は名前に情報を持たせるしかないだろう

48 ：

>>46
自分でスレを立てたらいいよ。"言語に依存しないコードの上手下手"とかそんな感じで。
ム板にしてはかなり盛り上がっているのだし、吠えても意味ない。

49 ：

>>48
言語や環境を特定せずに「コードが下手」と言っても意味がないという指摘なのでは
Javaの論理をVBに持ち込んでも仕方がないし、PHPの書き方をC++で使っても無為だ

50 ：

コメントの書き方とか、変数名の話とか、どこが言語実装依存かよくわからんけど。

51 ：

>8 >46
>7 や >11 辺りは比較的言語に依存しないヘタコードだと思うが。
n = 65; // n に 65 を代入する
ウボァー

52 ：

言語によっては、マジックナンバーを使うべしとか、グローバル変数をどんどん使うべしってのが
お作法になってりするのか。
たしかにN88BASICとかグローバル変数しかないし、HSPとか構造化されてないコードとか当たり前みたいだけど。

53 ：

定番の話題だけど、比較で定数を左にもってくるやつとか
if (100 == n) ・・・

54 ：

= とミスする可能性は排除するには、有りだな

55 ：

最近のコンパイラは警告してくれるけどな。

56 ：

代入と比較を間違えたらコンパイラが警告出すから、定数値を左にもってくるような不自然な書き方はしないってのが主流。

57 ：

google code searchで検索すると
==\s*0 lang:c
1,870,000
0\s*== lang:c
143,000
「定数が左」派は7%超えてるのか。
思ったより多いな。1%未満かと思ってた。

58 ：

VB.netだけど
bFlag = i = 0
って式があって一瞬混乱したんだが、こういう場合には
bFlag = 0 = i
みたいに定数を左に持ってきて、条件式だって明示するのもいいかもしれないとふと思った。

59 ：

おれは、
button.Enabled = (count = 0)
みたいに括弧でくくってるよ。

60 ：

代入演算子と等値演算子が同じなんて、言語仕様がバグってる。

61 ：

左辺と右辺が完全に独立しているから、混乱することはないので問題ない、
それよりも、式のど真ん中で代入できたり、代入がない式でもエラーが出ない方が異常じゃないかと思いつつC++を15年使ってる。

62 ：

「あとで(自分を含め)誰かが読んで何やってるかわかりにくいのがへたなコード」ってことでおｋ？
・相変わらず昔の名残で変数の宣言をメソッドの先頭でやって、後の方で使う
・同じ変数を、違う場面で(違う意味で)使いまわす

63 ：

・同じ変数を、違う場面で(違う意味で)使いまわす
これ最悪だな

64 ：

関数の中のコードをほんの数行変えてfunc2とかfunc3とかを量産するのはホントやめて欲しい。

65 ：

>1 の条件すべて満たすコードばっかりのところで仕事してる。
関数が長いのに加えてその中に長大な#ifdef〜#endifが無数にあって、一部はネストになってる。
もう人間が読めるようなものではない（がんばって読んでいるけどね）。
この仕事何年やってんだよお前ら。

66 ：

>>60 きもちわるいよね

67 ：

>>62
> ・相変わらず昔の名残で変数の宣言をメソッドの先頭でやって、後の方で使う 
C++やC#で、これプラスして、変数は必ず初期化するってルールでやってるもんだから、適当に0とかNULL
で全部初期化してたりするところもあるな。
コンパイラは未初期化の変数を参照したら警告出してくれるけど、それが台無しになってるっていう。
VB.NETは、初期化を省略したら勝手に初期化するって仕様だから、デフォでこの状態になってるけど。

68 ：

VB.NETにもスコープ用の{}みたいなのが欲しいな。
スコープを意識するような文化が根付けば
メソッドの先頭で変数宣言することも減るかもしれない。
ついでにスコープごとでの処理の抽出もしやすくなり、
自然と各メソッドも短くなるかもしれない。

69 ：

goto使いたくないからという理由で do {} while (0); でくくる。
キモいよ、キモすぎ。

70 ：

・省略可能な{}を記述してしまう
・三項演算子を使わない

71 ：

３項演算子は、書くときはすごい簡潔になってスゲーと思うんだが、他人が書いたのを読まされるときはさっぱり意味がワカンネエと感じる。

72 ：

省略可能な {} ってなに？
if (a) {b = 1;} else {b = 2;} → if (a) b = 1; else b = 2; みたいなやつのこと？

73 ：

>>69
それってdo whileの中で複数判定があって、そこでbreakさせるってこと？
別関数にしてreturnしちゃったほうが手っ取り早そうだな。

74 ：

>>72
それは3項演算子を使わないのほうじゃないのか？

75 ：

if ( a )
　b = 1; //省略可能
else
{
　b = 2; //省略不可能
　c = 1;
}
こういうことか

76 ：

そうなんですよ、いろんな箇所でbreak。
モチベーションとしては呼び出し元にreturnするのは、そのサブルーチンの最後ってことにしたいらしい。
コード自身のクオリティーがそもそも高ければ、エラー処理程度のgoto文は普通にOKだと思いマッスル。

77 ：

>>69
あるある。マイクロソフトのドライバのサンプルコードにそれが。

78 ：

if (cond) {
  n = 0;
}
こういう、一行でもカッコをつけるべしってスタイルの人は、このスタイルが絶対的に正しいって
信じ込んでる場合が多いですな。

79 ：

>>78
はい、そのスタイルは絶対神であります。

80 ：

>>75さんに言うわけじゃないけど
if、elseに限らず、たとえ省略可能であっても {} は省略しないほうがいい。
動作チェック後、たった1行の修正しようとした新人PGがこれにはまったことがあった。
省略可能とはいえ、その後のメンテを考えればつけるべき。

81 ：

if ( a )
　b = 1; //省略可能
　d = 1;
else
　d = 2;
{
　b = 2; //省略不可能
　c = 1;
}
気にしない。気にしない。

82 ：

有名プロダクツのソースとか、定番の書籍とかでも、省略してるのはよくあるよ。
追加したときに、{}を付け忘れてハマるから省略すべきでないってのが理由だけど、
そんなので嵌るのって、10年プログラムやってて、一回あるかどうかだと思われ。

83 ：

>>82
うん、Linux kernelソースなんかは全然ついてないね。
でも、プロプライエタリを複数人で開発してると、ソースの寿命ってそんなに短いわけじゃないから、
いつ新人が入ってきていじりだすか分からない。
事故は未然に防ぐという意味は十分あると思う。

84 ：

>>82
そんな理由じゃなく、神には叛けないからだろ。

85 ：

if ( a )
　b = 1;
これみたいに1行ならいいけど
for (i = 0; i < 100; i++)
　if (aaa (i)) {
　}
こんなのは外側のも囲わないと気持ち悪く感じる

86 ：

>>82
(っ´▽｀)っ
>10年プログラムやってて、一回あるかどうか
かなり高確率じゃないか。
こういうバグで数百億の損害を出すことだってあるんだよ。

87 ：

俺は１行か２行以上か考えて変えるのが面倒くさいという理由で全部に付けてる。
変更で後から付けるのも面倒だし、変更で後から外すのも面倒だ。
とにかく頭を働かせるのが面倒だ。俺のチャンクは他人より少ないんだぜ。

88 ：

2行を1行に修正した時に {} をとるってのもまぁ、律儀といえば律儀なんだろうけど変な気がする。
今のところそんな diff にはお目にかかったことがありません。

89 ：

(っ´▽｀)っがリーダーで、if文に{}をつけないメンバがいたら、
お前は今後の保守において、if文が2行になった時、
{}を付け忘れる奴がいないことを保証できるのか？
と問い詰めるね☆

90 ：

>>85
おれは、制御されるコードが一行のときだけ{} 省略ってルールでやってる。
複数行の場合は省略したら、さすがに見難いと思った。
K&Rはガンガン省略してたけど。
>>86
まあ、10年に一度ってのは、適当だけど、linuxとかやってる人は影響ないって思ってるみたいだね。
>>83
MISRAとか、ループをbrackで抜けるの禁止とか、安全側に振ったら、いくらでも厳しくなっちゃうだろうね。
たとえば{}の位置論争とか、たいがいの人はどっちでもいいじゃんと思うだろうけど、{}の省略は、なぜか
省略しない派の人は、ぜったい自分が正しいと思ってる場合が多いって話。

91 ：

> 複数行の場合は省略したら、さすがに見難いと思った。
具体的にどんなのよ？

92 ：

>>91
>>85 のようなコード

93 ：

>>90
自分が正しいと思ってるかどうかじゃなくて、実際に起こった事故の同じ轍は
二度と踏ませないという意味で説得力があるって話。

94 ：

インデントで見やすくしとけよ。

95 ：

(っ´▽｀)っ
{}の省略のメリットってなんだろう☆
2文字減らせるってことかな☆
デメリットは2行になった時に{}を付け忘れても普通に動くってことだよね
テストで気づけよと思うかもしれないが、将来直す人に対して言うことはできないよ
{}を付け忘れるなとコメントを残す？それだったら{}つけよう☆

96 ：

>>91
if (・・・) {
  if (・・・)
    n = 0;
}
こういう場合は内側のifは{}省略。外側は省略しない。

97 ：

(っ´▽｀)っ
と言いつつ(っ´▽｀)っも
if(条件A){
}
else if(条件B){
}
else{
}
ってやるけどね。
厳密に{}をつけるルールなら
if(条件A){
}
else{
　　if(条件B){
　　}
　　else{
　　}
}
だね☆

98 ：

(っ´▽｀)っ
だって、見やすいんだもん☆
条件が増えると
if(条件A){
}
else{
　　if(条件B){
　　}
　　else{
　　　　if(条件C){
　　　　}
　　　　else{
　　　　　　if(条件D){
　　　　　　}
　　　　　　else{
　　　　　　　　if(条件E){
　　　　　　　　}
　　　　　　　　else{
　　　　　　　　}
　　　　　　}
　　　　}
　　}
}
って感じで深くなっていく・・・

99 ：

>>93
でも、じっさいでかいコードを書いて、実績上げてる人でも、いらねって思ってる人もけっこうな数いるわけで。
そうでないひともいっぱいいるし。
正直「どっちでもいい」レベルの話だとしか思えない。
>>95
メリットはコードが見やすくなる。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 削除依頼 ▲
・　次のスレ
どの程度きれいなソースを書きますか
【普通のやつらの】 Arc Language 0 【上を行け】
【1行ずつ】リレープログラミング【言語問わず】
【VB.NET】LINQ友の会【C#, C♯, C#】