この会社辞めようと思ったソースコード＃Ａ

848 ：仕様書無しさん：03/05/30 22:40

retrun

849 ：仕様書無しさん：03/05/30 22:59

>if(i==0)をif(i=0)って書いて
>間違いに気付かずハマってる奴は結構多いよ

そのコードにwarningも出ないような、十数年前のコンパイラを使ってる方が多いのですか？

850 ：仕様書無しさん：03/05/30 23:11

>>849
> そのコードにwarningも出ないような、十数年前のコンパイラを使ってる方が多いのですか？

世の中あなたが使ってるようなメジャーどころのコンパイラばかりじゃないですからね

851 ：仕様書無しさん：03/05/30 23:13

>>846
構造化プログラミングって知ってる?

>>849
悲しいが開発環境に自分を合わせられるのもPGの能力のうち。

852 ：hn ◆iKwMOjCT4s ：03/05/30 23:17

やっぱ if(0==) は違和感ブリバリ

i が 0 なら、やる　というのが自然に分かっていい。warning 出すコンパイラにもっと頼れ。

(ちなみにjavaじゃ if は真偽返さなきゃいかんね。)

853 ：仕様書無しさん：03/05/30 23:21

>>847
> ってことだろうけど、この書き方を徹底的に嫌う奴が多いから

（例）
>>852

854 ：仕様書無しさん：03/05/30 23:28

今時 if (0 == i) なんて書きたくて書いてる奴はほとんどいない。

＞if(i==0)をif(i=0)って書いて
＞間違いに気付かずハマってる奴は結構多いよ
warningをdisableにしてるやつかな？
warning鬱陶しいからといって重要な警告まで抑制するなんてｱﾎなだけだと思う。

855 ：817：03/05/30 23:34

遅いレスですいません。
もちろん、if (0==i)の意図はif (i=0)というミスを防ぐためで、
そこまではわかりますので、まぁしたがってもいいかなと。
しかし、間違い(誤代入）の起こりようのない不等式の場合も
if (0 < i)だし、あろうことかif (0 != strcmp(s, t))なんて変態的な
書き方まで強要されるのでいらいらするのですね。
大体右辺左辺ともに変数だったらどうあがいても無駄じゃん…。

856 ：hn ◆iKwMOjCT4s ：03/05/30 23:40

わかった。適当にソースコード整形フィルター作れ。コミットするときだけ整形しる。

857 ：817：03/05/30 23:43

>>856
あ、それいいね。そうしよ。

858 ：仕様書無しさん：03/05/30 23:45

if (0 != strcmp(s, t))を後からif (0 == strcmp(s, t))にする
可能性は否定出来ないな。

>変態的な

もともと一般人から見れば==だって!=だって十分変態的だと思うが。
左右が変わるぐらいで騒がなくても。
まあ、オレはそんな書き方しないけど。

859 ：hn ◆iKwMOjCT4s ：03/05/30 23:47

ちゅうかしかし、周りの人はどうよ、適応しているのか？

チームワークの観点からすると、できれば適応できりゃいいが、
皆がぶつくさ言いながら従ってるっていう状況なら（わからんけど、上司が異常なプライドの持ち主ってことはよくある話だ）
ナントカできないか考えたほうがいいよなぁ。

860 ：仕様書無しさん：03/05/30 23:51

0 == i は日本人には分かりづらいから
i == 0 にしろといっても・・・。
if ( 0 == Panel.Labals.Items.GetSaruGechu( PSP, FuckU) )
＃　if ( Panel.Labals.Items.GetSaruGechu( PSP, FuckU) == 0)
＃　これは分かりづらい。結果を先に言えって主義なので。
なる使い方する場合も考慮すると、
0 == i　の方が統一感あるので、好きだ。

861 ：仕様書無しさん：03/05/30 23:52

０より大きく１００より小さい時
（A）　if((i > 0) && (i < 100))
（B）　if((0 < i) && (i < 100))

（B）を使ってしまう俺は会社辞めたほうがいいですか？
0 < i < 100 をイメージして書いてるのですが・・・

862 ：仕様書無しさん：03/05/30 23:54

3つ目を&&でつなぐときはどう書くのよ?

863 ：仕様書無しさん：03/05/30 23:54

>>861
それは、漏れも(B)を使う達です。

864 ：仕様書無しさん：03/05/30 23:59

範囲を書くときとか、順序が明らかになってほしいときとかは（B）だな

865 ：hn ◆iKwMOjCT4s ：03/05/31 00:00

OO言語じゃ .eql とか .equals とか == がメソッドとして定義されている場合が多いから、
やっぱ比較対照が前にあるほうが自然だ

866 ：本気にしちゃダメっす：03/05/31 00:02

(例1)
　　if( （hogehoge == 0)
　　 || (foo == 0) )
と書くより、
　　ｉｆ( (0 == hogehoge )
　　 || (0 == foo) )
と書く方が演算子が揃え易く、見た目が整然とする

(例2)
　　ｉｆ( this_is_long_name_function( this_is_longname_var, ...
↑のように画面からはみ出す位長い関数の戻り値を
見て分岐する処理があったとする。
関数の戻り値はbool型だから、trueを返してきたら実行か、
と思ったら末尾が
　　this_is_longname_var ) == false ) {
だったり…なんて事があると嫌だから

867 ：仕様書無しさん：03/05/31 00:04

いや確かに "".equals (str) とは書くけど、それはまた別じゃないか

ていうか >>861 は括弧つかいすぎな気がするが、これも決まってるのかな

868 ：仕様書無しさん：03/05/31 00:06

>859

ああ、そりゃ規約を変えた方がいいな。
その規約に従うことによって検出される代入文となることのミスより、
不自然と感じる記述による条件式のミスによるバグの方がきっと多くなる。
多分1桁か2桁くらい。

おまけに前者については多くのコンパイラで検出できるし、かなり手抜きの
テストケースでもおそらくひっかかるが、後者の場合はコンパイラでは
まず検出されない上に、思い込みが絡む分だけテストをすり抜けたりするから
より厄介。

869 ：仕様書無しさん：03/05/31 00:11

括弧は使ったほうが見やすいだろ

870 ：仕様書無しさん：03/05/31 00:15

>>866
>(例2)

bool result;

result = this_is_long_name_function( this_is_longname_var, /* 中略 */ );

if( result == true )
{
　　/* ... */
}

871 ：仕様書無しさん：03/05/31 00:18

>>870
if( result )
{
　　/* ... */
}

872 ：仕様書無しさん：03/05/31 00:20

>>870
その後に、似たような処理があるなり、
その結果を複数の箇所で使用する場合は、そうするけど。
一回しか使わない場合は、resultを宣言しないっしょ。

873 ：仕様書無しさん：03/05/31 00:20

>>870

switch (this_is_long_name_function( this_is_longname_var, /* 中略 */ )) {
case 0:
　　　　/* hoge */
　　　　break;
default:
　　　　/* not hoge */
　　　　break;
}

874 ：仕様書無しさん：03/05/31 00:21

>>872

基本的にresultの確保はデバッグ時に便利だからよくやります :)

875 ：仕様書無しさん：03/05/31 00:26

>>874
なるほど、そういう派かぁ。
Cやってたとき、先輩に言われたやり方だあ。
漏れは変数とステップを減らす派だから。

876 ：pascalらー：03/05/31 00:28

だからいったじゃないか
代入は:=比較は=にしろって

877 ：仕様書無しさん：03/05/31 00:31

ってか、ここはC言語でプログラム学んだヤシばっかなのか・・・。
考え方からして・・・。
>>876
もちろんだじゃないか！忘れた訳じゃないさ！

878 ：仕様書無しさん：03/05/31 00:59

クラサバの頃から脳味噌固まったままのオヤジ共、
Webアプリなのにブラウザのクローズを許さず
ユーザーにログアウトを強要するとか、
ブラウザがクローズしたら自動でログアウトするとかは
お願いなんでもう諦めてください。
それは出来ねえんだってば。

879 ：仕様書無しさん：03/05/31 01:09

適応力不足ってやつだな

880 ：仕様書無しさん：03/05/31 01:23

>>878
いるよな、そういうやつ。
なんで俺がお前のオナニーにつき合わなければいけないのかと考えてしまう。
なんで不可能なことを不可能と認めようとしないのかが理解できない。
なんであまりにも不自然で無理がある仕様をごり押ししようとするのかが不思議で仕方がない。

881 ：仕様書無しさん：03/05/31 01:34

0 との比較に 0 == foo と foo == 0 のどちらもありえない。

俺だったら if (!foo) と書く。もちろん真偽値との比較式も書かない。

と、新たな燃料を投入してみるテスト（ｗ

882 ：r：03/05/31 01:39

判ったよ。おれが今後コーディング規約作るときは
#define EQUALS ==
#define LET =
とかってマクロの使用を強要するようにしておくよ

883 ：仕様書無しさん：03/05/31 01:51

なぜLET・・・

884 ：仕様書無しさん：03/05/31 01:53

>>881
数値に論理演算ｷﾓｲ

885 ：r：03/05/31 01:57

>>883
いや、N-BASICがそうだったなぁっと...

886 ：仕様書無しさん：03/05/31 02:03

なんちゃって英語で埋め尽くされたソースコードってのもあるな

887 ：r：03/05/31 02:10

>>886
コボル？

888 ：仕様書無しさん：03/05/31 02:14

>>885
そういう理由でコーディング規約を決めるなとあれほど・・・

889 ：仕様書無しさん：03/05/31 02:16

>>887
英語ならまだいいよ……
なんちゃってローマ字の怒涛の攻撃に貴様は耐えられるのか？？

890 ：仕様書無しさん：03/05/31 02:58

>>884
C においては論理演算式も数値演算式もその結果については何ら違いは
ないのだが、何か？

891 ：山﨑渉(^^) ：03/05/31 02:58

やっぱ変数名、関数名、クラス名、コメントは漢字で行こう
わかりやすいくていいよ

892 ：仕様書無しさん：03/05/31 03:25

>>878
はげどう。
そんなにクラサバが良いならWebアプリ化なんぞしなきゃイイのに。

ああ、今度の仕様変更要求は
「全てのボタンにファンクションキーを割り当てろ」とか
「規定の桁数入力したら自動でフォーカスを移動しろ」とかそんなのばっか。
他に金かけることあるだろうと小一時間(ry

893 ：仕様書無しさん：03/05/31 03:26

>>851
大昔に講習受けた記憶があるけど「モジュールの出口は１つ」なんて規約
あったっけ？
goto も上から下は認めてた様な…
ダイクストラの文献探してみるか…

894 ：仕様書無しさん：03/05/31 03:42

途中でreturnって結局最後の行にgotoと同じ事だろ？
それを禁止してどうやって書くんだ？

それと関数の途中で抜けるはだめで、
ループの途中で抜けるはＯＫなのか？
関数の途中で抜けるのがだめな理由を考えると、
ループの途中で抜けるのもだめな気がするのだが。

895 ：仕様書無しさん：03/05/31 03:43

>>870
bool isSuccess;

isSuccess = thisIsLongNameFunction(thisIsLongnameVariable, /* 中略 */ );

if (isSuccess) {
　　/* ... */
}

896 ：仕様書無しさん：03/05/31 06:25

世の中にはMISRA-Cという
自動車開発向けのC言語規格(規約)ものがあってな・・・

・gotoの使用禁止
・switch以外でのbreakの使用禁止
・continueの使用禁止
・判定式での代入式の禁止
・関数の出口は一つ
・a = *p++; のような文はだめとか

Cっぽくないソースができあがる規約もあるのよ・・・

897 ：仕様書無しさん：03/05/31 08:23

さぞ糞ソースばかりになることであろうな