ヘタなコードの書き方

基礎編

    * サブルーチン(関数)を長くする。数百行以上。
    * コピペ多用
    * ネストを深くする
    * フラグを多用する
    * マジックナンバーを使いまくる
    * 識別子(変数名、関数名)は意味不明に
    * グローバル変数つかいまくり

まとめサイト
http://www34.atwiki.jp/hetacode/

↓以下、応用編、上級者編

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

if (success == true) ・・・

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

/*************************************************
 *
 *
 *
 *************************************************/

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

if not notNullCheck(notNullFlg) then

' <<<------------ 初期化 ------------>>>
 ：
 ：
' <<<------------ DB更新 ------------>>>
 ：

コメントにいらん飾りを入れる

基礎編
見れば分かるコメントを入れる

fp = fopen(path, "r"); // ファイルオープン

return hogeLength; // hogeの長さを返す

 

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

グローバル変数の応用編

size = **;
func(table);

配列は引数で渡してるのに、配列に入ってるデータの個数はグローバル変数で渡すとかってコードを見たときは、
鳥肌たった。

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

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

// ADD START M.YAMADA 2008/4/15
 :
 :
// ADD END

変更履歴みたいなコメントが大量にあるとか、変更前のコードとか削除したコードを消さずに
コメントアウトして残してあるとか。

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

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

int xxx = 0;
int xxxx = 0;
int xxxxxx = 0;
int xxxxxxx = 0;

↑こういうのじゃなくて

int xxx       = 0;
int xxxx      = 0;
int xxxxxx   = 0;
int xxxxxxx = 0;

↑こういういちいち桁を揃えてるほうが素人っぽく見える

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

・インデントがずれてる。
・関数が長い(制御のブロックが長い)
・削除せずにコメントアウトしてコードを残してる

のコンボで、どうしようもないコードをいじったことがある。

制御ブロックの最後の } がどこに対応してるか、目で追うのが大変すぎるから、
エディタの対応する括弧に飛ぶ機能を使おうとしたら、

// if (hoge > 100) {  // DEL M.YAMADA 2000/10/10
if (hoge > 200 {  // MODIFY M.YAMADA 2000/10/10

みたいなコードが途中に何行もあって、それも使えないでやんの。

>>14
>　 (例) o = --o - o--;

これは、下手なコードと言うよりバグだろ。

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

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

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

memset(s, NULL, sizeof s);

>>20
素のviしかない環境で作業させられた。

つか、ふだんそういう機能が必要になる局面がないんで、つかってるエディタが、言語の
コメントを意識するかとか、考えたこともないけど。

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

>>22
それは作業環境の改善を要求するべきだったね。とりあえずvimかemacs入れてもらうとか。

少なくともSyntax Coloringするエディタは言語のコメントを意識してるかな。

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

if (cond)
  return true;
else
  return false;

職場の年寄りがVB.NETで仕事してるけど、やっぱ変数名は intHoge とか lngHoge とかやってる。
打ち合わせで、ハンガリアンやめましょー、みたいな話がでて、そうしようみたいになってたと思うけど、
伝わってなかったか。

ほかの人も、MSのクラスライブラリの作成ガイドラインみたいな文章に沿いましょうみたいな話に
なってたはずだけど、なぜか定数値だけは、HOGE_MAX みたいな、Cのスタイルにこだわってたし。

>>27
ああ、あるな。

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

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

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

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

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

continueだったorz

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

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

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

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

if (...) {
　...
}

// なにやら
// 非常に
// 長ったらしい
// 説明と
// 空白行
// の後に...

else if (..) {
↑ってうぉ？！繋がってんのかよ！！！

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

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

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

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

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

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

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

名前や長さというのは名前ではなく所属クラス自体に持たせる情報だな

クラスがあればだが

クラスが無い場合は名前に情報を持たせるしかないだろう

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

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

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

>8 >46
>7 や >11 辺りは比較的言語に依存しないヘタコードだと思うが。

n = 65; // n に 65 を代入する

ウボァー

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

定番の話題だけど、比較で定数を左にもってくるやつとか

if (100 == n) ・・・

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

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

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

google code searchで検索すると

==\s*0 lang:c
1,870,000

0\s*== lang:c
143,000

「定数が左」派は7%超えてるのか。
思ったより多いな。1%未満かと思ってた。

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

おれは、

button.Enabled = (count = 0)

みたいに括弧でくくってるよ。

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

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

「あとで(自分を含め)誰かが読んで何やってるかわかりにくいのがへたなコード」ってことでおｋ？

・相変わらず昔の名残で変数の宣言をメソッドの先頭でやって、後の方で使う
・同じ変数を、違う場面で(違う意味で)使いまわす

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

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

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

この仕事何年やってんだよお前ら。

>>60 きもちわるいよね

>>62
> ・相変わらず昔の名残で変数の宣言をメソッドの先頭でやって、後の方で使う 

C++やC#で、これプラスして、変数は必ず初期化するってルールでやってるもんだから、適当に0とかNULL
で全部初期化してたりするところもあるな。

コンパイラは未初期化の変数を参照したら警告出してくれるけど、それが台無しになってるっていう。

VB.NETは、初期化を省略したら勝手に初期化するって仕様だから、デフォでこの状態になってるけど。

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

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

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

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

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

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

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

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

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

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

if (cond) {
  n = 0;
}

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

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

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

if ( a )
　b = 1; //省略可能
　d = 1;
else
　d = 2;
{
　b = 2; //省略不可能
　c = 1;
}

気にしない。気にしない。

有名プロダクツのソースとか、定番の書籍とかでも、省略してるのはよくあるよ。

追加したときに、{}を付け忘れてハマるから省略すべきでないってのが理由だけど、
そんなので嵌るのって、10年プログラムやってて、一回あるかどうかだと思われ。

>>82
うん、Linux kernelソースなんかは全然ついてないね。

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

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

if ( a )
　b = 1;
これみたいに1行ならいいけど

for (i = 0; i < 100; i++)
　if (aaa (i)) {












　}
こんなのは外側のも囲わないと気持ち悪く感じる

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

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

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

(っ´▽｀)っがリーダーで、if文に{}をつけないメンバがいたら、

お前は今後の保守において、if文が2行になった時、
{}を付け忘れる奴がいないことを保証できるのか？

と問い詰めるね☆

>>85
おれは、制御されるコードが一行のときだけ{} 省略ってルールでやってる。
複数行の場合は省略したら、さすがに見難いと思った。
K&Rはガンガン省略してたけど。

>>86
まあ、10年に一度ってのは、適当だけど、linuxとかやってる人は影響ないって思ってるみたいだね。

>>83
MISRAとか、ループをbrackで抜けるの禁止とか、安全側に振ったら、いくらでも厳しくなっちゃうだろうね。

たとえば{}の位置論争とか、たいがいの人はどっちでもいいじゃんと思うだろうけど、{}の省略は、なぜか
省略しない派の人は、ぜったい自分が正しいと思ってる場合が多いって話。

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

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

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

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

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

>>91
if (・・・) {
  if (・・・)
    n = 0;
}

こういう場合は内側のifは{}省略。外側は省略しない。

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

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

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

>>95
メリットはコードが見やすくなる。

>>95
全然関係ないが、俺は未来にメッセージを送信できる装置を考案したぞ。
完成したら将来直す人と連絡するために使ってみるか？

>>97>>98
厳密うんぬんの方はぶっちゃけどうでもいいんで、脳内で繰りひろげてください。
ただただキモいです。

>>101
(っ´▽｀)っ
そりゃキモいさ☆
http://www.google.com/search?hl=ja&lr=lang_ja&ie=UTF-8&oe=UTF-8&q=%E2%97%860351148456&num=50

(っ´▽｀)っがキモいのはよくあること。配慮してくれないと☆

>>102
ごめん、おれ、あんたとはファーストエンカウントだ。
あんたのことはたぶん忘れないよ。終生キモいってことでインプットしといた。

>>100
(っ´▽｀)っ
使ってみて使ってみて☆

読みにくいコードって確かに上に書かれているような
「書き方」の問題もあるけど「書き方」だけではない何かがあるよね。
なぜそれをしているのか分からないけど意味がある部分とか
論理的には正しいけど、簡潔に書かれていないとか。
う〜ん、うまく表現できないけど。

>>104
(っ´▽｀)っ
サンクス☆

>>99
興味本位で聞いちゃうけど見やすいってのは、
行数が少なくなるから？
文字数が少なくなるから？
{}がないことで処理が１行しかないと判定できるから？

>>106
最適化の問題かもな。
コメントで補えばいいだろ。

>>99
その「どっちでもいい」に足をすくわれた人間は、はたと気づく。
「ここの {} はあってもなくてもいいんじゃないですか？」と言われればちゃんと
自分の実体験からその必要性が説明ができる。
「どっちでもいい」と思ってる奴は今後も引き続き「どっちでもいい」でいいよ。

>>108
省略派の人は、省略すべきだと主張したりして、理由を言ったりしないから、一般的な理由はしらない。
お作法系の本でも、そういう議論はみた記憶がない。

個人的には慣れの問題。

>>110
コーディングスタイルって、どれか決定的に有利なのがあれば、2chで議論するまでもなく、とっくにそれに収束してると
思うんだよ。
有力な人たちの間でも考えが分かれてるような問題は、まあ「どっちでもいい」レベルなんだと思うよ。

>>78
残念ながらそれは正しくない。なぜコンパイルエラーにならないのか？不思議なくらいだ。
正しくは、こう
if(cond)
{
　　n = 0;
}

中間とって
if(cond) // {
　　n = 0;
// }
こうしとけばいいだろ。

>>111
最後の理由でないなら安心した。
付けることで思考の妨げになってるんじゃないかと心配してたが
そうでもないようで良かった。
（まあ複数行での括弧付きが読めるんだから当たり前か）

>>112
C#だと半強制的にそうなるな。

>>111がどの程度の規模のプロジェクトに関わっていて、また、
その中でどのポジションにいるのかわからないけど、
リーダーなどリスクに大して敏感な人は、その「有力な人たち」の一部が
危険性を孕んでいると認めているコーディングスタイルに対して
それを無為無策に放ったりはしない。

「どっちでもいい」と思うんなら別にもう「どっちでもいい」でいいよ。
これ以上は平行線だから。

>>115
VSの設定で変更できるよ。

お前らの書き込み見てるとどうも正しいコードの書き方について
論じているように思えてならない。

じゃあとりあえず
n = cond ? 0 : n;

if(...){
...
}
の様に右端に｛を書かれると、括弧の対応かなり読みにくい。こんな読みにくいコード書く理由があるのか？

じゃあとりあえず
(cond&&(n=0));

>>120
俺は昔そう書いてた。理由はCの本がそうだったから。
今では違う

>>120
ifがあるってことは{もそこにあるってことだから問題ない

ローカル変数を複数の用途に使いまわす

もかなりイライラ来るなあ

メンバ変数だと直させるが

XMLのノードは3階層までのアクセスに
限定させる
<a><b><c></b></a>

>>120
これは慣れの問題

俺はこれが読みにくい

if (...)
　{
　　...
　}
...

>>124

for (int i = 0; ...)

が許される言語なら同意

ま、C な人の一部は高級アセンブリだという宗教があって
どっちみちレジスタは使いまわすじゃんみたいなｗ

ループ変数は字面的に局所化されてるように見えるからいいんだが
そうでない変数をこねくり回されると死ねる

・明らかに何らかの判断結果を返している関数名が、executeXXXXX()
　逆に、処理を行っているのに checkXXXXXX()

普通に書け

バグを直してるうちにそうなっちゃうことがあるのは良くあること。

#define HYAKU 20

>>14
キャストと{}省略、難解な演算子はCなら比較的みんなやるだろ
そうだと言ってくれ…

おれはやらんなぁ〜ウヒヒヒヒィ

>>134
やってるよ。単に>>14のスキルが低いだけだろ

・checkXXX() なんてメソッド名

何がどうなるとその結果になるのか意味わかんねーw
せめて isXYZ() とかにしてください、おながいします

統一されているかどうかだなあ
アレコレが混在していたらそれら一つ一つが「オススメ」であっても
ヘタに見える

CheckError()だと、エラー有りがtrue/falseのどちらか迷うが
IsError()だとtrueがエラー有りと考えなくても分かるってことだな。

変数名には w と v しか使わない。

int wwvwvvww;
char * wwvvwvww;
FILE * wwvwvwvw;

>>137
やべぇ、最近までのオレだ・・・
CheckErrorがふつーにあるｗ
いつもTrueかFalseなのか悩んでたんだよな
これからはちゃんとIsErrorにします・・・

呼び出し元でチェックの真偽を確認する時はisErrorと名づけて真偽値を返すようにして
checkErrorというネーミングの時は値を返さずエラーの場合に実行時例外を出すようにしてるなあ

変数名、関数名に日本語だらけ。
ウチの社長、他所からソース提供されたときに「読みにくい。日本語にしてくれ」と要求していた。

>>120

C++、JAVAなどのコーディング規約ではifの{を右に書くことになっている

ちなみにC#だと改行することになっている

>>144
プロジェクトでの規約じゃないのか？

まぁ統一されてればどっちでもおｋ

ブラケットはK&R派かGNU派かって認識だったな。
オフィシャルでコーディング規約があるなら教えて欲しい。

>>147
C/C++の世界で公式と言えばGNUのこと。
非標準はマイクロソフト。

ISOでもANSIでもいいけど規格化されたコーディング規約ってあるの？
C/C++の世界で公式といえばそういうものを指すんじゃないのか？

>>149
いいえ。
標準化委員の大多数がGNU関係者だから。

結局、そういうふうに書くやつが委員に多いと言うだけであって
オフィシャルじゃないってことか？

意味ねー。

>>144
> ちなみにC#だと改行することになっている 

VSの設定いじれば、どっちのスタイルでも使えるよ。

コメントでも、ログでも、画面に出すメッセージでも、字の間にスペース入れて目立たせるやつ。

＊ ＊ ＊ 対  象  デ  ー  タ  更  新 ＊ ＊ ＊

みたいなの。
特にログでやると検索できねーだろ。アホか。

ワロタ

・無駄な括弧をつける
　if ((a >= 0) && (b <= 0) && (c != ((10 * 3) / d) + e)) {
・文字を詰める
　if(a>=0&&b<=0&&c!=10*3/d+e){

>>152
全員でやってないと、なにかの拍子に書き換えられちゃうんだよな。
デフォルトの力の前には無力だ。

各関数にreturnは1個というコード規約に振り回され難解なコードに化けたものを見たことがある。
return1個は慣れればどうってことないけどその人は初体験だったみたい。
ソースレビューはなかったらしい。

多重ネストでforから脱出するフラグがいっぱい♪

>>157
例外使ってないってことはCかな。

>>155
それは駄目なのか？むしろ括弧はつけろと思うが
演算子はつめてもいいんじゃないか？

>>155さんじゃないけど、おれもこれ程度のif文なら無駄な括弧は省きたい。
でも、レビューしたとき「なくてもいいのは知ってるけど、つける規約になってるからつけて」って言われてつけてる。

コンパイルは -Wall なんで、「ambiguous ...」みたいなメッセージをたまに見るところをみると
おれもまだまだダメちんのようです。

C系だと括弧は気にせず付けて、VB系だと括弧はなるべく付けないようにしてる。

無駄な括弧大好きで、if文は一行でも括弧付ける派の俺が言うのもなんですが
Javaでは
int a[];
よりも
int[] a;
として欲しい

・普通のコード
struct Item {
  int id;
  int size;
  string name;
}
Item items[NUM];

・基本
int id[NUM];
int size[NUM];
string name[NUM];

・上級者
struct Item {
  int id[NUM];
  int size[NUM];
  string name[NUM];
}
Item item

>>163
基本って何の基本だ？
AoSよりSoAの方がいいという話は聞いたことがあるが、未だにメリットがわからない・・・

x >= 0 ? x += 100 : x -= 100;

はどうかな? 「素直にif文使えよ」と言っといたんだけど。

x += (x >= 0) ? +100 : -100;

ならなんとか許容範囲。

>>164
パディングの分だけ無駄領域が出にくいとか。
つーか、AoSとかSoAってのも初めて聞いた。

>>164
>>1 に載ってる基本レベルかなと思って。

>>165
> x >= 0 ? x += 100 : x -= 100;
gcc-4.1.2だとコンパイルできん。

名前空間が分かれてるのにわざわざプレフィックスを付ける
struct Hoge {
  int hoge_xxx;
  int hoge_yyy;
  int hoge_zzz;
};

struct tmとかCの標準ライブラリでもやってるけど。

>>165
私は頭が悪いので少しでも考えないといけないソースは苦手です。

すべての行の右側にコメントが入っている。
FORTRANとかアセンブラの話じゃなくて、C++の話。

・なんでもかんでも>>163の上級者に従うコード

プログラムの律速はキャッシュミスにあるので、使用するアルゴリズム、処理によって
データ構造を適切に選ぶ必要がある。
また、組み込み系などメモリがシビアな時は、速度を犠牲にして空間効率を高めたりするので、
開発環境によっても自然、アルゴリズムとデータ構造は適切に選択しなければならない。

>>171
富士通だか日立だか忘れたけど、もと有名企業の社員で技術力には自信がありますとかHPでアピールしてる
フリーの人から仕事をもらったら、そういうコード書いてたよ。
こういうところがアマチュアと違うんだとか、本人は得意げだったけど。

>>173
書けばいいってもんじゃないんだがなあw
しかも書いてあるコメント見ると、>>7みたいなのがほとんどだった。

>>168
調べてみたが、C++ならおkだが、Cだとだめらしい。初めて知ったよw
つーか、>>170の言う通りだよなあ…

x += (x >= 0) * 200 - 100;
こういう書き方が玄人の証と考えていた時期が俺にもありました。

だいたいコードレビューでダメだしされます

x += ((x >> 31) & -200) + 100;

>>178
"Hacker's Delight"レベルなら許すんだがなあw

プロジェクトで指定されてもいないのに、
妙に大仰なファイルヘッダ書くのは素人くさいなあと思う。
ずれまくりだとは思うがこんな感じ。

//----------------------------------------------------------------------------//
//　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　//
//　　Sub System Name : Xxxxxx Module　　　　　　　　　　　　　　　　　　　　 //
//　　File Name　　　 : Xxx_Main.h　　　　　　　　　　　　　　　　　　　　　　//
//　　Engineer　　　　: xxxxxxxx xxx　　　　　　　　　　　　　　　　　　　　　//
//　　Created Date　　: yy.mm.dd　　　　　　　　　　　　　　　　　　　　　　　//
//　　Last Edit　　　 : yy.mm.dd　　　　　　　　　　　　　　　　　　　　　　　//
//　　Revision　　　　: nnn　　　　　　　　　　　　　　　　　　　　　　　　　 //
//　　Description　　 : Xxxxxx Module Local Define　　　　　　　　　　　　　　//
//　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　//
//　　Copyright (C) by xxxxxxxxxx Co.,Ltd. All rights reserved.　　　　　　　 //
//　　Author xxxxxxxxxx Co.,Ltd.　　　　　　　　　　　　　　　　　　　　　　　//
//　　機密文書:永久　　xxxxxxxxx Confidential　　(Critical:Eternity)　　　　　//
//　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　//
//----------------------------------------------------------------------------//

日付やリビジョンを人手で入力してたり、
日本語でおkなのにもかかわらず微妙な「英語」で書きたがるのもお約束かなあ。

今見たら、フッタにまでこんなのが書いてあった。

//----------------------------------------------------------------------------//
// 機密文書:永久 xxxxxxxxxx Confidential (Critical:Eternity) //
// この文書、図面、Source Code、及び、含有する全情報の所有権,著作権は //
// xxxxxxxxxxxxxx株式会社に属する。事前にxxxxxxxxxxxxxx株式会社の文書による //
// 許可無くして、xxxxxxxxxxxxxx株式会社の物品の製造以外の目的に、この図面、 //
// Source Codeを複写、複製及び使用してはならない。 //
// Copyright(c); xxxxxxxxxx Co.,Ltd. All rights reserved. //
// Use,duplication or disclosure restricted by the law & xxxxxxxxxx Co.,Ltd. //
//----------------------------------------------------------------------------//
// ****************************** [ XX_Common.h : EOF ] ******************************

別に法務部から何か言われたとか、上司から指示があったとか、
コーディング規約で決まってるとか一切なくて、本人の独断で入れたみたい。
こんなの書かなくても機密保持契約は有効だし、
会社の著作物であることは当然なんだけど、もしかしてわかってないのかなあ…

>>181
あれこれ理由はなくて、書いた本人が単にそういう様式で書きたかっただけだろ？
「ぷれぜんてっど　ばい　おれ」みたいな感じで

日本語の文中に、カタカナで書くのが普通な外来語を
英語表記で書くのってなんか馬鹿っぽいよね。＜Source Code
自意識過剰な人なのかもな。

ヘッダだけなら実害もないんだけど、そういうズレた自己アピールを成果物に盛り込みたがる奴は、
コードそのものでも>>176とか>>178みたいに「個性」を表現したがる。

そういう奴はコードレビューでいじめてやるのだが。

>>176はともかく、>>178はｲｲﾝｼﾞｬﾈ？速いんだし。
もちろんコメントつけてわかりやすくしといた方がいいけど。

全くもって速度がどうでもいい場所で
そういうコードばっかり考えて時間無駄にしてるならともかく、
コンパイラが最適化してくれない部分を
そういうテクで補うクセが付いてる人って、俺は羨ましいけどなぁ。
自分はなかなか思いつかんし。

>>178みたいなテクを考える人が減ってくのはちょっと寂しい。

>>184
もしかして逆アセンブルとかしてデバッグできない人？
すべてのケースで、またすべてのコンパイラで成り立つか分からないが、
多くの場合3項演算子使った最適化に有利。
そんなこと知らないとしたら、>>184みたいな人間にレビュー付き合わされる人間て可哀想。

>>185
真偽値を1,0と決め付けている点で五十歩百歩。技巧以前の問題なのだ。

あ、すんません。
>>185さんが言うように、すべてのケースにおいて3項演算子使えなんてことは毛頭言うつもりはないです。

>>178もどうかしかし
符号付きなら論理シフトになるか算術シフトになるか決まってないし
32ビットと決め打ちだし、そもそも普通のif文のほうが早い可能性もあるし

>>187
う？178のどこに真偽値が？
まぁどっちにしても環境を限定した書き方だから
処理系をまたぐであろうプコードでそんなの書けないだろうけど。

×プコード
○コード
orz

おまいら、アクロバティックな記述もいいが、オブジェクトの解放をしてない、なんてのもポイント高いですよ。
「システムを運用しているうちにサーバの応答が遅くなり、しまいには無応答になる。サーバを再起動すれば治るが、
数日でまた応答しなくなる」というクライアントの訴えを受けてサーバを調べた俺が見たものは……
メモリを埋めつくす数十プリニウスものexcel.exeだった。

三項演算子が「禁止」なのは、許可すると技巧に走るバカがいるから
三項演算子自体の可読性も性能も別段悪くないんだが…

>>185
>速いんだし。
x>>31 が abs(x) より速いという確証があるのか？
>全くもって速度がどうでもいい場所で
速度が問題になる箇所ならインラインアセンブラ使えって話だ。

>>187
>決め付けている点で
関係演算子の結果は、そう決まっている。
>>189
>論理シフトになるか算術シフトになるか決まってないし
こっちは処理系定義なんで、移植する気がないなら問題にはならない。
まあ個人的には、どっちもｷﾓいな。

abs(x)使うとどう書けるの？

abs(x)関係ない。すまん、読み違えてた。
元の>>178のコードだとふつーにifか三項演算子だ。

185だけど、論理式＋乗算(>>176)よりはシフト＋ビットごとのAND（>>178）
の方がさすがに速いだろうと思ったんだけど。違うの？
高速化に関しては初心者だけどさ。

＞速度が問題になる箇所ならインラインアセンブラ使え
そらそうだろうけど、ゲームなんかだと毎秒30〜60回実行されるコードが
何万行とあるじゃん。チリも積もればなんとかで、手軽に条件分岐を減らせるなら
減らした方がいいと思うけど。俺の場合は上にコメント書く。

abs(x)使うやり方は気になるｗ　まさか((x - abs(x)) & -200)とか？

ぶｗ　すれ違いだし最後の式おかしいし・・・
なんかいけそうな気もするけど無理か。スレ汚しｽﾏｿ

もっと時間食ってるコードが絶対あるから、
簡単な計算は可読性重視、速度無視

名前空間が分かれてるのにくべつ用のプレフィックスとか付ける
struct Hoge {
  int hoge_xxx;
  int hoge_yyy;
  int hoge_zzz;
};

struct tmとかCの標準ライブラリでもあるけど。

配列とかで大量に使うならともかく、ローカルのワークに使う変数とか、引数なんかでshortを使ってるやつ。

>>200
これは俺もよく見る。そのたび同じことを思う。

なんで>>169と同じ事を書いてんの
スルーされたから？

コピペによる予想外の冗長さを身をもって表現してくれたんだよ。

(っ´▽｀)っ
処理時間をどうこう言ってる人がいるが、
保守性、可読性を優先させたほうがいいでしょう。
処理時間をどうこう言うなら、目標時間を定めてから。
1秒を0.95秒にしたところでユーザに喜ばれるだろうか？
こう言うと、
ちりも積もれば山となる、処理時間だって言える
ソースコード全てにおいて、スピードを考慮すべき
と答える人がいるが、
実は、ソースコードの5％が処理時間の95％を占めるという研究結果がある。
つまり、闇雲にスピードを追求してもあまり意味が無いってことだ。
むしろ、スピードを追求した結果、
保守性が低くなるどころがバグ満載では、本末転倒である。

(っ´▽｀)っ
処理時間と保守性、可読性についてもっと知りたい、考えたい人には、
コードコンプリート下巻をお勧めしよう。

(っ´▽｀)っ
コードコンプリートは上巻を読まないと下巻は理解しづらいかもしれないね☆
上下巻併せて12,810円です。
上下巻ともに、広尾の都立中央図書館の1階開架に置いてあるようです☆

(っ´▽｀)っ
っていうか、名著中の名著だから、ここの人たちはみんな読んだことがあるんだろうね☆
(っ´ω`)っ 出しゃばってごめんね、いきててごめんね、

＞実は、ソースコードの5％が処理時間の95％を占めるという研究結果がある。

観念的な空論をとなえるのをやめてちゃんとプロファイルをとれば、
こんな流言に左右されずに適切な最適化を実施すること（あるいは実施しないこと）ができる。
ところで漏れが組んだシステムで↑みたいな極端な例は殆ど無かったなぁ。
実はかなり特殊な領域を対象にした研究なんじゃないだろうか。

リファクタリングの本だとたしか10%と90%って数字だったな。
まあなんにせよ速度の最適化にはまず測定からだ。

>>208
ちょっと前の俺に反論。
高速化したい対象だけ注視しないで、UIやらなんやらを含む全コードを見れば
やっぱり極々一部が大半のCPUパワーを使っているような気がするぞ。

//Author ああああ

毎度、毎度ファイル先頭に1行
ってなんだよやめてくれよｗ

(っ´▽｀)っ
こういう感じだね☆

処理時間の目標の設定(Plan)
↓
測定(See)
↓↑
処置(Do)

>>184
これ書いた人、ローカル変数の頭に全部"the"つけてるんだよね。こんな感じ:

#define UC unsigned char
#define CLEAR 0
static void Xxx_YyyClear( UC inXxxYyyName )
{
　　UC theXxxLocalYyyNameNo = CLEAR;

　　theXxxLocalYyyNameNo = inXxxYyyName;
　　xxxGlobalInfo[ theXxxLocalYyyNameNo ] = clearXxxYyyyInfo;
}

強烈でしょw 固有名詞は伏せたけど、実在のコード。
補完機能付きのエディタ使ってないのに、
使い捨てのローカル変数にこんな長い名前つけてて、なんともご苦労様なことで…

あ、関数名が(動詞+目的語ではなく)目的語+動詞になるのもへたくそっぽくない?

(っ´▽｀)っ
で、コードコンプリートってどうなの？名著なん？

一番気になったのはこれだ
#define UC unsigned char

>>203
ネタ帳から貼ったの忘れてたよ。

>>215
名前もあれだけど、なんでtypedefにしないんだ。

>>213
>補完機能付きのエディタ使ってないのに、
こういう人たちは補完を使わない=出来る人間だと思ってる節がある。
全員分IDE買ってんのに「自分はEditor派なんで」。

・・・しかも当然遅い。

>>215
実際にはそれはプロジェクトのヘッダファイルに入ってるんで、
それはまた別の困ったちゃん。ちなみに>>171w

まあ、typedef知らないんだろうと思うよ。
そういえばconstやstaticも使ってなかったな。

>214
絶対読まなきゃ、というほどではないにしろ、読んでおくほうが望ましい。
ちゃんとわかってて読めばいい本ですよ。

なんか急にレベルが下がったな
女の陰口のようだ

とあるヘッダファイルから。

　　#ifdef　　GLOBAL_VALUE_DEFINE_XXX_COMM
　　　　//　グローバルを作る
　　　　#define　 GLOBAL_XXX　　　　　　　　//　GLOBAL→空白に変換
　　　　#define　 GLOBAL_XXX_VAL(v) =(v)　　//　GLOBAL_VAL(数値)→(数値)を設定する
　　#else
　　　　//　グローバルを使う
　　　　#define　 GLOBAL_XXX extern　　　　 //　GLOBAL→externに変換
　　　　#define　 GLOBAL_XXX_VAL(v)　　　　 //　GLOBAL_VAL→削除する
　　#endif

GLOBAL_XXX SomeStructAaa　　　varAaa;
GLOBAL_XXX SomeStructBbb　　　varBbb;
GLOBAL_XXX SomeStructCcc　　　varCcc;
...

ある意味懐かしい感じがする。

なぜかcaseラベルのある行だけ複数の文を書く人がいる。

switch(xxx) {
case XXX: var1 = ...; var2 = ...; break;
case YYY: var1 = ...; var2 = ...; break;
case ZZZ: var1 = ...; var2 = ...; break;
}

>>222
何でもかんでもって感じで多用されてたらうざいけど、使うこと自体は別にいいかなって思う。
それよりもプリプロセッサのネストが気になるｗ

多次元配列の定義で、最初のデータを書き終わるまで改行してくれない。

struct Xyz fooBarBaz[DIM_XXX][DIM_YYY][DIM_ZZZ] = {{{{1,2,3},
　　　　　　　　　　　　　　　　　　　　　　　　　　　// 中略
　　　　　　　　　　　　　　　　　　　　　　　　　　 {7,8,9}},
　　　　　　　　　　　　　　　　　　　　　　　　　　　// 数十行くらい続く

構造体の(ポインタでない)メンバにconstとかvolatileがついてる。

struct Xyz {
　　　　volatile int xxx;
　　　　volatile int yyy;
　　　　volatile int zzz;
};

つーか、文法的にはおkなのかなあ?

う、POD型な構造体に限定したほうがいいかな。
それにしたってvolatileはないけど。

>>223
縦に揃ってたら見やすいじゃん。
一貫性があれば異質な物にも気付きやすいし。

>>226
const int * p;なら意味あるよん。
規格呼んだわけじゃないけどそれ以外は関数のexternと同じように無視される気がする。

>>229
うん、だからポインタでないメンバと限定したわけだ。
(PODな)構造体のメンバがint * const memberとか宣言されてたらおかしいでしょ。

>>223
case hoge: の後が一文（特に代入だけ）の場合、
俺も改行しないで列挙するなぁ。複数の文はさすがにアレだけど。

縦に揃うときれいだからといって、同じ条件の三項演算子をズラズラ並べるのはカンベンして欲しい。

おまえら正しくは条件演算子ですよ
三項演算子の一種であるので
C言語の場合ほぼイコールだけど

>>230
>(PODな)構造体のメンバがint * const memberとか宣言されてたらおかしいでしょ。
別におかしくない。
初期化で値を設定して、その後変更するつもりがないメンバだろ？

>>226
そのコードに必要だったかどうかは実物見ないとわからないけど、
一般論で言えば意味あるに決まってんじゃん・・・

割り込みで変更される可能性のあるメンバとか、
メモリマップトIOのアドレス範囲を構造体で定義するとか、
マルチスレッドで他スレッドからもアクセスされるフラグ的なものとか、
そんなときに使う。稀といえばまれか・・・
案外モノ知らない人多いんだな〜。

>>230
そのメンバには書き込んで欲しくないというときには、どう宣言せよと？

>>235
226が遭遇した事例では、メンバに付けるよりも
構造体の変数を宣言するときにvolatile付けるほうが適切だったんだと思う。

相手がvolatileを知らない前提で語ってるのがﾜﾗﾀ

volatile習いたてですか？

>>226はどうみても volatile を知らないわけだが・・・
＞つーか、文法的にはおkなのかなあ?
こんなこと書いてるし。

いや、「見かけたことはある」という程度には知ってるのか。

Google code search で、struct volatile を検索すれば
カーネル内のコードやら aKode やら山ほど出てくるね。

なぜポインタにしか使わないとかそういう誤解があるんだろう。

>>236
それだと今度は宣言する人が付け忘れちゃう可能性がなくない？

>>235,237,238,239
ISO/IEC 9899:1999 6.7.3.3
The properties associated with qualified types are meaningful only for
expressions that are lvalues.
ISO/IEC 14882:1998 3.9.3.2
A compound type is not cv-qualified by the cv-qualifiers (is any) of
the types from which it is compounded.

つまり、メンバにいくらconst/volatileを指定しても、
構造体全体としては指定されてないのと同じということだ。

仮にメンバごとにアクセスする時だけconst/volatileの効果があるのだとしても、
構造体まるごとで操作した時にその効果がなくなるなら、全然意味ないじゃんって話。
で、全メンバに同じCV修飾子をつけるなら、構造体自体を修飾したほうが素直だろってこと。

もっとも、const/volatileは文法的には型に対する修飾子なので、
メンバの宣言に使っても文法上は間違いではない。
記憶クラス指定子のように、オブジェクトに対する指定を行なうものだと
考えるのがわかりやすいかな。

>>230,234
C++のクラスならおかしくない。が、そういうconstメンバはコンストラクタでしか
設定できないから、CやC++のPOD型で指定するのはおかしいって話。

はじめてここにきたが
おれほとんどあてはまってる
みんなごめん

>>241
メンバ変数にアクセスするときに効果があるんだったらそれでいいんじゃないか？

だからstructまとめてコピーとかしたときにまずいって話でしょ

コピーも結局、暗黙でメンバ変数にアクセスしてるんじゃないか？

byte A = 0;
abs(A++);

行ったり来たり...

>>108
行数が少なくなる事で各メソッドの全体像を一瞥しやすくなる。
文字数はあまり関係ない。新規行および不具合のある行についてのみ横方向に解析するので。
{}がないことで処理が１行しかないと判定できる。これもデバッガ使用、机上デバッグ、リファクタリング等の際に有効に機能する。

システム保守等で取り扱うコード量が増える程この手の基本的な書き方が重要になってくる。

>>246
これは何？
意味分からない

int a = 0; for (;;) a = abs(--a);

>>247
＞{}がないことで処理が１行しかないと判定できる。
{}が無いのにうっかり処理を2行書いてしまった部分を見逃す危険性は無い？

for ();
このセミコロンは下に打っておかないと
１行追加するとき見逃す可能性があると思う
for ()
　;
こんな風に

>>250
処理をうっかり２行書いてしまった部分は変更を加えたのだからテスト対象になる。
また見逃してしまうようではシステム保守を担当できるスキルまで達していない事になる。
そもそも局所的にしかコードを把握していないようではシステム保守を任せることができない。

>また見逃してしまうようではシステム保守を担当できるスキルまで達していない事になる。

おまえはわかってないな
そういう奴が触る可能性を考慮して書くんだよ

一生そのプログラムの保守をする気があるとか、趣味でやってるとか、書き捨てなら話しは別だけど

>>253
わかってないのはおまえだよ。
そういう奴を育てる事も考慮して書くんだよｗ
ゆとりをもって取り組もうな。

その発想はなかった
保守担当が自分の部下ならそうするけど・・・
板違いになりそうだからやめとくか

>>252
(っ´▽｀)っ
プロジェクトにはスキルの高い人もいれば低い人もいる。
今はスキルの高い人がいるとしても、将来はどうだかわからない。
プロジェクトにスキルの高い人がいるとしても、その人が保守を担当するとも限らない。
要員の都合でスキルの低い人に任せざるを得ない場合もある。
つまり、将来の保守は、どのようなスキルを持った人が担当するかわからない。
貴方が未来永劫保守が正しくなされるのを監視するのであれば問題ないが、
貴方はいつかは退職するでしょう？
貴方がいなくなったとき、保守はどうなるのかな？

>>254
(っ´▽｀)っ
もし、その育てられた人が退職したらどうするの？

>>256 >>257
まず処理をうっかり２行書いてしまった人とテスト対象を見逃してしまった人は違う人物となり得る。
つまりコードを変更する事とその変更を検証する事は別の事柄だ。
コードを変更する人は>>247等を考慮して作業にあたれば良い。
変更を検証する人はテストケース等でテスト漏れを防止すれば良い。

それでもミス等は発生し得るのだから検証する枠組みを強化すれば良い事になる。
仮に個人のスキルに委ねた検証の仕組みしか提供できないのであればそれはその企業体自体の問題である。

>>249
a=a^1;

>>258
> それでもミス等は発生し得るのだから検証する枠組みを強化すれば良い事になる。

検証だけちゃんとやればいいという素人くさい意見有難う。(w

俺は、検証もがんばるし、そもそもミスを発生しにくいようにしたいから {} は
省略しない。

>>258
> それでもミス等は発生し得るのだから検証する枠組みを強化すれば良い事になる。

失礼なことお尋ねするようですけど、ちゃんとどこぞの会社で働いてらっしゃるんですよね？
ミスは発生しうるという考えが先行してるように見受けられますが、
なぜ、「ミスを起こさせないためにはどうするか」という発想に至らないのか不思議でなりません。

他の人も触る可能性があるなら {} つけといたほうがいいと思う

付ける付けないはそこまで重要じゃないだろ。
プロジェクトで統一されていることこそ重要。
{}付けるなら絶対にすべてに付ける。
{}付けないなら絶対にすべてに付けない。

>>263
重要とかそういうことじゃなく、それは決まりごとっていうんだ。
朝から強烈な電波、お疲れさまです。

>>263
すべてにつけないは無理だろう。
俺はすべっつけるけど。空文もな。空文の括弧には、意図した空文か判るようにコメント入れような。

決まり事は重要だぞ。
似たような処理が統一されたスタイルで書かれていれば
何も考えずに理解できるし、違う書き方で書かれた場所があれば
そこが特別だということが分かる。

決まりごとは守らなければならない、これあたりまえ。
おれは上で議論してるのは、なぜそれを決まりごとと決めなければならないのか、
そっちを議論してるんだと思ってたんだが？

うちだと1行に収まる場合以外はブロック化だな。

亀だけど。
>>173
大手ドロップアウト組はそんなもん。
WebSite見るとその頓珍漢なコードを掲載している傍ら、野菜作ってたり実家の手伝いしていたり。
まともな仕事を受注できなくても危機感もなければ研鑽する気もないから酷いコードのままの罠。

hoge(int aaa){

if(hogehoge(aaa)==-1) return -1

return 0;
}

見たいな感じでエラー処理したりしちゃう癖があるんだが
これは醜いのか？

>>269
(っ´▽｀)っ
C言語？それならエラー時にリソース解放するの忘れないでね☆

「関数の出口はひとつにしろ」とか言う人もいるんだよなぁ

インデント深くなるし、わかりにくくなるから、エラー時はさっさとリターンしたいんだけど・・

おれはエラー時はさっさとgotoしちゃいます。

void someFunc()
{
if (error) goto Return;
...;
...;
Return:
;
}

goto文は多重ループを抜けるときにだけ使えって教えられたから

(っ´▽｀)っ
そこでtry〜catch〜finally〜ですよ

それはC++前提ね

>>275
Cならどうしてる？

>>277
(っ´▽｀)っ
(っ´▽｀)っも>>273に似たようなもんだが

void someFunc()
{
　/* 主処理 */
　if (error) goto Catch;
　/* 主処理 */
　goto Finally;
Catch:
　/* エラー処理 */
Finally:
　/* 終了処理 */
　return:
}

(っ´▽｀)っ
>>278だと、正常の場合でもエラーの場合でも
終了処理が確実に実行されるよね。

Catch、Finallyなんて変なラベルは使わない（見たこともない）けど、同じだね。

>>280
|▽｀)っ
あえてラベル名は変えてある
(っ´▽｀)っの正体がばれるから☆

|彡☆ ｻｯ

(っ´▽｀)っ
>>278の手法って結構メジャーなのかな？
書籍とかであまり見ないから。
(っ´▽｀)っが誰だか特定されちゃうと困るんだけどね。

そんなもったいつけてどうすんのｗｗｗ
どうせ、そんじょそこらのおっさんでしょ？ﾌﾟｹﾞﾗｯﾁｮ

コテうぜえ

>>283
(っ｀Д´)っ お・ね・え・さ・ん！！！
(っ´▽｀)っは永遠の16歳だよ。美少女だよ☆

お局さんに内部変換した。
貰い手がいないんなら、おれがもらってやるよｗｗｗ

でこの書き方はどうなんだ？

＞永遠の16歳
なんだ、永遠に女未満なのか。

ま、いいんじゃね？一般的かどうかということになると、goto使わない派がそれなりに多い現状からすると
マイナー(ただしマイナーの中のメジャー)だと思うけど。
1行だけのブロックを{}で括らない職業プログラマは逝ってよし。

>>289
考え方の問題だろうけど俺は使わん

手元にソースのあるプロダクツをざっとみて確認してみた。
if で一行でも{}でくくってるか。

linux くくらない
postgresql くくらない
apache くくらない
vim くくらない
mozilla くくらない
sqlite 基本くくるみたいだけど、くくってないところもある
mysql くくらない

>>289
>マイナーの中のメジャー
(っ´▽｀)っは側近中の側近だよ☆

>>291
オープンソースな人とと職業プログラマでポリシーが違うのは当たり前だから、
あまり参考にならない意見有難う。

>>293
「と」 が余分だった... orz

確かに開発ペース＆品質なんかはオープンソース系の方が上だよな。

って事考えると職業プログラマってグダグダ議論するワリにアレだよな・・・。

オープンソースの場合は納期もないし責任もないのでそれはまた違った形になってくるのだろう

VC++ のランタイムのソースと、SunのJDKのクラスライブラリのソースはくくる派だな。

意外なことに eclipse はくくらない派だった。
Javaはくくる文化かと思ってたよ。

ちなみに以下のコードはある環境下でバグになるって事を認知してる？
    if (a > 0) {
#define _DEBUG
printf("a = %d\n", a);
#endif
    }

>>296
責任ないって言っても、バグっていいとか、保守性がわるくなってもいいとか思って、くくらないスタイルを
採用してるわけじゃないだろ。

>>298
そりゃそんなとこでdefineしたらおかしくなるだろ

>>296
納期があるから{}を必ずつけるのか。
俺には理解できない話だが、参考になったよw

>>298
ていうか_DEBUGって何? NDEBUGではなくて?
そんな環境依存の話されてもわかんない。

>>293
以前はクローズドで、後にオープンソースになったSolarisも、くくらない派だったよ。

#ifdefだろ常考

>>296
現実的な責任云々いいだすとオープンソースの方が責任重いと思うが、
web鯖にたとえるなら喪前はapache以上の普及率を誇る製品作ってるのか？

？

きっと296はWindowsOSの開発をしていてMSの社内ポリシーは{}を必ずつける、ってんだろ？w

オープンソースと責任を議論する人って一体？

>>288
(っ´▽｀)っ
16歳の女の子といえば女子高生！
食べ頃じゃないのか？

ああごめん。#ifdefの書き間違い。
    if (a > 0) {
#ifdef _DEBUG
printf("a = %d\n", a);
#endif
    }
    b = 1;
    c = 2;
これをリリースモードでビルドするとa > 0の場合にのみb = 1が動作する環境に遭遇したことがある。
使用していたコンパイラが空ブロックにNOPを生成しないタイプだったのが不具合の原因だった。

書籍だと、

詳解UNIXプログラミング、UNIXネットワークプログラミング くくらない
EffectiveC++ くくらない
Effective Java くくらない
プログラミング言語 C++ くくらない
プログラミング作法 くくらない

CODE COMPLETE くくる (書籍中では、この件に関しては議論はしてない)
デザインパターン(GoF) くくる

規格に準拠してないコンパイラなんてどうでもいいよ。

俺は不要な{}はつけない派だが、
そんな処理系固有のバグを得意そうに指摘しても意味がないと思うぞ。

紙媒体を引き合いに出されても困るんですけど。
よく「紙面の都合上…」ってをみるでしょ？

でもそういうバッドノウハウとして「{}をつけるべき」とか言ってる奴はいるかもな。
もはや常識であるdo{...}while(0)を知らずに

#define FOO(x) func1(x); func2(x)

みたいにして、痛い目にあったとか。

> これをリリースモードでビルドするとa > 0の場合にのみb = 1が動作する環境に
> 遭遇したことがある。

今時のコンパイラならリリースビルドだと普通 if() 分もろとも省略すると思うが。
どんだけしょぼいコンパイラなんだ？

# つーか、コンパイラのバグ回避はまた別の話だろ。

>>310
その情報って{}を付けるか付けないかと全く関係ないよね。
何が言いたいの？

>>316>>317
もう触れないであげて。彼はいま自分の若さを再確認してるところだから。

>>314
とりあえず第三者が検証可能だから。
上のほうの「自分の経験では」とかだとアレだけど。

まあ、チョイスも偏ってるしあくまで参考までに。

おっと、do{...}while(0)だって立派なバッドノウハウだな < 自己ツッコミ

だが、へぼいマクロのために必ず{}で囲うべきだと強弁するなら、
そっちのほうがよほどワースノウハウというものだ。

>>317
if (a > 0) {
}
b = 1;
c = 2;
をコンパイルすると
if (a > 0)
    b = 1;
c = 2;
と同じ挙動になったという話なだけ。
あくまで「ちなみに」レベルの話。

なんでそんな関係のない話を得意げに語るの？

>>309
体だけでしょ。心も知性も女未満。

Cは「プログラマは無謬」という前提で設計された事を
認めない（／知らない）人が多いところだね。

冗長な記述をいくら推奨しても「歪む」とは思わないの？

>>324
dmrはそんなこと言ってなかったよ。

〜〜ことを認知してる？
なんて偉そうに書いてるから俺も気になったじゃまいか。
ifステートメントは直後の１文（セミコロンが１つ見つかるまで）、
もしくは直後の１ブロック？（｛｝で囲まれた部分）までであるというのは
多分CでもC++でも標準規格ではっきり決まってることだと思うんだが、
その程度の仕様も守れないクソなコンパイラのアホなバグを
なぜ知ってなきゃならんのだｗ
技術者が信頼できない道具なぞ使うなと思うし、
使わなきゃならないならその環境が諸悪の根源なだけだろう。

本来であれば>>315のマクロ記述の方が不具合なのにそれを隠蔽してしまう「必ず{}で囲うべき」という思想がヘタの証。
>>321も最初から{}を省略する書き方であれば遭遇しない不具合だし。

プロトタイプ宣言を書くのはいいんだが、
仮引数を型だけ書く中途半端に古いスタイル。

int foo(int, int);

わざわざ仮引数名だけを消してて、ご苦労様と言いたくなる。
Quick-CとかMS-Cあたりの時代から進化していないらしい。

>>324
設計者の意図がどうあれ、そんなことを理解 { しない | できない }
奴等に仕事させないといけないので、{} は必須。

そう言うお仕事もあるってだけのことだ。

>>326
アホに構うな。

そこにしか突っ込めないなら、止めやしないが。

＞仮引数を型だけ書く中途半端に古いスタイル。
はぁ? 古いってどういう意味? プロトタイプ宣言は昔からパラメータ名を書いても書かなくてもいいんですが。
ついでに言えば、C++の場合は実体定義のときも省略できますね。

プロトタイプの引数に変数名入れるのは素人っぽいからﾔﾀﾞ

>>330
うんうん、そうだよね。文法的には正しいよね。
わざわざ情報量落してるあたりが馬鹿っぽいということとは無関係だもんね。

>>331
と考えてしまうところがヘタレな証拠

>>330は返り値がintの関数を定義するとき型名を書かないらしい。

それはc++とc99ではできなくなったはず

Cはプロトタイプと本体の定義で、名前が違っていてもエラーにならんからね。
書く人にやめろとは言わないけど、俺も書かない。

void func(int x, int y);

void func(int y, int x)
{
・・・
}

どっちかに統一してあればどっちでもええやん
#返り値がintの関数云々はともかく

引数名は省略できても書いた方がいい。

>>336
それは仮引数名の命名がおかしいだけであって、
仮引数名をつけない理由にはならないんだが。

>>339
引数に名前があっても、信用できるわけじゃないしって話。

コメントだって信用できないから、書かない方がいいって言う人？

# 書いてない方がマシなコメントもあるけどさ。

全ての文にコメントをつけろって会社で働いたことがあったが、あれは地獄だったな。

>>342
俺にも覚えがあるな。こんなコメントが蔓延してなかったか？

// ほにゃらら履歴を走査する�@
// ほにゃらら履歴を走査する�A

ちなみに、そのプロジェクトにはコメントの体言止め禁止という不可解な規約もあった。

コメント等の説明文に関しては「…される」じゃなく「…する」と表現しなければいけない等のルールにも出くわした事もあるな
上のを例にすると「// ほにゃらら履歴を…に走査させる」はNGとか

コメントは日本語と英語を併記するって所もあったな。
めんどくさいからコメントはなるべく書かないようにしてた。

>>329
お気の毒です（笑）。いや、それでも。
それは「仕事でやる場合、そういう{指導|規約}が必要になる」
という事実を表明なさっているだけに思えますが。
#スレ違いと考えたら駄目ですかね

>>335
化石プログラマにはC++やC99なんて存在しないのも同然。

>>331
変数名（笑）
素人臭さを演出して皮肉っているんですね。わかります。

> 仕事でやる場合、そういう{指導|規約}が必要になる
> という事実を表明なさっているだけに思えますが。

まさにそうだが？

>>346 で何を言いたいのかよくわからん。

スレチだと考えるならそう考えておけばいいと思うけど、できたら
今後この手の話題にレスする時は「仕事以外では」と明記してもら
えると心置きなくスルーできるので助かるんだが。

まぁこの手のくだらん制限がかかるのは大体仕事絡み

>> 仕事でやる場合、そういう{指導|規約}が必要になる
>> という事実を表明なさっているだけに思えますが。
>まさにそうだが？

正直、極一部のヴァカの為にﾍﾝﾃｺなルールを導入する組織もどーかと思うが。

ごく一部というか毎年一定の割合で入ってきたり、派遣されてきたり

解っていた事ではあるがオープンソースが責任やら納期やらの話で{}を省略しているのではなくて、
仕事でやっている連中はレベルが低すぎるから糞ルールを導入せざる得ない。
とハッキリ言えばいいのになぁ。

なんかヘンテコなプライドがあるんだかないんだが。

>>350
> 正直、極一部のヴァカの為にﾍﾝﾃｺなルールを導入する組織もどーかと思うが。

じゃあもっといい方法があるのか？

---
> 仕事でやっている連中はレベルが低すぎるから糞ルールを導入せざる得ない。
> とハッキリ言えばいいのになぁ。

>>256, >>329 に書いてあるのに理解できてない >>352 に言われても...。

スレの主旨や話題にケチつける気はないんだが（これは>>348に対する皮肉でもあるがｗ）
どーも感心するほどの話が出てこないなぁとｵﾓﾀ。
自分は現役離れてフリーターやりながら作品作ってる身分なので偉そうなことは言えないが、
「会社の超下手糞なスタッフが読んでもわかるように」、みたいな今の日本特有？の
IT土方的環境を前提にしたら話がおかしくならんか？

ヘタなコードか上手いコードか、ってのは
仕事、趣味、オープンソース、個人グループ、などに関わらず議論できることであって、
何でもすぐ自分の立場だけで考えようとするのはアホだしプログラマとしても才能無いぞ。
クソルール作ってる連中と大して変わらんしな。

逆にオープンソースのように、ちゃんとみんなでソースをチェックしてやれば
そんな些細なミスなんて問題じゃなくなるってことじゃねえか？
ソースレビューすればすぐ見つかるようなことだろ。

> 何でもすぐ自分の立場だけで考えようとするのはアホだしプログラマとしても才能無いぞ。

自己紹介乙。(w

>>348 にも書いたが、できたら今後コテ付けてくれ、スルーするから。

何か勘違いしてるようだが346は俺じゃないよ。

>>355
まあ、それはそうだが、無駄な手間が増えるってことだからな

>>357
それはすまんかったが、どちらにせよ「仕事以外の話」と言うならわかるように
書いてくれと言うだけのこと。

> 仕事、趣味、オープンソース、個人グループ、などに関わらず議論できること
> であって、

とてもそんな議論ができるとは思えないから。

# 少なくとも「趣味」が入ったら何でもアリだろ？
# 七行プログラムみたいのが上手いコードと言い張る奴もいるだろうし。

＞とてもそんな議論ができるとは思えないから。
そう？>>7とか>>39とか>>124とかがまさにそういう議論（というより意見か）
だと思うんだけど。
＞# 少なくとも「趣味」が入ったら何でもアリだろ？
＞# 七行プログラムみたいのが上手いコードと言い張る奴もいるだろうし。
短いプログラムとしてなら上手いだろうし、可読性の点では最悪だろう。
それは趣味プログラマだからどうこうっていう話じゃなくね？

>>124 は「メモリきちきちの環境」とかだとむしろ推奨とか言い出す奴がいても
おかしくないと思う。

> 短いプログラムとしてなら上手いだろうし、可読性の点では最悪だろう。

{} にしたって、文法上不要なところは省くと短いプログラムとしては上手いだ
ろうし、(未熟なプログラマに対する) 配慮と言う意味ではは劣るだろ？

それを、トータルでどっちが上手いと言う議論をしても、短いプログラムと未熟
なプログラマに対する配慮の重要度が「仕事、趣味、オープンソース、個人グ
ループ、など」では違うから、結論なんかでないと思うよ。

>>361
！？
それは逆アセンブルした結果をみて言っているのか？

>>124 と関連するが、自動変数のスコープを限定するためだけの {} はあり？ なし？

>>362
お前は何を言ってるの？

>>361
コンパイラの最適化時の賢さにもよるだろうけど、ローカル変数なら
別に使いまわしても使いまわさなくても吐くバイナリは同じだと・・・・
思ってるんだけど違う？ｗ
＞結論なんかでないと思うよ
いやそれでいいと思うんだけどなぁ。
ifステートメントとかの{}は、誰かも言ってたけど会社のコーディングルールで
決まってれば従えばいいし、一貫させることの方が重要だから
俺としては”さっさと終わっていい話題”だと思った。ｗ　
「このコードダメだよね？」「このコードうまいよねー？」みたいな話は
１．美的感覚を元にして話す
から面白いんであって、ここはム板なんだし
２．愚痴っぽいネガな理由持ち出してコーディング規則を語る
のは聞くに耐えんなぁ、と思っただけ。
音楽を聴くとき、あんたはアーティストがいかに不遇な環境で頑張ったかで良し悪しを決めるのかい？
先ほど書いた通りスレ主旨や流れにケチつけるのもアレだから、このくらいにしときまｗ

変数使いまわして意味があったのはインタープリタのBASICだけだと思ってたけど

>>365
> いやそれでいいと思うんだけどなぁ。

だったらスルーしとけばいいんじゃないかな。

> １．美的感覚を元にして話す

その美的感覚は人によっていろいろ違う。

君には、「愚痴っぽいネガな理由」としか思えなくても、他の人には
美的要素として重要なことだってあるんだし。

> 音楽を聴くとき、あんたはアーティストがいかに不遇な環境で頑
> 張ったかで良し悪しを決めるのかい？

仕事ならそう言うこともあるだろうね。

>>348=>>356=>>359=>>367？？さっきから何様なの？
＞その美的感覚は人によっていろいろ違う。
＞君には、「愚痴っぽいネガな理由」としか思えなくても
＞仕事ならそう言うこともあるだろうね。
なんていうか・・・色々と社会勉強してきてください；；；；
（ヒント：相対主義）

くだらん事で必死だな

上手なコード
ヘタなコード
fool proof なコード
のそれぞれに語る価値はあろうが、スレタイを前提とすると、このスレで"上手なコード"を語る意味はない。
であるからして"ヘタなコードだけどfool proofだから書かねばならぬ"というのを攻撃するのもスレ違いに思う。
"上手ヘタに関わらずfool proofであるべき"などと主張したい奴は別のスレを立てろ。

仕事でヘタコードを強要させられている愚痴ならともかく
仕事でヘタコードを制定しているアフォが自己肯定する為にこのスレで我侭言っている
だけだもんなぁ。

一番議論を邪魔しているのが自分だと気づけっての。

>>368-371
> だったらスルーしとけばいいんじゃないかな。
> だったらスルーしとけばいいんじゃないかな。
> だったらスルーしとけばいいんじゃないかな。

なんでそんな3回も連呼するほど必死なん？

むしろ下手なコードを奨励し、下手なコードを書く技術を向上させるための
議論をするスレだろ。
どうやったら上手に下手コードを実現するか。
さぁ議論再開。

おいおいｗ

>>373
今時必死か。

下手なレスの書き方を披露してるのか？ (w

ケンカはやめて（＞＜）

こういうのもヘタっぽい
if (b > c)
    a = b;
else
    a = c;

結局「{}は仕事で絶対必要」ｸﾝが暴れているスレになったな。

>>379とりあえず、職業プログラマにならないでね。
まわりの迷惑だからｗｗｗ

とりあえず漏れの会社は>>380の居るヘタコード強要会社ではないので安心だ。

おれも>>381がいるトンチキ会社じゃなくてほっとしたよ。

たぶん漏れの会社も>>380の居るヘタコード強要会社ではないみたいなので安心だ。

囲わないと後から文を付け加えたときに囲い忘れるかもしれないなんて、
「条件式で誤って代入演算子を書いてしまう」以上にありえないことだと思う。
それと違って、囲うかどうかはどっちでもいいと俺は思うしコンパイラも警告出すことでもないけどね。

ところで、1文だけのとき、普段は省略するけど、if - elseでは気持ち悪いから両方を囲っているんだ。
if (...)
{
  /*複数文の処理*/
  hage;
  piyo;
}
else
{
  hoge; //1文だけの処理
}
そうしていたら、それで最近、常に囲うほうで統一すればいいような気がしてきた。

囲い忘れたらインデントがずれるしね大体

>>384
> 囲わないと後から文を付け加えたときに囲い忘れるかもしれないなんて、
> 「条件式で誤って代入演算子を書いてしまう」以上にありえないことだと思う。

だよね〜。




と、俺も思っていたが、実際にあるから怖い。

>>381 みたいな自信過剰の奴は時にとんでもないポカミスをするから、そう言う
奴をはじく意味でも彼等の言う「ヘタコード強要」は必須。

1.1行で書ける／書くのが自然な時は囲まない
2.それ以外は囲む

これでやってる。でも1.の場合があまり無いから結果的に殆ど囲まないなぁ。

1行ってのはifも含めてって事ね。
if(a) hogehoge;

>>386
１行のifを中括弧で括るのがヘタコードだなんて誰も言ってないようなｗ

>>388
大量に羅列する時などは一行に書いてしまうが、その時は {} で囲む。

正直、単発で一行にするのは勘弁して欲しい。
インデントがあれば、キーワードを見ずとも制御構造があることがわかるという利点がある。
また、デバッガで追いかける時に面倒くさいことになることがある。

>>390
うん、だから1.はあんまり使わない。

それと>>387で全く逆の事言ってた。殆ど「囲む」の間違いね。

前にも書いたと思うが、うちも>387と同様。
慣れた奴は書かなくてもいいと思うかもしれないが、
それを真似して慣れてない奴が間違うのが困るんだ。

>>392
「間違えるから成長する」という考え方は？

>>393
間違えて成長する奴なら、間違えなくても成長する。
間違えても成長しない奴は、いつまで経っても間違える。

>>392
無いカスだから間違える
これ全世界共通の常識

意味不明ｗｗ

括弧で括ろうが括るまいとプログラムの変更箇所に対してテストしてれば
どっちでも問題ないと思うが「括弧で囲まないと困る」ってのはなんだかな？って感じだ。

「慣れてない奴が間違える」はコーディングルール以前に
品質を維持するルールが存在しないアフォ組織に思えるが。

そんなところで間違って貰っては困る

if (a != 0)
　　a--; b = a;

みたいなのは紛れもなく糞

糞と言うか見辛いだろうが、そこで修正間違えるヤツはかなりマとしての適正を欠いているとｵﾓ

>>399
こんなの見た日には、メーリングリストで晒し者したい気分

if (a != 0)
　　a--; b = a;
if (c != 0)
　　c--, b = a;

どうぞ

一応、こういうコード書いた奴を少し問い詰めたくなる罠

もしかしたら凄い理由があるのかも知れないし。

成長しない見本 (w

>>397=>>258

同じ事を何回も書くんじゃねぇ。

なにが言いたいのか解らんが日本語が不自由な人なんだろうか？

たぶん、漏れのレスが絶対正義と信じて疑わない人なんだろ
成長しない人間にありがちな思考だ。

>>378にもご意見くださいな

プログラミングが好きでもないのに仕事で中途半端に高い立場になってしまって
毎日ム板でストレス発散してんのさきっと。
だから趣味グラマ＝実力皆無、非営利のコード＝無意味と決め付けてるのもうなずける。
自分が会社の外で勉強する気が無い（向上心がない）から他人もそうだと思い込んでるのだろう。
そらウンコルールも作りたくなるわｗ

>>378
a = max(b, c);
a = b > c ? b : c;
の方がいいってこと？
どれでもいい気がしなくもないけどmax使った方が判り易いか。

>>409
そうそう。元のコードだと最低でも３行に目を通さないといけないからヘタな書き方だと思うわけ。
この場合はa = max(b, c);が素直だと思う。実際のa, b, cはもっと長い変数名なんだから。

しかし二つしか比較してないのにmaxってのもなぁ

え？こういうの書かない？
a = max(a, 0);

#define max(a, b) (a > b ? a : b)

普通、static int max(int a, int b) {return a > b ? a : b;}じゃないのか?

C++だとテンプレート版max()があったような。

俺は統一されてるのが好きだけど{}囲ってるけど、どっちもでいいな。
強要されるのはごめんだが。

ところでこいつを見てくれ、どう思う？
if(isA){
　if(isB)
　　if(isC)
　　　hoge1();
　else
　　if(isD)
　　　hoge2();
}

.NETにはEnumerable.Max<T>()が……

>>416
構文解釈しにくいなあ
elseはどこにかかっているんだろう

でも俺は{}でくくるのを強制されるのはゴメンだね。

>>416
レビュアーにケンカ売ってるのかな？ とか

>>416
プログラミング作法かなんかで見たような気がする

>>416
そのインデントからすると単なるバグ。正しくはこう
if (isA)
　if (isB) {
　　if (isC)
　　　hoge1();
　} else
　　if (isD)
　　　hoge2();

いや、実はインデントをミスしただけかもしれない

>>416
Cだとelseって一番近いifにかかるよな？インデント間違ってないか？

>>423
スレタイを読め

>>424
と思った、ということじゃないのかな？

>>424
お前さんのツッコミの意図がわからん。

このスレも末期ですね

スレ違いだけど、おれの場合はグローバル変数を使い始めたら
糞コード生産開始の合図だわ。。

グローバル変数にはメリットもあるだろ。

perlでクライアントの2chブラウザ作ったけど見たい人いますか？
4時間ほどで作りました

日本語でおk

別にいいです

Pythonのお勉強 Part 25
http://pc11.2ch.net/test/read.cgi/tech/1206876081/
604 名前: デフォルトの名無しさん Mail: 投稿日: 2008/04/20(日) 20:46:14
perlで2chブラウザ4時間で作った〜

ボク厨房！Pythonスレで自慢してみたのに、
誰も食いつかなかったからこっちに来てみたよ！＞＜

なんか流れを見てみると、自動インデント機能を使ってない人多いのかね?
(ちゃんと文法まで解釈するやつね)

>>416とかみたいなのは打ち込んでいるうちにおかしいってわかるから、
入力の手間を省くためというよりは、文法チェックのつもりで使ってる。

だから、そういう機能がない環境のやつほど
{}使いたがらせるんじゃないかと予想しているんだけど、関係あるかな?
かく言う自分はEmacsメインで{}強制はバカっぽく見える派。

一応確認するけど
ヘタだなと思ったコードを貼るのがこのスレの趣旨だよね？
まさかと思うけど>>374がこのスレの趣旨じゃないよね？

>>1を読め

>>435
374はネタだろ？
今までの流れからすると前者でおｋ

前者ならマ板だろ。
>>374で桶。
ここは技術板だ。

なんか、最近、技術って言葉を聞くとむなしくなる

俺は直感で書くとこうかなあ。
少し BASIC っぽい？

if(式) 文; else 文;

if(式) 文;
else {
}

if(式) {
} else 文;

if(式) {
} else {
}

それ珍しいなｗ
１つめはおいといて、個人的には
ifを囲うならelseも囲った方が、短くても同じ条件で分岐したものだと
認識しやすいと思う。
あと
} else {も、（賛否ありそうだけど）
}
else {
....
にした方が、行の最初に来るから認識しやすいかも？

あとネタ半分だけど
VC使っててあらゆるインデントを消すツワモノが居たなｗ
「どうせ一緒なんだから消してもいいじゃんｗ」
とのことだった。その人は今はCOBOLerだが。

変数名で悩まされるのはホント勘弁して欲しい。
int dynamic_static;
ってなんなんだよ･･･
一体何に使ってるのか気になってしょうがねえ。

>>443
そいつ、おちゃめだな

変数は大抵ローマ字で書いてる
int kao;
int me;
int hana;
みたいに

FILE* fairu;
_Bool raito_huragu;
とか？

int koreha_daijina_switch,tugini_daijina_switch;
float fudo_swith,syosuten;

死ねと思った

>>447
ネタでなくそんなコーディングがあるとは、いやはや

>>448
新人研修中で、実習させて提出されたコードの大半がこれ。
で極めつけが

課題.c 作成ファイル.doc <-Makefile

とかで渡してきやがった
文字コードがUTF-8(MAC)だし意味不明死ねと思った

>>449
新人研修とはよかったじゃないですか
今後業務で同じことをしないよう指導できるいいチャンスじゃないかな、しかも効率よく
教官の腕が試されてると思って頑張ってくらはい

>441
}
else {

は個人的には使わないなあ。

　　}

だけの一行ってのは、俺にはどうも
if〜elseまで含めた、全体の終わりに見えてしまう。

if(cond)
{ //...
//...
} else
{ //...
//...
}

>>452
それ見たことある

上のほうの#ifdefと同じで環境依存だけどVC8で

#ifdef _DEBUG
if( FALSE ) 〜;
#endif

上のthen行が実行されしまうんだ。

if( FALSE ) {
　〜;
}

と、括弧でくくればちゃんと機能するんだけどな。
#ifdefとifの組み合わせでバグる処理系って実は多いのか？

関数を分けすぎるってのはどうなんだ？
俺２行以上でかつ同じことを二回書くことになったら
関数に分けるって考えかたしてるんだけども
これだと分割しすぎるような気がしてきた

>>455
関数化って処理ブロックの名前付けという働きもあるから
適切に名前が付いてるならいいんじゃないかな。

グローバル変数にすべきものってなんだ？
勝手に書き換えられると困るからなるべくグローバル変数にしないで、引数で渡すようにしてるんだが

何階層もの関数を引数で渡していくのとグローバル変数使用とではどっちが見やすいだろうか。
グローバル変数といっても〜.cファイルの中だけで使うようにして他の〜.cでは使わないようにすれば
C++で言うところのメンバ変数みたいな感じで良いと思うんだが。

それならstaticってつけるべ

括弧の有無で問題が生じるなら。
それは括弧の有無自体が問題なのではなく、
関数の粒度が問題であると思うのだが。

>>458
グローバル変数じゃないじゃん
広義のグローバル変数にはあてはまる？

staticってつけたいけど、エラー時に変数ダンプしたい時にexternできなくなるからつけない・・・
ちゃんとつけてそのファイル内にダンプ処理書けばいいんだけなんだがめんどくさくって

クラスにしておけばいいのに。

＊変数名が意味しそうな内容と実際に格納される内容が全く関係ない。あるいは単なる一時記憶になってる

明解な変数名を付けて、名称通りの用途に使っておきながら、いつの間にかまるで違う用途に使っているとか、なかなかハイレベルなトラップだぜ。
レビュー前にコードを斜め読みして大混乱。

>>462
アクセサつければ？

Linuxならそんな問題起きないのにな。
ほんとWindowsは駄目だな。

おいおい、Windozeプログラマがキれちゃうぞ（笑）

>>465
プログラミング作法に似たようなのあったね。
コードを直したときにコメントを直すのを忘れて、コードとコメントが合ってない、とか。

俺は分岐する際、エラー処理を固めるためにネスト深くしてるんだが不味いかな？
returnは必ず一箇所で行うようにしてたらそうなってしまったんだが
こんな感じ↓

if( ) {
　if( ) {
　　if( ){
　　　if( ){
　　　　//処理
　　　}else{
　　　　// エラー処理;
　　　}
　　}else{
　　　// エラー処理;
　　}
　}else{
　　// エラー処理;
　}
} else {
　//エラー処理
}

Cではそうしていたけれど、他に移ったら例外処理があるから
そんなネストは要らなくなったし、returnを1ヶ所に拘る必要も失せた。
すれ違いすまん。

>>471
Cでも呼び元でエラー処理すれば同じことじゃね

if文でネスト深くなるのは、いいけど例外で深くなると見栄えも悪いな
まあ、別に悪くないけどさ

try{
　try{
　　try{
　　　try{
　　　　// 処理
　　　} catch( ) {
　　　　;
　　　}
　　} catch( ) {
　　　;
　　}
　} catch( ) {
　　;
　}
} catch( ) {
　;
}

try{
　　　　// 処理
} catch( ) {
　　　　;
} catch( ) {
　　　;
} catch( ) {
　　;
} catch( ) {
　;
}

これでいいだろ？

>>470
判定と異常の位置が離れてしまって見難くならないか。　
どれとどれが対応してるのか探すのがまず大変そうだ。
途中のreturnがいやならフラグはどうだ。
もしくはエラーだけ関数分けるか。
void hoge()
{
　if(IsOk()) {
　　//処理
　}
}
bool IsOk()
{
　bool isOk = true;
　if( ) {
　　//エラー処理
　　isOk = false;
　}
　中略
　if( ) {
　　//エラー処理
　　isOk = false;
　}
　return isOk;
}

ヘタ

ちくしょう、傷付くじゃないか。
ちなみにどう直したらいい？
ケチ付けようとかいう気持ちはなく、ただ純粋に参考にしたい。

俺ならエラー時、returnの手前にgotoする
まぁあくまで俺個人の意見

なるほど。そしてその指摘で気がついたが
別にすべての判定もエラー処理もする必要なかったから
else ifでも良かったかも。

むかーしはこんなんもあったよな。

if (a=0)
　　　{
　　　a = 5;
　　　}
else
　　　{
　　　a = 6;
　　　}

>>478
そこまでしてreturnしない理由て何？

>>481
ソース見たとき、一つのサブルーチンの中に複数returnがあるより、
ERRORみたいなラベルにgotoしてるほうが個人的にすごく見やすかったもんで

俺もreturnは一箇所で纏めるな
int iResult = FALSE;

if( ) {
if( ) {
if( ) {
iResult = TRUE;
} else {
}
}

return iResult;

ってな感じ

途中で送ってしまったorz

int iResult = FALSE;

if( ) {
if( ) {
if( ) {
iResult = TRUE;
}
}
}

return iResult;

それぞれの分岐のelseにはエラーメッセージの設定や後始末を入れる
ただ、ネストがあまりにも多い場合や 後始末処理が重複する場合のみ
先頭で return 返すかな

以前いた現場のコーディング規約に goto は原則OKだったんだけど、gotoアンチだった俺が
使ってみたらやばい便利だったｗ

なんでBOOLって4バイトもあるん？

#define BOOL int
とかなんとかあったような気がする。（Win32SDKの話だが。）
C++のブーリアン型のboolとは別。

理由になってないよ

8bitとかの方が節約できるのに、ってことか？
アホかお前

return を複数書いてて、それにケチをつけられたら「これはガード節ってテクニックです! ケントベック読んだことないんですか!?」とか
言い返してやればいいよ。

単純にintの方が速いからじゃね
どうせ1bitを正確に表現する型はないわけだし

intをcharにしてメモリを節約しても、油断してるとあちこちでintに変換するコードが入るから、
コード領域では、節約した分はすぐふっとぶね。

>>458
> C++で言うところのメンバ変数みたいな感じで良いと思うんだが。 

メンバ変数でも、ひとつのクラスにたくさんあって、メンバ関数もたくさんあるって状態で、
それを好き勝手にいじってたら、グローバル変数と同じだよ。

イベントドリブンのシステムで初心者に作らせると、たいがいそうなるね。

つーか、BOOLは真偽値(だけ)を現す型じゃないんだってば。

真と偽とエラー値の3通りの値を返す可能性がある、
返り値がBOOL型のWin32 APIがあるらしい。
どうせAPIの互換性なんか気にもしてないんだろうから(偏見)、
とっとと直せばいいのに。

GetMessageがBOOL返すけど、何の為にBOOLなのかわからん。
intでいんじゃね？　defineする必要なくね？

---MSDN引用
WM_QUIT 以外のメッセージを取得した場合、0 以外の値が返ります。
WM_QUIT メッセージを取得した場合、0 が返ります。
エラーが発生した場合、-1 が返ります。
---引用終わり

INTやらBYTEとかと同じだろ。そんなこと言い出したら
Win32APIの型全部無駄だし。

一応BOOLは、「TRUEかFALSEのどちらかになりますよー」という
返り値が２値であろうと予想がつくという意味がある。

だからこそGetMessageはINTか何かにしてくれないと誤解を招くがｗｗ

XXXcheckなメソッドを複数呼ぶまとまりの
メソッド名とか何かいい名前ないですかねぇ
登録前のチェック群メソッド名

CheckPhase

Checkers

>499
素でそれ使ってましたｗ
それでbool返せば他の人が　isMethodみたいに
イメージできるかなぁと思った次第です
まぁちゃんとメソッドヘッダにreturn説明書いてますけれどね

状況にもよるだろうが、Checkを確認するの意味で使っているとしたら、
CheckXXXになるケースが多いのではないだろうか。Checkerなら、XXCheckerでも分かるが……

gotoつかうやつは知識が無い奴。
上級者はfor(;;)やwhile(1){}を使う。
ヒント：break,continue

分かるかなぁ？ｗｗｗ

>>502
・・・

大学の時に教授にgoto文を使っちゃだめって言われたけど、
なんで？

無限ループよりはdo{...break}while(false);のほうが安心出来る

>>502
それを使うのが上級者かどうかは置いといて、それを知ってるぐらいで上級者って言って欲しくない。

>>504
それは
http://ja.wikipedia.org/wiki/%E3%82%A8%E3%83%89%E3%82%AC%E3%83%BC%E3%83%BB%E3%83%80%E3%82%A4%E3%82%AF%E3%82%B9%E3%83%88%E3%83%A9
という昔の学者が(ry

場合によって使い分けれるのが一番だな

だが、gotoがない言語でも普通に開発できるんだから無理に使う必要ないケースが多い。

>>502
　for(;;){break;}を使ったコードがgotoを使ったコードよりどういう点で優れているのか
説明してくれ。
　for(;;){break;}の何が良いのかさっぱり分からないんだ。

無限ループからbreakで脱出する利点はわかる。処理Aが終わらないと条件Aの判断ができないとき、

処理A;
while (条件A) {
　　処理B;
　　処理A;
}

みたいな冗長なコードを書かずにすむ。

while (1) {
　　処理A;
　　if (条件A) break;
　　処理B;
}

でもgotoとは関係ないよね。

>>510
goto は、ラベルのあるところならどこにでも飛べるのでほんのちょっぴり危険。

for(;;){ break; } なら、後の } に次に行くしかないので少しだけわかりやすい。
(とろこで、なんで for(;;) なの？ >>505 のように do{ break; } while(false);
じゃないのか？)

例えば、

if(〜){
　goto Err1;
}

Err1:
　〜;

if(〜){
　goto Err1;
}
Err2:
　〜;

なんて言うミスを防げる。

まあ、関数内で goto を多用しなければあまり問題ないと思うけど、一番の難点は
goto を許すと、ループを goto で作ったりするアホがでてくる可能性があると言
うことだと思う。

>if (条件A) break;
...だめだろw


>でもgotoとは関係ないよね
たぶん、こゆこと
goto skip;
do{
　処理B;
skip:
　処理A;
}while(条件A);

>>511 >>513 なるほど。たまに利用したいケースはあるかも知れない。

>>512
ん〜、タグ名のマチガイかぁ。
それって、変数 x に代入すべきところを y に入れちゃったってのと同レベルのマチガイでしょ。
なんでその問題解決に、無限ループしてカッコ閉じを探すスタイルを使うのかが分からない。
タグ名で意味づけできる＆無条件で移動するという意図が明確なんだから、
まだ goto 使うほうがマシな気がするんだよねぇ。

> 一番の難点は goto を許すと、ループを goto で作ったりするアホが
> でてくる可能性があると言うことだと思う。
これは激しく同意。

>>513
う〜ん。そのgotoはキモイｗ 悪い例として書いてくれているんだろう。

というのは、俺が>>511の書き方をするのは、長さのわからないストリームを読むときにほぼ限られるから。
処理Aでストリームを読んで、処理Bでそのデータをゴニョゴニョするのに、順番が逆になっていると、実にキモイ。

> それって、変数 x に代入すべきところを y に入れちゃったってのと
> 同レベルのマチガイでしょ。

自分はそう言う間違いを絶対にしないと言うなら、goto 文使っても問
題ないよ。

10行くらいの関数だったら多少のgotoは気にならない。
でも数十行以上の関数だったら勘弁してほしい。

>>513
511の方が普通だな。本当に普通だ。
何かが起こったらbreakする普通の無限ループに過ぎないわけだがｗ

javaの名前付きブロックで置換できないようなgotoの使い方は
多分、考え直した方が良いな。

名前付きブロック、デストラクタ、例外、関数リテラル
とかがあれば、gotoは要らなくなってくる。
全部無いプレーンCには明らかにgotoが必要だろ。

>>518
>>513が>>511に突っ込んでいるのは、多分、条件が逆ってことだろ。

>>519
あー、あー、やっと理解できた。
502が想定して叩いてるgoto使い、
を想像したコード例を書いたのか。

>520
本当に理解できてるのかw

>条件が逆ってこと
だNE!

>>条件が逆ってこと
>だNE!
その下の変なコード例挙げた意図を曲解したってことだよ。

goto議論はアホでも参加できるからすぐ荒れるね

ネタ投下したまま忘れてた。ゴメン

>>524
よぉ、キチガイ

goto文の代わりにwhile文を使うメリットを教えて進ぜよう。
それは宇宙の真理をコードで表現することである。
本質的に全ての制御はループで記述できるという宇宙の真理が存在する。
むしろ、我々が「ループではない」と思っているものは一回だけループするという特殊なループに過ぎない。
このことを表現することが出来るのである。

>>526
う〜んなるほどありがとう

つまり、whileさえあればifも必要ないってことですな。

>501
RegistCheck, InsertCheckとかで
XXXXCheckを束ねて　boolをreturnしてるけど
まぁ一般的なんですね

for(i=0;i<x;i++){
for(j=0;j<y;j++){
goto LABEL;
}
}

コードについて話すなら。
構造化定理
ぐらいは知っておいてくれ。

ぐぐってみた。
「構造化定理は、
全てのアルゴリズムは、
順次、選択、繰り返しの3つの基本制御構造を組み合わせて作ることができる
という定理ですが」
・・・・・ｗ

532 ：デフォルトの名無しさん [↓] ：2008/04/24(木) 12:32:51
ぐぐってみた。
「構造化定理は、
全てのアルゴリズムは、
順次、選択、繰り返しの3つの基本制御構造を組み合わせて作ることができる
という定理ですが」
・・・・・ｗ

>>470
>>475
>>278
(っ´▽｀)っ
この議論はコードコンプリートに取り上げられている。
さあ読むんだ。コードコンプリートを。

>>472
(っ´▽｀)っ
リソースを確保してるのがローカル変数だったらどうする？

int Func(void)
　void *p;
　p = malloc(1024);

　(処理)

　free(p);
　return;
}

alloca

>>491
(っ´▽｀)っ
それどころかめちゃくちゃ遅くなる場合がある。
たとえばchar型をループカウンタに使った場合。
ループ1回まわる度に、int型にキャストされるから。
単なるキャストと思われがちだが、
キャストというのは記憶領域を新たに確保しなければならない
結構高価な処理なのです。

(っ´▽｀)っ
っていうか、returnを複数書くと保守の時がっかりするんだよね。

int Func(void)
{
　　(処理)
　　if(ErrorCode == 1){
　　　　(エラー処理)
　　　　return;
　　}
　　else if(ErrorCode == 2){
　　　　(エラー処理)
　　　　return;
　　}
　　else if(ErrorCode == 3){
　　　　(エラー処理)
　　　　return;
　　}
　　else{
　　　　(正常時の処理)
　　　　return;
　　}
}

上司「(っ´▽｀)っ どんなエラーが起きても終了処理Aが行われるように直して！」
部下「(っ´ω`)っ 4箇所も直すのか･･･。」

〜1年後〜

上司「(っ´▽｀)っ どんなエラーが起きても終了処理Bが行われるように直して！」
部下「(っ｀Д´)っ また4箇所も直すのか！氏ね！」

コードの標準化、改善がなされているプロジェクト
(っ´▽｀)っ(っ´▽｀)っ(っ´▽｀)っ(っ´▽｀)っ ←みんなニコニコ

コードの標準化も改善も全くなされていないプロジェクト
(っ´ω`)っ(っ｀Д´)っ(っ；д；)っ(っ ﾟ▽ ﾟ)っ ←欝病、キレる人、泣く人、狂う人

>>538
Cだとそうなって仕方ないけど、
finallyやデストラクタなど後始末をまとめる機能のある言語なら困らない。

>>540
(っ´▽｀)っ
大賛成！Cだと困る。だからCは困る☆

まぁエラー時の共通処理を関数化したりマクロ化すればいいんだけど
それでも面倒だよね

(っ´▽｀)っ
こういうことだね。

int Func(void)
{
　　try
　　{
　　　　(主処理)
　　}
　　catch(Exception e)
　　{
　　　　(例外処理)
　　}
　　Finally
　　{
　　　　(終了処理)
　　}
}

上司　「(っ´▽｀)っ　終了処理Aを入れて☆」
部下　「(っ´▽｀)っ　は〜い☆Finally句に入れるだけでOK！」

(っ´▽｀)っ
構造化プログラミングとは、順次、選択、繰り返しで構成されるプログラミングだね。

主処理、エラー処理、終了処理で構成するプログラミングにも名前を付けよう☆

主処理、エラー処理、終了処理を1ブロックとし、
そのブロックも主処理、エラー処理、終了処理のいずれかに所属する。
そのブロックも、それを含むブロックも、さらにそれを含むブロックも
主処理、エラー処理、終了処理のいずれかに所属する。

ここでいう、主処理とはtry句、エラー処理とはcatch句、終了処理とはfinally句に対応する。

どんな名前がいいかな？

Java?

つ 定列化プログラム
すまん、センスねーな

gotoって昔は使うなっていう風潮があったけど
今はスキルのある人が使うのはいいんじゃない？ てきな流れになってなかった？
まあ、gotoのジャンプ先は return 直前の後始末にセットしておく以外使い道は分からんが

初期化

ループ {
if(x) goto 初期化
}

こんなときとか

>>547
初めてみたｗ

今居るプロジェクトで
do {
startLoop:

// 処理
if(){
goto startLoop;
}
} while(1);

↑のような書き方してる奴が居た
マジ吹きそうになったな

continueを教えてやれよ

(っ´▽｀)っ
VB厨なんじゃないの？continueを知らないってことは

勉強不足なんだろうな。
他人のコードを見れば分かるレベルの話じゃん

え？なんでcontinue使わないといけないんですか？
goto startLoop;でもあっていると思うんですが。。

doとwhileでcontinueしたときってwhileの判定ってやるんだっけ？
両方とも滅多に使わないから組み合わせ時の動作が分からない。

あってるよ。どっちも同じ動作だし。
同じ動作でも書き方が違うから「ヘタなコード」というものができるんじゃないのか？

gotoで済むところを
わざわざwhile + continueに変えて可読性を落とす馬鹿

555 ：デフォルトの名無しさん [↓] ：2008/04/25(金) 06:40:02
gotoで済むところを
わざわざwhile + continueに変えて可読性を落とす馬鹿

>>553
whileの判定はある

このスレ読むと goto は使ってもいいんだなと思うな
滅多に使わないけど

>whileの判定はある

マジで？
うわー勘違いしてた

gotoは有用だが解ってない奴に使わせると危険

ふぃなりーはとらいとかきゃっちのなかからりたーんのときでもじっこうされますの？

そのためのfinallyだ。読みはファイナリーだ。

ﾌｨﾅﾘｰｾﾌﾞﾝ！

gotoは構造を無視できるから嫌われる

本物のプログラマは、gotoを恐れずに使う。

本物?
gotoを使わないようにするためだけに変な構造のコードをかくのは確かにヘタだが

continueもbreakも概念的にはgotoと同列

>>565
「本物のプログラマ」をググってみるといいと思うよ

breakもcontinueもreturnも、乱用するとgoto同様に読みにくくなる。
ただ、gotoに比べて前者の3個は、飛ぶ方向と位置があらかじめ決まってる分だけ可読性に少し寄与しているだけ。

>>566
gotoの真の力は計り知れない。
continueやbreakなどとはその設計段階からして、まったく異なる思想の元に創生されたものだ。
迂闊にgotoの封印を解いてしまうと管理局の統制が利かなくなり世界を崩壊に導く恐れがある。

特にC/C++のgotoは、ループの外から中に飛び込めるからなあ。
switchのラベルもそうだが。

おまえらgotoでこんなに揉めるなんて

継続とか使ったらどうなっちゃうの

すまん継続って何だろう？
継承じゃない？

まあ、>>523の言う通りってこった。
テンプレートとかジェネリクスでは、ここまで盛り上がれまい。

>>572
プログラマが制御できる大域ジャンプのようなもの
setjmpの強力な奴と思えばいい

schemeとかrubyに実装されてる

>>574
ありがと
scheme、rubyはノータッチだorz

>>575
無知の言い訳ﾜﾛｽ

俺も知らなかったけど

>>575
ノータッチとか言う以前に
gotoの話してたのに継承のtypoなわけないだろ常考

>>577
昔は、継承は「90年代のgoto問題」とか言われてたよ。

continuation どころか closure さえ使えないんだから許してやれよ。

(っ´▽｀)っ
継承はカプセル化を崩壊させるからな

にちゃねるって程度が低いよな。
なんかがっかりするレスが多い。

わざわざ書き込んじゃうあたり、程度が知れるね♪

まとめると、
・本物のプログラマは goto を恐れないで使う
・賢い本物のプログラマは continuation も使いこなす
・女子供は break や continue だけを恐る恐る使う

continuation = 大域で状態付きのgoto

gotoよりたちが悪い

吉野家コピペに近いものがあるな

gotoは適切に使えばいいと思うが、
gotoを使うことを心がけたコーディングは駄目だな。

if と goto さえあれば生きていける。

そうか、gotoも使えるようにならないと駄目だな。
機会があれば使って、慣れるようにしよう。

悪習を真似る必要は無いぞ

goto使うと見通しが悪くなる

気がする

必要な処理が全て下に固まってるってとてつもなく
よろしくない？経験の浅い初心者にその処理下みれば全部あっから。
って指示しやすい。

それをするなら、必要な処理を全て下に固める事を規約で決めないといけない。
さらに言うとその規約の外で書かれたコードはそうなっている保証がない。
潰しのきかない知識を植え付けるだけだと思う。

クロージャーやらsetjmpって構造化無視なのか。
手元の小さな作業は減るけど見通しが悪くなるでよい?

とりあえず、closureとcontinuationについて調べてから発言しようぜ。

恐ろしい・・・

>>593
クロージャを使う事で構造化より見通しが良くなるのであれば
それは良い事

だいたい手段と目的を履き違えている奴多すぎだろ
色々な手法は何のために作られてるのか考え直せ

設計思想が無い
道具の使い方はいくない
バカと包丁だじぇ

・インデントが半角スペースではなくタブで行われている

・しかも、4桁毎のタブを使用している。

エディタでタブみたいにカーソルが動いてくれれば、正直どっちでもいい。
逆に言えば、そうじゃないことの方が多いからタブ使っている俺。

普通にtabですが

混在させてる奴は糞

基本タブで微調整にスペースって感じで混在させてる奴はよくいるな。

タ　ブ　ｽﾍﾟ4while(式) {
タ　ブ　タ　ブ　何らかのコード

なんてされると、4タブ派はまずネスト修正しないといけないからな。
単文のネスト以外はTabかスペースに統一して欲しいよ。

そんなのフォーマッタにかけてしまえばよいじゃん。
ソース内にアートを書くようなのにはjavadocでも教えてやれ。

>>603
条件演算子でこうやって縦に揃えるときにやる。
[タブ]return isHoge ? Foo
[タブ]ここは空白　　: Bar;

タブa = 0;
タブbb = 1;
タブccc = 2;
みたいに揃えるためにスペースを混在させるのはありか？

そろってないよ

>>607
IDEの類が勝手にスペースとっちゃうことがあるから、
行頭のインデント以外で、縦に揃えようとするのはやめてほしい。

そうか無しか。残念。
混在は行頭だけにしとく。

gnuはインデントがスペース2コで、8以上になるとタブになるって、変態インデントだよな。

>611
あれ、8タブを強制されてる感じがして嫌だわ。

>606
そういうコードはネストを崩される余地がほぼないから
4タブでもちょくちょく書く。

>>599
ifが追加されるなどインデント変更する作業が面倒そう

>>600
set tabstop=4とでもしとけばええがな

俺はタブは2つ分だよ。

ああ、キチガイか。

タブ8でコード書いてる俺は？

インデントはスペース2個！
タブは使わない(タブキーは使うけど)

インデントはタブキーでやれ！！
スペースでもいいけど。

ここを読んでいて、最近はVisualStudioの自動整形任せで、2年くらい自分でインデントしてないことに気付いた。

そういえばVisualStudio使うと強制的にスペースに変換されてるな。

VisualStudioを使うと強制的にTabになる。
場合によってはTab＋スペースになる。
（関数のパラメータの一つ一つについて改行を入れた場合など）

>>621-622
ひんと: オプション設定

>614
まともな環境ならインデントレベルの変更なんて
コマンド一発か、選択範囲のインデント変更くらいあると思うが。
無くても矩形コピー → 矩形貼付で出来ちゃうし。

オレは７カラム目で揃える主義。

インデントはtabにしておくと、読む側が好きなインデント量を指定できて便利じゃないか。

Tabキーでスペース四個挿入するオプションの無いエディタは
作者ともども消えてなくなればいいと思う。

インデントって>>626の言うように、Tabだから良いんじゃないのか？？？？
スペース１つだけ使うときは別として、インデントはTabじゃないの？？？？？？？？？？

>>625のソースの全行の6カラム目に*を入れたい

>629
それ何てCOBOLのコメント

6カラム目は Fortran の継続行じゃなかったっけ。
(ちなみに、空白以外の文字ならいいんだけど '$'
を推奨ってものの本に書いてあったな。)

COBOL のコメントは 7カラム目だし。

FORTRANの神カードには行番号と継続の桁の線が太くなってたから何桁目だったか覚えてないや。

恐れ多いカードだな。

だからどうして行主導の言語の話しになるのか　と

行主導じゃない言語のほうが稀だろ。
つーか、COBOLやFORTRANは桁依存性が高いと言うべきじゃね。

>>635
>行主導じゃない言語のほうが稀だろ。
いまどき、固定書式が要求されるのなんて
古いFORTRANと古いCOBOL、それにRPGくらいしか知らないんだが
そんなに多いのか？

>>636
例えばC/C++はプリプロセッサやコメントが行単位だし、ソース最終行に改行は必要だね。
改行コードを全く必要としない言語ってbrainfuckの類以外に何がある?

行主導と固定書式じゃ全然違うだろ。

つーか、行主導とやらの定義を明確にしてくれよ。

行主導って多次元配列の添え字の数の変わるのが
右からか左からかの違いに使われる言葉だと思っていたな。まあいいや

行主導：parsingの単位が物理的な行である言語
文主導：parsingの単位が文

ってなところでどうかな？

>>637
Pascal / Modula-2 あたりは改行コードは不要なはず。

>>639
> 行主導：parsingの単位が物理的な行である言語

おおまかにはそれでいいと思うんだけど...

・コメントは行末までと言う言語が多いからこれをどうみるか？
・プリプロセサの扱いは？
・BASIC なんかの行番号が必要な言語は？

等を決めないと俺俺定義で語る奴ばかりになりそう。

今いる職場でみたツールプログラムは

　・全変数の8割がグローバル変数
　・配列などを一切使っていない（それどころか、mallocなどもない）
　・変数名がやたら長い
　・ほとんどCの標準関数ばかりでWindows APIをまったく使っていない
　・メンバ変数やメンバ関数は全部 public にしている

一応作った人って6年くらい働いている人なんだけどね・・・

>>641
(っ´▽｀)っ
それはCOBOLerだな？！

>>641
>・ほとんどCの標準関数ばかりでWindows APIをまったく使っていない

移植性考えたらこの方がいいと思うが...。

て言うか、やっつけツールなら >>641 のような状況もありだと思う。

ツールプログラムなら変数名がやたら長い点を除けばワリとあるんじゃね？
だって他人が読む前提を捨てているプログラムだろ？
漏れだったら別にx1とかchr1とかメチャ省略するし。

それに漏れも出来るならWindowsAPI使わずに済むなら使わない派だし。

ツールなら逆に、全部ローカルでprivateにして、極力他人に触らせないようにするけどなぁ。

>>642
いや違うよ。Cをずっとしていたみたい。C++はそんなに経験ないかも。

>>643
>>644
やっつけツールみたいなのは今までも見てきたけど、今回のよりずっと見栄えもいい物ばかりだったからな・・・
漏れが厳しいのかな・・・
それに今使ってるツールはみんな日常的によく使うし、今後仕様改訂に伴って追加・変更もあるからせっかくならそれなりに書いたほうがいいと思ったのだ。

　

＞それに今使ってるツールはみんな日常的によく使うし、今後仕様改訂に伴って追加・変更もあるからせっかくならそれなりに書いたほうがいいと思ったのだ。

そう思うなら>>646が自分で書き直せば？って思うが。
やっつけのツールでソースが公開されているのは「不満があるならテメエで直せ」って
意思表示でもあると思うが。

漏れもやっつけ＆他人に使って欲しくないならソースを隠す。
やっつけ＆責任放棄の時はソースを晒しとく。ｗ

>>648
たしかにそうだね。
今度書き直してみるよ

やっつけでもグローバル変数８割はないだろ。
スクリプト言語で、50行のソースとかならともかく。

わかりやすいコードを作成するための 6 つの方法
ttp://www.ibm.com/developerworks/jp/linux/library/l-clear-code/index.html

ヒント 1: 賢い人にならってコメントを付けること
ヒント 2: #define をたくさん使うこと。ただしやたらに使うのは禁物です
ヒント 3: わかりにくい変数名を使わないこと
ヒント 4: エラー・チェックを行うこと。誰にだって間違いはあります
ヒント 5: 「Premature optimization is the root of all evil (早まった最適化は諸悪の根源である)」 - Donald Knuth
ヒント 6: あまりにも賢くなりすぎないこと

>やっつけでもグローバル変数８割はないだろ。
>スクリプト言語で、50行のソースとかならともかく。

やっつけなんて精々１・２画面程度のソースなんじゃね？
んな、やっつけで500行も書くとは思えんが。

そもそも、メンバ変数とか言ってるから C++ の話だと思うんだが、C++ で malloc が
どうのこうのと言ってる >>641 が人のコードを批判するのもどうかと思う。

>>653
new/delete はおろか malloc/realloc/free すら使っていない、って事だろう。
態々論点からズレたところを指摘せんでも。

え〜〜っと、本人乙ってことでいいのかな。

newもmallocもHeapAllocも使わないならどうやってヒープ確保すんの

配列を使わないのにヒープなんていらないだろ。

複数個のデータが必要な時はどうしてるんだ?
まさか
int n0,n1,n2,n3...;
なわけないよな?

リンクトリスト

>>659
>>659
>>659

>>658
std::vector

配列は使わないのにSTLは使うなんて、もう何が何だかw

>662
C++で、速度がそれほど切羽詰まってなきゃ妥当な選択だけど

vector なら配列も使ってないしヒープもいらないと言うのか？
vector は配列の一種だし、中でヒープも使ってるはずなんだが。

ユーザコード内で使うのは駄目ってことなんじゃないのかな

ユーザーコードって何だよ

相手の意図を読むとかググるとかできんのかな。

>>641で書かれてるヤツがvector使えるとは思えないｗ

初心者です
vector使うのはやっぱ高度な難しいんですか？
やはりGlobalAllocなどで馴れてからにしたほうがいいですｈおうか？

>>669
やってはいけないことを知ってれば問題ないよ。
追加削除したら参照もイテレータも無効になることを知ってればOK

>>669
そもそも日本語使うのは高度な難しいんじゃね?

高度な文字コード

有名なAccelerated C++では配列やポインタよりも先に
vectorが出てくるから全然不自然ではない。
>>641で言われている人がvectorを使っているのかどうかはさておいて。

アクセラC++はstringもchar[]より先なんだよな
""リテラルは出て来るが、stringに入れる為の表記としてだったり
その後もしばらくstringとは別物であることしか説明しない
詳細に説明されるのは、後々charと配列の説明が終わった後

同じ著者のC++Primerもそのスタイルになっとるな

そもそもGlobalAllocを積極的に使う機会ってあるか？

グローバルハンドルを使わざるを得ない機会はあるが、
そんときにはvectorで代替できない（アロケータで何とかなる問題でもないはず）。

それ以外のときはそもそもmallocとかnew[]で十分、GlobalAllocを選ぶ理由はない。
もちろん、その中のどれよりもvectorのほうが便利だが。

new と vector のどっちが便利かはさておいても、malloc のでる幕なんてないと思うが。

それは環境依存なので

C++でnewではなくmalloc使う状況が思いつかん。
newの実装がひどくて、しかたなくmalloc使っているとか?

書き込んだ後に思いついて試してみた。
malloc/freeならコンストラクタ/デストラクタが呼ばれないんだな。
そういうわけで、
・コンストラクタ/デストラクタの呼び出しを抑えたい
・ベターCとしてC++使っている
環境なら、mallocもありなんだな。

そういう場合でも　new char[x]　でOK

> ・コンストラクタ/デストラクタの呼び出しを抑えたい

そもそもそんな状態になること自体がヘタなコー...

realloc使うときとか？

>>680
> malloc/freeならコンストラクタ/デストラクタが呼ばれないんだな。
明示的に operator new ( size_t ) を呼べばコンストラクタは呼ばれないし、インターフェース的にも（例外以外は）malloc() 互換であり、その理由ならば malloc() は不要。

STLが使えない時にreallocしたいときだな

そのときはrealloc()を使えばいいのだから、やはりmalloc()は不要。

#include<stdio.h>
#include <windows.h>

void main(int argc, char **argf) {
argc = main(argc, argf);
return EXIT_SUCCESS;
}

コンパイル通らないだろ

さすがに、void main() で値を返してるから、エラーになっちゃうな。

int main() なら、コンパイルは通るけど、

test.cpp(7) : warning C4717: 'main' : すべてのコントロールのパス、
関数を回帰するとランタイム スタック オーバーフローが発生します。

と言われる @ VC++ 2005 Express

おきるわな

>>687
so what?

だからなにｗｗｗｗｗｗｗ

>>679
operator new
主にデバッグ用。まぁ後はリリースビルド時に
速度を殺しても自動で０クリアしたいと時とか。

昔、ヘタというか、見て驚愕したコード
#define LOOP_CANCELER(a)　　　　if(a>500000) break;
#define LOOP_CANCELER_COUNT(a)　a++;

int loop = 0;
while(1)
{
　　LOOP_CANCELER(loop)

　　 :

　　LOOP_CANCELER_COUNT(loop);
}

無限ループを恐れたらしい。巨大な関数内の、ありとあらゆるwhileにこれが入っていた。
これが原因でより深い闇へ落ちていったのは言うまでもない。

なんで

#define LOOP_CANCELER(a) if(a++ > 500000) break;

ってしないんだろう...。

まあ、そう言う問題じゃないのは承知の上で。

#define LOOP_CANCELER(a) (void)0;
って再定義したんじゃだめだったん？

Ｃ言語なら俺に聞け（入門篇） Part 33
http://pc11.2ch.net/test/read.cgi/tech/1217073697/544

217行でインデントが9レベルあったり482行で4レベルだったり……

>>694
その辺は彼なりになんかあったのかも。
まぁ、そもそもまともな思考があれば、このマクロが及ぼす弊害は簡単に想像つくわけで。

>>695
多分大丈夫だったと思う。しかしこれは氷山の一角で、
そのLOOP_CANCELERが本当に役に立ってるんじゃないかと信じてしまいたくなるほど
壊滅的なコードだった。ベテランも含め誰もが直接触るのは避け、
山ほどバグを出し、それらは場渡り的に修正され、そのままリリースされた。

void function()
{


for (int i = 0; i < HOGEMAX; i++)
{
.
.
fuga:
.
.
}

途中で投入してしまった。

void function()
{
・
・
goto fuga;
・
・
}

今仕事でメンテしてるのはコメントが疑問形で書いてあって辛い
//このループでXXXがXXXXとなった場合のXXXXをしているのか？

か？って言われても…

// はい、やってます。

って、書いとけ。

しかし、実際本当にわからないのがヘタコードクオリティ

引き継いだコードがマジックナンバーの嵐だった…

何か問題あるの？

全ての行にコメント書いてます

for(int i=0;i<max;i++)
{
　　　HOGE hoge = new HOGE();
}

>>706
＊がないからＣ＃か？
だったら問題ないか？

ヘタってのは、セキュアじゃないとか、リークするとかとはまた別の要素なんだな。
なんというか、正しい動作はするんだけど素人臭いというか、そんな感じ。

無駄なコメント

// これはコメントです

a = 0; // aにゼロを代入する

// 2009/02/08 変更開始
//a = 0; // aにゼロを代入する
a = 1; // aにゼロを代入する
// 2009/02/08 変更終了

procedure unko{
ittekuru();
}

Vector v = new Vector();
Iterator i = v.getEnumlation();
for (int j = 0; J<v.size(); i.next())
{
i.next();
:BUTTOBI
i.get(j);
}

goto BUTTOBI;

1行1動作厳守

{
int i;
i = 0;
int rep;
rep = 1;
for(; i < rep;) {
〜〜〜
++i;
}
}

>>715
{
int rep
= 1;
for (
int i
= 0; i < rep;
++i) {
...;
}
}

void scale(int *w int *h, int toWidth)
{
　while(*w > toWidth)
　{
　　 *w--;
　　 *h--;
　}
}

jmp_buf や using namespace をグローバルに置く

色や座標定義なんかでありがちだけど、定数や構造体の構造自体が洗練されていない。
機能的な重複、フィールド細かくなりすぎて多すぎ。
これやってしまうと、巨大で無駄が多くて明示性に欠けるものになるね。

RAIIにこだわりすぎて、わけわかんない物までダミークラスでラップされている。
せめて、対になってない処理をRAIIで扱うのはやめてほしいな。

5MByte超のソースファイルがある。

>>718
stdは許して
名前かぶるようなの使わないから！

GlobalHeader.hpp
using namespace std;

>>712
ﾂﾎﾞったｗ

おいらのクラスは13000行

test

????

WIN200

test

クラスのクラスをクラスのみんなと作ったよ

test

test

test

test

∩
ё∋→　З З З 〜
　∪
蜂の屁

if(i == (int)NULL)

本当のハンガリアンを知ったのは会社を辞めた後だったな
何か違うと分かっていたけど、惰性でシステムハンガリアンで書いていた

>>53
俺は左に定数、右に関数の変体コードを書いていたよ