12/03/13 23:57:17.22
>>43はRuby使いなんじゃね？
Rubyには標準ライブラリを含めてインデント2で書かれたコードが多い
51:仕様書無しさん
12/03/14 00:10:57.34
インデント2は明らかに少なすぎ。
デザイン的に空間が分かれてるように見えない。
52:仕様書無しさん
12/03/14 00:35:03.78
>>43
チカンすればいいじゃん
53:仕様書無しさん
12/03/14 02:52:09.84
>>52
おまわりさんこっちです
54:仕様書無しさん
12/03/14 07:34:18.44
生ポインタとusingを禁止で全て書き直せとのお達し
配列長が必要なので、shared_arrayは使えない
vector<Hoge*>* hoge;
↓
boost::shared_ptr<std::vector<boost::shared_ptr<Hoge>>> hoge;
マジキチ
下手すりゃdelete漏れを探すよりもカオスなことになりそうだぜ
55:仕様書無しさん
12/03/14 13:02:41.26
>>47-49
タブサイズは8に決まってるだろ。
タブサイズを8以外にしてるやつは迷惑だわ。
インデントを8以外にしたいときにはスペース使え。
>>52
どっちにしても面倒だし、チカンするくらいならエディタの設定を変えたほうが速いだろ。
56:仕様書無しさん
12/03/14 16:12:41.42
インデントはタブサイズの設定関係ないだろ
インデント以外のレイアウトにタブ使うヤツがクソ野郎
57:仕様書無しさん
12/03/14 16:20:32.15
みんなそれぞれ意見がバラバラなのが面白いぜw
58:仕様書無しさん
12/03/14 16:49:24.33
コーディングスタイルはしばしば宗教に例えられる
59:仕様書無しさん
12/03/14 17:57:48.38
コーディングルール・コーディングスタイル議論は山のようにあって正直ウンザリなので、
このスレでは「イラッつとする」かどうかのみで判断した感情的なレスをお願いします
60:仕様書無しさん
12/03/14 19:30:13.99
>>56
関係あるだろ。
タブサイズ4前提でインデントしてて、8に設定してあるエディタで見ると崩れるやつとかいる。
61:仕様書無しさん
12/03/14 19:41:56.11
いまやってるphpのシステムで関数の引数を
function hoge($arg1, $arg2, $arg3)
{
$weight = arg1;
$height = arg2;
$age = arg3;
}
と必ず$arg1, $arg2…みたいな意味の無い名前の変数でうけて、関数の中で意味のある
名前の変数に移してるんだけど、
普通に
function hoge($weight, $height, $age)
でいいじゃないか。
なんか意味あるのか。
62:仕様書無しさん
12/03/14 19:47:25.12
コードを追うと突如現る謎の空白行
ふと右を見ると変数の頭文字らしきものがニョキっと生えてる
タブ8とか3階層ネストするだけで宇宙に行ってまうわ
気持ち悪いったらありゃしない
63:仕様書無しさん
12/03/14 20:32:57.87
Full HDなモニタ買ってもらえ。
64:仕様書無しさん
12/03/14 20:42:50.52
>>61
Perl厨のせいなんじゃね？
Perlには仮引数がないから
sub hoge {
$weight = shift;
$height = shift;
$age = shift;
}
ってやるよ。
65:仕様書無しさん
12/03/14 23:14:52.71
>>60
すまん、インデントの意味を間違えてた
段落を意図したインデントのみタブを使えって言いたかった
こういうこと言いたかったんです
URLﾘﾝｸ(ameblo.jp)
66:仕様書無しさん
12/03/15 01:23:10.20
>>65
正しい日本語使おうな。
たしかに、タブとスペース混ぜられたり、後ろに不要な空白残したりされると殴りたくなる。
てめーのことだぜ先輩！
67:仕様書無しさん
12/03/15 02:07:12.65
いえ、わたくしは、イライラしながらフォーマッタでポチポチ揃えてる側の人間ですが。
68:仕様書無しさん
12/03/15 09:47:40.20
昔はタブサイズは8にするべきだって思ってたんだけどね
今は1か2がちょうどよく思えてきたよ
69:仕様書無しさん
12/03/15 10:36:11.89
タブのサイズを1に設定してタブを使うなら、ふつーにスペース使ったほうがよくね?
70:仕様書無しさん
12/03/15 11:36:52.65
bool hoge(){
if( fuga() != false ){ return false; }
else{ return true; }
}
なぜreturn !fuga();としないのだ……。
71:仕様書無しさん
12/03/15 12:14:05.59
/* 2011.3.11 なんかエラーになるのでとりあえず外す
return false;
*/
}
return true;
72:仕様書無しさん
12/03/15 12:26:17.66
>>70
Ａ：論理値をリテラルと比較するような阿呆だから
73:仕様書無しさん
12/03/15 13:45:30.08
>>71
3.11･･･
74:仕様書無しさん
12/03/15 14:00:09.04
>>73
rev.666 2011-03-11 15:47
ほぼ100％職場おわるので中間コミット
SyntaxError出るけどこれ以上はやばいのでかんべんしてください
去年下請けと組んでやった案件の作業ログにこんなのあったの思い出したわ
75:仕様書無しさん
12/03/15 14:05:41.36
修正したり追加した行に日付と名前が書いてあるのは
お前の名前分かっても意味無いんじゃ、って思うな。
76:仕様書無しさん
12/03/15 18:26:58.01
日付は何故そう修正したか雰囲気がわかったりするから無いよりはマシ
それよりはまともなコメントを書けよハゲって話なんだが
担当者を入れるのは責任問題の押し付け合いをするためのものと理解している
77:仕様書無しさん
12/03/15 19:03:15.35
日付と名前は必須だろ
どこにバグがあるか特定する時に一番役に立つ
78:仕様書無しさん
12/03/15 20:25:45.12
修正履歴なんて入れてないでソース管理ツール使えよって感じだけど、ドカタの現場だとただのファイル共有ツールって認識だし使っても同じか。
79:仕様書無しさん
12/03/15 21:04:29.64
わざわざソース管理ツールをインストールするの面倒じゃん
おまえらすぐ管理ツールを変更しちゃうから古いソースを見る時に大変なんだよ
80:仕様書無しさん
12/03/15 21:12:59.59
やっぱり新しいツールや技術についていけない無能に合わせるしかないよな
81:仕様書無しさん
12/03/15 21:13:26.95
名前がファミリーネームどころかファーストネームですらなく、
親しい間でなければ使わないような愛称
鼻穴に５センチほど割り箸突っ込んでグググと水平に近づけて
後遺症が残らない程度に苦痛を与えることで反省を促したい
82:仕様書無しさん
12/03/16 00:11:44.00
俺もちょっと前にPHPで
return hoge ? false : true ;
って書いてた。恥ずかしい
83:仕様書無しさん
12/03/16 06:55:35.96
return func();
とか、気持ち悪くないか？
84:仕様書無しさん
12/03/16 11:17:23.41
返却値の柔軟性を奪っておいた方が後々不具合が少ない気はしないでもない。
85:仕様書無しさん
12/03/16 19:59:37.11
/*2008.01.01 障害対応 start */
/*2009.09.15 障害対応 start */
/*2010.12.11 障害対応 start */
/*2011.02.13 障害対応 start */
return true;
/*2011.02.13 障害対応 end */
/*2010.12.11 障害対応 end */
/*2009.09.15 障害対応 end */
/*2008.01.01 障害対応 end */
こんなのを見ると腹立つ
消すなって言われると帰りたくなる
86:仕様書無しさん
12/03/16 20:10:41.24
>>85
え？なんで修正した箇所のソースが残ってないの？
普通はコメントアウトして残すだろ？
コメントアウトした部分を削除する時は日付も削除するし
そんな状態にはならない
87:仕様書無しさん
12/03/16 20:15:05.66
>>86
>普通はコメントアウトして残すだろ？
普通は…な…。
88:仕様書無しさん
12/03/16 20:20:45.49
正月から大変なんだなw
89:仕様書無しさん
12/03/17 01:07:19.71
>85
そもそもSubversionとか使ってないの？
90:仕様書無しさん
12/03/17 01:09:31.26
そこかよw
91:仕様書無しさん
12/03/17 07:04:29.13
全体の設計があきらかにアレなコードで
いちいち修正をコメントで残されてもなー
92:仕様書無しさん
12/03/17 10:36:26.07
ありきたりだけど、コメントが疑問系のやつ
一回それに対する回答コメントがあってワラタ
93:仕様書無しさん
12/03/18 07:15:33.32
LINQの使い方を知って以来、foreachまみれのソースは基本的にイラつく
94:仕様書無しさん
12/03/18 19:33:17.18
foreach？gotoでループを表現しているコードをいじらされるよりだいぶマシだな
95:仕様書無しさん
12/03/19 01:56:27.12
>>14
ちゃんと意味のある関数ならいいけどな。
96:仕様書無しさん
12/03/19 01:57:43.43
>>20
C#はなるんじゃなかった？
97:仕様書無しさん
12/03/19 11:49:33.84
C#にはポインタはありません（すくなくとも表面的には）
それよりもここのタイトルの「イラッつと」って書き方にいらっと来た。
98:仕様書無しさん
12/03/19 13:33:57.93
>>97
あからさまに仕様上あるわけだが＞C#のポインタ
そんなことより、スレタイに関しては >>5 で既出なんだが
ホントに直近のレスだけしか見てないんだなあ(´・ω・｀)
99:仕様書無しさん
12/03/19 13:56:14.92
何のひねりもないﾏｼﾞﾚｽにイラッつとした
100:仕様書無しさん
12/03/19 15:44:51.04
スレタイの「イラッつと」は「イラッと」の間違い？
なんかいらっと来た
101:仕様書無しさん
12/03/19 18:12:57.12
if (0 == hoge)
102:仕様書無しさん
12/03/19 19:25:54.13 BE:1248768735-2BP(0)
>>101
これはわからなくはないが見にくい
103:仕様書無しさん
12/03/19 20:01:41.88
>>101
if (0 < hoge && hoge < fuga)
これは許してちょんまげ
104:仕様書無しさん
12/03/19 20:29:56.00
>>103
それは普通
105:仕様書無しさん
12/03/19 20:57:03.45
もしかして、"<" は良くて ">"
は使わないの？
106:仕様書無しさん
12/03/19 21:03:08.93
はぁ？
107:仕様書無しさん
12/03/19 21:59:50.74
void hoge()
{
if(this.expr) return;
hogehoge();
fugafuga();
...
}
俺も7年前までこう書いていたんだが、
今ではイラッとまで来ないが、なんかもやっとする。
入口一つに出口一つ、例外的に途中抜けするから例外、
と考えているんだが、そういう考えは少数派なのだろうか
108:仕様書無しさん
12/03/19 22:14:45.37
>>107
return文の利用を気にしているのかな？
それを使わないことでネストが浅くなる場合もあるよ
以下は、ソート処理で使われる比較メソッドの例
def compare(x, y)
gender_result = x.gender <=> y.gender
return if gender_result == 0
age_result = x.age <=> y.age
return if age_result == 0
x.name <=> y.name
end
昔のgoto文不要論争と同じように、return文も全面的に禁止するのではなく、
必要に応じて使い分ける(=必要な場合に限って使う)ことを考えればいいのではないかと
109:108
12/03/19 22:17:52.90
ミスがあったのでコードを訂正(なお、言語はRuby)
def compare(x, y)
gender_result = x.gender <=> y.gender
return gender_result if gender_result == 0
age_result = x.age <=> y.age
return age_result if age_result == 0
x.name <=> y.name
end
110:仕様書無しさん
12/03/19 23:21:53.63
>>107
> 入口一つに出口一つ
これを守るためにフラグ変数導入したり、do～while(0)使ったりするコードは
イラッとする。
111:仕様書無しさん
12/03/20 00:23:49.93
>>110
>これを守るためにフラグ変数導入したり、do～while(0)使ったりするコードは
>イラッとする。
御意
112:仕様書無しさん
12/03/20 01:32:28.25
if(hoge) goto exit;
113:仕様書無しさん
12/03/20 03:16:51.32
>>107
出口一つにしたければ、
void hoge()
{
if(this.expr) goto EXIT;
hogehoge();
fugafuga();
...
EXIT:
}
こう書けばいいよｗ
つか、returnなんてこの書き方の短縮形でしか
ないんだから出口を一つにする意味はない。
114:仕様書無しさん
12/03/20 07:23:02.48
場合わけが多岐にわたり、なおかつ「通常」の抜け方が唯一の関数だと
末尾に「通常」のreturn、そこまでのあちこちにif文と抱き合わせで複数のreturn
というのは必然
115:仕様書無しさん
12/03/20 11:01:41.79
>>101
これをコーディング規約にするのは
「ウチのプロジェクトには、代入と比較を間違える間抜けがいます」
つってるようなもんだよなあ。
116:仕様書無しさん
12/03/20 12:20:25.49
代入と比較を 書き 間違える人なら
全員当てはまると思いますが？
117:仕様書無しさん
12/03/20 12:35:19.18
たしかVisualBasicだと比較も = １個だけだったと思う
BASIC系全部そうかな
118:仕様書無しさん
12/03/20 12:43:43.70
BASICは、ifで代入できるなんて
あほらしい仕様がないからね。
119:仕様書無しさん
12/03/20 13:06:39.30
>>115は根性と精神力でプログラミングするんだろうなあ
お近づきにはなりたくない
120:仕様書無しさん
12/03/20 13:40:45.28
まぁ普通は静的解析ツール使ってチェックするよなぁ。
>>101 みたいなプログラマの注意力に依存したスタイルは今どき流行らないよ。
121:仕様書無しさん
12/03/20 13:54:35.84
>>101
頭の中で0がhogeだったらって考えちゃうけど、こう書いたときにどう考えてるんだろ
122:仕様書無しさん
12/03/20 13:54:57.90
>>113
その手の奴で、それぞれ脱出する箇所によって終了処理が異なるから
EXIT1: EXIT2: …と、returnの前に4つくらいラベルが書かれたソースを
見たことがあるな。
ネストが深くなるのがそんなに嫌なのか。
123:仕様書無しさん
12/03/20 14:00:38.72
ネストが深くなっていいことは一つもないからな。
124:仕様書無しさん
12/03/20 14:19:18.43
>>119
なんで根性と精神力があると間違えないと思うの？
バカなの？
125:仕様書無しさん
12/03/20 15:25:25.39
if (sysfn(...) < 0) {エラー処理} //sysfn()は、エラー時に"-1"を返す関数
なぜすなおに-1を使わない？
126:仕様書無しさん
12/03/20 15:30:15.28
ネットで似たような処理を探してきて、意味もわからず貼り付けて、
「出来ました」
とかいうスタイル。 技術者なめとんのか
127:仕様書無しさん
12/03/20 15:40:00.90
>>125
負の整数をエラーコードとしている場合、新たなエラーコードが追加されたときにもエラー処理を実行させるため
128:仕様書無しさん
12/03/20 16:13:54.00
>>103
むしろそうしないコードにイラッつとするわ
129:仕様書無しさん
12/03/20 16:14:36.45
>>124
こんなもん静的解析ツールが見つけ出してくれるだろ
130:仕様書無しさん
12/03/20 17:55:49.64
>>127
sysfn()は、「失敗時に-1」と定義されたシステムコールです
131:仕様書無しさん
12/03/20 19:38:01.93
システムコールの仕様は一生変わらないとお思いかね
132:仕様書無しさん
12/03/20 19:42:26.65
変わってからまたおいでｗ
133:仕様書無しさん
12/03/20 19:44:21.26
「失敗Aが-1だけど失敗Bは3を返す」
という構造になる確率よりも
「失敗Aが-1なので失敗Bは-2を返す」
という構造になる確率のほうがたぶん高い
とにかく失敗ならヒットしたいという場合、とりあえず負かどうかチェックするのはいちおうはアリだ
「失敗なんだけど、既存のエラー処理では処理しきれない新失敗」という可能性もあるんだけど、
それはたぶんエラーコードがなにになっても結局うまく動かないだろうからどうでもいい
134:仕様書無しさん
12/03/20 19:47:28.02
>130
それならsysfn()のヘッダに
#define SYSFN_ERROR -1
って書かれてるだろうから俺はそれを使う。
書いてなければsysfn()を作った奴が無能。
135:仕様書無しさん
12/03/20 20:19:40.05
xxxxx{
}
xxxxx(
){
}
カッコの列が違うと読みづらくて仕方ない
136:仕様書無しさん
12/03/20 20:25:09.56
int mCode = 0; // 変数mCodeの宣言
そんなの見りゃ分かる。
mCodeが何の変数かを書いてほしかった。
137:仕様書無しさん
12/03/20 20:55:44.58
>>136
もう一歩踏み込んで変数名だけでわかるようにしないと
138:仕様書無しさん
12/03/20 21:34:41.41
日本語で書かないとわけがわからなくなる値の入る変数名というのは結構あったりする
139:仕様書無しさん
12/03/20 21:40:17.74
>>125
成功時に0以上の値を返す関数だから。
140:仕様書無しさん
12/03/20 21:57:22.53
・
141:仕様書無しさん
12/03/20 21:57:25.05
普通にそう考えられないやつはセンスないよね。
142:仕様書無しさん
12/03/20 23:54:41.16
CのベテランがJavaにきても成功/失敗を、0/-1で返してたな。
関数名も chkHoge() みたいな感じだし。
イラっとするっていうか懐かしい感じがした。
143:仕様書無しさん
12/03/21 00:20:49.82
exit 1 が失敗を現す文化がですね
144:仕様書無しさん
12/03/21 00:44:15.06
>>25
式の評価順が気になって安全に振ってんだろ
145:仕様書無しさん
12/03/21 01:18:59.93
>>54
これって、typedefつかっちゃダメなのか？
146:仕様書無しさん
12/03/21 03:45:59.92
ループの全てをdoループで処理したらイラッとするって言われた。
forとかwhileとか使えって(´･ω･`)
ループ前に変数初期化、ループの最初と最後にifで必要に応じてbreak。
ループカウンタ進めるタイミングとか、ループ抜ける条件を一覧(風)に並べられたりとか、見やすいと思うんだけどな。
イラッとするもの？
147:仕様書無しさん
12/03/21 06:16:44.32
たかがループで
> ループ前に変数初期化、ループの最初と最後にifで必要に応じてbreak。
> ループカウンタ進めるタイミングとか、ループ抜ける条件を一覧(風)に並べられたり
こんなことやらないといけないのは、何かおかしいと直感的に感じる。
条件などをきちんと整理すれば普通の forとか whileになるんじゃないか？
148:仕様書無しさん
12/03/21 06:28:26.77
いちいちインクリメンタに意味のある名前をあたえているせいで
forの宣言行が長くなっていると予想
149:仕様書無しさん
12/03/21 09:33:37.32
K&R Cっぽい関数宣言してる人がいてビックリしたことがる
150:仕様書無しさん
12/03/21 09:41:20.56
C++やC99 or laterなら問題になるがC89までなら問題ない
それより関数定義のほうを見たらびっくりするだろ
151:仕様書無しさん
12/03/21 12:49:10.36
>>146
> ループの全てをdoループで処理したらイラッとするって言われた。
イメージが沸き辛いんだけど、
for (int i = 0; i < N; ++i) { /* something */ }
を
int i = 0;
do {
if (i >= N) break;
/* something */
i++;
} while (true);
みたいに書いてるのか？
ループの最後にifってのがよくわからんが。
もしそうなら今までで１、２を争うイラッつとレベル
152:仕様書無しさん
12/03/21 13:22:32.98
>>146
イラッつとするって言うか、死ねって思う。
do whileだと終了判定とカウンタの処理の２か所でバグ仕込む可能性が上がって
解析する場合に余計なコストがかかる。
ただのfor文だと分かった場合であっても、それ以前と仕様が変わって
そうせざるを得なかった場合まで考えるから鬱陶しい。
153:仕様書無しさん
12/03/21 17:20:34.42
>>146
俺なら全部書きなおさせる。
154:仕様書無しさん
12/03/21 18:13:00.78
>>146
命令の数が増えたら読みにくいじゃん
ループはforで統一するのがいいんだよ
155:仕様書無しさん
12/03/21 18:28:43.38
>>154
えっ？そんな理由でforに統一してるの？
絶対一緒に仕事したくないなぁ～
156:仕様書無しさん
12/03/21 18:59:49.89
新着があるはずなんだがぜんぜん表示されない…
157:仕様書無しさん
12/03/21 19:16:16.72
whileしか使わない
158:仕様書無しさん
12/03/21 19:54:01.21
ifとgotoしか使わない
159:仕様書無しさん
12/03/21 22:59:55.17
俺はwhile統一派
変数初期化やインクリメントは単独の式でやったほうがいい
160:仕様書無しさん
12/03/21 23:01:01.13
>>154
for統一ってのは無いな
161:仕様書無しさん
12/03/21 23:01:23.71
>>159
処理系によって遅くなるぞ
162:仕様書無しさん
12/03/21 23:05:05.67
forとwhileの統一なんかは別にどーでもいいが
do whileで統一はまじでやめほしい
163:仕様書無しさん
12/03/21 23:12:53.60
until文とか出てくると紛らわしい。
164:仕様書無しさん
12/03/21 23:24:25.39
>161
forとwhileの違いごときで体感レベルで遅くなるような処理系って現存するのか……？
165:仕様書無しさん
12/03/21 23:39:43.30
whileは変な書き方したら遅くなりそうな気はするな
166:仕様書無しさん
12/03/21 23:44:18.23
ってもJUMPするだけじゃん
167:仕様書無しさん
12/03/22 00:27:49.79
for(;;)は条件式の省略が認められてるが、while(true)は定数のboolで条件式を代用してる
168:仕様書無しさん
12/03/22 01:38:23.47
>>164
現存するかは知らんけど、数年前のC++ Builderに付いてたコンパイラは
forで加減算してる場合しかループ展開しなかった
169:仕様書無しさん
12/03/22 06:24:32.18
gotoが使える言語で
1回だけしか実行しないループとbreakで疑似goto
多重ループを抜ける為の大量に設置された判定文
gotoは使わないでね☆ミみたいなのにとらわれすぎだと思った
コメントにしっかり書くならいいと思うんだけどなぁ
170:仕様書無しさん
12/03/22 08:33:09.39
>>54
thisポインタ使われてたら終わるなｗ
171:仕様書無しさん
12/03/22 09:38:41.47
>>169
複数回のメンテを受けた後がGOTOの本領発揮
共同作業でGOTO使うなっていうのは鉄の掟
あがっている例ではその部分を関数化すれば解決するんじゃないだろうか
returnによるgotoも賛否がわかれる所ではあるけれど
172:仕様書無しさん
12/03/22 09:56:37.14
>breakで疑似goto
別モンだろｗ
173:仕様書無しさん
12/03/22 10:58:08.82
>>172
上から下に流れるだけのgotoと言うかなんと言うか
どっちかと言うと1回のループでなんでこんなもんが…と混乱した後に
「ただbreakで飛びたいだけでしたーｗｗｗ」ってのがな…
174:仕様書無しさん
12/03/22 11:06:25.62
難読化技術はとどまることを知らない
175:仕様書無しさん
12/03/22 13:13:43.25
goto使うなというのは、あなたのために言っているのではない
あなたの次の次の次の人くらいのために言っている
176:仕様書無しさん
12/03/22 13:23:26.07
> 1回だけしか実行しないループとbreakで疑似goto
なんで if 使わないの？
177:仕様書無しさん
12/03/22 13:28:57.86
forだと2回条件を評価しているんだがifだと1回だよね
178:仕様書無しさん
12/03/22 13:40:20.34
エラー時に関数抜ける場合とかの解放忘れ防止に goto もありかな、と思う事はある。
179:仕様書無しさん
12/03/22 13:51:40.67
>>175
コメントはしっかり書くと言t
俺のコメントが…消えた…？
関数にするほどの処理じゃないor関係性があった処理で戻り値無しの関数終了をイメージした何かだったんだろう
調査だったからそれで動いてたし触らないが吉としてスルーした
180:仕様書無しさん
12/03/22 13:56:27.17
>>178
解放なんて例外でキャッチしてやればいいじゃん
というかそれ以外の方法だとどうやっても抜ける可能性でるだろ
181:仕様書無しさん
12/03/22 14:51:20.98
例外が使えない状況もあるからね。
182:仕様書無しさん
12/03/22 14:55:17.06
>>180
Exception Safetyって知ってる？
知らずにレスしてるならもっと勉強しろ。
知ってるなら、そう簡単な話ではないことくらいわかるだろ。
183:仕様書無しさん
12/03/22 17:38:53.68
gotoが「絶対ダメ」なのなら、例外だって「かなりダメ」だろう
どっちにしても大域脱出なのは変わりがないのだから、極めて慎重に設計されて極めて慎重に使用されるべき
「gotoはダメだけど例外ならいいよ」なんてことはあって欲しくない
あって欲しくないってことは実際にはあるってことなんだが
184:仕様書無しさん
12/03/22 17:56:13.71
>>183
君、何の言語ができるの？
185:仕様書無しさん
12/03/22 20:15:58.44
まぁgotoが許されるのは多重ループの脱出か
try-catchが無い場合の例外処理に限られるわな。
goto禁止ってのはそもそも、gotoが悪いんじゃなくて
処理ブロックの中を行き来するのが悪いって話だからなぁ。
ダイクストラ本人はgotoがダメとは言ってないし。
あと、breakは本来の意味では問題あるgotoになり得ない。
if( x )
{
goto label1;
label2:
goto label3
}
while( n )
{
label1:
goto label2
label3:
}
186:仕様書無しさん
12/03/23 23:51:50.59
カッコの内側にスペース入れてるのとカンマの後ろにスペース入れてないのがイラっとするわ。
187:仕様書無しさん
12/03/24 07:42:22.62
これか
foo( aaa,bbb,ccc )
なんか、AKBにそういう顔をしたメンバーが居るそうだな
（ ∵ ）
188:仕様書無しさん
12/03/24 09:44:13.79
ﾐｻﾜさんか
189:仕様書無しさん
12/03/24 09:59:23.99
浜ちゃん
190:仕様書無しさん
12/03/25 22:03:08.33
a = a + 1;
191:仕様書無しさん
12/03/26 11:06:32.52
>>190
Luaとかはそう書かないとダメだと思った
192:仕様書無しさん
12/03/26 20:21:29.78
>>190
宣言型言語に慣れるとイラッとするのかもしれない
【関数型言語(Haskell)】
a' = a + 1
【論理型言語(Prolog)】
A1 = A + 1
193:仕様書無しさん
12/03/27 09:04:29.30
1ならインクリしろって事なのかマジックナンバーだからなのか
一定の数値足すならそれが記述方法として正しいし理解しやすいと思う
194:仕様書無しさん
12/03/27 09:08:07.35
あぁ同じ変数に突っ込むってのもあったか
何かしら足してるなら別物になる事が多いしなぁ…
195:仕様書無しさん
12/04/03 21:38:44.46
phpばっかやっとるやつは、
きたないな、ソースも顔も。
196:仕様書無しさん
12/04/04 00:34:00.34
金を儲けると顔がきたなくなっちゃうよね
197:仕様書無しさん
12/04/07 02:10:36.21
// TODO 自動生成されたメソッド・スタブ
198:仕様書無しさん
12/04/07 16:30:48.93
// 仕様追加対応
if ( id > 11 && id < 13) {
}
199:仕様書無しさん
12/04/07 18:55:20.54
コメントをテンプレートを使って強制するとおこりがちなこと
/************************************
* 関数名 Initialize
* 日本語名 初期化関数
* 概要 初期化を行う
* 機能 パラメータの初期化
* 備考 特になし
*************************************/
InitStatus (...) {
}
200:仕様書無しさん
12/04/07 18:57:08.56
たいてい、コメントブロックと関数の間に
//Initialize (...) {
が存在する
201:仕様書無しさん
12/04/08 17:24:39.33
＼ ヽ | / ／
＼ ヽ / ／
‐､、 殺 伐 と し た ス レ に 鳥 取 県 が ！ ！ _,,－''
｀－､、 __／＼ _,,－''
｀－､、 _| `～┐ _,,－''
_ノ ∫
＿,.～’ /
────‐ ,「~ ﾉ ────‐
,/ ｀￣7
｜ 島 根 県 /
_,,－' ~`⌒^7 / ｀－､、
_,,－'' 丿 ＼, ｀－､、
,'´＼ ／ _７ ／`⌒ーへ＿,._⊃ ／｀i
! ＼ _,,-┐ ＼ ＿,.,ﾉ ｒ‐-､、 ／ !
ﾞ、 ｀ー--＜´ / Ｌ. ,～’ ﾞ、 ＞－一'′ ,'
y' U ｀ヽ/ / ヽ ヽ '´ U ｲ
＿＿＿＿
/ ＿＿ | ＼＿＿＿＿＼
＿＿＿/＿＿ /￣ ＿＿＿＿|＿＿＿＿ ＼ ＼＿＿＿＿＼
／/ヽ /＿＿＿ ／|＼ ＼ ＼＿＿＿＿＼
／ / ヽ / /＿＿ ／ | ＼ ＼＿＿＿＿＿＿＿
／ / ／ ／ / ／ | ＼ | ＼
／ / ／ ／ ＿／ __／ | ＼__ | ＼ ￣―＿
202:仕様書無しさん
12/04/09 10:43:48.99
＞198
idがdoubleかなんかになってるんだよ。
203:仕様書無しさん
12/04/11 21:01:07.00
俺がおかしいんだろうけど
privateかつ仮想関数でもない関数がstatic関数じゃ無かったとき。
てか、できるだけクラス内部で呼ぶオブジェクト自身の関数は、
static関数であって欲しい。
まず、インターフェースとして外に見せてる関数じゃないんだから、
static関数で十分だし、コード追うときメンバー変数弄ってる関数は
見た目がグローバル変数中で使ってる関数と同じなんで読みづらい。
204:仕様書無しさん
12/04/11 21:13:17.77
this使えよとしか
205:仕様書無しさん
12/04/11 21:19:09.81
this->～();ってしてても他のヤツ保守するときサボるし
this省いてもコンパイルエラーにならんし
206:仕様書無しさん
12/04/11 21:23:10.50
Objective-Cとかjavascriptだと
selfやthis強制するから便利だよな
207:仕様書無しさん
12/04/11 21:32:49.03
>>203
うん、君がおかしい。
でもそれがイラッつとするなら
そりゃ感情論だから仕方ない。
208:仕様書無しさん
12/04/11 21:38:44.72
>>204
thisもどうかと思うわ。5個メンバー変数あっても、
実際一つのprivate関数が必要とするのは2～3って事が多いし。
だったら直接その変数を引数渡しした方がましじゃん。
209:仕様書無しさん
12/04/11 21:55:57.48
>>208
メンバー変数をわざわざ引数で渡す必要性がわからん。
210:仕様書無しさん
12/04/11 22:21:59.19
>>209
グローバル変数と同じ理由
// ここだけ見ていつループが終了するか解るか？
for( point = 0; 100 > point; ++point ) Function();
211:仕様書無しさん
12/04/11 22:27:32.68
極端にもほどがあるな
212:仕様書無しさん
12/04/11 22:30:07.16
数年前のコード追うときとか楽なんだよ
>>210の例でいうFunctionで実際に値が
変更されるかどうか、Functionの中身
見ないで判断することができるからね。
213:仕様書無しさん
12/04/11 22:37:37.22
グローバル変数は目の敵にするくせに
メンバ変数にしただけで安心しちゃってる人は
グローバル変数の何が悪いのかもう一度考え直したほうがいいね。
214:仕様書無しさん
12/04/11 22:38:55.94
> >>210の例でいうFunctionで実際に値が
> 変更されるかどうか、Functionの中身
> 見ないで判断することができるからね。
意味がわからない。
215:仕様書無しさん
12/04/11 22:42:45.84
>>213
普通は必要があるからメンバ変数として保持するわけで。
メンバ変数として保持する必要がない変数までメンバ変数として保持してる
コードは、そもそもそれ自体が変だとは思わないか？
216:仕様書無しさん
12/04/11 22:44:24.83
>>214
pointがフィールドだった場合Functionメソッドが何もしなければ100回でループを抜ける
もしFunctionがpointに対し何かしていればループの回数はFunctionの実装を確認するまで不明となる
217:仕様書無しさん
12/04/11 22:46:03.03
>>215
問題点が違うよ。
無駄じゃないメンバーでも問題は変わらないんだから。
218:仕様書無しさん
12/04/11 22:46:26.79
>>215
メンバ変数は状態を保持するための苦肉の策でしょ
本当は禁止したほうがいいくらいだよ
219:仕様書無しさん
12/04/11 22:48:06.79
なんか、static爺の匂いがしてきたぞ。
220:仕様書無しさん
12/04/11 22:49:07.12
俺とプログラム議論で戦おうて言うなら徹底的にしてやるぞ
221:仕様書無しさん
12/04/11 22:50:04.98
インターフェースとしてクラスを使うのか、thisを省略するためにクラスを使うのかじゃ全然違うしな
222:仕様書無しさん
12/04/11 22:50:07.26
>>218
全部の変数をmain関数から引き渡せば状態を保持するメンバ変数なんていらない
っていう主張だったっけ？
223:222
12/04/11 22:51:28.59
あぁ、ちょっと違った。
main関数じゃなくて、上位の関数だったかな。
224:仕様書無しさん
12/04/11 22:52:52.35
>>223
インターフェースになる関数の中で呼ぶ自分のメンバーには
引数でメンバー変数を渡せって話。
225:仕様書無しさん
12/04/11 22:53:08.84
なぜグローバル変数が嫌われるかといえば
変数のスコープがブロックを超越するために
生成消滅のタイミングを把握できないからだ。
メンバ変数にしたところで
スコープがクラス内に限定されるだけで
メソッドというブロックを超越する問題は解決されていない。
226:仕様書無しさん
12/04/11 22:54:56.26
>>225
消滅というか変更全般だろ
下手すりゃ無限ループも起こすし
227:仕様書無しさん
12/04/11 22:54:57.12
まあオブジェクト指向も所詮道具なんだから
良い所悪い所判って使えばいいんだけどね
228:仕様書無しさん
12/04/11 22:58:14.63
オブジェクト指向は関係なくね
もっと構造化レベルの原始的な話でしょ
229:仕様書無しさん
12/04/11 22:59:28.54
>>228
その通り。
この話題に違和感を感じるならオブジェクト指向以前に
構造化を判ってない証拠。
230:仕様書無しさん
12/04/11 23:03:17.37
>>224
そもそもそんな関数をメンバ関数にしてる設計がおかしいんじゃない？
インスタンスに関係ない関数なら、クラスに入れないのが正しいのでは？
231:仕様書無しさん
12/04/11 23:04:30.58
>>230
Javaとか.Net系統じゃ無理だし
232:仕様書無しさん
12/04/11 23:04:36.84
>>230
インスタンスに関係ないわけじゃなくて
お行儀良くしましょうってことだよ
233:仕様書無しさん
12/04/11 23:07:35.43
>>230
あるクラス内でしか使わない関数なら
不要になったとき捨てやすいように
クラススコープに隠しておきたい
234:仕様書無しさん
12/04/11 23:11:24.14
>>231
別クラスにするとかあるでしょ。
>>232
基本的にはオブジェクト指向である限り、インスタンスと相互作用が
ないものはクラス内に入れないほうがいい。
まぁコーディング上の都合でちょっとしたことをさせる
(インスタンスと関係ない)小さなメソッドを入れることはあるけど。
235:仕様書無しさん
12/04/11 23:11:57.08
>>233
同意。
整理整頓しようってだけの話。
236:仕様書無しさん
12/04/11 23:14:21.42
>>234
別クラスで公開してしまったら他から使われる可能性があるからな
237:仕様書無しさん
12/04/11 23:15:16.96
>>234
メンバ変数を直接いじるよりは、引数と戻り値を通じてやり取りしたほうが良い。
プライベートであっても、副作用があるより無いほうが良い。
238:仕様書無しさん
12/04/11 23:23:21.29
>>236
副作用を起こすことを目的とした関数の場合には、
結局メンバ変数を参照渡しするか何かして副作用をおこすんだろ？
そんなに変わるとは思えないな。
239:仕様書無しさん
12/04/11 23:25:37.88
戻り値で受け取ったほうがはっきりするでしょ
this.value = privateMethod( 100 );
240:仕様書無しさん
12/04/11 23:31:11.70
操作するのが一つでよければね。
241:仕様書無しさん
12/04/11 23:32:16.97
>>240
戻り値が一つしか返せないから不便というのであれば
タプルを持つ言語を使えば良い
242:仕様書無しさん
12/04/11 23:33:20.27
>>241
言語を選ぶ自由があるなら>>206でFAじゃね
243:仕様書無しさん
12/04/11 23:34:54.43
before:
for( point = 0; 100 > point; ++point ) Function();
after:
for( point = 0; 100 > point; ++point ) point = Function( point );
多少明示的にするだけでかなり違うね。
244:仕様書無しさん
12/04/11 23:35:04.92
>>242
参照で返してもいいよ
245:仕様書無しさん
12/04/11 23:38:10.17
>>243
ループ中にループ変数に代入する(かつ下位関数で書き変える？)
っていうコーディングスタイルがそもそもありえない。
246:仕様書無しさん
12/04/11 23:39:25.25
別にこんなものは絶対こうしなくちゃていうものじゃなくて
方便で使い分ければ良いんだけど
意識してるかどうかは別の話だからな
247:仕様書無しさん
12/04/11 23:39:34.35
>>245
forの例は極端だろうけどwhileとか
ループ中で副作用が発生すんのはよくあるよ
248:仕様書無しさん
12/04/11 23:41:41.00
whileはループじゃねーよ
249:仕様書無しさん
12/04/11 23:42:47.37
whileがループじゃなかったら何なんだw
250:仕様書無しさん
12/04/11 23:54:05.04
>>245
「ループ変数」てのがすでにおかしい。
それはただの変数だ。
251:仕様書無しさん
12/04/11 23:58:36.37
>>240
戻り値がオブジェクト一個で済まないなら
それこそ別クラスにすりゃよくね
クラス内部でprivateメソッドにするような
内容じゃないでしょ
252:仕様書無しさん
12/04/12 00:04:11.70
おまいらスタイルの話じゃないですよ、と。
253:仕様書無しさん
12/04/12 00:08:32.12
問題の本質はあるクラスメソッドにおいて
メンバ変数にアクセスしてるのかグローバル変数にアクセスしてるのか
ぱっと見区別が付かないということだったはず。
thisを強制すれば済む話だけど、
社内の統制がクソでコーディングスタイルが統一できないのであれば
何を提案しようが無駄な気もする。
254:仕様書無しさん
12/04/12 00:11:39.58
>>250
ただの変数pointで
> for( point = 0; 100 > point; ++point ) point = Function( point );
こんなコード書いてきたら何も言わずに書き直すわ。
255:仕様書無しさん
12/04/12 00:12:07.49
グローバル変数と問題が同じというだけで
もとからメンバー変数とグローバル変数が紛らわしいという話じゃないよ
256:仕様書無しさん
12/04/12 00:12:21.59
>>253
問題の本質は
引数と戻り値を使わず、メンバ変数を直接いじるプログラムを書くことによって
思わぬ副作用に見舞われることがあるってことだよ。
257:仕様書無しさん
12/04/12 00:13:27.56
>>254
わざわざ問題を単純化して話をしやすくしているのに
話をすり替えるな
258:仕様書無しさん
12/04/12 00:15:04.57
>>254
それを書き直すのは構わんが
こういうケースだって問題はかわらんのよ
while( 100 > point )
{
FunctionA();
FunctionB();
FunctionC();
}
while( 100 > point )
{
FunctionA();
point = FunctionB( point );
FunctionC();
}
259:仕様書無しさん
12/04/12 00:16:14.07
>>253
それこそｽﾚ的には
「アプリケーションハンガリアン使え」
で済む話じゃね？
260:仕様書無しさん
12/04/12 00:19:35.71
ハンガリアンは、型を表すプリフィックスであって
スコープを表すプリフィックスはハンガリアンではありません。
プリフィックスが付けばなんでもハンガリアンだと思うバカが多くて困る。
ぶっちゃけ、::や->や.を記号ではなく文字として捉えれば、
nantoka::fooとかの nantoka::もプリフィックスだってーの。
261:仕様書無しさん
12/04/12 00:20:05.29
>>259
システムハンガリアンじゃね？
アプリケーションハンガリアンってと
pxSize ptSize emSizeみたいな単位とか
変数の型(とスコープ)じゃなく中身の情報含ませるものだから
262:仕様書無しさん
12/04/12 00:20:46.53
>>260-261
263:仕様書無しさん
12/04/12 00:24:14.52
話を戻そう。
プリフィクスを付けたところで
ある関数で、メンバー変数やグローバル変数が
書き換えられている事は解らないので意味がない。
264:仕様書無しさん
12/04/12 00:28:07.06
全部const関数にしましょってか
265:仕様書無しさん
12/04/12 00:28:19.01
>>258
どうも、例にあげてるコード自体が何となく臭いんだけど。。
メンバ変数pointが100未満の場合ループするよっていう
仕様なら(=pointがそれだけ重要な意味を持ってるなら)、
前者でいいと思う。
266:仕様書無しさん
12/04/12 00:29:10.29
>>260
恥ずかしいな
267:仕様書無しさん
12/04/12 00:29:42.46
>>265
マジで？
268:仕様書無しさん
12/04/12 00:32:31.44
>>265
問題は直すとき。今後者のループを見ればpointを
書き換えてる関数は一発で解るけど
前者だと3個とも疑わしい
実際の具体的な名前の関数ならすぐ解ると思うかもしれないけど
具体的な名前の関数でも分かりづらい事が多い
269:仕様書無しさん
12/04/12 00:35:21.54
while( 100 > point )
{
this.proc.FunctionA(&point);
this.proc.FunctionB(&point);
this.proc.FunctionC(&point);
}
もうこれでいいよ。
270:仕様書無しさん
12/04/12 00:36:24.40
>>269
渡さなくても良い関数には無理して渡さなくても良いんだよ
271:仕様書無しさん
12/04/12 00:36:45.59
>>267
別スレッドでpointを書き換える関数(publicかもしれない)が
呼ばれたときのこととか考えるとね。
意味としては、
100 > pointが成り立っている間、
FunctionA(), FunctionB(), FunctionC()を実行しつづけるよ
っていうのが重要だとおもうんで。
272:仕様書無しさん
12/04/12 00:37:42.86
>>266
お前がなｗ
273:仕様書無しさん
12/04/12 00:39:17.57
>>271
そんな例外（プログラム的な意味ではなく）を考えたところで意味が無いでしょ。
例外は例外らしく処理を切り分けるべき。
ここでは変数pointがどの関数によって影響を受けるか
明示されていることが大事なんだ。
274:仕様書無しさん
12/04/12 00:43:07.32
>>273
後者の書き方でも、結局は明示されてないということ。
むしろ、
point = FunctionB( point );
だけをチェックすればいいんだと間違えるかもしれない。
275:仕様書無しさん
12/04/12 00:43:13.34
>>271
どうしても無理っていうなら別だけど
できる状況なら分かりやすくしとけばいいでしょ
276:仕様書無しさん
12/04/12 00:43:17.04
>>258の流れから
while( 100 > point )
{
this.proc.FunctionA();
this.proc.FunctionB(&point);
this.proc.FunctionC();
}
これで文句あるまい。
277:仕様書無しさん
12/04/12 00:43:52.25
>>274
だけをチェックすればいいようにするんだよ。
278:仕様書無しさん
12/04/12 00:48:40.72
URLﾘﾝｸ(logsoku.com)
URLﾘﾝｸ(logsoku.com)
パラダイム未修得のトーシロらしいぞお前ら
279:仕様書無しさん
12/04/12 00:51:55.39
オブジェクト指向はインターフェースの外の話しだし
パラダイムがどうのとかどうでもいいよ
飽くまで構造化と実用的な保守スタイルの話しだし
280:仕様書無しさん
12/04/12 00:56:18.33
>>278
同じような話だけど、バカが水差して終わってるだけじゃん
281:仕様書無しさん
12/04/12 07:00:21.99
何か随分と伸びてると思ったら、ゆうべはおたのしみでしたね。
メンバ変数の書き換えについては、小規模なら良い様な気もするけども、
ループカウンタを途中でいじられるのはイラッつとするな。
This必須とか制限を増やしてコーディングの自由度を下げて
誰が書いても似たコードになるようにするのが今の言語の流れかね。
282:仕様書無しさん
12/04/12 12:03:48.69
>>243
実際に動かしてから死ねよって思うかソース見た瞬間に死ねよって思うかぐらいの違いしかないが
この違いのおかげでおおごとにならずに済むこともまあまあある
283:仕様書無しさん
12/04/12 13:20:34.27
for( point = 0; 100 > point; ++point ) Function(); // Function()内でpointを更新
284:仕様書無しさん
12/04/12 14:38:32.69
だからコメントは信用するなと……ぐふっ
285:仕様書無しさん
12/04/12 16:41:17.25
なんかすげえ伸びててワロタ
286:仕様書無しさん
12/04/12 21:28:30.37
ここまで読み流した
ループカウンタをメンバ変数にするな
287:仕様書無しさん
12/04/12 21:28:30.63
>>281
> This必須とか制限を増やしてコーディングの自由度を下げて
逆に言えばさ、thisを書かなくても良くなったら
自由度があがるってことになると思うんだけどさ、
「thisを書かなくてよくなった、俺は自由だ！」って思う奴いるの？
つまりね、俺が言いたいのはthis必須と自由度とは全く関係ないよってこと。
× 「コーディングの自由度を下げて 」
○ 「コーディングの面倒くささを下げて」
君が本当に言いたいことはこうでしょ？
で、問題はthis省略で本当に面倒くささが下がったかどうか。
確かに書くときの面倒さはなくなったが、逆に読むときは
正確な意図がすぐには分からず面倒さは増えることになる。
これは、どっちがいいかって話。トレードオフの話でしかない。
なぜ俺が最初に「自由度とは無関係」と言ったのかというと、自由度は
上がるか下がるかしか無い。そうするとトレードオフの話ではないように見えてしまう。
本当は、this必須かどうかってのは、トレードオフの問題なのに、
this省略できたほうが優れてるような印象になってる。
288:仕様書無しさん
12/04/12 21:31:27.37
解釈の自由度が下がるやん
289:仕様書無しさん
12/04/12 21:52:32.47
解釈の自由度ってなに？
まさか、書いた本人が
どう解釈されてもいいように書いた！
なんて言うわけないしｗ
290:仕様書無しさん
12/04/12 21:57:34.84
> 誰が書いても似たコードになるようにするのが今の言語の流れかね。
これもよくわからんね。
ですます調でかけ！と言われても
似たような小説にはならんだろ？
オリジナリティがある小説を書く場合、
そのストーリーでオリジナリティを出すのであって
そんな語尾をどうするか程度で、似てる似てないなんて
判断しないだろ。
291:205-206
12/04/12 22:18:30.30
ごめん、眠くて>>205-206にいい加減な事書いた。
thisじゃなくてメンバー変数を明示的に引数で渡せば十分だった。
別にthis->
292:is a pen
12/04/12 22:19:05.26
293:205-206
12/04/12 22:21:26.76
途中で送信してしまった
別にthis->～を強制する意味はなかった。
せめてthisでも明示的に渡せば書き換えが
分り易くなると思ったが無駄だった。
294:仕様書無しさん
12/04/12 22:25:38.38
>>291-293
いや違うって。
引数で渡そうが渡すまいが、
同じクラス内のメソッドだとメンバ変数に自由にアクセスできてしまうから
まずは他所へ追いやるのが先だろ。
その追いやる先というのはthis.～から始まるサブクラスしかあり得ない。
それ以外から始まるクラスはぱっと見でスコープわからんだろ。
295:仕様書無しさん
12/04/12 22:27:43.50
>>294
既にさんざん出てるけどstatic関数なら制限できるよ
296:仕様書無しさん
12/04/12 22:34:18.14
>>295
でもそれがstaticかどうかってぱっと見わからないよね。
staticじゃなくてもコンパイル通るよね。
297:仕様書無しさん
12/04/12 22:40:31.22
>>296
通るだけならグローバル変数だってコンパイル通るじゃん
じゃなくて、ルールでそう規制するんでしょ
レビューとかでさ
298:仕様書無しさん
12/04/12 22:47:24.21
>>296
簡単な文を一行書くだけで簡単にグローバル変数は使える。
でも現実には、みんな引数渡しを使う。
組織内でダメという風潮を作れるかどうかよ。
299:仕様書無しさん
12/04/12 23:24:28.33
>>282
バグに限った話じゃないけどな
改修しやすさも大きく変わる
5個関数がならんでて、5個の関数の中身調べなきゃ
改修する変数の影響が解からん場合と、
2個関数調べれば変数の動作を完全に把握できる場合とじゃ
作業に掛ける時間が大きく異なる
300:仕様書無しさん
12/04/12 23:26:48.40
実装の安易さと、保守と、バグ発生の回避を同時に満たすコーディングか。
301:仕様書無しさん
12/04/12 23:45:09.36
スマポにするとコンストラクタでthis使えないからな
どんどんソースが汚くなる
302:仕様書無しさん
12/04/12 23:46:30.95
1段メンバー呼び出してるだけでも面倒だが、
メンバー呼び出し階層が2段でその先で
書き換えられてるとか相当辛いよな
そもそも階層増えるなら自分のクラスじゃなく
他のクラスメンバー呼べって話だろうけど
303:仕様書無しさん
12/04/12 23:51:13.90
if(null == hoge)
C言語屋の年寄りってこう書くよね
最高にウザいんだけど
304:仕様書無しさん
12/04/12 23:52:57.20
>>303
お前の周りだけ。
類は友を呼ぶ
305:仕様書無しさん
12/04/13 00:11:15.56
Ｃ言語ならなおさら書かないんじゃないか？
文字列を==で比較する感覚に似ている
306:仕様書無しさん
12/04/13 00:51:18.01
>>303
一生懸命アラ探ししてやっと見つけたのがそんなどうでもいいことなのなら
その先輩は結構デキる奴だな
もしくはお前がダメすぎて他のアラが見えないか
307:仕様書無しさん
12/04/13 01:08:09.16
1年目の新参ですがこのスレは勉強になります
308:仕様書無しさん
12/04/13 01:20:16.77
1年目の新参だからこのスレは勉強になります
309:仕様書無しさん
12/04/13 06:15:22.90
>>303
定数を先に書くのはC初心者の象徴だろう。
310:仕様書無しさん
12/04/13 06:41:06.79
>>309
俺も定数先に書くわ
何か問題あんの？
311:仕様書無しさん
12/04/13 06:52:14.05
「定数を先に書いておくと、
比較と代入を間違えて記述したときエラーになるので
間違いを見つけ易い」
という理由でそういう記述の仕方をする人は散見するけども、
それは
「私は比較と代入を間違える可能性があります」
と宣言してるようなもんで、他の部分もちょっと信用ならないよねーという
ただの経験則。
312:仕様書無しさん
12/04/13 07:07:50.84
==は「～が一致する」的な読み方だから「1とaが一致」より「aと1が一致」がaの中身を調べてるって文章になり読みやすい…気がするから変数先だな完全に個人的な理由だが
313:仕様書無しさん
12/04/13 07:14:55.68
>>311
0 > ExampleFunction( ・・・, ・・・, ・・・, ・・・, ・・・ )
定数左に書けば条件見やすいけど
ExampleFunction( ・・・, ・・・, ・・・, ・・・, ・・・ ) < 0
定数右に書くと条件が右端に行くんで見づらい
314:仕様書無しさん
12/04/13 07:39:34.94
>>313
下のが見やすいんだが
315:仕様書無しさん
12/04/13 08:45:33.13
>>313
変数使えばいいやん。
条件式に直接使うぐらいなら、ほとんどの場合はExampleFunctionは意味のある名前の「はず」だから
文脈そのまま読める方が読みやすいと思うが・・・まぁ慣れれば慣れるんだろうな。
316:仕様書無しさん
12/04/13 10:47:49.74
伸びすぎててイラッつとしたコーディングスレ
317:仕様書無しさん
12/04/13 14:45:34.51
>>311
> 「私は比較と代入を間違える可能性があります」
> と宣言してるようなもんで、他の部分もちょっと信用ならないよねーという
== とタイプしようとして = とタイプしてしまう可能性は誰にでもある
「俺は間違えるかもしれない」と言ってる奴は、「俺は絶対間違えない」って奴よりも信用できる
たとえコンパイルオプションやツールでチェックできるとしても、 (0 == foo) って書くのは悪いことじゃない
そもそも、(0 == foo) が理解し辛いって奴は、数学的センスに欠けている
地図を読むときに、常に進行方向が上になるように地図をぐるぐる回す奴に通じるものがある
そんな奴とも一緒に仕事をしなければならない以上、 規約で (foo == 0) って記法に統一するってのはあるかもしれないが、
そんな奴はお荷物だということを自覚すべき
318:仕様書無しさん
12/04/13 14:52:53.94
>>317
> 「俺は間違えるかもしれない」と言ってる奴は、「俺は絶対間違えない」って奴よりも信用できる
俺なら、コンパイラがチェックしてくれるのに、「俺は間違えるかもしれない」から(0 == foo)とか書く奴は、
間抜けか頭堅い奴と判断する。
> たとえコンパイルオプションやツールでチェックできるとしても、 (0 == foo) って書くのは悪いことじゃない
悪いことだよ。
> そもそも、(0 == foo) が理解し辛いって奴は、数学的センスに欠けている
数学的センスなんか関係無いよ。言語の話をしてるんだよ。
「if foo is zero」と「if zero is foo」を同じように同じ速度で紛れがなく誰でも判断できるかどうかの話。
> そんな奴はお荷物だということを自覚すべき
お前がお荷物だよ、全く。
319:仕様書無しさん
12/04/13 14:56:55.59
マジックナンバーを直書きすることはほとんどないし
定数なのにconstを忘れる可能性もあるな
320:仕様書無しさん
12/04/13 15:17:29.57
0 == fooと書いたとしても、問題の解決になっていないからねぇ。
手癖みたいなもんで、書くのは勝手だとおもうが
「0 == fooのほうがいい」と主張する奴の話は当てにしない。
321:仕様書無しさん
12/04/13 15:28:50.32
たとえ話をする奴は説明が下手
322:仕様書無しさん
12/04/13 16:12:14.85
誰も 0 == foo の方が良いって主張してないと思うが
foo == 0 の方が良いって主張してる奴はいるけど
323:仕様書無しさん
12/04/13 16:17:01.34
>>322
日本語の読解力に甚だしく欠けてます
324:仕様書無しさん
12/04/13 16:28:25.79
>>322
お前にイラッつとしたわ
325:仕様書無しさん
12/04/13 16:55:33.94
>>311
ちょっと頭悪すぎ
hoge == null の方がいい理由は、null == hoge と書いたときに得られるわずかな利点よりも、
直感的に理解しづらいという欠点の方が大きいから
もちろん if (hoge = null) みたいなミスを検出できる開発環境下が前提だが
326:仕様書無しさん
12/04/13 17:11:28.77
>>325
いや、お前が頭悪すぎだから
>>311を百回読め
327:仕様書無しさん
12/04/13 17:18:36.25
if (0 == hoge)の件は、ある程度の分量の文章を一度読んだだけでは理解できないIQの層の奴らの
琴線に触れる何かをもってるんだろうな
328:仕様書無しさん
12/04/13 17:27:01.97
>>326
俺は 0 == x と書く人に対して、用心深いとは思っても
> 「私は比較と代入を間違える可能性があります」
> と宣言してるようなもんで、他の部分もちょっと信用ならないよねーという
みたいな感想は抱かないがね
329:仕様書無しさん
12/04/13 17:31:55.14
>>325=>>328だとしたら、ちょっと何言ってるのかわからないレベル
330:仕様書無しさん
12/04/13 17:37:41.05
え？
「私は比較と代入を間違える可能性があります」から、用心深く0 == x と書く人が糞だとみんな言ってんじゃないの？
331:仕様書無しさん
12/04/13 17:42:57.72
>>328
俺なら、そんなくだらん用心深さなんか発揮しないで、読みやすいコード書けアホと思うな。
332:仕様書無しさん
12/04/13 17:50:48.47
雨が降る可能性が0%でないからと言って、毎日レインコートと長靴で生活する馬鹿
333:仕様書無しさん
12/04/13 17:50:49.33
>>331
で、お前は 0 == x と書く人の他の部分のコードが信用ならないと思うのか？
俺は他の部分にも同様の用心深さを期待できてむしろ信用できると思うがね
334:仕様書無しさん
12/04/13 17:53:34.46
>>333
全く信用できない。
そいつは、
・コンパイラが教えてくれるのを知らない無知
・それは知ってるが、「念のため」とかいう訳のわからない理由でスタイルを崩さない馬鹿
のどちらかだから。
335:仕様書無しさん
12/04/13 17:53:44.63
>>332
> 雨が降る可能性が0%でないからと言って、毎日レインコートと長靴で生活する馬鹿
ソフトウェア開発においては、それが普通
336:仕様書無しさん
12/04/13 17:56:18.69
if (0 == hoge)と書く奴を「用心深い奴」と評価する奴に初めて会ったわ
337:仕様書無しさん
12/04/13 17:59:37.08
if (0 == x)と書くことが良いことだと思うような間抜けのコードが信頼できるわけないだろ
338:仕様書無しさん
12/04/13 18:00:54.32
条件式は左辺が評価対象じゃないとな
左読みで重要な情報を先に目に入るようにしないと、思考の効率が格段に悪くなる
339:仕様書無しさん
12/04/13 18:03:58.21
returnやsizeofで不要な括弧を「その方がわかりやすいから」と取ろうとしない奴とか、
if (hoge == true)を「その方がわかりやすいから」という奴と同じ臭いがする
340:仕様書無しさん
12/04/13 18:04:59.80
GNUのコーディングスタイルほどいらつくものは無い
341:仕様書無しさん
12/04/13 18:08:09.13
>>311
コーディング標準とか禁じ手を全否定？
342:仕様書無しさん
12/04/13 18:10:42.06
またわけのわからん奴が現れた
343:仕様書無しさん
12/04/13 18:17:26.07
括弧や演算子の前後に一切スペースを入れず、空行も一切入れないスタイルにいらつく
344:仕様書無しさん
12/04/13 19:14:49.43
>>317
＞== とタイプしようとして = とタイプしてしまう可能性は誰にでもある
自分のを発見して「ホントにあるんだ・・・」と、変な感動を覚えた記憶がある
345:仕様書無しさん
12/04/13 19:18:12.09
不毛な議論
346:仕様書無しさん
12/04/13 19:18:48.78
3 x 4 と 4 x 3 は意味が違うんだ、という小学校の話を思い出した。
347:仕様書無しさん
12/04/13 21:18:11.51
>>339
sizeofは括弧付けちゃうなあ・・・
348:仕様書無しさん
12/04/13 21:30:47.51
>>346
3+3+3+3と4+4+4は確かに違うといえば違う
349:仕様書無しさん
12/04/13 21:37:56.62
== を妄想オーバーライドしすぎ
350:仕様書無しさん
12/04/13 21:51:32.59
regist
351:仕様書無しさん
12/04/13 21:55:31.92
>>350
あるあるw
352:仕様書無しさん
12/04/13 22:13:55.77
>>315
やだよ一時変数で済むもんワザワザ宣言するなんて
あと、具体的な名前書いても条件が画面右寄りになることで到底分かりやすくなったとも思えん
while( 0 < GetMessage( &message, 0, 0, 0 ) ){}
353:仕様書無しさん
12/04/13 23:05:38.21
hoge == 0 でも 0 == hoge でも何とかなるのだが、
hoge == 0 で統一されたソースに 0 == hoge で
追加修正された時はイラッつとした
354:仕様書無しさん
12/04/13 23:48:50.81
まだそのネタが続いてるのか
0 == hoge か hoge == 0 かなんてどうでもいい
>>311の頭おかしいのは
> 「私は比較と代入を間違える可能性があります」
> と宣言してるようなもんで、他の部分もちょっと信用ならないよねーという
の部分
もっと言うと、>>311は一切typoしない、typoする奴は信用ならねーって言ってること
355:仕様書無しさん
12/04/14 00:00:15.21
両者を納得させるために
hoge == A は (hoge - A) == 0 にしようず
356:仕様書無しさん
12/04/14 01:27:09.14
>>339
ちなみに、「sizeof 識別子」と「sizeof(型)」は別物ですよ？
混在してると解り難いってゆーなら括弧必須のルールでもいいけど。
357:仕様書無しさん
12/04/14 01:29:53.09
>>352
while (GetMessage(&message, 0, 0, 0) > 0) { }
ふぅ。
358:仕様書無しさん
12/04/14 01:47:16.66
１００％ミスしない人間が存在しているという前提がもう頭おかしいだろ。
0==hogeが見難いのは単なる慣れ。
オレの気に入る書き方以外はクソとかどんだけ自己中なのか。
359:仕様書無しさん
12/04/14 02:18:18.91
>>358
>>334
360:仕様書無しさん
12/04/14 02:29:41.11
そうかいちゃダメな理由になってないだろうｗｗ
361:仕様書無しさん
12/04/14 02:47:50.81
そうだね。
362:仕様書無しさん
12/04/14 04:40:43.71
0==hogeって書く奴は定数がdefineされててもFUGA==hugeってやるんだよな。キモイ…
つか、==じゃない比較演算子もそうすんの？HOME>=hageとか。==だけ？
363:仕様書無しさん
12/04/14 05:22:19.96
>>362
不等号に関しては、複数並ぶときに向きを揃えるっていう
数学的なお約束があるんで、それに合わせることも多いんじゃね。
定数1 <= 変数A && 変数A <= 定数2
みたいに。
364:仕様書無しさん
12/04/14 05:24:52.86
>>358
スレタイ読め
365:仕様書無しさん
12/04/14 06:25:36.06
｡･ﾟ･(Дﾟ(0==(´∀｀ )
これをグループ内で提案したらものすごく気持ち悪がられた
本質的に「わざと違和感を抱かせてミスを防ぐ」トリックだから
やむをえないかもしれない
366:仕様書無しさん
12/04/14 09:10:49.83
それは慣れていない所だから有効なんだろう。
違和感が無くなるほど使用されている現場ならミス防止には役に立たない。
削除の時の確認ダイアログと同じ話。
367:仕様書無しさん
12/04/14 09:28:16.94
>365
>本質的に「わざと違和感を抱かせてミスを防ぐ」トリックだから
>やむをえないかもしれない
そんな理由付けが許されるならば、
int func0005()
とかも許されるな。
「これも、わざと違和感をもたらせてミスを防ぐトリックですよ」とか
「関数名がもたらす思い込みを排することでミスを防いでいます」とか。
368:仕様書無しさん
12/04/14 09:38:57.26
>>367
違和感を抱かせて「あぁ。そういうことね」と思い出させる。
0==hogeを見れば、「hogeに代入しないように」ということを思い出す。
さて、int func0005()
違和感は感じるが、肝心の「思い出す」ことはなんだ？
369:仕様書無しさん
12/04/14 09:52:09.53
hogeには代入してもいいんじゃないの？
代入したくないんだったらconstでも付けとけばいい話では。
(言語によってはできないのもあるのかな)
370:仕様書無しさん
12/04/14 10:27:21.14
if( 0 == hoge ) はほとんどお目にかかった事無いから気にして無い。
if( hoge = 0 ) はWarning出てるのに放置されてたのをこの前見かけた。
Warning出てるのにコミットする奴にイラッつとする。
371:仕様書無しさん
12/04/14 10:56:45.31
>>368
「動作を知りたければ仕様書にあたれ」とか？
372:仕様書無しさん
12/04/14 11:09:30.40
だいたいそんな言語を使うほうが悪い
VB使えよ
373:仕様書無しさん
12/04/14 12:33:07.09
だめだ、このスレは汚いソースコード位イライラする
374:仕様書無しさん
12/04/14 12:34:52.32
イライラじゃなくイラッつとしなくちゃダメだろ
375:仕様書無しさん
12/04/14 12:36:56.40
☆
× ' . ×
x ｀ . ｘ ヽ . ☆
Ｘ ,. -. ‐'´￣｀`丶､ ﾉ} Ｘ
／} ／: : : : : : : : : ｰﾍ
× / //: : : :l: .:. .} | . : : : : } . ． ゜
_ノ_,ﾑ′: : : |:::::::/! l.::. : ! /: :＼ , ☆
_／ /,. -‐〉 : : :_ !:;ｲ￢.|:i::: |i.|. :.i::: : : ヽ ;
☆ . . ,. '´!{ ゝ-‐''＾¨二.ノ:〔__－ V!::!LTV{::: : : :.',
×ｘ . ぃ .イ::. : : |⌒` }:ﾘ'示Y１:: : : ｉ } x ×
. '´ ,. 介iｰ-､ ｛:::::::::. : : ! ＾' ﾋ'ﾘ ',.|:::. :.. :.!ﾘ Ｘ
Ｘ ／ ／ヽ' Ｌ! ヽ. Y::::ｉ::::. .::. |ｒ:ｩ- ､' ｀＾ /:::l::::.::::.x:ﾘ′ ; ☆ イラッ☆
ｘ ／ / ／⌒ヽ 込Jヽ:ﾄ:{>､:ィ八_ ,.‐く ｲ:ィ:::!x::X::/ ゛
i'´ ／-r‘ｰ､ ﾍ-┴‐〉 ｀'i￢ ヘ.__{:::::::}.彳〔__レ1::ﾙ'゜ ゜ ．
ｰ ､ --－'´ ｺ:..:.}: ＼ 丶 .ｌ | -､匸⌒´:_;-､ノ ｝_ ´ ゜ ×.
｀ヽ､ └;.:. .. } 〉 ヽ.｜ 〈__:,.イv/´〕、冫｀i x ☆
｀ ￢ゥ´:..:....:..:..:..: ,ﾉ､ ＼ { ! {.{j_/,ィう′ !
ｘ ' Y:..:..:..Ｘ:..:..:.∠.._ ヽ.} |. } ｀ﾏ^V | X
, ゛ヽ:..:..:..:..／ ,.⊥_ ／小＼￢-{ ∨ﾍ._,. -‐￢､
☆ ｀ ー′ j:..:..:..:Y´:´/ハ卜':..! :ヽ ∧::ﾍ .:..:... }
/:..:..:..:..j/:..:.｀:..:´:..:..i :..:ﾄ-_ノ ﾏ'’:..:..:..:..ﾍ
376:仕様書無しさん
12/04/14 12:44:31.81
>>357
それ何が見やすいの？
377:仕様書無しさん
12/04/14 12:47:34.30
おまいらなんでC前提なん
378:仕様書無しさん
12/04/14 12:53:40.47
他の言語と違って、標準的なコーディングスタイルってものがないから。
379:仕様書無しさん
12/04/14 12:58:37.37
そんな言語早く捨ててしまえ
380:仕様書無しさん
12/04/14 13:11:52.79
比較演算に順序が決まってる言語なんてそもそも有っただろうか
381:仕様書無しさん
12/04/14 13:53:02.05
>>368
>違和感は感じるが、肝心の「思い出す」ことはなんだ？
一言では言い表せない、その関数の振る舞い全て。
>>371
その通り。
382:仕様書無しさん
12/04/14 14:06:32.51
>>381
そう思うならプログラムなんて適当に書けば？
ここにいる必要ないし、この板にいる必要もない。
プログラマ辞めちまえよ。
383:仕様書無しさん
12/04/14 14:11:37.03
>>381
真性の馬鹿だな。死んで欲しい。
384:仕様書無しさん
12/04/14 14:25:13.34
>>381
> 一言では言い表せない
じゃあダメだろｗ
一言で言い表せることが重要なんだから。
385:仕様書無しさん
12/04/14 17:06:28.29
イラッつとした相手が上司だったり先輩だったりすると何て言えばいいかわからない
386:仕様書無しさん
12/04/14 17:15:42.21
>>382-384
お前は何と戦っているんだ？
387:仕様書無しさん
12/04/14 17:17:27.90
>>385
イラッとしたら何か言わなくてはいけないという
法律でもあるのか？
388:仕様書無しさん
12/04/14 17:23:41.06
普通イラッてしたら
イラって言うだろ？
昨日も満員電車で
イラって何回も言ったわ
389:仕様書無しさん
12/04/14 17:30:20.61
昔ある中華料理のチェーン店でバイトしてたせいか
内装の同じ店に行くと新しい客が来たとき「イラッ」って言ってしまう
390:仕様書無しさん
12/04/14 17:59:30.27
>>388
うわーキモいw
そういう中二病のやついたなー学生の時w
391:仕様書無しさん
12/04/14 18:25:54.65
>>388
言わねえよｗｗ
392:仕様書無しさん
12/04/14 18:26:10.67
>>55 同意
>>249 あくせる
>>289 解釈の自由度が下がる=誤解が減る
393:仕様書無しさん
12/04/14 18:28:55.84
>>386
イラッつとしたら人に当たり散らすタイプなんだろう。
>>385
言い返す権利はないのよ？(´･ω･`)
394:仕様書無しさん
12/04/14 18:54:49.16
>>389
しゃーせー
395:仕様書無しさん
12/04/14 19:18:26.96
>>381は敢えて仕様書を読ませる為に
プログラムを読みにくくすると言ってるんだぞ。
まるでコボラーだな。
396:仕様書無しさん
12/04/14 20:06:14.10
ソース暗号化しといて、readmeに「複合鍵は仕様書の中に隠されているよ！頑張ってね☆ミ」で解決
397:仕様書無しさん
12/04/14 21:10:03.59
while (GetMessage(&message, 0, 0, 0) > 0) { }
が
while( 0 < GetMessage( &message, 0, 0, 0 ) ){}
になるだけで仕様書読まなきゃならんのか
398:仕様書無しさん
12/04/14 22:32:45.64
>>395
もう関数名を「仕様書嫁123」とかにすればいいのに。
399:仕様書無しさん
12/04/14 22:37:11.11
コンパイルしてしまえばコーディングスタイルなんて気にしなくてもよくなるだろ
400:仕様書無しさん
12/04/14 22:43:49.11
そゆこという奴よくいるよな
401:仕様書無しさん
12/04/14 22:44:20.94
コンパイルした後のコードを読んで修正してメンテナンスし続けるのならそうかもなｗ
402:仕様書無しさん
12/04/14 22:54:21.47
>>395
有象無象のソルジャーというか土方というか、そういうのを束ねて開発する
方法論としてはアリだと思うがな。やらされる立場になったら負けということで。
403:仕様書無しさん
12/04/14 23:03:55.99
やる立場になっても負けだろｗ
404:仕様書無しさん
12/04/15 01:09:35.10
男ならコードで語れや
405:仕様書無しさん
12/04/15 15:19:30.14
if (VeryLongoLongFunctionName(var1,var2,var3,var4) > 3)
みたいにクソ長い名称と比較するときは、定数を左辺に置いたほうが見やすい。
406:仕様書無しさん
12/04/15 15:26:58.70
int value = VeryLongoLongFunctionName(var1,var2,var3,var4);
if (value > 3)
こうすればいいだけ
407:仕様書無しさん
12/04/15 15:35:57.19
そもそも関数名すら読まないのかと疑いたくなる
408:仕様書無しさん
12/04/15 15:46:23.75
引数が多くて横に長くなる時にどう書いたら見やすいかでイラッつとする。
func( var1,
var2,
var3 );
funcがやたら長い名前だと何か変な感じになるしで困る。
409:仕様書無しさん
12/04/15 16:19:41.22
func( val1, val2, val3, val4,
val5, val6, val7, val8) {
}
って書けばいいだけ
410:仕様書無しさん
12/04/15 17:30:55.79
Bazooka bazooka = new Bazooka("89mm");
bazooka.setDigree(60f);
bazooka.setRoll(25f);
bazooka.setPitch(0f);
bazooka.setExpression(0.5f);
bazooka.setPos(0f, 0f, -0.5f);
bazooka.setColor(1.0f, 1.0f, 1.0f, 1.0f);
bazooka.isMorningBazooka(false);
bazooka.setTarget("Kycilia Zabi");
Result result = bazooka.shot();
411:仕様書無しさん
12/04/15 19:29:26.29
>>406
いちいち変数に入れるなよイラッとする
412:仕様書無しさん
12/04/15 19:33:24.86
>>411
デバッガ使わない (使えない) 人特有の症状だね＞一時変数を嫌う
413:仕様書無しさん
12/04/15 19:56:25.02
おまえがいってるのは一時変数じゃないだろ
それはともかく、whileやifの条件ならどっちの分岐に進んだか、
ループを抜けたか抜けないかで判断できる。
それによほどしょぼいデバッガーじゃなけりゃ戻り値確認できるし。
414:仕様書無しさん
12/04/15 20:06:06.00
>>409
こいつ馬鹿
>>410
何回も変数書いてバカっぽい。
どんだけタイピング好きなの？
415:仕様書無しさん
12/04/15 20:25:38.67
このスレのほとんどはGoにすれば解決しそうだな。
416:仕様書無しさん
12/04/15 20:33:30.55
メソッドチェインにするか
417:仕様書無しさん
12/04/15 20:33:53.56
>>414
うん、それで？
続き言わないとお前が恥をかくよ。
418:仕様書無しさん
12/04/15 20:39:41.62
>>414は構造体に入れて渡すと言いだす
419:仕様書無しさん
12/04/15 20:41:52.50
構造体にいれたら
関数のインターフェース変わるじゃんｗ
420:仕様書無しさん
12/04/15 20:49:56.05
カリー化しようよ
421:仕様書無しさん
12/04/15 20:56:44.35
じゃあ俺チキンカリー
422:仕様書無しさん
12/04/15 20:56:56.57
毎回引数が変わるのにカリー化するのか？
カリー化がわからない人へ。
class Foo {
Foo(x, y, z);
}
↓Foo（コンストラクタ）をカリー化すると
class Foo {
Foo(x, y) { Foo(x, y, 1) }
Foo(x, y, z);
}
こうなります。これがカリー化ですｗ
423:仕様書無しさん
12/04/15 20:59:25.22
おおー、よく使うけど呼び名知らなかったわ
424:仕様書無しさん
12/04/15 21:00:41.71
デフォルト引数でいいやん
425:仕様書無しさん
12/04/15 21:04:36.87
>>422
違うだろ。
これだよ。
void foo(x, y, z)
↓ カリー化
#define foo1(x, y) foo(x, y, 1)
関数fooの引数のいくつかを埋めた、
”新しい関数を作る”こと
426:仕様書無しさん
12/04/15 21:09:58.81
>>425
変わらんだろ
427:仕様書無しさん
12/04/15 21:13:27.79
つかいま出てるのってカリー化モドキだよな
F(1, 2, 3, 4, 5);
F(1)(2)(3)(4, 5);
本来のカリー化なら呼び出し方を変えられるだけ
新しい関数を定義する必要はない
1つ関数を定義すれば自動で2通りの書き方ができる
428:仕様書無しさん
12/04/15 21:37:46.36
>>427
ほう、それは便利だ！
なにが？
429:仕様書無しさん
12/04/15 21:47:58.06
F(1, 2, 3, 4, 5);
F(1)(2)(3)(4, 5);
単に数学の概念上この2つが別である事がおかしいって話だよな
プログラム的にはこれが出来るとアダプター作る手間が省けて格段に楽になるんだが
430:仕様書無しさん
12/04/15 22:01:57.19
実際にはアダプタ作るとか
ラッパー関数作れば終わりなんだけどな。
431:仕様書無しさん
12/04/15 22:02:21.06
引数の数を変えるだけの場合。
432:仕様書無しさん
12/04/15 22:48:31.36
引数の多い関数が嫌だ。
引数が多いだけならともかく、多機能にして省略可能な引数を作るクズを絞め殺したい。
433:仕様書無しさん
12/04/16 00:22:40.42
「コーディングスタイル」以外の話はｽﾚ違いですよ莫迦共。
434:仕様書無しさん
12/04/16 00:53:37.95
ぬるほど
435:仕様書無しさん
12/04/18 14:38:45.93
int GetSize()という関数を使うのに
if (!GetSize()) {
…
}
436:仕様書無しさん
12/04/18 15:37:32.74
>>435
ああ、これはイラッつとするな
437:仕様書無しさん
12/04/18 19:50:50.31
>>435
Javaで、java.beansを使うわけでもなく、
それどころかCかC++なのにいちいちGet付けてんのがイラッとする。
Qtやらboostみたいにobject.Size();か、～Size( object );でいいだろうに。
438:仕様書無しさん
12/04/18 21:35:43.22
>>437には同意
だが、
if (! foo.size()) {
// fooが空でないときの処理
}
の書き方は全く問題なし
439:仕様書無しさん
12/04/18 21:50:25.96
え？
>>438
コメントかコードのどちらかが間違ってるんじゃね？
440:仕様書無しさん
12/04/18 23:13:07.07
>>439
そのsize()はboolean型で、オブジェクトが空のときにtrueを返すという仕様という罠。
441:仕様書無しさん
12/04/18 23:15:14.67
>>435
とりあえず、Gが大文字なのがイラッつとする
442:仕様書無しさん
12/04/18 23:26:48.71
それは言語によって推奨されとる命名規則が違うんでなんとも
443:仕様書無しさん
12/04/19 07:03:01.65
Type.newと書ける言語でもないのに
関数名のキャメルケースがコンストラクターの
キャメルケースと違うのがイラッとする
const Example &object = Type();
const Example &object = Function();
444:仕様書無しさん
12/04/20 05:38:44.65
どうでもいいが、
for (i = 0; i < point; i++) {...}
は許せるが、
for (i = 0; point > i; i++) {...}
はイラッとくる。
あと、K&Rスタイルじゃないコーディングもイラッと来るおっさんですが。
445:仕様書無しさん
12/04/20 06:59:50.72
ラムダ式とプロパティの存在
446:仕様書無しさん
12/04/20 18:04:11.69
void illatz(int n, int step)
{
printf("%d, ", n);
if (n < 2) {
printf("%d step\n", step);
return;
}
++step;
n = n%2 ? 3*n+1 : n/2;
illatz(n, step);
}
447:仕様書無しさん
12/04/20 19:59:13.79
見やすく書く、
呼び出し構造を追いかけやすくする
インデントを揃える
こういう書き方ができない奴は
プログラマに向いていない。
美意識が無いやつは消えろ。
448:仕様書無しさん
12/04/20 20:04:12.06
hoge禁止
fooは許せるがhogeはイラッつとする俺だが、表立ってhogeを禁じられるのはそれはそれでイラッつとする
449:仕様書無しさん
12/04/20 20:06:43.00
fooとかbarは西洋かぶれっぽくて嫌味が。
450:仕様書無しさん
12/04/20 23:55:09.79
>>448
お前hageだな？ｗ
451:仕様書無しさん
12/04/21 00:16:12.53
は、は、は、はげちゃうわ！
452:仕様書無しさん
12/04/21 11:07:27.55
まあまあ
アイスでも食って落ち着こうぜ
URLﾘﾝｸ(www.haagen-dazs.co.jp)
453:仕様書無しさん
12/04/21 12:52:00.49
俺は薄いだけだからセーフだな
454:仕様書無しさん
12/04/21 17:15:03.61
ホリエモン 元ニート でググれ
やばすぎｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
455:仕様書無しさん
12/04/21 18:57:29.69
a.set(b.getHoge())
こういう戻り値を直接引数に渡しているコード
デバッグしずらいんだよね
456:仕様書無しさん
12/04/21 19:43:40.18
どうすべきだと思う？
いったん器に入れてから食う？
457:仕様書無しさん
12/04/21 20:29:54.84
デバッガを変える
458:仕様書無しさん
12/04/21 21:43:37.82
うーん、読みやすいと思うんだけどねー
459:仕様書無しさん
12/04/21 22:53:11.51
デバッガ使わないやつはまったく使わないからな。
オレなら一時変数に1度いれるようにする。
460:仕様書無しさん
12/04/22 06:52:26.52
場合によるが大抵は一時変数にいれるな
461:仕様書無しさん
12/04/22 18:58:57.81
俺も一時変数に入れる
462:仕様書無しさん
12/04/22 19:02:15.91
>>456
戻り値を表示できるデバッガを使うのが一番楽
463:仕様書無しさん
12/04/22 19:29:33.48
int getHoge(){ return Fuga; }
ってのがヘッダに書いてあってもデバッグし辛い時があるけど、諦めてる。
464:仕様書無しさん
12/04/22 21:44:00.17
それはインライン展開があるからしょうがない。
でも行を分けてないとデバッグしにくいよね。使わないやつには判らんだろうが。
465:仕様書無しさん
12/04/22 21:56:01.47
printfデバッグだって変数につっこまなきゃできないぞ
466:仕様書無しさん
12/04/23 00:33:12.37
一時変数にいれる一手間を加えると美味しいソースが出来るの？
同じ味が出せるなら手抜きした方がいいと思うんだけど。
467:仕様書無しさん
12/04/23 00:38:58.96
> 一時変数にいれる一手間を加えると美味しいソースが出来るの？
簡単に味見ができる。
468:仕様書無しさん
12/04/23 00:52:14.87
そんなに手間かなあ？
469:仕様書無しさん
12/04/23 04:46:41.50
そんなに手間っていうより、無駄な手間って感じ。
関数名が正しければ一時変数にいれない方が文章として読みやすいし。
あと、処理系によつまては処理が早そうだし。
と書いたけど、俺も一時変数にいれた方がその後のコードが読みやすくなる場合は一時変数にいれてるな。
入れる入れないの判断基準が「デバッグ出力しやすいか」ってのと「読みやすいか」ってのとの違いか。
470:仕様書無しさん
12/04/23 07:43:18.44
副作用を消せば返ってくる値が同じなので変数に入れる必要すらなくて
ただ関数の結果をピークすればいい。
471:仕様書無しさん
12/04/23 08:01:12.26
>>464
コンパイラにまかせろよ
ライブラリとして外部に譲渡すること考えたらキモチ悪いだろ
472:仕様書無しさん
12/04/23 13:55:23.45
一時変数に入れるのはいいが、temp だの value だの ret なんて名前だったり、const つけてなかったりしてるとイラッつとする。
473:仕様書無しさん
12/04/23 22:00:40.40
>>472
そんな奴が一時変数の効能考えて使ってるとは思えないわｗ
474:仕様書無しさん
12/04/23 22:32:09.16
中途半端な変数使うぐらいなら観察用関数使った方がましだわ
名前考えるのマンドクセ
template<class type> type &Check( type &value )
{
return value;
}
template<class type> const type &Check( const type &value )
{
return value;
}
FunctionB( Check( FunctionA() ) );
475:仕様書無しさん
12/04/23 22:44:57.33
>>474
そうするくらいならFunctionAの結果を直接見るよね
476:仕様書無しさん
12/04/23 23:11:32.50
今どき戻り値が見れないデバッガとか何を使ってるの？
16bit環境？
477:仕様書無しさん
12/04/24 01:00:11.79
パートナー
478:仕様書無しさん
12/04/24 10:32:44.75
>>474
これはイラッとするわ
479:仕様書無しさん
12/04/27 18:52:57.59
if(!strcmp(foo,bar)){
480:仕様書無しさん
12/04/27 21:16:24.59
strcmpが真偽値を結果とするような関数じゃないから不自然だね。仕方ないね。
481:仕様書無しさん
12/04/28 06:30:45.48
#define 麿 malloc
#define おじゃる free
482:仕様書無しさん
12/04/28 11:01:56.73
>>479
ふつーに使う
483:仕様書無しさん
12/04/28 11:37:23.29
switch( mode ){
case eHoge: mode++; break;
case eHoge+1: mode++; break;
case eHoge+2: mode = eFuga; break;
case eFuga: mode++; break;
case eFuga+1: break;
}
484:仕様書無しさん
12/04/28 13:21:59.68
>>480
真偽値などという型がないCが不自然なのであって
Cとしてはあれで正しい、といえなくもない。
485:仕様書無しさん
12/04/28 13:36:00.81
strequal関数を作ればいいだけの話
どちらが大きいか比較して
真だった場合。
意味がわからないだろ。
if(strcmp(a,b)) とはそのように読む。
どうしてもstrcmpを使いたいなら==0とするのが正解。
0をSTRMATCHと定義し、==STRMATCHとするのがベター
486:仕様書無しさん
12/04/28 14:40:19.32
>>484
不自然か？真偽値なんて、真偽値がオブジェクトだったり、
オーバーロードが必要と言う理由じゃなければ独立した型である必要ないだろ
単なる名前付けした定数で充分なぐらいじゃん
487:仕様書無しさん
12/04/28 14:42:23.28
真偽値という別の名前を与えている以上
別のものであると我々人間が解釈しているのですよ。
コンピュータに合わせない。
人間に合わせる。
488:仕様書無しさん
12/04/28 14:48:31.46
未だ真偽値という分け方自体が最善かすら揉めてるのにw
489:仕様書無しさん
12/04/28 14:51:37.24
真偽値というか、ifの文脈で明らかにおかしいだろ
490:仕様書無しさん
12/04/28 15:07:33.70
外国人にはこのように見えています
もし（文字列比較(a,b)の否定) なら
491:仕様書無しさん
12/04/28 15:17:02.25
コードかきなれてるやつで、自然言語に近づけたいと
思ってるヤツなんてほとんど居ないだろ
慣れて気になるのは合理的か、回りくどくないか(考える手間が増えないか)
ぐらいだろ
492:仕様書無しさん
12/04/28 15:21:04.96
じゃあなんで関数名、変数名、キーワードは
英語なんですか？
英語＝自然言語ですよ。
493:仕様書無しさん
12/04/28 15:24:41.47
>>492
名前だけだろ
文章の体をなしてない
494:仕様書無しさん
12/04/28 15:24:54.62
if(!strcmp(foo,bar)){
これで、実効時間が一クロックでも違うのなら意味があると思うけど、
== 0 と変わらないのであれば、採用するメリットがない。
495:仕様書無しさん
12/04/28 15:24:59.39
>>492
英語じゃなくてもいいけど
496:仕様書無しさん
12/04/28 15:26:26.29
>>493
でも、名前は英語ですよね。
その名前から連想できるものは何でしょうか？
そこは変わらなはずですが。
むしろ、自然言語から連想できるように
キーワードを選んでいるわけだけど。
497:仕様書無しさん
12/04/28 15:28:25.70
例えばifという名前が、繰り返すという意味だったりしたら
わけがわからないことになる。
そんな事するぐらいなら、ifもforもやめて、
A01、B02 とかいうキーワードの方がまだまし。
でもそうしないで、ifという単語を割り当てているというのは、
ifという単語の本来の意味が重要だってこと。
498:仕様書無しさん
12/04/28 15:28:31.58
>>493
Javaなどでは、オブジェクト.動詞目的語
という命名規則が普通ですね。
499:仕様書無しさん
12/04/28 15:50:55.83
>>496
日本語でも、イスラム語でもフランス語でもいいぞ。
500:仕様書無しさん
12/04/28 15:53:58.39
>>496
構文に自然言語を求めてないと言ってるんだが。
大体、Unixのソースコードとか英語名称に準拠してるか？
アルファベット使ってるだけで略語だらけじゃねぇか。
アルファベット使ってりゃ自然言語だというなら、そりゃ全部自然言語だろうよ。
501:仕様書無しさん
12/04/28 16:00:09.18
馬鹿って絶対に自分の非を認めないよね
故に馬鹿なのか
502:仕様書無しさん
12/04/28 16:04:07.16
英語で書いてある部分なんて機能が解るシンボルとしてしか見ないな
言語自体が英語らしいかどうかなんてどうでもいいや
COBOL見たいなの見せられたら吐き気がするし
503:仕様書無しさん
12/04/28 16:05:57.41
>>500
> 構文に自然言語を求めてないと言ってるんだが。
あなたわかってるじゃないですかｗ
自然言語を求めてないのは構文でしょう？
単語には自然言語を求めてるんですよ。
504:仕様書無しさん
12/04/28 16:06:45.08
略語も自然言語。自然言語の略語。
505:仕様書無しさん
12/04/28 16:22:10.58
>>492 は、「アルファベット」を見ると「英語」と言ってしまう
ローマ字未修得の小学生、あるいは戦中派に違いない。
506:仕様書無しさん
12/04/28 16:25:09.14
>>505
え？ 普通言語って英語を元にしてるでしょｗ
507:仕様書無しさん
12/04/28 16:27:30.60
俺の大得意な言語は
日本語を元にしてますよ。
なんてなーｗｗｗｗ
508:仕様書無しさん
12/04/28 16:32:49.85
>>506
UKとUSAの人間が読めなくても英語なのか？
509:仕様書無しさん
12/04/28 16:33:55.58
>508
if が読めないのですか？
510:仕様書無しさん
12/04/28 16:34:11.97
string や compare が読めないのですか？
511:仕様書無しさん
12/04/28 16:34:34.45
TSUNAMI, HENTAIは英語だけど
Heigh Visionは日本語という不思議。
512:仕様書無しさん
12/04/28 16:35:51.86
英語が分かる人
「strcmpって何？」
「string compare の略だよ」
「なるほど！」
513:仕様書無しさん
12/04/28 16:36:21.62
>>509
"if"だけじゃなぁ。interfaceの略かもしれんし、
イタリア語かもしれんし、フランス語かもしれんし。
514:仕様書無しさん
12/04/28 16:36:57.36
>>511
英語わからないならムリしないほうがいいよｗ
515:仕様書無しさん
12/04/28 16:38:06.09
>>509
ifとかdefaultとか予約語じゃない言語もいっぱいあるぞ
関数型系とかSmalltalkの派生とか
516:仕様書無しさん
12/04/28 16:38:10.51
>>513
英語と考えれば辻褄が合うでしょｗ
だからほとんどの言語＝英語が元になっているわけです。
517:仕様書無しさん
12/04/28 16:39:29.02
>>516
if( a == b )
これをよめるヤツはプログラマーぐらいだろ
518:仕様書無しさん
12/04/28 16:40:07.42
>>515
予約語かどうかは本質じゃねーｗ
プログラム言語はほとんど英単語が
元になってるってことだろ。
英単語そのものか、英単語の略語ばかりだ。
よってコーディングする時は
英語の意味を考えなさいということ。
519:仕様書無しさん
12/04/28 16:41:12.04
>>517
ifが英語だからプログラマーは読めるよね。
gtaweg( a == b)
これ、読めるかい？
520:仕様書無しさん
12/04/28 16:41:29.02
>>518
cat と cdr はどういう意味？
521:仕様書無しさん
12/04/28 16:42:12.07
>>519
言語仕様読めば解るんじゃね？
522:仕様書無しさん
12/04/28 16:43:51.60
>>519
プログラマー外の英語圏の人間はすぐ解らんだろうと
いう意味で書いたんだが
523:仕様書無しさん
12/04/28 16:43:51.88
Lisp の car や cdr が、以下の略であることぐらい、Lisp をかじったことのある人なら知っているでしょう。
Contents of the Address part of Register number
Contents of the Decrement part of Register number
524:仕様書無しさん
12/04/28 16:44:53.93
>>522
そりゃそうだろ。
そんな話はしていない。
ほとんどのプログラム言語は
英語が元になってることに異論はないね？
525:仕様書無しさん
12/04/28 16:45:31.86
>>523
やっぱりcatやcdrも英語の略なんだね。
526:仕様書無しさん
12/04/28 16:48:37.26
>>524
COBOLレベルなら英語が元になってるとは言えるかもしれんが
シンボルだけ英語使ってるものを英語が元になってると言われると
違和感が有るぞ
527:仕様書無しさん
12/04/28 16:49:23.26
> シンボルだけ英語使ってる
あ、認めたｗ
シンボルだけじゃなくて
意味も英語の意味を使ってる。
528:仕様書無しさん
12/04/28 16:51:22.35
文法は英語じゃなくが
単語は英単語だし
意味も英単語だ。
なのだからその意味に当てはまらない使い方をしたらダメ。
529:仕様書無しさん
12/04/28 16:56:57.83
>>528
> 意味も英語だけど
int 変数 = 0;
classs Type { public Type(){} }
英語の意味でどう読むんだ？
530:仕様書無しさん
12/04/28 16:59:31.80
>>527
俺は構文が英語じゃないから、言語全体は自然言語に近い必要はないと
いう意味でしかレスしてない。名前云々のレスといっしょにすんな。
531:仕様書無しさん
12/04/28 17:04:57.39
>>529
変数は日本語ですが？
int ・・・ integerの略。なるほど整数か！
class ・・・種類
Type・・・型
public・・・公開
英語だと考えれば、辻づまがあう。
532:仕様書無しさん
12/04/28 17:05:54.91
>>531
単語の意味じゃなく英文として読めよ
533:仕様書無しさん
12/04/28 17:06:08.67
>>530
俺は単語が英語だから
その英語の通りの使い方をしろと言ってる。
534:仕様書無しさん
12/04/28 17:07:24.65
>>532
なぜ英文として読まないといけないの？
俺は最初から構文は英語じゃないが
単語が英語であり、
その意味のとおりに使えと言ってるだけですが？
535:仕様書無しさん
12/04/28 17:13:37.49
>>534
俺は最初から構文は英語じゃないからコードが英文に準じる必要はないと言っている
まぁ、>>500で余計なことは書いたが。
536:仕様書無しさん
12/04/28 17:15:42.11
なら単語が英単語になっている理由は？
537:仕様書無しさん
12/04/28 17:15:57.31
英単語の意味を無視していいなら、
英単語を使う理由はない。
538:仕様書無しさん
12/04/28 17:19:33.03
名前と構文をごっちゃにするなって
ダンボールに英語のラベルはってあったら、
ダンボールが英語に準拠してんのかよ
539:仕様書無しさん
12/04/28 17:21:25.05
そうですが何か
540:仕様書無しさん
12/04/28 17:21:47.37
つられて英語と書いてしまったが
そもそも、自然言語に準じる必要が無いといだけで
英語かどうかは重要じゃないだろ。
541:仕様書無しさん
12/04/28 17:28:03.72
>>539
XSLTとXMLの仕様をごっちゃにしてそうな発言だな
542:仕様書無しさん
12/04/28 17:30:35.83
多分最近のaviにはH.264が入ってることが多いから
>>539にとってaviはH.264がなんだろうな
543:仕様書無しさん
12/04/28 18:55:32.75
ダンボールの中身が英語に準拠しているかもしれないと期待することは出来るかな
544:仕様書無しさん
12/04/28 20:41:52.10
プログラムは自然言語ではないが
自然言語に似せて書くのが上手い書き方だろ。
何故なら、コンピュータが読むものであると同時に、人間が読むものでもあるからだ。
545:仕様書無しさん
12/04/28 21:33:26.78
>>544
「個人的見解」って頭につけといた方がいいですよ。