ぱっと見て「ヘタだなぁ」と思うコード

基礎編
・サブルーチン(関数)が数百行
・ネストが深い
・マジックナンバーが使われまくり
・識別子(変数名、関数名)が意味不明
・グローバル変数使われまくり

↓応用編、詳細編どうぞ

２げっとー！

・コメントの装飾が妙に凝っている
・古いコードがコメントアウトで残してある(しかも履歴つき)

＞・古いコードがコメントアウトで残してある(しかも履歴つき)
それが下手と関係あるのか？

>>4
かなりヘタ。

古いコードって、コメントしても元に戻すことってまずないよね
俺はコメントしても、時間が経ったらコメントごと消すようにしてる

＞・古いコードがコメントアウトで残してある(しかも履歴つき)

究極は、#ifdef 0 でコメントアウト。

イベントドリブンの環境で、「グローバル変数状態つかいまくり」状態が多いね。
イベントハンドラから呼ばれた入力データのチェックルーチンが直接コントロール
なり、フォームの入力を保持してる変数を直接見にいってるから、使い回しがきかない
とか。

役満＼(＾o＾)／

これも置いておきますね。
・制御文が2種類しか使われない

>>7
#if 0
ではないのか

いまメンテしているC++のクラスのメソッド

Public:
int initialize()
int execute()
int finalize()

以上。

補足。

int initialize()・・・呼ばれていない
int execute()・・・約１２００STEP
int finalize()・・・呼ばれていない

orz

>>11-12
下手なだけで、「int execute()・・・約１２００STEP」を読めなくは無い。
クラスにしてくれてるだけ、メソッド分離しやすいぉ。

いやまあヘタなコードのスレですから

修正可能なソースはヘタじゃないですぉ。
ニッチもサッチも逝かないのが、ハードコーディングですぅ。

>>6
古いコードは残しておく。

別にパフォーマンスにも響かないし、最近のエディタなら
邪魔だと思ったらたたむことも出来る。

とくに最適化前のコードは絶対に残しておく。計測用に
切り替えて使うこともあるから。

一度書いたものはなんであれ財産。消すことは絶対許して
いない。

>>16
なんか力、入ってますねー。
ソースコード管理システムを使ってれば、HEAD/trunkで消してもすぐ元に戻せるんですが。
自分はソースの見通しが悪くなるようなのは積極的に消します。
残すのはコメントでリビジョン書いとくくらい。

人力でバージョン管理やってるところって、絶対「財産」を無駄にしてるよな。
一世代くらい前ならともかく、数世代まえになると、コメントアウトでコードを
残すなんてことをやってるところじゃ、復元不可能。

つ CVS >>16

バージョンにブランチ（枝）すると、複数の分岐で開発出来るお。
で、良いやつを本枝にマージすると完璧。

>>6
バックアップ取れば良いじゃん

マジックナンバーって何だっけ
度忘れちゃた

ここはツールでソース管理されてないインターネッツですね。

お前ら、あ、愛してる。だからﾊﾞｰｼﾞｮﾝ管理ｋｗｓｋ教えて。

Cで、NULLと0と'\0'の使い分けができてないやつとか。

文字列のクリアで
memset(str, NULL, sizeof str);
みたいな。
(memset()使ってるってのもあれだし。本人は手間をかけて安全なコーディングを
してると思ってるっぽいけど)

>>24
NULLは意味的に間違いとしても、
memsetが何でダメ?

組み込み系ソースのfor文で回して0にしてたり、
メモリのアロケートやり直しで初期化してるつもり（本人から確認）のコードの方が驚いた。

>>25
初期化子使えとかそういうことでは？

>>25
strcpy(hoge, "初期値"); か hoge[0] = '\0'; で十分なところを、
memset()で全部クリアしてるってこと。

>memset()で全部クリアしてるってこと。

これ、C++とかじゃなくて、C言語とかだと結構セキュアに動作するお。

C言語の開発中バグでメモリ破壊したときとかに。

ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ・・・が見れなくなるのでさびしい

>ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ・・・
って難だっけ？

メモリカードとかはFFで初期化したような。

Cの文字列を入れる変数で
hoge[0] = '\0'
ならバグるところを
memset()
ならバグらないって状況を、セキュアと呼んでいいのだろうか。。。

28自体もスレタイに沿ったコードの例のつもりで書き込んだということだろう。

>>31
開発中にアプリがどっかーんといくときに、
ＯＳ吹っ飛ばさない、その方がボロクソデバッガでも変数とか把握しやすい、ということ。

Win16時代にC言語プログラミングしてない若造には分からんこと。

そこでOpenBSDですよ。

ちなみにC++ではヌルターミネイト自体古いというか、もうやらんじゃん。

＞hoge[0] = '\0'
を評価しても、Ｃ言語ではふつー、Ｃ＋＋ではダサダサ。

perl で

`rm $foo`;
`mv $bar $bar.bak`;

とか。

>>33
バグが表面化しないのくらべたら、OSごとドッカーンといくほうがかなりマシというか。

どうも37は分かってないようだが、C言語はC++と違って大局的な書き方じゃないから、
OSがドッカーンと逝かない（普通逝かない。Win16以前しかそんな話無いし、汎用機がドッかｰﾝと逝ったら大騒ぎで該当ツール使用禁止令も出る）アプリをバグ無しアプリと言うんだが。

不毛だなぁ

>>33
安全策をとるならば、文字列の終了位置であるはずのところに
'\0'を上書きしとくべきなのでは？

>>40
　>>35

で、C言語時代にはＯＳとかアプリ実行環境が不安定にならないことに最重点を置いたから、
ヌルターミネイトを大目にとmemsetとした。

>>1
ヘタなスレ立てだな・・・
最近立つのはゴミスレばっかり

if (hoge != false)
なんてのを見つけると、そこから先を読むのが厭になる。

>>40
それをしないのが、下手糞が下手糞たる所以。

たとえば
(1)バグがある
(2)コードを追いかけたりしない
(3)とりあえず文字列をmemset()で0クリアしてみよう
(4)直った!
これは直ったわけじゃなくて、表面化しなくなっただけ。
こういうことをしてる新人がいたら、デバッグをやり直させるでしょ。

memset()で前もってクリアしておこうってのは、いきなり(4)の状態になる
可能性があるわけで、バグの存在さえ認識できない可能性がある。

そういえば、Ｃ言語時代は構造体をmemsetってもう決まりだったお。
charも安心、intとかfloatもintelでは０になるし、実は他CPUでも０になる。
どのソース見てもmemsetの嵐だお。

45=しつこい

どちらにせよ、
＞hoge[0] = '\0'
おまいはＣ＋＋時代のダサダサﾌ用人間。

int foo[10];
for(int i = 1 ; i < 11 ; i++)
foo[i - 1] = 0;

>>41
いや、それは違うだろ。

>>45
＞memset()で前もってクリアしておこうってのは、いきなり(4)の状態になる
＞可能性があるわけで、バグの存在さえ認識できない可能性がある。

Ｃ言語時代にはこれを目指してmemset使われまくり（当時の慣習）でしたが、何か？

正直、今の時代において何の役にもたたない昔話はどうでもいい。

49=stringを知らない無知を無知と分からない

>>44
if (hoge == true)
に比べたらまだましではなかろうか。

>>51
なら、
＞hoge[0] = '\0'
こんなコードを書く香具師は頃してしまえ。

こちらのスレへどうぞ
http://pc8.2ch.net/test/read.cgi/tech/1127283408/

>>53
同意。

trueは不定、falseは0固定だもんね。

C言語コードは構造体と初期化の嵐だから、
「C言語＋memset」
「C++＋stringでヌル無視」
の組み合わせが良い。

＞hoge[0] = '\0'
↑
こいつはこれだ！ >>ttp://pc8.2ch.net/test/read.cgi/tech/1127283408/

>>50
OSのカーネルとか、データベースとか信頼性が要求されるコードでは、
そういうの見たことないなぁ。

瞬時に糞とわかるコード
・mainメソッドの先頭３０行くらい全部変数宣言だけになっているとき

>>50
それは君の周りだけでは？

>>58
　>>60

＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
↑
こいつヴぁか杉！！！！！！！！！！！！！！！！！！！！！！！！！！！！

そっとしといてやれよ。
きっと、デスマーチが当たり前な悲惨な現場で育ったんだよ。

日中こんなスレに常駐して暇潰してる奴の生産性をどうにかしてください。

>>62
そういう暴れ方しても、言ってることに説得力でないよ。

現代においてあんなことを言う56のコードも下手なんだろうなぁ。

説得力が無くて結構。

至上最強の恥ずかしさ： hoge[0] = '\0'

C言語解説本の出だしでしか見た事無いぉ。

>>66
現代においてもtrueが不定という定義は普遍ですが、何か？

逆に古い実装のtrueがdefineされてる場合にのみ正常動作。

>>68
俺はC++のつもりで話をしたが、どうやらお前はC++とは別の言語の話のようだ。
すまんな、俺の勘違いで。

＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
＞hoge[0] = '\0'
↑
氏んだ方がいいよwwwwwwww

69=至上最低のプログラマ二人目

C言語ならTRUEがdefineされてるから正常動作だが、
C++言語なら言語仕様のtrueだから値がますます不定になる。

>>44 >>53 >>71
？
あえて聞きたいのだが、不定でも別に問題ないんじゃないか？
例えば↓のようなコードが合っても、
if( b==true ) ;
代入時でどうせ↓のようにしてるんだから問題ないんじゃないの？
bool b = true;

↓コレだったらまあわかるんだけど。
int i = 1;
if( i == true );

↓この記述が悪いっていってる意味があまりわからん。
if( b==true ) ;

bool b = true;
int *p = reinterpret_cast<bool*>(&b);

こうでもすれば*pの値はたしかに不定だろうが、static_cast<int>(true)は1だ。
JIS X3014:2003の4.7の4節。

>>72
>代入時でどうせ↓のようにしてるんだから問題ないんじゃないの？
>bool b = true;

Win32APIをご存知無い？
返す値がBOOLでありながら不定（実体はハンドル。メモリポインタ）だお。

>>74
？
それはWin32APIのインターフェースでTRUEとFALSEという定数で比較するようにすべきだから、
C++のtrueとfalseで比較するほうが間違ってるんじゃないか？

>>72
そういえば、mem〜、str〜系の関数も失敗で０を返しても、
成功はポインタ返してtrueの代わりにしてるね。

>>75
現実は真偽値の定義をとって、trueの場合は０以外の不定値をふつーに返す関数が溢れながら、
それを知らずにとは。

>代入時でどうせ↓のようにしてるんだから問題ないんじゃないの？
>bool b = true;

↑
こいつプロジェクトメンバから外せ。

あるぇ？BOOLの比較ってTRUEかFALSEでいいんだっけ？
Win32APIなんて懐かしいものはもう忘れた orz

>>78
TRUE比較はダメ。

こういうスレって必死に揚げ足取ったり重箱の済みつついたりに終始して
得る物がないんだよな。

80=常識を知らず叩かれた香具師

おまえら、さっさとバグつぶせよ

>>77
＞現実は真偽値の定義をとって、trueの場合は０以外の不定値をふつーに返す関数が溢れながら、
そういう戻り値は大概intだろ？boolのtrue、falseと比較する意味がわからん。
それにそういう関数の仕様を読めば何と比較するか書いてあるだろ。trueとfalse以外で比較することが。
それをtrueとfalseで比較するのか君は。

TRUE,FALSE,true,falseの区別がむつかしいなら
C++なんて窓から投げ捨ててCやれば良いじゃん

>>82
戦死にもたまには休息が必要だ

バグと戦い2chでも戦い…
大変だねPGって

すげー伸びてるなあ
クソスレかと思ったら良スレだったんだな

>>83
おまい、超無知杉。

char *pc = getPt();

if (!pc) throw exception("Error");

とかやるじゃん。

char *pc = getPt();

if (pc = false) throw exception("Error");
はおｋでも、

if (pc != true) throw exception("Error");
はダメだろ。

スレを読まずにカキコするが、

おまえら　こういう話　大好きだよな

どっちにしても、bool値と比較してる時点で「ヘタだなぁ」と思うよ

>>88
いや、あの、それくらいは知ってるんだが…。

俺が言いたいのは↓のような間違ったtrue、falseの使い方を例示もせず
char *pc = getPt();
if (pc==false) throw exception("Error");

↓のコードだけ例示して==false使う奴はアホとかいってるのがよくないといいたいの。
if (pc==false) throw exception("Error");

>>87
もしそう見えてしまうならまともな書籍買ってきて目を通したほうがいい。
こんな糞スレにいるより10倍の量と精度の知識が身につくだろう。

>>92=ゴミ
結論。
おまいの読み間違い。
>>44 >>53 >>56
の流れだから、TRUEとの比較はダメの流れ。

89でも同じ文章を書いている。

>>89
いや、ポインタをfalseで比較するのは駄目かと・・・。NULLで比較すべきかと・・・。

その元のgetPt関数だって、エラーの場合は戻り値でreturn NULL;とか書いてるはずだろ。
return false;じゃ型の不一致でコンパイルエラーだとおもうぞ。

必死に反論してる奴見てると笑える

いや、true の値なんかどうでもいいんだが。
hoge が真理値のつもりなら、なんでいちいち等価演算子
使うんだ？っつー話。

>>95

いや、Win32/C言語の全盛期はFALSEがDEFINEされてて、

if (XXX != FALSE) { //ハンドルが無効で無い
　//処理
}

と説明本でも書かれてる。

>>98
いつの時代の話だよ。 つーか氏ねよ

>>44
おー、そういうこと？例えば↓こうとか？
int a=100;
int condition = (a==100);
if( condition == false ) ;
それなら確かに。
==とかの比較演算子はたしか偽の場合０で真の場合１でいいんだっけ？
それをtrue、falseではたしかにまずいな。

やべ>>97だった。

>>98
まともな参考書読めということでは？

>>98
それはWin32APIのHANDLEが戻り値である関数の正常異常比較方法の話でそ？
>>89はchar*をtrueやfalseで比較してるので変ですよといってるのです。

>>103
89の内容はWin32APIのつもりで書きます田。

if (true == true)
else if (true == false)
else if (true != false)
else if (true != true)

素人が流れ読まずにｶｷｺ
>>88とかやってしまいそうなんだけど、やっぱりNULLで比較するべきなん？

そらそうだ

>>106
Ｃ言語なら88推奨。
C++ならNULL比較推奨。

C++でNULL比較はやめとけ。

やってることは、このポインタがNULLかどうか、だから
どっちでも NULL 比較だろ

ところでさぁ、Javaは対象外？

>>111
いんじゃねーの？俺Javaのこと書いたし。

ﾁﾞｬｳﾞｧはC++のパチモンだから取り上げる必要無いんでね？

ぱっと見て「ヘタだなぁ」と思う釣り

Javaは誰が見ても自明だから。
仕様がシンプルで良い言語だから論争にならないんじゃまいか？

#メイン
int main(void) {

これとかこれ

nCount += 2; #カウントを2増やす

意味のないコメント

i++; //iをインクリメント

init_globals()とかいう関数を見かけたとき。

>>116
貴様、スクリプト言語を主流に使っているな！？
コメントが#になってまつ。

ところで logical xor のつもりで
bool変数２つを !x != !y とやるのはアリ？

ある関数ではFileName
またある関数ではfilename
さらに他の関数ではFilename

大文字小文字はある程度は統一しようぜ

>init_globals()とかいう関数を見かけたとき。

初期化処理を毎回コピペしてるよりマシ。

綺麗なコードを目指したらキリねえよな
精神的な健康とのトレードオフですよ。

さっきのtrueとfalseの話って何だったの？
ついていけなかったorz
誰か要約してください

あなたのように理解していない人が
適当に使ってしまうから困るという話です

>>124
最初に>>56>>66-73辺りでtuueが1か不定かという話があった。

そのうち>>72-から論理値をtrueやfalseと比較するのはよいかということに移り、
C++のbool/true/falseとWinAPIのBOOL/TRUE/FALSEとポインタ/NULLがごっちゃに。
全体的にtrueやfalseと比較することを肯定する方の書き込みがあると叩くの繰り返し。

おまえら小手先の話をごちゃごちゃする前に上司なり会社なりに
認められて役職のひとつでももらってから偉そうなこと言えよ

CでTRUEとかFALSEとか、怪しげな値を返すライブラリがあったら、
しっかり比較したほうがいいよ。

if (hoge() == TRUE) とか。

>>127
FALSEと比較しる！

ifとかwhileの括弧をくっつけて書いて、括弧の内側を空けてるとか。
二項演算子をくっつけて書くとか。

if( x==10 ) {...

こんなの見ると、うへーとなる。

>>128
TRUE 0
FALSE -1
みたいな変態ライブラリとかどうすんの?

unixのシステムコールに感化されてるのか、成功で0を返す、
エラーはマイナスで返すとか変な信条のやつがたまにいる。

>>130
> TRUE 0
> FALSE -1
> みたいな変態ライブラリとかどうすんの?

変態ライブラリはとりあえず放って置いて、

> unixのシステムコールに感化されてるのか、成功で0を返す、
> エラーはマイナスで返すとか変な信条のやつがたまにいる。

これは、TRUEと比較すべきという根拠にはならない。

昔のC/C++にbool型（trueかfalseだけが入る）が無かったのが諸悪の根源だな。

if （ 真偽値　） 以外はコンパイルエラーになればいい。

>>132
C++も昔はboolなかったの?

C++はCとの互換上仕方がないと思う。
つまりCが諸悪の根源。
Cなんてなくなればいいのに

C99では intを_Boolに変換するとどうなるんだろう。

>>134
なかったよ

QACで引っかからないコード。
MISRA-Cで引っかからないコード。

ちなみに言い出しっぺの>>44はＣだとは言ってないから
Ｃ＃だったら話が違ってくるような。

まあでもif (hoge != false)とかif (hoge == true)とか書くなら
if (isHoge)でいいだろとは思う。

もし
(hoge == true)
の評価がtrue だった場合、以下を実行する。


ということだよな

if ((hoge == true) == true)

そもそもbool型を評価するのに
true false と比較しなきゃいけないケースってあるの？

trueとfalse以外でどうやって比較するの？

宇宙空間のような密度の低いスレだ

ザルで水をすくう、とはこの事か。

比較した結果がtru,falseなわけで、もともとtrue,falseなら比較する必要は無い

ようするに比較しなくても

bool b;

if(b)
{
//処理
}

って書けばいいってこと？

こう書けばって強制できるもんじゃなく、
プログラムってのは記述性によって、
人間に近づくもの。

自分だってこう書く。
＞if(b)
＞if(!b)

でも、初心者が、
＞if(b != false)
と書くのは禁止出来ない。

しかしだな、
＞if(b == true)
は禁止。

a( ... ){
}

は

a( ... )
{
}

に直すべき？
学生のころ見た本で前者のクセがついてしまった。

あ、a の前に型書いてない・・・if とか for でいいや。

> でも、初心者が、
> ＞if(b != false)
> と書くのは禁止出来ない。

それはまずいね。

bがboolなら(b != false)もまた同じくboolなんだから。
boolのbに対して != false の比較が必要なら、
(b != false)に対しても同じく必要。
だから
if((b != false) != false)
と書きたいところだが、これでもまだ足りない。
なぜなら((b != false) != false)もまたboolだからだ。

もし
if(b) // (1)
よりも、
if(b != false) // (2)
の方が良いならば、
if(((((b != false) != false) != false) != false) != false) // (3)
こちらの方がもっと良いということになる。
もちろん
if(x == y)
より
if((x == y) != false)
の方が良いだろう。

誰が賛成できるかな。
もし(3)を禁止するなら、同じ理由で(2)は禁止になる。

なんかﾜﾛﾀ

なんて頭の悪い奴だ

>>148
> しかしだな、
> ＞if(b == true)
> は禁止。

これは意味のあるコードだから禁止できない。
bがboolではなく、3値の状態 (false,true,unknown?) を確保する
クラスオブジェクトに変更となったとき、
bool operator==(bool)メソッドを用意しておけば、
「if(b == true)」記述は有意義だからな。

>>149
オレは画面が80x24じゃなくなって行を多く表示できるようになってからは
後者のほうだな。Windows3.1の頃のプログラムの本からの影響だが。

>>155
俺はエディタを横長画面で使うから前者だな。

ま、スレタイとは関係ないけどな

>>154
＞bがboolではなく、3値の状態 (false,true,unknown?) を確保する

トリッキーなネーミング超禁止！！！！！！！！！

３つの状態なら、cond_false,cond_true,cond_unknownくらいにしとけ。
boolに新たな値を足すのは超販促ワザ。

Rubyの$VERBOSEはtrue, false, nilで意味が変わってくるんだよな

>>159
true, false, nilの状態確保は良くあることね

Ｒｕｂｙ禁止！

3つの状態を保有するclassの定義をしてみろよ。

>>161
なんでRubyってこうやって好き嫌いが激しく分かれるんだよ。
Perlは「好きだけどあまり使わない」「嫌いだけど使う」って
曖昧な奴がいっぱいいるじゃないか。Rubyへの好き嫌いは明確過ぎるぞ。

別に好きでも嫌いでもないけど

>>154 は
ぱっと見て「頼むからお前は何もするな」と思うコード

真偽値って２種類であるところに意味があると思ふ。

DBのカラムだとNULLが絡んでくるの分かるけど、
逆に真偽値カラムは初期値入れてNULL無くせ！、と。

C#のboolもnullable出来るしな。
もはや3値は時代の趨勢といわざるを得ない。

＞C#

カス

bool* b;
でいいじゃん。

Ｃ丼使わない理由が一つ増えた。

＞C#のboolもnullable出来るしな。
既存のＣ／Ｃ＋＋ライブラリを異色作業に困るわこれ。
過去のライブラリは使えないは、移植作業を邪魔するわで、ちょーさいあく。

↑ぱっと見て「バカだなぁ」と思うレス

ソースとソースの間にコメントが多すぎて流れが読めない。

インデントがメチャクチャのソースとか、どういう経緯でそうなったのかわからん。
4桁と8桁がまじってるのとかはともかく、数行だけ3桁が混じってるとか。

>>149
それは上手い下手じゃないから好きなほうでいいんじゃない？
俺は会社ではプロジェクトのルールに従ってる
家ではネットで拾ってきた各言語の一般的なルールに従ってる

>>173
・別人が書いた
・適当なところからコピペした

はい。いいえ。未入力。

普通は、NULLも入れられるboolを使うな。

>>170
Ｃ＋＋で書いたようなライブラリをＣ＃で使う気にはなれんがな。

アセンブラからＣ／Ｃ＋＋に移植するとコードが簡潔にできるように、
Ｃ／Ｃ＋＋からＣ＃へ移植するとかなりコードが簡潔に書ける。

Ｃ／Ｃ＋＋のコードをそのままＣ＃でコンパイルだなんて、
Ｃでインラインアセンブラ使って書いてるようなもんだ。

>>176の最後
「使うな」が「使ってはダメだ」と禁止しているようにも「使うよね」と自分の意見を語っているようにも解釈できる
文脈で多態するような単語は使うな

なんかぱっと見て、初心者が変なプログラミングスタイル覚えそうなスレになってきたな。
ここで言ってるスタイルはあんま参考にしないほうがいいかも。

まともなソースや本を見て、判断すればいいだろ。
会社の先輩のソースとかは、参考にしないように。

会社の先輩が書いた本なんだが？

>>181
まともな本なの?

python教に入ればカッコやインデント論争から楽になれるぞ

インデント論争したいやつには
「自分用のインデントプログラム作れば？」でおｋ

mallocしておいてfreeしないヘタくそなコードをどうにかしてください。

>>185
つりかよ。

freeしなくても良いという言い訳どぞー
↓

昔、某所で延々とfree()論争があった。
googleで見れるかな?

まともなインデントに直してやったのに文句いわれたよ

>>188
freeする必要がないのと同様、論争を見る必要もない。

fclose()も状況によっては必要ないな。

C++でboost::scoped_ptr始めスマートポインタ使ったり、std::vectorでいいだろと思う。

スペースを100個入れるのに、

/*　　　　　0123456789 */
strcat(str, "　　　　　"); /* 1 */
strcat(str, "　　　　　"); /* 2 */
　：
strcat(str, "　　　　　"); /* 9 */
strcat(str, "　　　　　"); /* 10 */

関数名に hogeFunc()、
変数名、構造体にhogeInfo、hogeData

仕様書をそのまま書き下したようなコードは下手だなぁと思う。
まじめにすべて書き下してるから、一関数1000行とかいってしまってたり。

>>193　ですごいと思ったのは、手抜きでペーストを10回、パパパとやったのではなくて、
わざわざ回数や桁数をコメントで入れてるから、本人は丁寧にやってるつもりなんだろうな、って所。

>>193
これはひどい（わらい
memset(str, ' ', 100);
str[100] = '\0';
２行で書けるじゃん。

あとstrcatってあんまり使って欲しく無い。
パフォーマンス悪そう。

>>195
それは・・・ところによっては優秀なコードと判断される・・・
１対１に対応していないと気に入らない人って
未だにいるんだな、これが

にしても徹頭徹尾誰の役にも立ちそうにない雑談スレだな。
厨房のまとまったコード晒して添削した方がよっぽど参考になるけど
そこまでして実のあるスレにしようと思う奴なんて誰もいないしな。

おまえがやれ

人より一段上から発言してみたい年頃。

>>197
sprintf()なら一行

俺の役には立ってるから心配するな

>>170
C#のboolとnullable boolは別物

class
{
int a,b,c,d,e,f,g;

void setABCDEFG(int a,int b,int c,int d,int e,int f,int g)
{
this->a = a;
this->b = b;
this->c = c;
this->d = d;
this->e = e;
this->f = f;
this->g = g;



}

};

char kore-nanikana =
"　　��"
"�凵寐�"
"　▽";

// ヒント： 太陽じゃない

質問です。
マイナスってくっつけます？

i = j - 4;
と書いているなら、
k = - 1;
とするべきでようか？

--はどうするんだ？

>>208
単項演算子のマイナスは、くっつける。
k = -1;
それ以外は、くっつけない。

"-1"なら数値の-1だとわかるが、
"- 1"なら何か書き忘れたのかと思う。

return (a*b+c-sizeof(d))+1;

こういうコード書く奴は反省正座
演算子は密着させるなって何度言ったら(ry

オレは | 演算子以外は基本的にスペース無しで記述するけど。

というか、こんなの好み以外なんでもないだろ。
コーディング規約で既定されてるのに従ってない、とかじゃない限り、
反省正座とか、意味不明な否定をされるいわれはない。

いや、演算子をくっつけて書くなんて、かなりキモイ。

演算子がくっ付いたコードは死ぬほど読みにくいんだよ
そういうコード書く奴に限って213みたいに自己中な逆ギレするから困る

thread.level.down();

↑読みやすくしてやる
thread　.　level　.　down　()　;

そんなに読み難いと思うんなら、自分用の整形ソフトを作ればいいじゃないか

なぜそんな事を言う前にそれをやらないんだ？
それともそんな簡単な事も出来ないのに、そんな大口叩いてるのか？

だったら、すみません。私の読み易いように整形して下さいと、頭を垂れろ。
ホワイトデーにはまともな貢物の一つもよこしやがれ

二項演算子をくっつけて書くとか、カンマの後ろを空けないとか、
制御文のカッコをくっつけるとか、ぱっと見た目、へたくそに
見えるね。

妙に必死な腐女子SEが降臨してるようだな
誰か早く回収するんだ

#include<hoge.h>

けっこう売れてるらしい某初心者向けの本は、
↑みたいに、<>をくっつけて書いてるらいいじゃん。(見てないけど)
ほんとみに、こういうのやめて欲しい。

↑実害ないのに大騒ぎするバカ

ごちゃごちゃ言ってないでおとなしくK&Rに従っとけ。

顔の整形しとけ

「動けばいいだろ」って、汚いソース書いてるやつのソースはまともに動いてないね。

>>221
それがぱっと見てヘタだと思うコードなのか？
人による好みの問題で、その人がうまいかヘタかは全然関係ない気が駿河。

width = foo + 1 +  + bar;
前に書いた俺のコードにこんな感じのものがあった。
間に何があったのか思い出せない。

幸いなのは自分が勉強に作ったものだから外への影響はないということ

>>225
コーディングがきれいでも、汚いソースなんて腐るほどあるからなぁ。

>>215
所詮それも慣れの問題。好みでしかない。

オレは逆にスペースがあるとキモイいもの。
間が抜けた、マヌケコードに見える。

しかし、それを他人の力量の判断材料にはしない。
所詮宗教問題だからだ。

そんなことも分かんない奴の力量は低いと判断するけどね。

>>226
いや、そういうコードを書く人間が、まともな本やソース、環境で勉強してるとは思えない。

むしろ、変な書き方をして、本人だけはいい書き方をしてると固く信じてるってパターンじゃ
ないかと予想する。
ソース開いて、そういうコードが最初に目に入ったら。

>>229
> 所詮宗教問題だからだ。

スキルの高い人たちの間でも、意見の分かれるスタイルの問題はあるけど、
二項演算子の両側とかカンマの後ろを空けるとか、そのあたりで意見が分かれてるのは
見たことない。

>>230
「まとも」が何かによるけどな。
コーディングスタイルの流行なんて、すぐ変わるものだし。

エラー処理のコードが書いてないソースほど演算子がくっついていたり
if(){
}
みたいなキモいコードブロック書いてるよな。
タブの代わりにスペース2個とか。視ねって。

>>232
#includeの後にスペース入れるか入れないかなんて、流行すたりはないよ。

標準的なスタイルなんて、Unix/Windows/Mac/組み込み etc..で変わるもんだしな。

こういう瑣末なところにのみ執着する奴らはダメだな

astyle　でも使えばいいだけの事

>>231
そらどうでもいいからな。

なんで

#include<hoge.h>

はくっつけたらダメなの？

逆に、離したら何がいいの？

論理的に説明できずに、感覚的にキモイとか言ったら低脳認定。

>>233
エラー処理かかないのと、スタイルは関係ない。
ただの言いがかりをつけるやつは人としてダメだな

>>238
いや、議論するまでもなく意見が一致するから。
二項演算子の両脇を詰めろってヤツが混じってたら、かなり紛糾すると思うけど。

>>236
瑣末だと思ってるあたりがダメ。

>>241
自分のスタイルを他人に強要して、詰めろ、というバカが居たらそうだろう。

同様に、自分のスタイルを他人に強要して、空けろ、とかいうバカが居ても紛糾するよ。

このスレのように。

>>242
これが瑣末だと思えない時点で、プログラマ失格。

多分姑になるといいよ。嫁いびり上手そう。

ところでこういうスレだと誰か一人は
「Cプログラミング診断室」を引用するもんだけど
もうそういう時代じゃない？

だから、好きなスタイルにツールで翻訳すりゃいいじゃない。

そういう機械で出来るような部分に価値を見出してもしょうがないぞ

スタイルは統一することに価値はあっても
特定のスタイルに固執することに価値はない。
それがわからないのは趣味グラマだけだろう。

オプソの世界では原作者への感謝と義を通すため、
元ソースのコーディングスタイル（変数名等の付け方も含む）を
踏襲するのが普通だと思うんだが…。（つまり、スタイルを気にしてない）

職業PGだって、規定があればそれに従うのみだろ…。

ここでキモイとかいってるやつは行数を増やすことだけに熱心な
アホ会社に勤めるカス職業PGか？

行数が増えたっていいじゃねーか。
べつに行数で金取るわけじゃねぇし。
ま、行数カウントして試験計画に反映することは良くあるけどな。

>>243
> 自分のスタイルを他人に強要して、詰めろ、というバカが居たらそうだろう。

数人で作業をやるとか、コーディングルールを決めるような状況ならある程度「強要」はあるだろ。
そういう状況でも、二項演算子の両脇を開けるとか、カンマの後ろを空けるとかは
常識のレベルだから、紛糾なんてない。
あまりに常識過ぎて、言及しないこともあるけど。
(まともなところならね)

だいたいスタイルを強要するしないって話じゃなくて、
単にまともなプログラマーなら、こう書くって話だし。

命名規則なら決める意味はあると思うけど、
そもそもコーディングスタイル決める意味ある？

うわぁ、そっから話をしなきゃならんのか・・・

結論: indent使え

おまえらは人の読まれても恥ずかしくない自信があるコードを書くためにどんなことに気をつけている？

訂正：おまえらは人の読まれても恥ずかしくないコードを書くために、どんなことに気をつけている？

>>256
訂正：おまえらは人に読まれても恥ずかしくないコードを書くために、どんなことに気をつけている？

人の

春真っ盛り

コーディングスタイル云々は、>254で全て解決する結論でましたので、無しでいきましょう。

>>255
publicな関数やクラスは、doxygen相当のツールで拾えるドキュメントを必ず記述する。
privateも自明なの以外はつける。

関数内にコメントは記さない。
コメントがなくても自明なコードとなるようにする。

訂正：おまえらは人の読まれると恥ずかしいコードを隠すために、どんなことに気をつけている？

>>261
二重に意味わかんね。
ソースを隠したところでasmでは（時間かかるけど）バレバレだしな。

>>248
>　元ソースのコーディングスタイル（変数名等の付け方も含む）を
> 踏襲するのが普通だと思うんだが…。（つまり、スタイルを気にしてない）

それはまともなスタイルだからだろ。
二項演算子の両端を空けないポリシーで、世間で評価されてるオープンソース
のプロダクツとかある?

まったくないな。

そもそもオープンソースの作者ってのは変質者が多い。
露出狂とでも言うか

なかにはオープンソースを餌にしてこんなオナニーを見せて喜ぶ奴もいる
#define BEGIN {
#define END }

ホントあほらしい議論。
　色分けしてくれるエディタ使えば、演算子の前後に空白があるだの無いだの気にする必要もない事だろ

>>263
君はgrepを知らんのか。それともオプソのソースが手元に一切ないのか。
それくらい調べればすぐにわかるだろう。

>>265
議論というか、空白無いとダメなんだもん！君が喚いてるだけ。
皆、どうでもいいだろ、どうしても嫌ならツール使えよ、とやさしく諭してあげてる。

まあ読み合わせするのにいちいち印刷して配る所もあるんだろ

もうコーディングスタイルなんていいじゃん
それで「ヘタだなぁ」って思うやつが結構いるということは分かったから

>>266
そんなことは、演算子の両脇を詰めるのがまともだと思ってる人に言ってください。

>>269
けっこう多いっていうか、まともな人は、ほぼ全員へただなぁ、素人っぽいなあって思うんじゃない?

>>267
> どうしても嫌ならツール使えよ、

変な書き方してる連中って、ツールも使ってないってことだろ?

>>269
そうなの？　俺は変だなとは思うけどヘタとは思わない
同じソース中でバラバラだったら素人っぽいと思うけど

日本人でまともなコード書く人って少ないよな。

演算子の両側を詰める人のもたれる印象
・へた
・素人
・変

てか下手な書き方して読みづらいっていわれてるのに
何で平気でツール使えとか言えるのかがわからん。
責任感って物がないのか？

てか単項演算子の両端をあけないのって小さくて単純なプログラムしか組んだこと無いからだろ。
そりゃたしかに
n = n + m;　とか
for(n = 0 ; n < MAX; n++)
みたいなんじゃぁ間抜けにみえるかもな。

>>270
オレは２項演算子の両脇を詰めるのが自分のスタイルだと言ってるだけで、
まともとかとかそういう話はしてない。

仕事でコーディング規約でそうあるならそれに従うが、
そうでない以上、こんなのは好みの差にすぎない。ギャーギャー騒ぐことではない。

つーか、「まともな人」とか笑わせんなよ。
論理的な理由も示せず、感覚的にキモイって理由で
批判するなんて、まともな人間のすることじゃない。

>>263
nnnesterJは元が*nix系の書き方なのに、
途中で変数名がM$お得意のb〜とか、i〜とか入ってきて
ヘタとかじゃなく非常識極まりないものになってる。
こんな状態になると、演算子で詰めるかどうかの議論なんてアホらしくなってくる。

自分のやり方以外の一切を許容できないのはただのアスペだろ。
なるべく一緒に仕事をしたくない類の人間だな。

>>276
コーディングスタイル以前に、まともな知識付けた方がいいのでは？

演算子を詰めて書くことに関して
延々とファビョってるのって213だろ
これだから腐女子は嫌なんだ

>>271
お前の意見って、全部根拠ナシのただの主観だよなぁ。
そういう意見つて、そっくりそのまま逆に言い替えれるんだよなぁ。



空白があろうがなかろうがどうでもいい人って、けっこう多いっていうか、
まともな人は、ほぼ全員どうでもいいなぁって思うんじゃない？

こんな空白無いと「へただなぁ、素人っぽいなあって思う」人をへただなぁ、素人っぽいなあって思うんじゃない?

sizeof (char)

むしろ「どうでもいい」とか「人にどうこう言うな」みたいなコトを言いながら、
書き込みせずにいられない人のほうがアレなんじゃないの?

とりあえず何が何でも上司に逆らってでもルールを破ってでも
詰めて書く派はいないんだろ。
あとは何が何でもあけないと気がすまない派という痛い存在が
いるかどうかでないの。
そこんとこどうなの？

>>282
いや、世間でそれなりに評価される本とか、プロダクツのコードで、
二項演算子の両脇を詰めてかいてるのってある?

とりあえず、最近見た「ヘタだなぁ」と思うコード
>>276
> n = n + m;

>>286
今見てる、「Perlクックブック」は、
大体においてPerlのガイドラインの通り、演算子は空けているが、
空けていないところもある。

ま、重箱の隅をつつくなってことじゃね？

>>286
>>266

まぁいいか。手元にあったオープンソース見てみた。
例えばこれは演算子の空白の数はアバウトな感じだけど。
http://www.codercorner.com/Opcode.htm

お前がなんて言いそうか大体想像つくなぁ。

もう止めろよお前ら
実に禿げな議論だ

議論というか、何が何でもあけないと気がすまない派という痛い存在が騒いでるだけ。

>>276
だからさ、読み辛いのは、それを読んでるオノレの問題だろ？
少なくともオレの問題じゃない。
オレはカラーで表示されるエディタで見てるから何の問題もないんだからさ。

オノレが読みづらいならそれは自分で解決すべき問題だ。
なんで責任感が無いなんてわけの判らん発言になるんだ？

>>289
ああ、それは知らなかった。

コーディングスタイルなんて美的センスの問題だから決着がつくわけない。
どっちかが妥協しないとな。

ほんとに読み辛いと思うのは

http://pc8.2ch.net/test/read.cgi/tech/1141740363/35
この35からの質問者のような　書き方だ。

＞
ある角度αで回転した四角形があります
左上角を(x,y)とします
上辺の中心を(x',y')とします
この中心をドラッグし移動するとマウスと上辺は交差する位置を維持します
下辺２点は固定です
この時いまマウスがいる座標を(x'',y'')とします
この座標と交差する上辺の左角の座標を求める計算式を提示してください
-----------------------------
言葉が足りない上、交差する位置　とか謎言葉がちりばめられた文章

まあでも、お客様からの文章からは、こんなものは序の口。
そっから真意を探り出してくるんだぞ。

演算子の左右に空白が無いとかで読み辛いとか、ホント笑っちゃうよ

やっぱり
a*b + c*d
だよなぁ。

>>294
演算子の両側のスペースなんて、その手の宗教論争とは違うだろよ。
「変数名は内容を表すようにつける」とか「サブルーチンは適切な単位に分ける」とか、
そういうレベルの話。

boostもばらばらだけど読みやすいから
スタイルなんかより設計が全てだな
一貫してるMFCやATLの読みにくいこと。

>>297
そうだね。　演算子の両側のスペースなんて
「変数名は内容を表すようにつける」とか「サブルーチンは適切な単位に分ける」とか、
そういうレベルの話とは全く違って、全く意味の無い話だ。

演算子の両側にスペース入れるのは簡単なプログラムを作れば自動で出来るが
前者２つを自動でやるのは、現時点では不可能だし
それが出来るならプログラマなんて不要になってるだろう

「演算子の両側のスペースは宗教論争ではない」教？

>>297
ツールで完全に自動でどうとでもなるものを、それらと同列に？マジかよ。

いいか、
プログラミングというのは >>295のような曖昧かつ漠然としたところから

「内容を適切な単位に分けて明確にしてそれに名前をつける」

という作業をする事であって
少なくとも、演算子の両端に空白を入れる事に必死になる事じゃないんだよ

ツールでどうにでもなるって言ってるのは、上のほうで、人のコード読むんだから、
かってに整形すればいいって言ってるのと同じ思考なんだろうか。。。

>>303
反論があるんなら、モゴモゴ言わずに、ちゃんと意見を言え。

ちんちん付いてるんだろ？　しゃぶるぞ！

>>302
> 少なくとも、演算子の両端に空白を入れる事に必死になる事じゃないんだよ

必死になってやるんじゃなくて、とくに意識しなくても当たり前にやるんだよな。

>>305
読みやすいコードを書くように意識しろよ。

何が何でもあけないと気がすまない派という痛い存在は確実に居るようです。

>>307
逆もまたしかり。

統計では開けてる人が90%で開けて無い人が10%ぐらい

>>308
何が何でもあけないと気がすまない派
と
どうでもいい・気にしてない派
だけどな

本当にどうでもいい人は書き込んでない。

>>305
あなたが意識しなくても入れるというのはあなたの問題。
あなたが人のコードで空白を入れてないのがダメってのもあなたの問題。
そのコードを見て　下手だなと思うのもあなたの問題。

自分の問題をさも他人の問題のようにいわないでくれ

>>310
ちがうでしょ
そういう対比じゃなくて、

何が何でもあけないとダメだとか、責任感が無いとか

それは違うでしょと。

>>309
もっともっと少ないんじゃないの? (まともなのでは)

・何が何でもあける。
・適度にあける。
・何が何でもくっつける。
・どうでもいい。

xを8で割った余りを計算するのに

x %= 8; でも x&=(8-1); でもいいけど x&=7; はチョッと嫌だなとか

10回のループを表現するのに

for(i=0;i<10;i++) ..... でも
for(i=01i<=10;i++) ..... でも いいけど

for( i = 0 ;i <= 9 ; i++ ) ..... はちょっとダメだとかは思うけど


空白が入ってる、入ってないが価値基準ってのはどうかと思うけどね

まだやってんのか。時間の使い方がヘタだなぁ。

あと、3次元ベクトルを処理するコードで

#define _DIM 3 とかヘッダで定義して

for(i=0 ; i < _DIM;i++)...　とか書くの　２とか４にする場合があるなら別だけど

for(i=0 ; i < 3 ; i++)... と　数字の３書いた方が何倍も読み易いのに

756 名前：　[sage] 投稿日：2006/03/11(土) 22:16:28
このプログラムについてprintf下3つが理解できないので、どのような動きを
しているのか、解説をして頂きたいのですが、お願いします。

#include <stdio.h>

char *c[]={
　　　　　"ENTER",
　　　　　"NEW",
　　　　　"POINT",
　　　　　"FIRST"
};
char **cp[]={c+3,c+2,c+1,c};
char ***cpp=cp;
main()
{
　　　　　printf("%s",**++cpp);
　　　　　printf("%s ",*--*++cpp+3);
　　　　　printf("%s",*cpp[-2]+3);
　　　　　printf("%s\n",cpp[-1][-1]+1);
}
出力　　POINTER STEW

>>319
ヘタ以前に人格を疑うな…。
つーか、ポインタの宿題じゃねーの?

>>316
> for(i=01;i<=10;i++) ..... でも いいけど

唐突に8進数でてくるのはどうかと

>>321
ホント色別けしてくれるエディタは有難いね。　昔は２桁の8進数を間違って使ってなかなか気付かなかった

else 節が多いと、なんか主張が弱いというか視点のハッキリしていない人の意見を聞いてるようでイライラする


あと、条件判断で　&& || を同じ行で使うのも、なんか下手っぽい

if( XXX && XXXX) 使うなら

if(XXX )
if(XXXX) と書く方がいい。　 実際、　&& || は良く間違って使われてる。

>>316
> 10回のループを表現するのに

その三つの例は全部ダメだろ。やざとやってんのか?

下手とかそういう問題か？
if( XXX && XXXX){
} else {
}
こう書きたいときは二段ifにするわけにはいかない。

＞&& || は良く間違って使われてる
あまりにレベルが低いのを引き合いに出されてもな。
ああ、そういうスレか

for (i = 10; i; --i) ...

>>316>>318
空白の有無よりも数値の意味を明確するほうが大事だと言いたいのかもしれんが、
統一されてないのはやっぱり問題だと思う。
特に ; の前後の空白が全く統一性がないのがあれだな。

プログラムでも英語の文法に従うとするなら、
句読点の前には空白を入れず後ろには空白を１つ入れることになる。

>>325
　だからそれ1個だけならいいよ。　
　一つの手続き内に　そんなのが沢山あるとか
　ダラダラ　入れ子にして るコードとか

それからチャンスがあるなら 他人のコードで　バグ取りをする時は、　&& || を使ってるとまず疑うといいよ

>>328
&&はifをネストすればいいけど、||はどうしてるの?

>>326　 PICではそんな感じに書かないと最適化が働かないから、必須な場合もあるね

>>327 統一しないとダメな人は、自分でツールに通せばいいじゃない。
　　そんなの変換するの一瞬でしょ？　そんなことに時間を使うのは勿体ないよ

>>330
スタイル統一するのに、時間かかっちゃう人なのか。

330は徹頭徹尾自分の趣味しか話してないわけで。
統一も何もしたことないしする必要も無いんだろ。

>>332
そうだね。
スタイルの話をしてるわけじゃなかった。

>>329
　あんまりそういう事はない。
　仕様書に　　 かまたは　　をワザワザ書いてあれば　|| を使うけど

たとえば、どんな時に || を使う？
大抵は 事前に判断をまとめてしまうとか　case A: case B: と重ねるとかするよ

if(l->m_subTypeType == CTNCT_INT || (l->m_subTypeType == CTNCT_FLOAT && !intOnly))

は、どう書き直すの？

>>327
コボラー？

>>328, >>334
ぱっと見て「ヘタだなぁ」と思う文章

なんか判り辛いね
if (l->m_subTypeType == CTNCT_INT
|| (l->m_subTypeType == CTNCT_FLOAT
　　&& !intOnly))

だったら

switch( l->m_subTypeType ){
case CTNCT_INT :
case CTNCT_FLOAT:
if(　0== intOnly ) ....
}

こんな感じに別けると思うよ 　!　は勘違いしやすいから　自分は0== にしてる。　どっちでもいいけどね

> if(　0== intOnly ) ....
> }

ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!!!

ようするに頭が悪いだけですね

>>334
ふつうに、
if (code == 2 || code == 3)
if (error || out_count > XXX_MAX)
とか。

>>334
値の範囲チェックとか。

>>338
は？意味変わってるし。

ほーら、直感と外れる書き方するからバグ出してるよ。

あと、l->m_subTypeTypeがintじゃなかったら、どうすんの？

if (exp1||exp2
&& exp3)

とか書いてるの見たら俺も一言言いたくなるが、そうでないならどうでもいいだろ。
そんなのプログラムの価値の1%も左右しない。

>>336
いや、全然。

K&Rはなぜあんなスタイルなのかと考えた結果、
英語の文法に準拠して書いたのだろうと思い至っただけのことだが。

例えば、コンマ、セミコロンの前には空白を入れず後ろに入れる点とか、
括弧の内側には空白は入れない点とか・・・。

妄想かよ。

>>341
そんなコードホントに書いてるの？　ミスの元だよ。

1行目の　if (code == 2 || code == 3) 　は
これなら即値を書いてるから後で変更もないし、このままでもいいと思うよ
>>338のようにcase 使わないかもしれないね

まさか if( (code & -2) ==2　）　とかはさすがに書かないな


2行目は

　error || out_count > XXX_MAX
　これはたぶんエラーをまとめているのだろうから、エラーとして一つのフラグにするべきだよ

>>347
偉そうに言ってるけど、お前338でバグ出してるわけで。

ミスの元なのはどっちやら。

日本語ヘタだなぁ。

>>343
ああゴメン。　読み間違ってたよ。

これなら　　m_subTypeType　　にもう一つ 増やすと思うよ。

　CTNCT_INT
　CTNCT_FLOAT
　CTNCT_OnlyFLOAT

として　事前に intOnlyで ３つに別ける

>>350
iniOnlyは見た目通り単なるローカル変数で、一緒に出来るもんじゃないけど。

あと、intじゃなかったらどうすんの？答えろよ。

>>348
はは、だからオレは|| && は使わないの。　
ましてやネストなんてしないわけ

だからミスするんじゃないか。

なんで仕様変えてるん？

>>352
バグの元だからmallocとか使わないという人みたい。

>>351

だから、チャント仕様を書いてくれよ。
どういう時に || を使うの？　って聞いて、コード直せってのは違うだろ？

こんなコードは、オレは書かないんだから判らないんだよ。
ましてや == 使ってて float とか使うとは思いもしないわけで

この関数はどういう条件なわけ？

>>354
そりゃ、mallocは当然ラップしてから使うよ

都合の悪いレスは無視なんだなぁ。

引き数は ｌ と　intOnly

l->m_subTypeType　は列挙型で

　 CTNCT_INT
　 CTNCT_FLOAT
その他がある。

　 CTNCT_INT 　かまたは、　　intOnly　というローカル変数が0でかつ　CTNCT_FLOAT 　の時は・・・・・

というような仕様なら、前にも書いた通り、その通り書くよ。

自分の設計なら

　 CTNCT_INT
　 CTNCT_FLOAT
　 CTNCT_OnlyFLOAT
の３つの条件して渡すよ

>>347
> そんなコードホントに書いてるの？　ミスの元だよ。

信頼性が高いといわれているソフトでも同じようなコードが散見するんで、
問題ないでしょ。

>>355
じゃあこんなのはどうすんの？
仕様は見たまんまで。

Window* p=getWindow();
if(p == &topWindow || (p == &bottomWindow && p->visible)){

}

>>345
おもしろいですね。

if( intOnly == 0 ){
ではなく、
if (intOnly == 0) {
とカッコの外側にスペースを入れるなど、まさにそうかもしれませんね。

>　 CTNCT_OnlyFLOAT

勝手に変な型をふやすなよ

>>361
上の書き方で書けとか言われたら個人的にはサブイボ出る

>>360　今度は間違わないように書き直すね

　(p == &bottomWindow && p->visible)) visibleであって　bottomWindow 　
|| (p == &topWindow ）　　かまたは topWindow　である場合　

だね？
これがそういう仕様なら、この通りかく。　それは仕様書に従うべきだから。

で自分の設計なら、　
この処理をしなければいけない理由があって、その状態だから、この処理をするのだから
p のクラスに状態フラグを入れてしまう。

>>363
>>338とか？

func (arg)
?

数学関数は、関数名と括弧の間には空白は入れないから、
そこはそれに従ったのだと思う。

>>364
状態フラグを導入する？そっちのがヘタっぽい気が。

自分はそういう状態フラグの周辺でバグは出やすいと認識してる。

>>360
で自分の設計ならの場合は

結局メンバをstatusHoge を増やして、

topWindow.statusHoge=true;
bottomWindow.statusHoge=bottomWindow.visible;

みたいな処理があって・・・・

Window* p=getWindow();
if(p->statusHoge){

}

ね。　こっちがすっきりするでしょ？

>>354
俺が見た例
・malloc()禁止
　配列にサイズチェックなしでデータをためていくようなコードが当たり前のようにあるプロジェクトなのに。
　(逆にそういうレベルだからmalloc禁止か?)
・MFCは使っているのにCStringは禁止
　理由はメモリリークするからというので、どういう操作でメモリリークを起こすか質問したら、
　「わからない先輩にそうきいた」と。
・詳細は忘れたけどVBでテキストが変更されるときに飛んでくるイベントは使用禁止
　理由はバグるから

手っ取り早くおまえらコーディングスタイルを次にあわせてくれませんか？
・２項演算子はスペースを入れる。
・if(){とかかないで{は次の行にする
・if () のように括弧の前にスペース入れない。

>>371
やだ

>>369
釣り？

>>371
だぁめぇ〜

>>371
if ()は譲れない

>>368
　状態といっても、ようするにコレ一部でも見えてる場合はって感じの場合なんでしょ？
　だったら、そういう状態を持っているのが普通だと思うのだけど？

各自好きなスタイルでコーディングできるエディタ作ればいいじゃん。

>>369
悪い、ちょっと書き間違えた。
topWindowとbottomWindowは実体じゃなくて、ポインタ変数で、
ウインドウの関係が変われば書き換わるんだよ。

その場合、お前の設計はどうなる？

>>377
好きなスタイルでコーディングできるから、ヘタクソが分かっちゃうんでしょ。

>>370
そうなら、なおさら、top/bottom の位置関係はオブジェクト側で持っているべきだと思う

ポインタで比較するのはあんまりしない。

>>379
設定によって
if()
と書かれたコードでも
if ()
と表示するわけだが(もちろん、その逆も)。

>>378
たぶん top/bottomはZ軸　オーダの事で、リストのような構造を辿るというような設計なんでしょ？

でtopにする場合にリストの先頭につなぎなおす筈だから、その処理で
先頭から順にメッセージを送って、それぞれ状態を作り直せばいいじゃない

>>361
K&Rだとキャストの後ろも
d = (double) hoge;
みたいにスペースが入ってるけどそれも同じ理由なのかね？

バグとかアンカーミスとかあると、
こいつのやった仕事、信用できねーと思う。

>>380
オブジェクトに相対的な位置関係情報を持たせるのはあまり上手い設計じゃないな。
自分の相対的な位置を知るためには、他のオブジェクトの位置も知らないといけないということだから。

if(XXX )
if(XXXX) と書く奴はヘタだなって思う。

&& 演算子知らないのかよって感じ。

あと ||を避けるために変な仕様にする本末転倒なコード見たら張り倒すね。

>>385
確かにそうだね。　では GetStatusHoge() とメソッドにしておこう。

bool window::GetStatusHoge(){
if(this->IsTopWindow() ) return ture;
if(this->IsBottomWindow() ) return visible;
}
こんな感じかな

ぱっと見て「心配だなぁ」と思うコード

Window* p=getWindow();
if(p->statusHoge){
...

IsTopWindow()とかIsBottomWindow()とかは、誰かが作ってくれる前提なのか。

>>389
いや、
if(this==topWindow )
と書きかけたけど、topかどうかを知る方法はメソッドとして、
後で変更出来るべきだと思い直したから　中途半端な書き方になった

スマン

普通にこれでいいじゃん。

bool window::GetStatusHoge(){
　return this->IsTopWindow() || (this->IsBottomWindow() && visible);
}

>>387と比べて、何がしたいか意図が明確。

>>391
否定はしないけど、
この仕様、

ゴメン bottomの場合って言うのは間違いで、top以外なら visibleだけで処理してよ
え？　topを特別にする理由？　だからtopなら無からずvisibleだからだよ。　他の窓に隠れないだろ？
だから、 visibleは見えてる部分があるかどうかだよ。

え？ visibleだけでいい？　まあそうだね

論理 or や and を嫌うのは、ブール代数とかが嫌いなんだろうなぁ
自然に読み下せていいと思うけどなぁ
英語も嫌いなんだろうなぁ

>>393
というか単純な事を複雑にしたがるのが嫌ってのが大きいかもしれないね

&& || が多い人は、
妙にくどいし、重複を厭わない
不思議な事に & | ^ を使って短く書いたコードになぜか拒否反応がある事が多い。

>>392
>ゴメン bottomの場合って言うのは間違いで、top以外なら visibleだけで処理してよ
>え？　topを特別にする理由？　だからtopなら無からずvisibleだからだよ。　他の窓に隠れないだろ？
>だから、 visibleは見えてる部分があるかどうかだよ。

意味不明。というかアホすぎ。
top以外なら？勝手に仕様を脳内変更だよ。

お前こう言ってただろ。
>364
>visibleであって　bottomWindow かまたは topWindow　である場合　

>>394
>というか単純な事を複雑にしたがるのが嫌ってのが大きいかもしれないね

お前だドアホ！

>>360

＞if(p == &topWindow || (p == &bottomWindow && p->visible)){

オブジェクトの外側で　ヘタな事やってるね

OOPなら メッセージを投げなさいな

>>395
（　（visibleであって　bottomWindow ）　かまたは topWindow　）　である場合でしょ？

だから、この条件って何なのよ？　その仕様をはっきりさせて
たぶんもっと簡単な解決法があるから

>>397
oopなんて一言も言ってないけど。
あくまで || と && をどうやって無くすつもりかのサンプルとして書いたもので、
最初は単純なCのつもりで書いてるし。

とりあえずこのスレを眺めて思ったことは
自分のスタイルを確立してしかも他人に対してそれを主張するのは
他人の書いたコードをうんざりするほど読み込んでからにした方が
おそらく変に偏らずにすむということだ。

>>400
ぱっと見て「ヘタだなぁ」と思う文章

>>399
どうやって無くすかより、
>>360みたいなコードを書く場合は
それが自分の設計なら、必要かどうかを先に検討した方がいいよ
先頭か　（最後尾で表示オン）　って妙な条件でしょ？

このスレで議論されてることはほとんど、うんざりするほど読まなくても、
有名なプロダクトのソースや本をかいつまんで読むだけで、はっきり
するようなレベル。

>>398
だから条件は、ウインドウがトップウインドウ、
もしくは、ボトムウインドウでvisibleな場合だけだって。

その場合にアラーム鳴らしたりすんだよ。

>>402
お前、if(l->m_subTypeType == CTNCT_INT || (l->m_subTypeType == CTNCT_FLOAT && !intOnly))
は||をムリヤリ無くそうと、↓のコードに改悪したくせに。

switch( l->m_subTypeType ){
case CTNCT_INT :
case CTNCT_FLOAT:
if(　0== intOnly ) ....
}

ポインタはswitchに直せないからって、主張微妙に修正しやがって。まったく。

>>403
議論というか趣味の押し付け合いだな。
しかも題材も捏造したコードでなぜゆえにこんなに必死になってるんだ。

>>403
本の名前あげてみて

どうせこのスレで集めたネタも本にするつもりなんだろう

>>404
わかった。
ようするにトップなら無条件で、2番目なんて興味なし、でもイケメンならビリも可愛いいから喰っちゃうわよと。
こういう事？

なら、if( IsCool(p) ) {. .. } でいいじゃない。

IsCool(window * p){
if(p==トップ） return もちろん;
if(p->いけめん） //なら
if(p==ビリ） return OK;
}
これで判り易いでしょ？

>>405
だから、それ、仕様をハッキリしてくれたら、もっと上手な方法教えたげるよ

switch( l->m_subTypeType ){
case CTNCT_FLOAT:
　if( 0 == intOnly ){
case CTNCT_INT:
　　...;
　}
　break;
}

>>407

・Cの文字列はmemset()で0で埋める
・#include と <・・・>はくっつけて書く
・二項演算子の両脇はあけない
・&&と||は使わない

こういうことを薦めている本を教えてください。

>>411　好き

int f=1<<->m_subTypeType;
f &= (1<<CTNCT_FLOAT) | (1<<CTNCT_INT);
f &= (0==intOnly) << CTNCT_INT;

if(f){ ...　}

>>409
isCool関数内で&&,||演算子を使わない理由がわからん。
お前は結局、&&と||を使わなくてもなんとかけることを示してるにすぎない。

そりゃ、使わなくても書けることは分かってる。
しかし、どう見ても使わないより上手くかけてるとは言いがたい。

それではお前の 「||を使う奴はヘタ」という主張を通せない。

>>413
そういうCTNCT_FLOATが32以上の可能性を考慮しないアホコード晒して、何が楽しいの？

>>414
まあ、どっちでもコストは同じだとは思うよ
||も内部では条件分岐だしね。

でも、>>409のように書けばデバッグし易いメリットがある
ブレークポイントも仕掛けられるんだしね
トレース実行で、どっちの条件で落ちたか確認するのも容易だ
トレース実行すれば体感的に動作が判る＝身につき易いという事

もう一つのメリットは
論理型以外も返せるという事

こんな関数を沢山作るのが嫌なら
pascalの集合型のような方式で条件を作って返すようにすれば、and or 表方式で
簡単に条件の差し替えを実行中にも出来るように出来る

ブザーを鳴らしたい条件が後から変更されてもコードを直さないで
その場で iniファイルの設定で修正できるわけさ

関数に切り分けることは否定していない。
結局 ||,&&を使う奴はヘタという対した理由は無しと。

>>418
登山をするときには最も体の弱い人間にペースを合わせるのが鉄則。
同様に開発においても最も頭のよ（ｒｙ

a || b || cより

if(a)return;
if(b)return;
if(c)return;

が、デバッグしやすいから常に優れてるというのなら、
あらゆる二項演算子も同様の記述をすべきだ。

return a + b + c;

は

temp = a + b;
temp += c;
return temp;

しかし、普通は逆に見がたくなるケースが多い。
つまり、同様に &&,||もデバッグのしやすさをの方を追求することは、
常に優れている方法ではない。わかる？

あまりにも体の弱い人間は連れていってもらえないわけだが

>>418 　たとえば自分なら、こんな仕様が渡されたら

f= (p == &bottomWindow)<<2
+　 (p == &topWindow)<<1
+　 (0 != p -> visible )<<0

とすれば 0〜7の値となる。　 さらに、
b= 1<<f;
とする。　値は1,2,4,...128 という値となる

条件判断部は
if(b&getSetting(__BEEP)){
}

てな感じにする

これで設定ファイルで　この３つのどんな条件でも作れるという事になる
この場合、初期値は
f=0b011 3
f=0b100 4
f=0b101 5
f=0b110 6
f=0b111 7　で 0xF8 となる

ムダに複雑にしたように見えるかもしれないが
定型コードだから、書くのに手間はない。（というか、この設定値のGUIも作ってある）

実際、|| && を組み合わせるような条件は仕様変更の対象になり易い。
キミは修正してと言われたら帰ってビルドしなおしますと答える必要がある。
片方は、そのまま実行しながら条件を変更してみせられる。

じゃあa && b || cで混乱するような奴も不参加だな。

まあ、こうやって客に誉められても、オレ指定の仕事が増えるばかりで、
給料は変らない。　お勧めはしないけどね

>>420
確かに　2項演算子を代入演算子に変換してしまうことは多いな。

見辛くてごめんね

ああ　チョッとぼけてる >>422は少し間違い
f =　 (p == &topWindow)<<2
　+ (p == &bottomWindow)<<1
　+ 　 (0 != p -> visible )<<0 ;
だな

+ と << では演算子の優先順位があれなので・・・。

またバグ出したのか。偉そうにいってコレではなあ。
そりゃ給料変わらないわな。

>>428
でも、この方法なら、客先で気付けばその場でビルドせずに修正出来たわけだ

>>328

チャンスがあるなら、それからチャンスがあるなら 自分のコードで　バグ取りをする時は、　&&,||をムリに変更加えたところや<< + を使ってるとまず疑うといいよ

>>429
おいおい、お前が間違えたのはソースの方だぞ。

>>429
バカ丸出し。これをビルドせずに修正？出来るわけないだろ。

設定ファイルで動作条件を変えられるようにするくらい、どこでもやってるだろ。

Cインタプリタ使えば万事解決

結局ヘタというより、盛り上がるのはC/C++言語故の悩みってのが殆どだね。

memsetとかtrueとかしまいには、空白作法・・・・

pascal系のように綺麗でカッチリした言語にもう少し普及して欲しいねえ
っと言えば
#define BEGIN {
みたいなのを勧めるトンでもな奴と叩かれるんだろうが・・・・

pascalってかdelphiにも宗教戦争あるじゃん
インデントにはスペースとタブどっちを使うかとか
やはり演算子の脇のスペースとか
大文字小文字の統一・混在とか
withはバグの元だから使うなとか
if文でbeginを書く位置とか、やっぱり色々あり過ぎね

pascalもカッチリしてないよ。
begin、endをどこに書いてもいいし、空白だってそうだ。

自己満足以外の理由・根拠なしに、他の流儀を掻き乱すから叩かれるんだ。

IDEが俺俺スタイルとプロジェクトスタイルを相互に変換してくれればほとんど解決じゃない？
読み込み時に俺俺スタイルに変換
保存時にプロジェクトスタイルに変換

もっとこう言語使用がカッチリしていて
C並の速さで動作して、しかもGUIが簡単に作れる
ビシッと一発痺れる憧れるぅ！な言語まだ〜？

pascalの宗教戦争はあんまり見た事が無いな

インデントにはスペースとタブどっちを使うかとか ----それこそエディタ上でどっちでも変更出来る事だろう
やはり演算子の脇のスペースとか ---- 演算子が　and or だから入れるべき所に入れない訳にはいかない
大文字小文字の統一・混在とか ----大文字小文字区別しない言語だから、比較的寛容かもね
withはバグの元だから使うなとか ------- with TStringList.Create do tray ..... finally free end; とか？
begin end を採用したおかげで、そんなにネスト出来ない事もあるのかもね

まあ何より pascalはborlandの拡張まで分割コンパイルが出来なかったから
多人数で共同制作という機会が無かったのだろうな

> pascalの宗教戦争はあんまり見た事が無いな

それ以前に使っている人見たこと無いなｗ

もうね。

ソースコードにメタ情報入れて、
タブは何文字で、演算子の前後にはスペース入れてとか、

んで、エディタで読み込むときは、自分のスタイルに変更して表示、
書くときはメタ情報のもとのスタイルにもどして書く。

デザインと中身の分離だよ。そうしろよ。

>>442
禿同

>>442
いっそ、言語仕様をXML化して、CSSで表示するってのはどうだ？

そういうのは必ずバグがあったり他のﾂｰﾙとの共存ができないなどで駄目。
やっぱりまともなコーディングスタイルをみんなが実践しないと。
演算子をくっつけてファイルサイズを節約しているそこのあなた。
｛をｉｆと同じ行に押し込めて行数を節約しているあなたも。
反省したまえ。

>>442
有り難いことにindentのオプションをソースの先頭にかいてあるものもある。

char* p = (char*) malloc(hoge_size);
memset(p, NULL, sizeof(p));

>>445
じゃあそのまともなコーディングスタイルをお前が作ってくれ。

もうさ、生のソースコードは、インデント無し、改行無し、
余計な｛｝無しの一行コードでいいじゃん。
そうすりゃ、誰もが整形機能を持ったエディタで見るだろう。

>>440
もう本当に、ふだん、いい加減にソース書いてるって感じの認識だな。

>>435
> 結局ヘタというより、盛り上がるのはC/C++言語故の悩みってのが殆どだね。

いや、ヘタだろ。
ここで盛り上がってるのって、世間じゃ意見が分かれるようなことじゃないのに。
宗教論争になりがちなタイプの話題とはぜんぜん違う。

またソレかよ。>>450

試しに、素数を列挙するコード書いてみてよ。　
この1レスに収まるという条件で、結果出力は必要ないから

>>451
空白絶対空けないと許さないよ君がしつこくなければ盛り上がらなかったよ。

>>451
そもそも、ふつーの人は興味無いしね。

木村18

↑ъ( ﾟｰ^) 誤爆ｽﾏｿ

>>456
　　　　　　　　　　　　　　　　 　＿　＿　　　　　.'　　，　．. ∧＿∧
　　　　　　　　　　∧　　_　- ― ＝￣　￣`:,　.∴　'　　　　　（ 　　　）
　　　　　　　　　,　-''￣　　　　＿＿――＝',　・,‘　ｒ⌒>　 _／ ／
　　　　　　　　／　　　-―　￣￣　　￣"'"　. 　　’ |　ｙ'⌒　　⌒i
　　　　　　　/　　　ノ　　　　　　　　　　　　　　　　　|　　／　　ノ ｜
　　　　　　/　　, ｲ ）　　　　　　　　　　　　　　　　　, ー' 　／´ヾ_ﾉ
　　　　 　/　 　_,　＼　　　　　　　　　　　　　　　／　,　　ノ
　　　　 　|　　/ ＼　 `､　　　　　　　　　　　　／　／ ／
　　　　 　ｊ　 /　　ヽ 　|　　　　　　　　　　　／　／　,'
　　　　／　ノ　　　｛ 　|　　　　　　 　　　／　 ／| 　|
　　 ／　／　　　 　|　（_　　　　　　　 　!､＿／ / 　 〉
　　`､＿〉　　　　 　ー‐‐`　　　　　　　　　　　　|_／

>>454
興味ないからじゃなくて、変な書き方する人がいないから。
(まともなところは)

まともな人たちが何人かでコードを書くんで、コーディングルールを確認しました。

二項演算子の両側は空けるってルールを作っても誰も文句は言いません。
詰めるってルールを言うヤツが混じってたら、「なんで?」「それやめましょうよ」って
ことになる。

興味ないから、議論にならないってわけではない。
(あたりまえすぎて議論にならないってならそう)

出た。口癖の「まとも」ｗ

まともかどうかは主観に過ぎないのに
自分の「まとも」を押し付けようとするバカｗ

ちなみに、絶対に詰めろ、というバカは居ないので、
押し付けてるのは、絶対に空けろ、というバカだけです。

なんか芳ばしい匂いがすると思ったら、このｽﾚか…。

ソース位、コンパイラの様におおらかに見る所と、
厳しく見る所のメリハリをつけれよ。

>>459
詰めてないオプソのソースもあったろ。
お前がやーやーうるさいから出してやったのに、もう忘れたのか。
お前の脳味噌はニワトリ並か。


あと、半角の?のような特徴を残さない方がいいよ。
同一人物だってバレバレだから。

>>459
なんで詰めるルールを作るんだ？
頭大丈夫か？

頭だめですっ！もぅ頭ですっ！誰か頭たすけてっ!!

流れを読まずに書くが、

スタイルなんて個人のもっとも読みやすい形で書くのが普通だろ？
それが、そのソースを書いた人にとって一番コーディングしやすいし、読みやすい。

人間一人一人、個性や好みが違うというのに、俺のスタイル以外はキモイ！って言うのは、
納豆が嫌いなやつに「納豆うまいだろ！何言ってんのキモイ！」とかいうのと一緒。

あっ、スレタイネタを一個投下。
フラグを使う奴は「ヘタだ。」とまでは思わんが、うまくはないなぁ。とは思う。

>>465
納豆はウマいです。勘弁してください。

>>465
466がなければよかったのに。
残念だ。

あっ、スレタイネタを一個投下。
OS書く以外の用途でCを使う奴は「ヘタだ。」とまでは思わんが、うまくはないなぁ。とは思う。

また昨日の基地外が現れたのか
ID出ない板だと一人基地外が出現するだけで大盛況だな

>>467
納豆うまいだろ！何言ってんのキモイ！

>>468
「フラグは使うな」ってＣプログラミング診断室の人もいってるぜよ！

>>469
ちょ、おま、まねすんな。なんか恥ずかしい
画像ファイルとかの読取り、書込みでも使うと思うよ。っていうか使ったよ。
あ、でもＣじゃねーな。Ｃ＋＋だ。ＯＳか。ならやっぱ同意。

Ruby作者が言語作るのにCより高級な、
特にクラスのある言語を使うと頭が混乱するというような事を言ってたな。
なんとなくわかるようなわからんような。

>>472
クラスのある言語で、クラスのある言語を実装するのは混乱する、ということを言ってたはず。
お前のニュアンスは違う

半角の?と まともな で検索したら、キチガイが浮かび上がってくるね。

char* p, q;

Cの方が速いのにうまくないなぁって、アフォかと

>>471
フラグの是非じゃなくてさ。
どんな優秀な作品にもケチつける人がいるように、
フラグ使用も個人の好みじゃないの？ってこと。

ぶっちゃけ、一貫したスタイルで書いてて、動けば何でも来いだ。

>>477
＞フラグ使用も個人の好みじゃないの？ってこと。
まあ、確かに。フラグ使ってる人もヘタなわけではないし。

＞動けば何でも来いだ。
これは同意できないけど。コードはやっぱりできる限り、綺麗な方がいい。

まあ、俺が思った事とは、違う意味で言ったのかもしれないけどね。

>>370
CString使えないんじゃMFCやめてしまっちゃええええーーこの！

virtualでpublicなメンバ関数

martialでcedricなシーラカンス

>>460
主観ていうか、世間で評価されてるプロダクツとか、まともな本に掲載されてるソースとか、
圧倒的多数は二項演算子の両脇を開けるってスタイルなのよ。

「宗教論争」とか「好みの問題」とか言ってる人がいるけど、その言い方で言うなら、
二項演算子の両脇を詰める「宗派」とか、「好んでいる」人っていないわけ。

自分はヘタじゃないって思い込みたい人がこのスレで暴れているだけ。

一律すべてにおいて、二項演算子の両端を空けたほうが絶対に
読みやすい。空けないと読みにくい、と思い込むのは宗教。

結局全体的なバランスというか、コンテキストによるんだよ。
複雑な式なら、意味のまとまりごとにスペースや括弧を入れるとか、
自己満足じゃなくて、いかに他人に伝えるかが大事なんだから。

if( a + b >> 1 > x - y * 4 )
と
if( a+b>>1 > x-y*4 )

ではどっちが可読性高いか。（個人的には下。個人的にね）。


たとえば、一行に複数の文を入れるのを嫌う人がいるが、値のスワップにおいては

int tmp = a[i]; a[i] = b[j]; b[j] = tmp; /* a[i],b[j], swap */

と一行で書いてしまったほうが、コードを見渡したとき、全体を把握する際邪魔に
なりにくい場合が多い。もちろんこの場合はマクロにしたほうがいいけどな。

もう宗教論争はいいんじゃね

>>482
暴れてるのは「まともな」が口癖で、
文の後に括弧で言い訳みたいな注釈つけたり、半角?を使うのが特徴のお前「だけ」だよ。

>>221もお前だろ。

主観だと指摘されてるのに未だ「まともな」とか口走ってるのね。ｶﾜｲｿｽ

演算子を詰めて記述しなさいっていうコーディング規約なんて見たことないけどな。

「演算子の両端をあけなさい」なんていう規約があったらその規約そのものに疑念を抱くな俺は。
そういう規約には往々にして、本質的に大事なことが抜けていたりする。

つうか、そもそもお前の論理おかしいんだよ。

お前はこう主張したいんだろう。
「まともな本では空白を空ける」　->　「だから空白を空けるのがまとも」

しかし、お前のレスを読むと、次のように捉えてることがわかる。
「空白を空けるのがまともな本で、空けないのはまともじゃない」　-> 「まともな本では空白を空ける」　->　「だから空白を空けるのがまとも」

こんな論理展開ありえない。

>>487
詰めて記述するのが正しい、と主張してる人は居ないので、それはどうでもいいんだよ。

ケースバイケースでいーじゃんもう・・・

二項演算子の両側にスペースを入れている有名な
プロダクトの優秀なプログラマに、二項演算子の両
側にはスペースを空けたほうが上手なコーディング
ですよね、と質問したら鼻で笑われるよｗ

>>482
ttp://www.gnu.org/prep/standards/standards.html
の5.1 Formatting Your Source Codeには、

v = rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000

なんて記述がありますよ。
GNUウェアは世間で評価されていないプロダクツですね。

おれもだんだん不毛にみえてきた
「あぁ、バグでたとこをどんどん直してテストコード書いとけばいいんですよ」
って言ってた後輩がいたんだがあいつが一番正しいな、と思う
ま、そういってもここの住人は「お前が一番分かってない」と嬉々として書き込むんでしょうがｗ

そういえば、-> って二項演算子だよな。

俺のコーディングスタイルが
まともということでいいな？

誰だよｗｗ

俺が思うにな。まともなソースってのは、
俺と同じコーディングスタイルをしているんだ。
俺と違うコーディングタイルをしているものはまともじゃない。

そうすると、まともなコードってのはどんなのかわかってくるよ。
そのときにコードを見てみ。俺と同じコーディングスタイルだから。
で、違っていたら、それはまともじゃない。

俺が推奨するコーディングスタイルの奴を、「まともな本」と定義する。

するとな「まともな本」のコーディングスタイルは
必ず、俺が推奨するコーディングスタイルなんだ。

この謎わかる？

>>492
それ２つの例の両方とも、二項演算子の両端を空けてない場所があるやんけ。

>>492
GNUが評価されてないなんてこた言う度胸はないけど、
GNUのって日本ではあまりお目にかかれないスタイルって
感じするよね
if (x < foo (y, z))
haha = bar[4] + 5;
else
{
while (z)
{
haha += foo (z, z);
z--;
}
return ++x + bar ();
}
こんなスタイル(海外のOSSではもちろんあるけど）日本で仕事する限りにおいて
すくなくても俺の周りでは見たことない

>>499
空けてある場所もありますよね。

この二つからでる答え。
バカじゃない人ならわかりますよね。
わからなかったらバカです。

>>500
じゃあ、お前の周りにいる奴は、まともじゃない。

ところでお前ら、２ちゃんねるに長文書くとき

一行一行に空行空ける？空行空けない？

俺空ける派。

くっつけて書いたら見にくいって時は空けて、
別に見にくくないって時は、空けなくていいじゃん。
そんなもん気分次第でいいでしょ？
ルール作るほどのこと？

それともどっちかにしないといけないという明確な理由でもあるの？
理由が無いルールのためのルールは作らないでよね。

精神病の判定でそういう項目があったと思う

>>502
そうか？422や391などみてみれば？このスレでもGNUスタイルで括弧
つけて書いてるやついたっけ？ まったくいないとは思わんけど、このスレでは
圧倒的にGNUスタイルのやつは少数派でしょ
いくらなんでも見識狭すぎじゃね？

空けても損は無いが空けなかったら駄目っていう場合がある。
だから空けた方がいい

バグに無関係な項目ならば、
単純にその人にとって読みやすければよい。

そんな細かいことを気にすると禿げるぞ。
ただ、C++やっているならむしろ禿げるべきかもしれない。

>>507
空けなかったらダメという場合だけ空ければいい。

>>508
何ではげなきゃいけないんだよｗ
と、ちょっぴり不安だぞ

ハゲに無関係な項目ならば、
単純にその人にとって読みやすければよい。

そんな細かいことを気にするとバグるぞ。
ただ、C++やっているならむしろバグるべきかもしれない。

俺は絶対に禿げない。

俺は絶対にバグらせな。。。すまん。。。

>>484
>if( a + b >> 1 > x - y * 4 )
>if( a+b>>1 > x-y*4 )

演算子の順序あってるかい？
あってるとすれば俺ならこうかな？

if ((a+b) >> 1 > x - y*4)

>>483
　一番の勘違いは
「自己満足じゃなくて、いかに他人に伝えるかが大事なんだから」
の部分だろうね。

余程の酔狂か仕事でなけりゃ、誰も他人のコードなんて読みたいとも思わないもの。

指導者なら仕方なく貴方の汚いコードを読まなければならず、
そして汚いコードを読まなければならない苦痛から色々作法を言いたくなるのだろう。
実際、俺たちもそんな事をつい言ってしまうが、ホントは違う。

逆に言えば作法について言わなくちゃいけない相手ってのは余程相手がヘタクソなレベルだ。

たとえば、
「cの文法から演算子の左右に空白が無ければ空白を入れて出力するフィルターを作ってごらん」
と言って、2時間くらいで書いてくるような奴には、そんな事は言わないし
実際書いてくる奴のコードは、そんな作法とか関係なく、
読みたくなるほどアイデアが込められていて面白いもの

v = -1
v + 1

for(i=0; i<size; i++) {
if(i==0) {
} else {
}
}

俺は空白云々は好みの問題だと思う派。
==、forの()内、長い式で優先順位の高い演算子
辺りはくっつけるのが好き。

読みたくなくても読みやすく書け
他人のためにも自分のためにも

とりあえずプロジェクトに従う
あとは気分

＞cの文法から演算子の左右に空白が無ければ空白を入れて出力するフィルターを作ってごらん

フィルターというと標準入力　標準出力だが、
プログラム中で使えるフィルターに変更となると、出来る奴は極端に少なくなる

たとえば　1バイト毎に呼び出される手続スタイル
それより面倒なのが、１バイトが必要な時に呼ばれる関数スタイル

両方に対応出来るコードを書けといわれると
１）　コルーチン
２）　FIFOバッファ
を使わないといけないが、２）はともかく　１）はLONGJUMP/ファイバが使える環境でも実装出来る奴は少ない

逆に言えば、そういうツール作りさえマトモに出来ないから、
妙な所にコダワルのだとも言える。
プロジェクトで最初にそんな話題が出るなら、そのプロジェクトの奴はみんなヘタクソという事だ

たぶん　そういうの作れと言われた場合の反応

A 作れる派
　・実際に2時間くらいで作ってみせる 3% 30分なら神レベル　0.3%

B 作れない派
　・ そんなもの作らなくてもあるんだから車輪の最発明なんてしません　40%
　・ どっかのコードをコピぺ 30%
　・ 2千行くらいのスパゲッティコードを書いて、しかも動かない　20%
　・ すなおにゴメンなさい　7%

で10人くらい集まってると、車輪の最発明だからしない派と、どこからコピペすりゃいいの派とがワイワイやってる間に
　1人が作って、それで終わりか、その一人がいなくて、半日以上時間が過ぎてゆくか

>>515
仕事でコード書いたことないだろ？
それともゲームプログラマかなんか？

>>521
派遣で携帯電話の仕事でもしてるの？　

もしかして、
indent(C++,javaならastyle)というプログラムがあることを知らない人が多いのか？
いつまでやってんだ？

>>523　知ってる上で真面目な顔して言ってるみたいよ。　演算子の両側に打鍵時に強制って・・・・ちょっと怖いよね

どうでもいいけどcontinueやbreakって使ってる？
ループ内でネストが深くなりそうな気がしたら良く使ってるのだが、
以前一種のgotoだといわれてしまった

goto だって平気でドンドン使うが？
状態遷移で分析した結果を素直に書くには gotoが一番さ

そんなこと言えば だいたい break なんかより switch文こそ gotoじゃないか

>以前一種のgotoだといわれてしまった
そうだが何か問題でも？

本質的には不要で属性上はgoto

つまりあったほうが便利

便利さの代償とバランスについては過去から延々議論されてて答が出ないので触れないほうがよい

日本語変なやつが多いな

ぱっと見て「ヘタだなぁ」と思う日本語

関数の途中の return も gotoだし
else もgotoだ

結局、制御文は goto なのさ

エネルギー保存の法則とはよく聞くが、このスレで捨ててしまった
貴重な人生の一部はいったいどこに保存されているのだろうか。
恐ろしいことにこのスレに常駐していると一分一秒ごとに
寿命がどんどん縮まっていくということを
彼らはちゃんと認識しているのだろうか。

エントロピーは増大する一方なのだよ

>>370
CString使えないプロジェクトなんか絶対従わんっ！

オレのえなじーは無限大だよワトソン君

>>532
お金というのは、捨てるという事が無ければ　常に　貰う人と差し出す人がいて、それぞれ+/-とすると
ゼロサムになるんだよね。
株の売り買いとか土地の売り買いは、ゼロサムゲーム。

でも、消費だけ生産があり、生産は価値創造。
消費は人にだけ許された行為。　消費には必ず創造がつきまとうんだ。


だから、このスレで何かが消費されたり、消耗されるとすれば、その分創造もあるという事だし
何か、誰かがこのスレに触発されて創造すれば、消費もあるという事かもね

>>523
もしかして、indent なんてｶﾞｲｼｭﾂだということを知らな（ｒｙ

>>537
もしかしてないよ。
結論とか言って既出なのは知っていたが、それでも続いていたから書いた。
細かいことを気になさる方ですね。ﾆﾖﾆﾖ。

>>489
> つうか、そもそもお前の論理おかしいんだよ。
> 「まともな本では空白を空ける」　->　「だから空白を空けるのがまとも」

いやいや「まともな」ってつけてるのは、学生が勉強しながら書いたような本とか、
変なの探し出してきて「こんなのがある」って言うヤツがいるかもしれないからさ。

普通の本だと、二項演算子の両側をくっつけて書いてあるの、捜すの困難だろ。

Cで
・流し読みしてあちこちでshortが目につくソース。
・構造体をfwrite()やfrwad()で丸ごと読み書きしてるソース。
・fprintf()やfwrite()などはエラーチェックしてるのに、
fclose()やfflush()はエラーチェックしてない中途半端なソース。

shortはデータ量削減のために使うことはあるなぁ。
構造体もそのまま読み書きする事は多いね。

で、fclose失敗したらどうすんの？





つかこのスレわざとやってんの？

＞流し読みしてあちこちでshortが目につくソース。
　これは理由があるのだろう。　理由が無ければヘタだが
　まあ今なら __int16 とかが使える環境ならそれでいいのだろうけど

＞構造体をfwrite()やfrwad()で丸ごと読み書きしてるソース
　エンディアンの違いやサイズの違いで可搬性は悪くなるが
　どうせ別の環境同士でファイル交換をそうするわけじゃないなら問題ないだろ
　とりあえず速度優先って仕様かもしれないし、一昔前の環境なら、そうしないと速度出なかったからね

＞・fprintf()やfwrite()などはエラーチェックしてるのに、
　fclose()やfflush()はエラーチェックしてない中途半端なソース。
　でもまあ　fclose失敗したからってどう対応出来るわけでもないし
　そこまでエラーが無いなら、とりあえずファイルは出来てるさ

>構造体もそのまま読み書きする事は多いね。
これはダメ。たまたま動いてるだけだと思った方がいいよ。

>>544
どうしてそう思うわけ？　可搬性の問題を言ってるの？

>>541
でかい配列を確保するとか、shortを使わされるライブラリが必要なときとか、
そういうときには使うけどさ、単独で使う用途とかあまりないんじゃない?

構造体のそのまんま読み書きは、同じ環境、コンパイラでも、オプション一つで
バグるじゃん。

>>546
それこそ、バイナリデータを構造体にそのままfreadで読み込む為に shortを使うんだよ

>つかこのスレわざとやってんの？
正解です。短いレスでたくさん釣れると高ポイント。

>>543
>　でもまあ　fclose失敗したからってどう対応出来るわけでもないし
>　そこまでエラーが無いなら、とりあえずファイルは出来てるさ

バッファのフラッシュに失敗して、最後の書き込みに失敗してるかも。
入出力のエラーチェックをして、対応してるコードなら、同じように対応すればいいよ。

short というより　SHORT とか USHORT は普通に使うけどねえ

うわー、へたくそが多い。
こわ！

>>549
でもさ、 fwrite　/ fprintf なら再度実行するような処理が出来るけど fclose/fflashが失敗なら
とりあえず何かエラーでしたよと伝えるしかないわけだ。
まあ出してもいいとは思うけどね。　

数キロ程度のファイルとか、fclose()するまで、ファイルサイズが0だったりするな。
某OSでは、fclose()のまえにfflush()を入れないと、プログラムが終了するまで、
バッファがフラッシュされないとかある。
どうやって、エラーチェックするんじゃい。

>>546
＞構造体のそのまんま読み書きは、同じ環境、コンパイラでも、オプション一つで バグるじゃん。

そうならないように、 #pragma とかで大抵は固定出来るようになってるから、勉強しておいで
ヘタ云々の前に　お勉強中の状態みたいだね

>>552
出してもいいっていうか、ユーザに伝えるなりなんなりしないとまずいでしょ。

>>555
まずい場合もあれば、気にしない場合もある。
表示すると簡単に言うけど、 ライブラリレベルで作成する場合には
そう簡単に表示出来るというかしていいわけでもないしね

新春の候、皆様いかがお過ごしでいらっしゃいます か。

>>556
入出力のみのライブラリだったら、そりゃ表示はしないでしょ。
かわりに、呼び出し側に教えるってことになるね。

fcloseで問題になるのは、そのタイミングで
ウイルスチェッカが走ったりすること。

shortを頻繁に使ってるって人はなんにつかってるんだろ。

大量のデータとか、通信とかIO関係まわりとかくらいしか思いつかないね。
(IO関係も、できればshortのバイナリイメージの直書きとか避けたい気分)

>>539
頭悪いなお前

「空白を空けるのが普通な本で、空けないのは普通じゃない」　-> 「普通な本では空白を空ける」　->　「だから空白を空けるのが普通」

>shortを頻繁に使ってるって人はなんにつかってるんだろ。
お前はそれを一切知らずに先に批判してるのかよ・・・

>>558
　ああ、時々、自作の errno もどきを作る人がいるよね
アレって何の意味があるんだろ？ errnoで足りないなら
windowsなら　GetLastError　すりゃいいのに・・・・

>>554
#pragma packを必ず使うだけで解決できるといいな。

>>560
short はあんまり使わないけど SHORT は　サイズがわかってるから使うんだよ

サイズがわかってるから、わざとラップアラウンドさせたり
そこでオーバフローの検出をしたりするわけ

たとえば、加算結果が16ビットを超えたかどうかを 0x7FFF　-0x8000の２回チェックするより
16ビットのサイズの入れ物に入れてみて、同じ値かどうかチェックとすれば比較が1回ですむでしょ？

>>561
たとえば、世に出回ってる本の何割かが二項演算子の両脇を詰めるというスタイルだったら、
俺の言ってることはそういう屁理屈になるけどさ、そういう本がないんだもん。
あっても、すごい珍しいでしょ。

二項演算子の両脇は空白が普通だよね。

詰めてるヤツは、ろくに勉強せずに「動けばいい」と、一人で、もしくは閉じた環境で、
ゴリゴリ書いてるやつ。

windowsの場合、
ファイルの入出力をするようなライブラリの呼び出して
いちいち、帰り値で何のエラーでしたとか知るよりは
　SetLastError(0)　-> ライブラリ -> GetLastError で確認
他に特別伝えなければいけないエラーは、ライブラリ内で SetLastError

てな方式に統一しておくのが一番だよ

エラーチェックをリトライ目的と思っているコード。
fwrite()のエラーチェックをしているのに(直後の)fclose()のエラーチェックをしないコード。
fscanf()のエラーチェックをしていないのに(直後の)fclose()のエラーチェックをしているコード。
入力ファイルを内容が「あるだけ」処理するプログラムでfgets()の後にferror()しているコード。

>>566
普通という単語は、「一般的」といった感じで使われてるけどさ、
所詮、発言者の経験した範囲内でのことでしかないのだよ。
「普通」が口癖になってる人は気をつけた方がいいよ。

>>566
まあ、印刷するんなら、読んでもつまらないコードの部分は、少しでも体裁を整えるのは当然の事。
だからそれが正義だと言われてもねえ。　必要なら後で整形すりゃいいじゃない。
整形してないコードを渡されたら黙って整形してあげればいいでしょ？

fcloseが失敗するなんてデストラクタが例外を投げるのと同じくらいありえないことにしてほしい。

>>571
実際は fcloseでflash動作もするから残りのバイトを書く領域が無いとかでエラーになるかもしれないよね。
でも、それは、fcloseの帰り値をいちいちその場でチェックしなくても、
ライブラリから帰ったメインがチェックするならすればいいじゃない。

>>572
光らせてどうする。

>>566
> たとえば、世に出回ってる本の何割かが二項演算子の両脇を詰めるというスタイルだったら
本が世の中のすべてじゃないよ。
間違いだらけの本だって多いし。

>>566
とりあえず手元の本ぱらぱらっとめくったら、
５冊のうち４冊で空白入ってないコードが載ってた。

goto以上に盛り上がるテーマがあったとはなぁ。

>>575
その本、教えてください！

>>566
お前みたいなタイプが好きそうなK&Rより。(p.173)

p = (char *) malloc(strlen(s)+1);
if (p != NULL)
    strcpy(p, s);

文脈に応じて使い分けろってこった。

>>566
おまえの人気に嫉妬する。

おれは566に賛成。普通だ何だと叩く口実にしている
奴らの方が気持ち悪い。566は自分の感覚を信じて
世の中渡っていくタイプ。いわば主役。批判してるの
はその他大勢

>566を批判も賛成もしないでスルーしている漏れが勝ち組み。

IDでないって便利だね♪

>>580
お前、賛成の理由が書いてないぞｗ

お前の言い方じゃ、>>566と逆のことを言って、
自分の感覚を信じて世の中渡っていっている
やつにも当てはまるんだが。

それに普通だなんだと言っているのはむしろ>>566の方。


まあ、どうせ自演だろうがなｗ

>>566
都合の悪いレスを見ないフリするのはもうやめろ！

お前自身がまともでも普通でもねぇよ。

そんな言い方する人は常識がないでつ

戻り値を返り血と言う

>>565
> たとえば、加算結果が16ビットを超えたかどうかを 0x7FFF　-0x8000の２回チェックするより
> 16ビットのサイズの入れ物に入れてみて、同じ値かどうかチェックとすれば比較が1回ですむでしょ？

何でそんなに馬鹿なふりするの？
君はもっと素直な子だったじゃない

http://www.tcct.zaq.ne.jp/ayato/programming/java/codeconv_jp/

空白については、これか。ずいぶん細かいな。
http://www.tcct.zaq.ne.jp/ayato/programming/java/codeconv_jp/CodeConventions.doc7.html#682

>>587
そうだな。
それで満足しちゃいけない。
さらに飽和処理まで論理演算でやらないと素直とはいえないな

>>560
音やビットマップの情報は　8/16bitなどのサイズを使う場合が多いよ。
たしかにMMX-->SSEで、処理そのものは浮動小数点でリッチにやるとしても
結果は、8/16固定小数点にしないといけないし
ライブラリも固定小数点のものも多いから

それから、多倍長処理を書く場合も、Cなら32bitより16bitで処理する方が桁処理が楽とか

構造体のfread/fwriteについては C なら普通の手法
C++だと構造体でもメソッドを付ければVMTがついてくる場合があるから少し危険だし
そもそもC++使うような環境なら、こんな直の手法はやらない方がいいね。

>C++だと構造体でもメソッドを付ければVMTがついてくる場合があるから少し危険だし

こんなアホ認識は危険だな。場合がある、とかなんであやふややねん。

仮想関数テーブルへのポインタが付加されるのは、仮想関数をつけたときだけ。

構造体にユーティリティ関数をつけることは全くの無害。

静的に解決されるからね。
決まり切った初期化とか、構造体の関数にしてるけど、これってヘタかな？

何ともいえない。

>>594
で、誰かが継承して 使おうとして、勝手にvirtual を付けたりして

>>594
Delphiの try 〜 finally の代用として
関数内で構造体を定義して、デストラクタを使うというのは良くやるけどね


ちなみに
Delphiの try 〜 finally というのは
例外が投げられたり途中return で　ブロックを勝手に抜けられるような時に
必ず実行される機能

>>596
final欲しいですよねえ。何とかできないことはないけど、美しくない。
>>597
finallyも欲しいですよねえ。何とかできないことはないけど、美しくない。

__finallyってC++標準になってないだけで、
BCB、VC++、gccに全部あるような希ガス
















hewに無いかOTL

Delphiって文法は個人的には良いと思うんだよね
死滅してしまうにはそれなりに惜しい言語だ

ObjectPascal って死滅しちゃうの？

でもVC++では同一関数内で__finallyとC++のデストラクタと併用できないのが痛い。
ほかのは知らないけど。

DelphiはIDEが秀逸だったけどPascalは基本的に嫌いだった。
っても、{;}意外の言語は全般嫌いなんだけどなｗ
まぁ、趣味じゃないってだけの話なんだけどな。

>>600
Delphiは戦略が悪かったな。
タダで配ればよかったものを。

{}が嫌いってC系言語以外は使わないってこと？

>>604
只で配ってた時期が存在していた。
ま、そんなもんだ。

>>605
好き嫌いと、使用不使用は話が別。

無料で配ってたときは勢いがあったように思ったもんだが

ﾎﾞｸとｷﾐは赤いスレッドで結ばれている。

↑誤爆。すまそ

ｆead/fwriteで構造体を読み書きできないというなら、何に読むつもり？
intに読めばエンディアンの問題、
char 配列に読むといったって、char が 8bitじゃない環境(TMP32用とか）だって世の中にはあるわけで
結局はバイナリの読み書きは環境依存でしかない。

それを吸収するのがＤＢでつよ。

通信でも吸収するよね

Cはポータブルにも書けるし無茶苦茶環境依存にも書ける。
そんだけ。

>>611
> ｆead
> (）

ぱっと見て「ヘタだなあ」と思う文章

f r e a dのミスです

TMS320のミスです

うちの会社のオールドミスです。

Mr.＆Mrs.スミスです。

>>606
最初っからタダで配っていれば・・・
そして、たかがダウンロードするためにメールアドレスとか要求しなければ・・・

発売当初は、VC++並みの開発環境と、VBなみのＧＵＩの書きやすさで、
かなり期待していたもんだがねぇ。

言語の普及なんて、色々な付加価値つけたとしても難しいのに、
金とるわ、メールアドレス要求するわじゃだめだな。

>>616-619
プログラマの発想って、こんなのばっかり。
よほど抑圧されてんだな。

単項演算子の両端詰めてるやつは、短いコードしか書いたこと無いんだろ？
それで偉そうに言われてもね・・・・
for文内とかならまだしも、ちょっと長い文で詰めてたらすぐ見づらくなる。
それに両端空けないときちんと動作しないこともあるから統一性を考えたら
あけたほうがいいだろ？
何度も言われてるがこれは普通の宗教論争とかじゃない。
これが普通だし、普通だと思えない奴はただ単に経験不足。
てか学生の独習して身に付けたプログラミングスタイルだろ。
自分の未熟さを必死に主張して恥ずかしくないのか？
プログラマーに多すぎるんだよ。こういうの。
他人に迷惑かけまくって（この場合だと見づらいコード）注意されたら
必死に反論してくる奴。最初はまともな反論だけど反論できなくなると
すぐむちゃくちゃな理論持ち出して強引に自分の意見を正当化させようとするやつ。
邪魔だからいやなんだけど。
さっさと書き方直せ！！いやならせめて、他人に見せるコードの時くらいは直せ

>>613
通信？通信はrecv()で構造体を読み取った後にエンディアン合わせのためにntolとかでつよ
fread/fwriteによる構造体でのやり取りも、ntolみたいに対策とっておけば問題なしですよ。

まあ、開発するソフトが、常に同じ機種（ＣＰＵ）であるという前提があれば、
読み取りや書き込みの速度も速いしfread/fwrite使ってもよし。
異なるＣＰＵを想定するならば、ntolみたいに対策とればよし。

fread/fwriteを「絶対使ってはだめ！」という理由は絶対にない。

機種互換よりは、速度を要求される局面もあるし、そうでない場面もある。
fread/fwriteのメリット、デメリットを知らなければそれは「ヘタだなぁ」ではあるけれど、
メリット、デメリットを知りながら使いこなしているのであれば「うまいなぁ」とも思う。

スペースが気に入らんかったら
自動整形すりゃいいやん

そろそろそのヘタな時間の使い方を何とかした方がいい

ワードバウンダリ

>>622
　　　　　／＼⌒ヽﾍﾟﾀﾝ
　　　 ／　 ／⌒)ﾉ ﾍﾟﾀﾝ
　 ∧＿∧ ＼ （(　∧＿∧
　（； ´Д｀））'　））（・∀・ ；）
　/　　⌒ノ　（ ⌒ヽ⊂⌒ヽ
.（O　　 ﾉ　)￣￣￣(）__ 　 ）
　）_）＿） （;;;;;;;;;;;;;;;;;;;）（＿（

コーディングスタイル（if()と{の間には改行とか細かいスタイル）なんて、
ピーマン好きとか、嫌いかとか、そういう個人の好みの問題だと思うんだけどなぁ。
そんなもの日本語でいえば「方言」みたいなもんで、読みやすいかどうかにはさほど関係はしないと思う。

コードが読みやすい、読みにくいが決定される根本的な部分は、そんな「方言」みたいな部分でなくて、
構造の組み立て方や、よけいな変数多かったりとか、そういう部分だと思う。
言葉でいえば、主語がなかったり、「あれ」とか「それ」とか頻繁に使うような奴だね。

単項演算子の両端詰めるなとかいうのは、関西弁は聞き取りにくいから直せとかいってるようなもんで、
標準語に直しても意思疎通のしやすさには、さほど影響はないかと。

ピーマンの好き嫌いは重要な論点です

>>629
ピーマンだけは勘弁してください。ピーマンだけは勘弁してください。

慣れてないプログラマ(或いは無駄に経験だけあるSEでもいい)に取り扱い説明書かせると、
しばしば主語がオペレータになったりプログラムになったり画面になったりする。
そういう連中の書くコードもやはり、ifぶんなどで「何と何を比較して」の部分で
しばしば順序が入れ替わって読みにくい傾向はある。

>>631
読みにくい。

>>631
「そういう連中の書くコード」が読みにくいかどうかは知らんが、
一般的なコンピュータ知識しか持たない人間に向けたマニュアルに、
「検索の入力欄には%が使えます。DBのLIKE句と同じです」とか書いてあるのにはﾃﾗﾜﾛｯﾀ

一般人にLIKE句の意味がわかるかっつの。

>>628
ところでそのAAは何？

>>634
餅つけ→おちつけ

>>635
なるほど！

>>622
質問１、あなたのパソコンにはモノクロのモニターがつながっているのですか？
質問２、あなたはキーワードを色で別けられないようなエディタ（例えばメモ帳）を使ってコードを読んでるんですか？
質問３、あなたは強度の色盲ですか？
質問４、あなたは、ちょっと長い文になるような数式を平気でそのまま書いているのですか？
質問５、あなたは、両端空けないときちんと動作しないようなコードを平気で書いているのですか？
質問６、プログラマーに多すぎると理解してるのに、あなたの意見が少数である事を理解出来ないのですか？
質問７、他人のコードを見る時に、自分のスタイルにして見るのに、あなたのパソコンはどれだけの時間を使うのですか？

そもそも単項演算子はあける場合とあけない場合が混在するのが一般的じゃないだろうか。
二項演算子なら兎も角。

なぜかfor文だけは詰めて書くことが多い僕……

なんだこのアホ・・・・>>637
それが経験不足からくる発言だってんだろ？
大体ほとんどの人が読みづらいと思うコードを書いといて、
「読みづらいなら書き直すプログラム作れよ」とかふざけすぎ。
ちょっとは人のことも考えろカスが。

>>638
そりゃもちろん詰める場合もあるが、ここで話してるのは
何か特別読みやすくなるときを除いて両端は空けろってこと。

複数人で開発してるという意識があるかどうかだけどな、結局

ソースコードはドキュメントだ。このドキュメントを見づらくしてどうする。

>>640
再確認するが、単項演算子でか?
if (! flag) {
* ptr = - * ptr;
++ counter;
}
って書くのか?
if (!flag) {
*ptr = -*ptr;
++counter;
}
このように全部詰めてもそれほど読み難いとは思わんぞ。

VBってさ、二項演算子をくっつけて書くと自動的にスペース空けるのな

>>640
貴方のように簡単なプログラム作れないようなヘタレにも世の中は優しいもの。
既にそういうソフトはありますよ。

ソースの見栄えを気にしない人は貴方が勝手に変更しても気付きもしないでしょう。

>>641
複数で開発してようと、実際にコードを設計し書いてデバッグ作業の70％は一人でやってるもの。
ソースの空白が気になって仕方ないのに、自分でどうこうする工夫も出来ないような人は、単なるお荷物。
無視した方がいいでしょう

よそでやれ

いやここでやれ

教科書読んでると、空白無しなコードはよく見かけるんだけどなぁ。
空白開けろと力説してる人は、教科書とか読んでないんじゃないかと。
もしくは初心者用の本読んで満足してるとか。

Followup-To: japan.yoso

>>648
教科書は、初心者用ではないとでも？
つかなんだその腐った本。晒せ。

>>650
プログラミング言語C++ 第三版とか
UNIXネットワークプログラミングとか。

>>651
＞プログラミング言語C++ 第三版とか

http://public.research.att.com/~bs/3rd_code.html
これ?

あけてあるじゃん。　と思ったけど、一部あけてないね。
どういう法則性だろ。

> UNIXネットワークプログラミングとか。

ぱらぱらっと見た感じだと、あけてあるけど、そうでないところもあるのかな?

if (ready()) {
　flag = true;
} else {
　flag = false
}
みたいのは下手だなと思う

だから、空けたり詰めたりをエレガントに使うのが本当にうまいんだって

うん、";”が抜けてるしね

Numerical Recipes in C なんてぎゅうぎゅうだよ

>>655
空白の話じゃないんだけど……　違う人へのレスか？
>>656
見逃してくれ orz

>>643
ごめん。+ とか - とかだから二項演算子だった。首つってくる

西施の顰みに倣う
昔、中国の越にとても美しい人がいた。
西施という人だが、病気になってその苦しみに眉をひそめていた姿がさらにたいそう美しかったので、
そうすれば美人に見えるのだと思った近隣のブスがまねをして、しかめっつらをしたところ、
さらにブスが際立ったと、気味悪がられてしまった。


人のコードに憧れるのはいいが、肝は空白じゃないんだよ

憧れるなんて誰も言って無いが

びょーんすとらうすとっらぷは、「C++の設計と進化」でも空けたり空けなかったりだね。
りちゃーどは、空けてる。
空白詰めてるのヘタでしょ。


・浮動少数が等しいかを、==で判定してる。

しかも誰も空白が肝だなんていって無いが。常識だといっている

空白が常識ってどういう意味？

>>655
空けたり空けなかったりしてる人って、使い分けてるわけじゃなくて、
特に意識してないんじゃないの?

空白絶対空けろ男ウザー。

散々非難されてるのにしつこい。

こいつのコードがヘタかヘタじゃないかに関係なく、仕事一緒にしたくねー。

>>665
まぁ意識はしないよね。
手がきれいなコード覚えてるから。

int
main(int argc, char **argv)
{
}

とか書く奴も死んで欲しい。死んでくれる？お願い

>>666
非難っていうか、自分をヘタじゃないって思い込みたい人が、暴れてるだけじゃん。

>>667
特に基準があるわけじゃなくて、気分でやってるとか?

>>665
空白は空けろよ。
空白を空けるように指示するコーディング規約はあっても
空白を詰めなさい、っていうコーディング規約はないだろ？
空白を詰めることが醜くなるだけで何のメリットもないということだよ。
ｷﾐのような経験もスキルもない奴はコーディング規約を守っておけ。

>>622
>必死に反論してくる奴。

必死になのはお前じゃーん。なにその長文。キモイ。
つうか、空白が大好きな癖に、なんでそんなギチギチに書いてんの？
読みやすく段落ごとに空行ぐらい入れろよバカ。

>最初はまともな反論だけど反論できなくなると
>すぐむちゃくちゃな理論持ち出して強引に自分の意見を正当化させようとするやつ。

例えば、 >622なんかはかなり当てはまってるな。

>これが普通だし、普通だと思えない奴はただ単に経験不足。

お前は社会人として経験不足。たかがこんなことで暴れるなよ。

>>671
＞ 空白を詰めなさい、っていうコーディング規約はないだろ？
当たり前だ。
頭大丈夫か？

>>669
そう。お前のことな。

Perl とか Ruby だと、関数(orメソッド)呼び出しの
括弧が省略できるために、、
+ の左右に空白があるかどうかで
評価が変わってくる場合があったような気がする。

ぱっと見てｷﾓいなぁと思う仕様だった。

>>673
だから、当たり前のことだから空白を詰めるなって言うんだよ。
おまえホントバカだな。まだ理解できてないの？

世の中の本とか、有名ソフトはほとんど空けて書いてるし、
特に意識してなくて、普通に勉強してれば、空けてないのは
美しくないって感性が育つよね。

>>676
「空白は空けなくてもいい」という仕様書を見て
「空白をあけてはいけない」と読むキミは
プログラマに向いてないと思う。

>>654はなにが下手なの？

散々空いてないソースの本やらソースやらが指摘されてるのに…。

このバカ感性はどうやったら育つのやら…。

>>680
散々って、どれ?

>>679
直接、変数に代入しろってことでは?

>>677
当たり前のように嘘をつくのはやめたほうがいい。

>>683
うそじゃないでしょ。

詰める派の人は、上でウソを書いてるけど。

>>682
あ、そっか　サンクス

>>681
なんだ、文盲なのか。
それでそんなに空白に拘るのか。

はいはいそうかそうか。もういいや俺コイツ飽田。

>>684
嘘じゃないと思えるのなら、単にコードも本も大して読んで無いってことかな？

空けた方がみやすいときは空けるし、詰めた方がみやすいときは詰める。
詰めた方がみやすいときにバカのひとつ覚えで空けているコードを見るとヘタだなぁと思うね。
もちろんその逆も。

詰める派というか、絶対に空けろと強要するアホ派を諌めてるだけだけどね。

大体詰める奴って美的感覚がないよな。
部屋の中もいろいろなものがごちゃごちゃ散らかってるんだろうな。
机の上も常時モノでいっぱいｗｗ

>>684
そもそも、詰める派なんているのか？
妄想の中で敵を作って戦ってるだけじゃないのか？

元詰める派がなんかおっしゃってますね。

>>687
じゃ、詰めて書いてある本って？

>>693
ちゃんと例をあげてるじゃん。

昔の人も言いました。
重箱の隅をつつくような・・・と

>>694
ストラウストラップだけ?

空ける派の人は「if(p1[(p2-p1+1)/2]<v){ /* */ }」ってコードはどう書くの？（Ｃ言語での二分探索コードの一部）
「if ( p1[(p2 - p1 + 1) / 2] < v ) { /* */ }」？　もっと空けるの？

よ そ で や れ

空白を入れないやつはソースに対する愛情が足りないんだと思う

http://www.research.att.com/~bs/matrix.c

>>696
注意力が足りないんじゃないかと。

>>701
なんかはっきり書けない事情でもあるの?

関数の先頭で使う変数全部定義しているコードはヘタだと思うね。

そのコードはC言語だった説を提唱する

経験的に空白を入れないプログラマーにろくな奴はいなかった。


>>697
配列添字部分は式によっては詰めるね。俺は。

//
if (p1[(p2-p1+1)/2] < v)
{

}

>>705
ｷﾓｯ・・
吐きそう。

>>703
このまえニュー速で、コンピュータ関係のスレで、それ言ってるヤツがいたね。
C++で、関数の途中で宣言するのやめろとか。
本とか一切読まないのかね、ああいうのって。

詰める奴って読む人への配慮がぜんぜんないよね。
俺もよく途中で万歳した奴の尻拭いとかするけどそういうコードは今まで
すべて例外なく詰めて書かれていた。

空白入れろって言っている奴が
一人しかいない。

>>709
俺以外にも、最低一人はいるよ。

>>708
あのな。そりゃ偏見ってやつだ。
会社の中の人間のソースコードなんぞ評価せず、
もっと世界のうまい人のソースコードをみてみれ。

入れろって言うか、ヘタって言ってるだけだけどね。

>>711
著名なプロダクツのソースで、詰めて書いてあるやつって?

つーかなんだっけ？↓のソースだとどうなるの？ヘタの部類に入るの？
if( x == 7 ) {　　　　　　　/* ８個置き終えた */
　　printf( "Answer\n" );
　　printboard();
} else {　　　　　　　　　　/* 一つ右側について調べる */
　　for( z=0; z<8; ++z ) {
　　　　tryqueen( x+1, z );
　　}
}

if とか while の後に空白を入れないで、カッコの内側をあけてるのは、ヘタっぽいね。

>>713
いや、つめるか、つめないかは左程、重要ではないといいたい。
うまい人でも詰める人は詰めるし、詰めない人は詰めないといいたい。

具体的に誰と言われると、探すのめんどくさいから書かないが。

関数の途中で宣言するのやめろってスゴイな。
C++の超入門書ですら必要になってから宣言しろって書いてあるのに。

ifの後ろに空白入れる奴は頭おかしい。

>>713
ところでずっと不思議に思ってるんだけど、
「常に空白をあけるわけではない」を「詰めて書いてある」と誤読する
理由がわからない。

>>716
> 具体的に誰と言われると、探すのめんどくさいから書かないが。

すごいレアだから、探せないのでは?

>>719
詰めたり空けたりしてるやつもなかなか出てこないね。

俺は二項演算子の左右には空白を入れるけど
他人にそれを強制まではしないな。
読みにくいとまでは感じないからだけど。

1000行超える関数が多用されてて
先頭で wk とか t とか n とか言った名前の変数がたくさん宣言されてて
変数の説明をするコメントがなくって
wk があらゆる箇所で参照・書き換えされてて
50行くらいのロジックが繰り返し出てくるのに関数になってなくて
switch-case で default 句がないのにその説明すら書いてないことに比べたら
二項演算子の左右の空白なんてどうでも良くなる。

>>721
それはいっぱいあるでしょ。

>>718
if のあとを空けないのって、ヘタな日本人に多いね。

>>723
たとえば?

>>720
じゃあ、君が探してみれば？君がうまいと思ってるコードの書き方のプロダクツとやらを。

だるいだろ？

空白入れる入れないは上手い下手に関係ないわな。
他人が読む場合のことを考えているか考えていないかに過ぎない。

空白入れない奴は他人が読みやすいかどうかなんてどうでもいい奴が多いからろくでもない奴が多い。
自分で上手いと思っていても他人からしたら糞コード。

ifの後ろには既に(という区切り子があるのでわざわざスペースを入れる奴はアホ。

ifやwhileの後ろは空白
関数名の後ろは詰める

逆でもいいけど

>>725
とりあえずLinuxのカーネル(つかドライバ)コードなんかそんな感じ。

>>726
linux,FreeBSDのカーネルとか。

クラスを宣言するときに、
属性から書くか操作から書くかの論争並に不毛極まりないな。

昨日見た　Subversion　のソースも開けてた。

一箇所空けていたからって、
全部空けているという証明にはならない。

>>727
＞他人が読む場合のことを考えているか考えていないかに過ぎない。

詰めて書くほうが読みやすいと思って、俺はあえて詰めて書いてるけど。
詰めて書いてる人も「相手の読みやすさをまったく考えてない」わけではないと思う。

つーか詰めたほうが読みやすくね？

これはもう好みの問題だと思うのだが。
詰めた奴だって、相手・自分にとって読みやすいと思って詰めてるわけで。

VCの標準関数のライブラリ、MFCのソース、SunのJavaライブリのソースも開けてた。

>>736
大昔のCの入門書なんかだと詰めないとか改行せずに{とかっていうのが多い。
ようは古臭い奴らなのかも。
当然考えも古臭い。だから糞が多い。
納得。

各種コーディングスタイル関係の論争みたいに「宗派」が分かれてたら、
好みの問題ってことになるけど、まともな本やプロダクツはほとんど、
空けて書いてる。

>>737
で、最近の入門書はどうなんだ？
古臭くないから糞じゃないんだよな？

>>738
で、まともな本やプロダクツってなんだ？
もし、空けて書いてある本とか言ったら殺すぞｗ

>>739
まぁ昔よりはましなんじゃないか？

具体的な話は出さずに「まとも」とか「常識」で逃げるのは変わってないのね(w

>>741
たとえば？

>>740
ｷﾞｬﾊｗｗ
ﾌﾞﾁ切れじゃんｗｗ

>>738
というか別に君の周りでヘタだった奴がたまたま詰めて書いてる奴だった。って理由だけで、
全世界の詰めてる人間をヘタ扱いするのが謎。

>>740
あなたの持ってる本ってどんなの?
ちょっと確認してみてよ。
空いてるだろうから。

java3dのGMatrix.SVDはぎゅうぎゅうだね。
ニューメリカルの影響か知らんけど、
数値計算系は詰める傾向が多いね。

大多数は、基本は離して、ダラダラしてきたら適所で詰めるってのじゃない？

>>743
まぁ言語の本じゃないけど誰もが認める名著のAdvancedWindowsのサンプルソースとか。

>>745
周囲っていうか、世間で評価されてる本やプロダクツは空けて書いてるよ。

ちなみに世間で評価されている本とはすなわち、空けている本のことだから。

>>747
> 大多数は、基本は離して、ダラダラしてきたら適所で詰めるってのじゃない？

大多数は、空けるのが基本だよ。

盛り上がってるね

詰める派は、世間で評価されてて、詰めて書いてある本を列挙すればそれで済むことなのに
それができない。。。

空白を開けてあるコードは糞のガイドライン

理由
・厨房のコードの90%は空白を空けて書いてある。

まだ仮想的「詰める派」を相手に戦ってるのか。

>>753
空けて書いてある本意外は、空けたり詰めたりで書いてあるんじゃないか？

空けて書いてある本がいくつ列挙されているか知らんがｗ

>>749
逆。詰めて書く奴はすべてヘタであることを証明してくれ。

「詰める奴はヘタだ！」と決め付ける態度を取るなら、
世界のソースを全部みて、詰めて書く奴がすべてヘタであることを証明してからにしろよ。
それを調査してはじめて「詰める奴はヘタだ！」っていえる言葉だと思うぞ。

俺の周りがそうだったから、とかそんな理由だったらあまりにも失礼。

>>756
あなたの持ってる本で、空けたり詰めたりしてる本って何冊ある?

>>751
『プログラミング作法』は適所詰めることを推奨してるよ
>>753
いや、だから『ニューメリカル・レシピ・イン・シー』とか読んだらアンタ卒倒するんないの。
この本のコードの本当に酷いのは無理やり配列を1から始めてるところだけど。

無駄だと思うなぁ。
いくら例を示しても無視して自分の主張書くだけだから。

空白を入れないってことは英語の文章で単語の間にスペースを入れないようなもの。
Icanflytennis.とか言われても分かり難いだろ？

ある二項演算子opについて
　(A) opの左右は必ず空ける。
　(B) opの左右は基本的に空ける。場合によって詰める。
　(C) opの左右は基本的に詰める。場合によって空ける。
　(D) opの左右は必ず詰める。
という４パターンがあるが、ほとんどのやつはBかCだろ？（おれはB。）
演算子によって使い分けるやつもいると思うし（例えば&&と||が混在する式では&&の左右は詰めるとか）。
で、頑張ってるやつはAか？　それともDに対して文句たれてるんのか？
Dなんかいねぇと思うぞ。

おれもＢ

>>759
プログラミング作法ってカーニンハンのやつ?
たしか会社にあったから、見てみるよ。
ソフトウェア作法のほうでは、全部空いてるようだけど。

あ、有名どころでぎゅうぎゅうの思い出した。
つlibvorbis

「必ず空ける派」は大変だよな。本に載ってる全コードをチェックしないといけないんだから。
「場合によっては詰める|空ける派」はとりあえずほかと違ってる部分を見つければいい。

ほとんどのヤツは(A)だから。
(まともなのは)

俺もＢだな

>>766
そのあたりは、だいたい一貫してるのから、そんなに大変じゃないよ。
ストラウスとラップは、一貫してないけど。

>>761
これのどこがわかりやすいんだ？ｗ

I c a n f l y t e n n i s

場合によっては空けたり詰めたりって人は整形ツールとか、スタイルをチェックするツールとかは使わんのかね?

空白は決して怖くありません、自信をモテクダサイ。

ん〜boostは空けたり詰めたりだな〜

>>771
たいていの整形ツールは、演算子の前後に空白を入れない設定も出来る。

よい子はツールに使われるような大人になっちゃダメだよ

>>774
その場合は、一貫して詰めたコードになる?
それとも、空けたり詰めたり、ルールで指定できる?

(A) 1
(B) 3
(C) 0
(D) 0
(AHO) 1 (>>770)

　(E) opのフォントだけ小さいフォントを使い、opの左右は必ず詰める。
ですが何か？詰めても見易いよ。

>>773
ほんとだ。
boostは空けたり詰めたりだね。

>>771
ものによるな。
オプソものとかでいわゆるGNUスタイルで納品したほうが良さそうなのは
indentかけることもある(手でGNUスタイル書くのが苦痛だから)。

>>778
そこだけ小さいフォントを使うってことは空白入れてるようなもんじゃない？
そのままだと見辛いから小さいフォント使ってるんでしょ？

>>777

>>770は数字の100とかを1 0 0 って書く奴だと思われ

たとえ空白空けるで統一されていたとしても、
それは単に整形ツールでそうなっただけのことであって、
それが良いコードというわけじゃないんだよな。

>>770を見てもわかるように、
適切に空白を入れたり詰めたりしろってこった。

STLPortは空けたり詰めたり
ODEは空けたり詰めたり
quake3は空けたり詰めたり
rubyは空けたり詰めたり
pythonは空けたり詰めたり

もう漁るの飽きた。やっぱある程度の成果物は
徹底して詰めてるor空けてるのはほとんどないんじゃないの？

>>770は>>761のアフォさ加減に合わせてやっただけじゃね？
二項演算子と識別子に出てくる文字種は基本的に異なるから>>761は意味ねぇよ。

複数人で書かれたソースに対して空けたり詰めたりっていうのを調べるのは意味が無いだろ。
その部分の担当者が徹底して空ける人だったり徹底して詰める人だったりする場合もある。

でも英語の文章考えたらifの後にスペース空けるのは自然だな。
aaaa( bbbb cccc dddd )eeee.
aaaa(bbbb cccc dddd)eeee.

こんな括弧のつけ方しないもんな
普通はこうだよな。
aaaa (bbbb cccc dddd) eeee.

空白空けたり詰めたりでも、どうでもいいから修正されずにマージされてるんだろｗ

一人で書いたソース調べる方が意味無いと思うけど。
それこそ、ほとんどが小規模なプロダクツだろうし。

VB.NETでIfにAndやOrを使ってるコードはヘタ

修正の結果かなんだか知らんが、常に偽になるifブロックを見ると勘弁してくれって思う。

完全に整形されてるのは印刷する時とかの為にツールを通してるんだろ
コード書くとき、いちいち文法に関係ない空白をどうするかなんて考えもしないよ？

他人に読んでもらうために・・・・って他人のコード読むのに空白なんて何の支障にもならないと思うのだが？

プログラミングってのは、機能に名前を付けてゆく作業だから、肝心なのは名前付の方。
機能は名前通りに実装されていればそれでいいわけで
実装である演算子のレベルまでいきなり読むわけじゃない

>>697
空白とは関係ない話だが

＞if(p1[(p2-p1+1)/2]<v){ /* */ }

これが既に　コナレているかどうかの方が大事かもね。
自分はこの手のコードを　 wihile(c=*p++){ /* */ } 程にはパターン化していないから
中間変数を入れて２行に別けてしまうな
{ cent=(p2-p1+1)/2 ;
　if(p1[cent]<v){ /* */ }
}

中間変数を使う場合はC++でもブロックを書く事が多い

職業プログラマってのは矛盾を抱えている。
大量に人を必要とする所ほど、人が居つかない。
慢性的なデスマーチ、疲弊し去ってゆく兵と補充される兵。
その回転の為に「他人が読めるコード」を強制しようと、
コーデングルール他、訳の判らない規約が作られ、
結果それがさらにプログラマの体力を奪い、回転を早める。
そういう現場では人もコードも使い捨て、
コードを使い捨てたくないと作った規約が余計にコードを使い捨てさせる事になってゆく矛盾がそこにある。


まあしかし、この矛盾の根っこは深く、プログラマレベルではどうしようもない。
キツイ規約は労働の証。　労働契約は努力義務でしかない。
いつまでも労働では搾取されるばかり、どこかで自分もまた転回する事が必要なのだろう

大企業のは見ないほうがいいかもな
俺はMFCは世界最高の技術者が書いたと信じてまねてたからなｗ
今はJoel de Guzmanまねてるよ
見た目だけなｗ

>>792
今は一時的に使わないコードだけどコンパイルはしておきたい(≒メンテナンスしておきたい）場合は敢えて
if (0) {
...;
}
ってことやるけどそれも勘弁して欲しい?

>>797
つCVS, Subversion, VSS, GNU arch, ...

>>645
てことは30%も他人に手が入るのに独善的なあなたみたいな人がいるんだね。
ソースが汚い分、ドキュメントやコメントを多く書いて時間稼いでるんだね

>>797
そんな女々しいコードは嫌だ。

>>798
現場で必要なテストコードなんで、入れておきたいのですよ。
最近のコンパイラならエラーチェックだけして出力には影響しないところが味噌でね。

o・）Σ
女々しいっすか……

>>801
だったらif (0)じゃなくてif (DEBUG)とかしてDEBUGを別に定義したりしない？
（プリプロセッサ通せば一緒だけど、ここはコードの話だから）
DEBUGを変数(debug)にして外部から与えるようにすれば、再コンパイルの必要もないし。
if (0)のメリットがわからんです。

関係ないけどSunのJava Tech Tipsに、if (debug)は性能を劣化させないとかいう記事があったな

起動時の引数とか、設定ファイルとかでテストモードかどうかを
切り替えればいいんじゃないかと。
現場でコンパイルする手間も省けるし。

仕様が確定してないとか、将来実装する予定とか？

>>805
そそ、そんな感じで。
現場で「ちょっと試してよ」に対応するコードとか。
ある程度長期生き残るものならマクロで分岐するか>803のようにするんですが。

ほら、>>793のように空白を入れない奴はろくでもない奴だろ？
他人のことを考えない独善的な人間だから思考が１人で完結してる。

>> 他人に読んでもらうために・・・・って他人のコード読むのに空白なんて何の支障にもならないと思うのだが？

客観性まるでなし。
こういう奴は空白以外の部分でも糞コードなのは間違いない。

>>807
あなたの書き込みを読むと、全ての批判はご自分に該当するように思えますが、たぶん眼鏡が曇ってるのでしょうね。

ぶっちゃけ何処の誰かも分からないやつの書き方なんてどうでもよくね？
ほっとけよ

まあまあ。
汚いソース読まされてイライラさせられた人じゃないとわからんよ。

他人のコードを読むのはコツがある。
空白とかスタイルのせいでイライラするような事はないよ。

＼|／
/⌒ヽ　　　／￣￣￣￣￣￣￣￣￣￣
| ゜Θ゜）＜　そうでもないよ
|　∵　つ　＼＿＿＿＿＿＿＿＿＿＿
|　∵　|
＼＿／


他人の考え方は読める。
ジェネレートされたコードは考えも伝わってこないからツライ。

>>788
> aaaa( bbbb cccc dddd )eeee.
こんなのが山盛りのソースのメンテナンスが、俺に回って来た!

ジェネレートされたコードって・・・・まあ逆アセンブラ出力から全体を読むのは、それは面倒だね

他人のコードを読むといっても色々だけど読まされるとするなら
　１、単に該当箇所の修正
　２、新規に作るが動作仕様がソースからしか判らないと言われた
　３、指導者としての立場

があると思うが、
　１なら、基本的に触らないのがコツ。　修正ではなく、とにかく追加してゆく。
　　　その後の人はさらに大変になるだろうが、そんな事はこっちの仕事じゃない

　２なら1ファイル毎に、実際に動作させてゆく。　それが必要とする関数をエミュレートというか適当にでっち上げるような感じね
　　組み込み系なら、実行環境もどきを最終的に作ってしまう事になる

　３なら、もっとおおらかにいった方がいいよ

関数はつける、関数以外は括弧なしか、離す。

おまえら空白の他に話すことはないのかよ

空白くらいエディタの設定でどうにかなるだろ？
読み込んだら自動的に自分の好みの方法で表示して
保存するときに勝手に規約に沿った形にすれば良いだけなんだから。

>>817　全て他人とは自分に奉仕するもの　という発想だから、そんなメンドクサイ事はしないんでしょ。
だったらプログラマもやめればいいのに

>>813
好きなスタイルのindentのオプションは何なの？

>>806
コンパイラのオプションにマクロシンボル定義するオプションがあるだろ？（bccだと-D）
それ使ったほうがよくね？

for(int i = 0; i < 4; ++i){
　　switch(i){
　　case 1:
　　　　/* なにかコード */
　　　　break;
　　case 2:
　　　　/* 別のコード */
　　　　break;
　　/* 以下略 */
　　}
}
お前はfor文というものをどう考えているのか問い質したくなる。

for(int i=0; i<4; ++i){

これ見にくいか？

>>821
久々にまともな「ヘタだなぁ」の例で嬉しい

>>882
俺も普段は空けるが、()内が短い場合はそんな感じ。
ただし、for (..) {だけど

おまいら、こんなとき空行あける？

if(...) {
meirei1();
meirei2();
} else {
meirei3();
}

と

if(...) {

meirei1();
meirei2();

} else {

meirei3();

}

行を空けないでインデントしろ

>>821
こんな感じのコードは良く書く
for(int i = 0; i < 16; ++i)
if(HogeFlag & (1<<i)　)
　　switch(i){
　　case 0:
　　　　/* なにかコード */
　　　　break;
　　case 1:
　　　　/* なにかコード */
　　　　break;
　　case 2:
　　　　/* 別のコード */
　　　　break;
　　/* 以下略 */
　　}

それってforを使う意味あるの？

>>828
意味ないよ。　1個づつ if 文書くのと等価。　でも書いちゃうんだよ

昔見たコード。
int main()
{
switch (0) {
case 0:
someFunc();
case 1:
otherFunc();
case 2:
moreFunc();
default:
break;
}
return 0;
}

まあ俺も最後仕様変更くらって、やっぱり必ずsomeFunc、otherFunc、moreFuncを全部呼んでください。
って言われたらそうすると思う。

>>831
main()に、その他の制御構造が何もないことに注目。

>>830
成程と思った

>>832
は？それが何か？

>>834
なんも思わないのか……　すごいな

スタイルの問題なのかもしないが

// 奇数の場合
if(value%2){
　　：

// 偶数の場合
}else{
　　：
}

というコメントの書き方は（特にelseのところで）途惑う。

>>835
俺もなにが言いたいのかわからん。
someFuncの実装すら書いてないんだから、main()のその他の処理も端折って書いたと思った。

>>836

if (value % 2) { // 奇数の場合
　　：

}
else { // 偶数の場合
　　：
}

としてるな。

ここからは if-else について語る？

俺は
if(cond){
　　stmt;
}
else{
　　stmt;
}
ですね。

以前は
} else {
だったんですが、"else{ ... }" を一まとまりにした方が、
else (や else if) の評価の順番変える時とかに都合が良かったので。

はっきりいってコーディングスタイルの話はどうでもいい

>>836
DB系のなんかの言語は、確かブロックの先頭にコメントが書けないので
そういうスタイルになる必然性があった希ガス。

ドラゴンボール系？？？

If Rtn = True Then
　　Workbooks("A.xls").Worksheets("Sheet1").Cells(1, 1).ClearContents
　　Workbooks("A.xls").Worksheets("Sheet1").Cells(1, 3).ClearContents
　　Workbooks("A.xls").Worksheets("Sheet1").Cells(2, 1).ClearContents
　　Workbooks("A.xls").Worksheets("Sheet1").Cells(2, 3).ClearContents
　　Workbooks("A.xls").Worksheets("Sheet1").Cells(3, 1).ClearContents
　　Workbooks("A.xls").Worksheets("Sheet1").Cells(3, 3).ClearContents
　　Workbooks("A.xls").Worksheets("Sheet1").Cells(1, 1) = Workbooks("B.xls").Worksheets("Sheet3").Cells(I, 3)
　　Workbooks("A.xls").Worksheets("Sheet1").Cells(1, 3) = Workbooks("B.xls").Worksheets("Sheet3").Cells(I, 4)
　　Workbooks("A.xls").Worksheets("Sheet1").Cells(2, 1) = Workbooks("B.xls").Worksheets("Sheet3").Cells(I, 6)
　　Workbooks("A.xls").Worksheets("Sheet1").Cells(2, 3) = Workbooks("B.xls").Worksheets("Sheet3").Cells(I, 8)
　　Workbooks("A.xls").Worksheets("Sheet1").Cells(3, 1) = Workbooks("B.xls").Worksheets("Sheet3").Cells(I, 9)
　　Workbooks("A.xls").Worksheets("Sheet1").Cells(3, 3) = Workbooks("B.xls").Worksheets("Sheet3").Cells(I, 12)
Else
　　Workbooks("A.xls").Worksheets("Sheet1").Cells(1, 1).ClearContents
　　Workbooks("A.xls").Worksheets("Sheet1").Cells(1, 3).ClearContents

以下省略。Then内の行数は実際の3分の1で書きました。
"B.xls"が修正された為正常に動かなくなり、私がメンテする羽目に。

約２画面分を覆いつくすコピペに背筋が凍りました。

マジックナンバーはヘタ云々以前の話かもなあ。

java 使ったプロジェクトで singleton 使ってるコードがあって
なぜかコンストラクタが protected だった。
コメントに「privateにすべきだが、テストのためにprotectedにする」
とか書いてあった。
何のためのテストだろうと不思議に思った。

>>844
class A{};
class TestA : A{};
だろ？
protectedメソッドをテストするにはこうする必要がある。

protected にして844の反応を見るテストに違いない

>845
いや、そうじゃなくて。

もともと singleton として使うクラスで、
コード書いてる人も singleton パターン自体は知っている。
のに、テストするために protected にしてる。
普通はありえないけどパッケージ内から
ぼこぼこインスタンス立てまくれる。
それを制限するためのパターンなのに、
本末転倒だろうと。＞何のためのテスト

オリジナルコードに手を加えなきゃ実行できないようなテストは（本番でも実行されることがないのだから）する必要ないと物の本で読んだ気がする。

>>827-828
俺もたまにそうすることがある。

たとえば、CSVを char * の配列に入れたあとで、0、1、2の
カラムはそれぞれ何か違う処理をしないといけないが、3より
あとは全部同じ処理という場合、など。まあ、個別に書いても
いいんだけどね。for で回してもいいじゃない。人間だもの。

　　　（ ´∀｀）＜ みつを

>>843
でも、マクロだと、あるいみ仕方ない面もあるね。

Workbooks("A.xls").Worksheets("Sheet1")　で一旦変数に代入する程度はやるだろうけど

for 文で回してもそう判りやすくなるわけじゃないし
if 文の前に共通処理を吐き出しても、 Rtn の作成箇所から離れるのも嫌だし

>>851
こういうものは名前付き領域のコピーで済ますとメンテは楽になる
ドキュメントがなくなると地獄が待っているが

C++でキャストするとき、static_cast, reinterpret_castとかって使ってる？
それともCスタイルが普通？

c++専用コードなら使うと思うのだけど　cとの共用コードが多いからしょうがない

ぱっと見て「ベタだなぁ」と思うコード

俺が3時間ぐらい悩んだヘタC言語コード

if (logfile == NULL);
　　return;

まあ、logfile はログのファイル名が入っている char * なんだけど、
これをログを出力する関数の先頭でやっていて、一切のログが出力
されなくなった。

で、コンパイル後のコードが異様に小さいわアセンブリ言語まで
出力させてなんでこんなに小さいんだろうと、冗談抜きで3時間ほど
悩んで、10分ぐらい前にセミコロン発見。orz

こんなバグ作ったの何年ぶりだろう。

>>856 ソレは良くやるミスで　ヘタというより、Cに文法上の配慮が無いのが原因だろな

コンパイラによってはreturn の後に警告が出るけど、出ないのもあるし

ifの{}省略禁止ってコーディング規約を作るだけで解決しそうだが・・・・・・
if (logfile == NULL);{
　return;
}
とか、やられたら意味ないがｗ

>>856　滅多にやらないけど、滅多にやらないから、自分がそんなミスするとは思えなくて長時間気付かないんだよな

そういや if (...); というのを文法上許しているってのも奇妙な感じではあるな。
コンパイラが警告一つ出さないってのもまた何とも。

実際こんなの必要になる時はないよなあ。for (...); とか while (...); なら
ループして繰り返すから意味のあるものが作れるが、 if (...); は一体どういう
時に必要となるのかが想像できない。

ブレークポイント設定したい時

マクロを作る時に　式の結果を絶対に使わせんという場合とか

>>860
ごく稀に
　if (…)
　　;
　else
　　なんたら
というコードを見かける。
判定条件を逆にすりゃいいのにと思うが、それなりの意図があるらしいｗ

>>858
while(flag);
{
　;
}
のコーディングスタイルだと{}あっても分かり難いです　昔泣きました

そんなもん見た瞬間気がつくよ。
コーディングスタイル関係ない。

だそうですｗ

vcだと警告してくれるけどな。

>>865
いや、机上で流してると目は見てても脳が読まない可能性はある。
て言っても、テストが付いてりゃ範囲は局所化されるから、あとは
デバッガでトレースしてみれば直ぐにみつかる類のバグだけどな。

ただのバグにうまいもヘタもない。

公正取引委員会が教科書の金品を伴う売り込み規制を撤廃へ
金儲け主義の教科書が学校を埋め尽くし、教育品質の低下を招く！？
意見は下記の公正取引委員会のページより
http://www.jftc.go.jp/info/p-comment.htm
４月17日締め切り。

>>868
俺はデバッガ(gdb)も使ったのだが、いきなり関数の最後の } に飛ぶんだよ。
もう最適化されちゃってどこから飛んでるか分かんないの。(最適化を強制的に
させないオプション使ってコンパイルすれば良かったか?)

人のプログラムは基本的に読みにくいんじゃないっすか？

>>863
　すまん。俺それ多用するわ。

　・ == NULL とか if != 0 とか書くのマンドクセ。
　・ if ( !li ) とか if ( !ill ) とか、何だよ、八卦かよ。
　→ なるべく 0 と比較し、かつ 0 を省略。 ! もなるべく使わない。
　→ 論理の融通がきかないので、 if ( p ) ; else { } 登場。
なんと if ( p ) { ... } else ; 役に立たないっつーか警告が出る else ; まで書いておくことも少なくない。あほだ。

　あ、 if != 0 だって　ﾐﾟｍ ﾟ ﾐ ﾌﾟﾌﾟ
手拍子で if ( p != 0 ) と書いちゃって消し損ねた。あほだ。

ねよう……　ﾐー仝 ー 'ﾐ_｡o○

#define unless(exp) if(!(exp))

bool b;

///長いコード


if( b == true )
{

}

このtrueは「俺はbool型を比較してるんだぞ」と強調するために書いている。
文句をいわれる筋合いなどないわ！

×if( b == true )
○if(b==true)

その状況で b なんて変数名をつかっちゃうところがヘタクソ

変数の存在を忘れてしまうような長いコードがダメすぎな気が。

if の中は条件式を評価するのだから
if(cond){ .. }　か if(!cond){ .. } で良いと思う。
cond == true とかは時間の無駄というか
if の中なのに true 以外の何と比較するのだろう、と。

int i;
...
bool b = i != 0;

変数名は有効範囲に応じて省略形ってのが格好いいと思うよ

#define true 0
#define false 1

C言語で無限ループを作る場合、俺は while (1) という書き方が嫌いだ。
for (;;) の方が好き。

for (;;) 　は　可変幅フォントで見ると、ちょっとH

俺は
A:

goto A
のほうが好き。

>>885
無限ループを作ろうとしたとき、本やネットなどで見たことなしに for (;;) で書いてた？
俺は while (1) で書いてて、後で for (;;) を知ったので逆の感覚だ
あれこれ言い合うほどのこだわりはないけど

#define ARRAY_INDEX1 1
#define ARRAY_INDEX2 2
#define ARRAY_INDEX3 3
(ry

#define ONE 1

こんなことやってるコード、現実にホントにあるんだねorz

>>888
その名前だったらヘタだけど、意味がある名前なら連想配列感覚でいいかもよ

>>877
if ((b == true) == true)
だったらこのほうがよいのでは？

>>889
いや、分かりづらかったかもしれない

ループなら 1回で済ませられるのに
こんなん使ってずらずら並べてる箇所がいくつもあるんでつorz

>>890
if ( (bool) b )
はいかが？

>>877
ぜんぜんOK

参照型言語(VB.NETとかJavaとかC#とか)で
関数の引数に参照を渡すのと参照渡しを混同しているのを見ると大丈夫か？と思う。

同じく参照型言語で
なんらかのオブジェクトへの参照をコレクションから取り出してそのプロパティなりメソッドなりを使ったあと
最後にコレクションに格納しなおしているのを見ると、なんも考えてないんだなと思う。

>>890
if (((b == true) == true) == true)
だったらこのほうがよいのでは？

・・・という風にして、if (ブール値)なんだということを悟ってもらうのが
普段の教え方。

>>894
筋が悪いな。
繰り返しを発見したらループにするのが鉄則だろう。
int ct = 0;
while(b = (b == true))
　if(ct++ > 100000/*これくらいやっておけばほとんどのケースで十分*/){ puts("b == true"); goto finish; }
puts("b != false");
finish:
これで判定可能だ。

ifの中はブール値でなければならないわけで、
変数や関数の名前が、たとえばisFoo()のように工夫されており、
ぱっとみで、ifの中はちゃんとブール値になっているなと分かるときは、
if(isFoo())でも良い。

もしvalueのように中身がブール値かどうか分からない名前の場合は、
if(value==true)する。

if((value==true)=true)なんてのは、最初のvalue==trueの時点で
ブール値だと明確になっているので必要ない。

修正
×if((value==true)=true)
○if((value==true)==true)

ぱっと見てブール値かどうかわからない名前をつけるなんて「ヘタだなぁ」と思う。

if ( (bool) b ) は単にbをキャストしているだけで
bそのものがブール値だと明確になっていない（int bかも知れない）ので駄目。

b および bなんたら はブール値と命名規則で
決められているのならいいけど。

いまさらハンガリアン？

WebアプリのGUIは未だにハンガリアンにしてまうなぁ…
txtUserIdとか、rdoMaleとか。

ASSERT(typeid(b) == typeid(bool));

>>898
>>877とか>>881に言ってくれ。

> if の中は条件式を評価するのだから
> if(cond){ .. }　か if(!cond){ .. } で良いと思う。

「if の中は条件式」なので単体の変数がくるとは限らない。
condとは式、すなわち、i=1や、0<i && i<10なんて場合もありえる。
"cond"ではなく"checked"なんて名前ならif(checked){ .. }でいいが、
"cond"って名前ならcond==trueにするべきだ。

要は名前の問題。

でもチェックボックスのcheckedはチェックされた状態でも、
チェックされてない状態でもない、第三の状態（未入力？）が
あったりするんだよな。まあ名前の付け方が悪いんだが。

>>899
C/C++を使う限りbがintだろうとchar*だろうと無問題。
それで混乱する奴は単に文法に不慣れなだけだろ。

if (b == true) {　でも
if (b) { でも、asmでは同じもんができあがるだから、
意図が明確な方がいいんじゃね？

>if (b == true) {　でも
これ書いた奴がアホなのか何なのか読んでて不安になるから却下

>884
これ（ネタだろうけど）見て思い出した
Cのソース
#define TRUE 0
#define FALSE (-1)

既出？

>>901
それは、Camel形式だと捉えれば無問題。

>>906
それだけ見て、アホかどうかわからんが、
全体みりゃわかる

>>905
>>890のほうがもっと意図が明確だと思わないのか？

エンディアンの扱いを考えていないソースを見るとちょっと嫌になる・・・

>>911kwsk

>>912
例えばリトルエンディアンで数が格納されたバイナリを読み込んで、
そのまま変数に格納しちゃってたりしてる奴。
リトルエンディアンなプロセッサじゃなきゃ絶対おかしくなる・・・

>>910
>>890は、日本語で表現すると
まったく違う条件を書いていることに気がついてないの？

>>913
要件がそうなってれば問題ないし、たいていのシステムではなってると思うけどね。

>>913
異なるプロセッサで動かすことを要求されていなければ、問題ないだろう。
ネットワークに流すときは同一プロセッサ同士でも一応ネットワークバイトオーダに
変換してくれとは思うが。

>>913
ビッグエンディアンで読む予定がないなら不要だろ。
プロジェクトの性格に関係なく最初から無駄にポータビリティを確保してる奴はｱﾌｫ。

>>915
そうなのか・・・
なら私はあのプロジェクトから手を引いて、移植が失敗するのを見守るか・・・

>>918
キミがいなくても、問題なく移植できると思う。
もし失敗するのなら、エンディアン云々以前の問題。

なんにしても、権威主義にとらわれないことだね

>>910
本当にそう思うなら、理由を説明せよ。

上からざっと読んできました
プログラマーとして就職したのに全然言ってることわかりません
怖くなってきた

if(price){...}

どう思う？

なんとも

「もし金なら」と思います。

priceはブール値だとこの行だけでどうやって判断すればいいでしょうか？

>>923
ちょっと天狗になりかけてるプログラマが書きそうだな

>>926
言語によるのだけど C 言語には論理型はなく　論理値もどきがあるだけ
if や && || では　0かどうかという比較になる

だから 代金が0でなければと読む事になる

>>926
priceはブール値だとこの行だけでどして判断しなければならないのでしょうか？

っつーか、なんでブール値にこだわりたがるのかそこが分からん。

priceは実はポインタ型、とか。

riceへのポインタということか。

>>928
新人君に一々説明するの大変そうですね

>>930　ポインタでも、結局はゼロかどうか