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
「個人的見解」って頭につけといた方がいいですよ。
546:仕様書無しさん
12/04/28 21:34:38.61
>>545
まずお前から実践なｗ
547:仕様書無しさん
12/04/28 21:53:43.30
>>544
人間が読む場合と、コンピュータが読む場合があるところまではいい。
ただし、人間が読む場合は、人間らしい人間が読む場合と、コンパイラみたいな人間が読む場合と、宇宙人が読む場合があるんだよな…
「個人的見解だが」
すべての人間に読みやすいプログラムというものは存在しないと思う。
なので、読む人に合わせた書き方が求められる。
これは、もはやソースコードを介したコミュニケーションであって、そういう意味では、やはりプログラマは物書きだなーと思うし、コミュニケーション能力が求められる仕事だなと思う。
548:仕様書無しさん
12/04/28 22:17:18.20
>>547
すべての人間ではなく、
大部分の人間といえばいいだけの話。
549:仕様書無しさん
12/04/28 22:40:44.94
>>544
COBOLが読みやすいか？
ならCOBOL使えばいい。
ひまわりでもかまわんぞ
550:仕様書無しさん
12/04/28 22:51:04.29
>>549
URLﾘﾝｸ(www.aoky.net)
551:仕様書無しさん
12/04/28 22:56:54.08
>>550
すごいな。
たまたま英文風に読める文章を
持ってきて全てを語るなんてｗ
552:仕様書無しさん
12/04/28 22:58:44.27
>>550
そのページが読みにくいのはなんでだ？ｗ
553:仕様書無しさん
12/04/28 23:04:43.00
>>550は
自然言語とプログラム言語は白と黒のようにはっきり分かれておらず
プログラマは皆、灰色の領域で仕事をしているのだと判らせてくれる。
554:仕様書無しさん
12/04/28 23:05:57.12
>>550
>['toast', 'cheese', 'wine'].each { |food| print food.capitalize }
英文まねても読みづらいだけだな。
555:仕様書無しさん
12/04/28 23:07:10.90
>>554
そもそも英語が読みやすい言語かっつうのもあるしな
556:仕様書無しさん
12/04/28 23:11:55.82
しかし、単語は英単語であり、
その英単語の意味通りを使い方をしているのは
どの言語も同じなのだ。
557:仕様書無しさん
12/04/28 23:25:22.95
何が問題か解ってないコミュ障が居るな
558:仕様書無しさん
12/04/28 23:30:53.03
じゃあ、話を最初に戻そう
if(!strcmp(foo,bar)){
問題はこれ。
strcmpは文字 比較の略であり、
ifはもし。
つまり、「もし（文字比較）なら」
という意味になるので、これはイラッとするコーディングである。
559:仕様書無しさん
12/04/28 23:33:13.51
この話に対して、プログラム言語は、
英語の文法と違うとか的外れのこといいだして、
そうじゃなくて、単語は英語であり
単語の意味通りの使い方をするべきという
話だよって教えてるだけ。
それを分からず、文法が～文法が～と
的外れのことを言い続けてる。
560:仕様書無しさん
12/04/28 23:38:06.42
>>558
! が Not ならいいの？
561:仕様書無しさん
12/04/28 23:43:31.70
違うね、ごめん。
562:仕様書無しさん
12/04/29 00:00:23.13
>>559
英単語と名前の話が一番ずれてる
563:仕様書無しさん
12/04/29 00:02:23.85
>>559
>つまり、「もし（文字比較）なら」
>という意味になるので、これはイラッとするコーディングである。
問題は、文としての書き方なのに何でお前は名前に拘ってんだ？
564:仕様書無しさん
12/04/29 00:08:33.22
> 問題は、文としての書き方なのに
どこ見てそう思いましたか？
565:仕様書無しさん
12/04/29 00:09:46.10
>>564
「もし（文字比較）なら」
566:仕様書無しさん
12/04/29 00:10:20.91
strcmpの戻り値が真偽値ではない、
真偽値ではないものを、もし（if）で使うなという
話ですよね？
567:仕様書無しさん
12/04/29 00:11:05.12
>>564
文の話じゃねーよ。
真偽値を返さないものを
ifで使うのが気持ち悪いという話だよ。
568:567
12/04/29 00:11:30.38
× >>564
○ >>565
569:仕様書無しさん
12/04/29 00:12:46.49
なぜ真偽値じゃないものをifで使うのが気持ち悪いかというと
ifが、もし～なら という意味だからでしょうね。
570:仕様書無しさん
12/04/29 00:17:59.45
>>567
だからif文の中で真偽値を返さないものを返してる文の書き方がおかしいんでしょ
571:仕様書無しさん
12/04/29 00:21:13.19
>>570
文がおかしい？
じゃあ、どういう文ならおかしくないというの？
”文”ですよね？
572:仕様書無しさん
12/04/29 00:28:03.95
>>571
真偽値を返す関数を使った文だったらよろしいんじゃないでしょうか
573:仕様書無しさん
12/04/29 00:29:31.39
>>572
つまり、式を変えるってことですねｗ
あれ？文の話じゃなかったのかいｗ
574:仕様書無しさん
12/04/29 00:31:34.03
直感と反するのが気持ち悪い
一緒だったらって判定に!使うな
575:仕様書無しさん
12/04/29 00:32:25.05
strcmpは「一緒だったら」ではなく、
「比較したら」
576:仕様書無しさん
12/04/29 00:37:31.36
>>573
文として分かり辛いから文の中の式を直すってのがおかしいか？
577:仕様書無しさん
12/04/29 00:38:41.57
もし(おなじである(a, b))なら
なら気にならない。
578:仕様書無しさん
12/04/29 00:39:49.83
>>576
文はおかしくなかったから、文はそのままで
式を書きなおしたんだろｗ
お前、文がなにかわかってるのか？
if文の定義・・・if (条件式) 真文
仕様書見てもこんな感じでしか書いてないぞ。
579:仕様書無しさん
12/04/29 00:40:38.23
>>577
つまり、英単語の意味と合っていないということか。
580:仕様書無しさん
12/04/29 00:40:50.64
>>575
大元のif文はどう見ても一致してるかの判定
それ以外の意図で書いてたらなお悪い
581:仕様書無しさん
12/04/29 00:40:53.63
もし(ひかくする(a, b))なら
だとわかりにくい
さらに
もし(文ひか(a, b))なら
だからもう死ね
582:仕様書無しさん
12/04/29 00:43:04.40
>>578
仕様書には書いてないから実現は可能だが、プログラムには意図を込める事が出来る。
プロなら使わない手はない。
583:仕様書無しさん
12/04/29 00:44:04.46
>>582
で、何が言いたいの？
584:仕様書無しさん
12/04/29 00:44:39.33
>>583
より分かりやすく書けって話だよ。
585:仕様書無しさん
12/04/29 00:45:43.69
>>580
> 大元のif文はどう見ても一致してるかの判定
もし（否定 比較する(a,b)）
これを「aとbが一致した場合」と解釈するのは難しい。
586:仕様書無しさん
12/04/29 00:47:20.56
もし（ 比較する(a,b) == 差が0なら）
こう書けばわかりやすい。
587:仕様書無しさん
12/04/29 00:49:40.01
>>585
書き方のぜひはともかく文字列一致判定の定型文だろ
588:仕様書無しさん
12/04/29 00:52:37.27
>>586
どんな顔してこんな当たり前の書き込みするのか興味深い
589:仕様書無しさん
12/04/29 00:59:33.34
>>587
こんなのを定型文と言わなきゃいけない事自体がおかしい。
590:仕様書無しさん
12/04/29 01:00:23.87
>>588
え？ 当たり前のことを言ったような顔を
しているだけですが・・・？
591:仕様書無しさん
12/04/29 01:05:32.77
>>578
if文 = if statement
CやC++だと、そもそも式も文も同じ意味なんだが
592:仕様書無しさん
12/04/29 01:10:42.27
C/C++のif文は、値を返さないので式として使えませんよ？
if式っていうのはこういうものです。（Scalaの例）
val msg = if (true) "true dayo" else "false dayo"
593:仕様書無しさん
12/04/29 01:12:18.69
>>591
文と式の違いも知らん奴が
さっきから喚いていたんだなｗ
594:仕様書無しさん
12/04/29 01:37:33.40
日本語として正しいテキストのやり取りでこれだけ揉めてるんだから、
言語としての正しさは、意思疎通の効率化の一要素でしかないってのを
自ら証明してる罠
595:仕様書無しさん
12/04/29 01:37:58.64
>>594
日本語でおｋ？
596:仕様書無しさん
12/04/29 01:40:09.09
>>595
日本語の議論でもこれだけ揉めるのだから、やはりプログラムは奥深くて楽しい。
597:仕様書無しさん
12/04/29 01:40:59.74
What's your point?”
598:仕様書無しさん
12/04/29 01:48:55.76
何か伸びてると思ったら、何の話してんの？
599:仕様書無しさん
12/04/29 03:27:22.81
毎年この時期は色々とアレな人が湧くなあ、というお話。
600:仕様書無しさん
12/04/29 05:25:20.32
↑ここまでイラッとするレススタイルの話
↓ここからイラッとするコーディングスタイルの話
601:仕様書無しさん
12/04/29 05:27:33.91
終了
602:仕様書無しさん
12/04/29 05:30:53.97
>>598
理系のボクにはよくわからないお話。
603:仕様書無しさん
12/04/29 05:32:15.06
>>602
理系とか関係なく
単にあなたがお馬鹿であるだけ。
604:仕様書無しさん
12/04/29 18:30:27.78
三項演算ってのがあってだな・・・
605:仕様書無しさん
12/04/29 18:31:41.69
それで？
606:仕様書無しさん
12/04/30 11:28:44.34
ハンガリアン記法を使うなら使うで統一してればまだいいが、
ハンガリアンな変数名とそうでない変数名が混在しているソースコードはバカだと思う。
607:仕様書無しさん
12/04/30 14:32:32.64
b p m_ g_ だけ付けてる。
608:仕様書無しさん
12/04/30 14:57:12.58
それはハンガリアンではない
609:仕様書無しさん
12/04/30 15:26:03.24
>>606
ハンガリアン記法で統一されていても、記法が実態と合っていないと、
もっとイラｯつとする。不具合修正後にたまに見かけるんだが……。
610:仕様書無しさん
12/05/01 04:35:45.89
システムハンガリアンをコーディング規約に盛り込む連中は漏れなく無能。
611:仕様書無しさん
12/05/01 09:48:20.21
プログラムのお勉強的な意味でどうしてこんな事が必要だったのかを
若手に学習させるためにシステムハンガリアンは割りと良いんだよなｗ
612:仕様書無しさん
12/05/01 13:26:21.50
システムハンガリアン使ってるヤツは、ハンガリアン使うときどうするんだ？
例えば、↓とかどう修飾してる？
ptX; // ポイント単位のX軸
cmX; // センチメートル単位のX軸
dbY; // デシベル単位のY軸
613:仕様書無しさん
12/05/01 13:35:03.26
fPtX
nCmX
dDbY
614:仕様書無しさん
12/05/01 13:42:21.92
イラッとするな
615:仕様書無しさん
12/05/01 14:30:32.62
他人のコーディングスタイルは常にイラッつとするものなんだよ
616:仕様書無しさん
12/05/02 21:39:30.85
なにがハンガリアンだよハムスターかよ！
俺はローマ字で変数を使うからな！
617:仕様書無しさん
12/05/02 22:13:12.04
だったら日本語でかきゃいいのに
最近のコンパイラーは日本語使えるんだぞ
#define 整数 int
#define 無 void
#define 本体 main
#define 戻す return
整数 本体(無)
{
整数 値 = 0;
戻す 値;
}
618:仕様書無しさん
12/05/02 23:35:31.92
ｷﾓｲwww
619:仕様書無しさん
12/05/03 00:05:17.09
そうか？
英語で命名しても認識する時は日本語だからそんなに気にならないけど。
620:仕様書無しさん
12/05/03 03:58:47.27
なでしこ思い出した
621:仕様書無しさん
12/05/03 04:01:24.82
ひまわりでやれ
622:仕様書無しさん
12/05/03 04:29:44.89
>>617
マクロの謝った使用法の中でも最悪だなこれ。
623:仕様書無しさん
12/05/03 05:00:42.74
変数名に$aとか$bとかマジ勘弁
624:仕様書無しさん
12/05/03 05:13:27.17
>>623
VMS「…(´･ω･`)」
625:仕様書無しさん
12/05/03 10:37:35.39
>>623
でも $i は良いんでしょ？
626:仕様書無しさん
12/05/04 13:03:50.07
$iiiまでは許してくれ。
627:仕様書無しさん
12/05/05 04:07:53.59
$とか通るのかよ。アセンブラでおかしくなるだろ？
628:仕様書無しさん
12/05/05 06:16:15.35
phpならきっと・・・
629:仕様書無しさん
12/05/05 19:21:20.26
むしろPHPでは$つけわすれるのがエラーの筆頭だろ
630:仕様書無しさん
12/05/05 23:03:56.89
Perlも？
631:仕様書無しさん
12/05/07 03:22:45.46
Perlは頭に何付けるか考えなきゃいけないから
他の言語を直前までやってたときに新規でソースファイル起こしたときの最初の数分だけかな忘れるのは
632:仕様書無しさん
12/05/07 03:52:46.25
#define ZERO 0
#define ONE 1
#define TWO 2
…
#define ELEVEN 11
驚愕したそして
12以降は普通に使われていた
俺は泣いた
633:仕様書無しさん
12/05/07 07:09:08.37
よくあるコード改善本の指摘に「できるだけマクロを使うな（コンパイラを働かせろ）」というのがあるけれど
実際どれくらいメリットがあるのだろう・・・？
634:仕様書無しさん
12/05/07 19:42:52.59
「マクロを使わない＝コンパイラを働かせる」
の意味がわかんないんで教えて
635:仕様書無しさん
12/05/07 20:36:38.67
Cの本読めば最初の章に出てくるだろ
マクロの部分を処理するのは、コンパイラではなくプリプロセッサ
（気を利かせることができて賢い）コンパイラを使え ＝ （単純で馬鹿な）プリプロセッサを使うな
636:仕様書無しさん
12/05/07 21:30:39.56
てか、マクロを多用するコードの方がコンパイラの仕事が増えるような気が。
637:仕様書無しさん
12/05/07 21:34:21.83
一緒だと思う。
638:仕様書無しさん
12/05/07 22:28:35.51
マクロ展開した後のソースがどんだけデカくなるのか見たことないのかよ！
コンパイラさん凄い頑張ってんぞ！
639:仕様書無しさん
12/05/07 23:53:37.14
>>633
知らない方がいいよ。それを知ったとき、おまえは地獄にいる。
640:仕様書無しさん
12/05/07 23:56:57.94
>>636
ようは、コンパイラをプログラマの道具として使えってことだよ。
コンパイラが分かる形にしておくと、
コンパイルした時にミスを色々教えてくれる。
静的型付け言語ならではの、コンパイラを使った
快適プログラミングテクニックが生かせる。
641:仕様書無しさん
12/05/08 10:40:28.54
プリプロセッサを働かせずにコンパイラを働かせろということだと思うが、
コードの肥大を防ぐのが目的なのかなんなのか
642:仕様書無しさん
12/05/08 10:47:16.38
マクロは基本的に定数定義とか、移植性の向上のために使ってるな。
643:仕様書無しさん
12/05/08 12:20:14.89
マクロ禁止って暗にCをディスってるような気がする。
C++かC#陣営の策略に違いない。
644:仕様書無しさん
12/05/08 16:18:08.66
コメントは40カラム目から
645:仕様書無しさん
12/05/08 17:30:22.51
>>644
うわ、それ強制されたことあるわ
646:仕様書無しさん
12/05/09 07:53:56.36
switchには必ずdefaultをつけるべし
ifには必ずelseをつけるべし
647:仕様書無しさん
12/05/09 08:32:49.88
それ嫌いだわぁ
else書いといて中身無しとか
せめてプログラミング作法くらいは皆読んで欲しいところだ
648:仕様書無しさん
12/05/09 11:01:52.47
switch () {
default:
;
}
これはあり。というか、俺はいつもそうやってる。
defaultの考慮漏れはしていないし、defaultではやることないよという表明。
> ifには必ずelseをつけるべし
これはあまり見たこと無いな。
「if～else if～には必ずelseをつけるべし」なら、見たことあるし、俺も実践してる。
switchのdefaultと同じ理由。
649:仕様書無しさん
12/05/09 11:27:41.36
たまに頭が回らん時とか、if文の条件が書きづらい時とか
if( !(条件) ){ 処理 }
ってしないで
if( 条件 ){}else{ 処理 }
って書くのも他人から見たらイラッつとさせてるんだろうなと思った。
650:仕様書無しさん
12/05/09 21:39:26.50
>>633
1.オーバーロード可能になる
2.using宣言、もしくは名前空間の別名で短い名前が使える
この2点だけでも結構楽になる。
651:仕様書無しさん
12/05/09 23:27:06.14
リポジトリからソースを落とすとThumbs.dbがついて来た。
システムに必要なファイルだろうから消すなだと。
652:仕様書無しさん
12/05/10 22:36:52.26
>>649
何もやることないよ
というより
書き忘れたのかと思ってしまう。
653:仕様書無しさん
12/05/11 00:07:09.59
>>648
> defaultの考慮漏れはしていないし、defaultではやることないよという表明。
オレだったら、それはコメントに記述するなあ
654:仕様書無しさん
12/05/11 00:34:49.93
そういえば以前の上司がどうしても『defaultは最後に書け』と言ってゆずらなかったな。
655:仕様書無しさん
12/05/11 00:56:41.06
デフォルトに出会った時点で分岐終了するウンココンパイラなかったっけ
656:仕様書無しさん
12/05/11 01:16:38.05
名付けて、運コンパイラ
657:仕様書無しさん
12/05/11 14:08:06.49
>>653
defaultが無いとwarning出す静的解析ツールとかありがちなんで、俺はコードで書く。
658:仕様書無しさん
12/05/11 17:24:17.65
>>653
俺はdefaultに assert(false) を入れとくなあ。
ミスの検出にも役立つし。
659:仕様書無しさん
12/05/11 17:28:42.09
そこに
assert(false); // 来ないはず
とか書いてあるソースは見た事ある。
来ないはずの所に来るバグがあるって事なんだろうな、と思った。
660:仕様書無しさん
12/05/11 17:54:19.52
>>658
いや、来ないのでは無くて、来ることもあるが処理は無しよ、って意味なんだけど。
来ないはずならエラー処理入れるわ。
661:仕様書無しさん
12/05/11 21:13:10.20
いいこと考えた
assert(true); // 入れとけばいいんじゃねｗ
662:仕様書無しさん
12/05/12 00:02:23.15
定義増えた場合の取りこぼし対策でASSERTいれるのはアリ
663:仕様書無しさん
12/05/12 04:08:02.61
でふぉるとさんはどんな条件にも引っ掛からなかったダメな子を許容してくれるお姉さんキャラ
たまに「絶対に書いておけ」と言う参考書がある為に
//ここに来る事は無い
と言う書き残しをして居る時があるが
nullやDBNull判定をすり抜けて来た0や空白さんがたまに来る
初期値はシステムで統一しろ
664:仕様書無しさん
12/05/12 04:28:51.61
ifにelseは必要ない。
なぜなら、条件を満たしているか？という質問をするならば
みたいしていない場合が存在するのは明らかだから。
switchに関しては、case一個だけ書くことなんてまずない
Aの場合、Bの場合、Cの場合、じゃあそれ以外はどうなるんだ？
ということになる。
取りうる値がA、B、Cの三つしかないというのであれば、
Aの場合、Bの場合、それ以外(default)。でいいはず。
defaultがないということは、なにか意味があるということなので
それを明記するのが良い。
665:仕様書無しさん
12/05/12 04:31:07.25
>>659
assertionはdefaultだけで使うものではない。
何のためにassertionを使っているかを考えれば分かる。
666:仕様書無しさん
12/05/12 04:52:54.88
>>664
>ifにelseは必要ない。
お前は何を言っているんだ
667:仕様書無しさん
12/05/12 05:50:36.01
bool値を返す関数で
bool func(){
if(exp){
return true;
}else{
return false;
}
}
668:仕様書無しさん
12/05/12 05:52:39.62
途中で書き込んでしまった。。
bool値を返す関数で
bool func(){
if(exp){
return true;
}else{
return false;
}
}
って書いてるのがイラッとする。
669:仕様書無しさん
12/05/12 06:49:59.39
>>666
あれじゃないか○○であるの条件のelseは明示的に書かれていないだけで○○ではないのif文
つまり読みやすいとは別として理解しやすいと言う部分、何がしたいかをはっきりさせたい場合はifを2回書いた方がいい
つまりelseは要らない
670:仕様書無しさん
12/05/12 06:55:40.08
>>669
「それ以外」の条件をいちいち列挙するの？面倒くせえ
671:仕様書無しさん
12/05/12 08:26:14.32
面倒くさいだけじゃ済まないぞ
わざわざ別に書いてる位だから、本当は別の条件があるのに記述漏れがあんじゃねーかって疑念が湧くし、
ifに入る条件がより限定されるような修正する際に、
else使うなら一箇所の修正だけで済むものを、使わない場合はelse相当のif文も修正が必要になる
どう考えてもバグの誘因になる
言語仕様でelseが無いとか、switchのdefaultが無いならともかく、
言語仕様としてあって、更にそれを使うのに適した場面なら、それを使う方が良いと思う
まぁ、全部にelseやdefaultを入れろって縛りはどうかと思うけど
672:仕様書無しさん
12/05/12 09:42:39.16
>>668
どう書けばいいのでしょう・・・
ご教授していただけると嬉しいです
673:仕様書無しさん
12/05/12 10:23:26.26
return (bool)exp;
だろ？
674:仕様書無しさん
12/05/12 10:29:07.54
else書くなって言ってるんだろ
675:仕様書無しさん
12/05/12 13:21:10.78
gotoは基本的に使用しないこと
ただしエラー処理や多重ループから抜ける場合などは使用した方が見やすくなる
・・・ったく、いつまでクヌースの呪縛に捕らわれてんの？
全面禁止だろ、いまどき
676:仕様書無しさん
12/05/12 14:00:43.31
>>675
全面禁止ってことは、
breakもcontinueもreturnもダメってこと？
これらはgotoと同じ事出来るんだけど。
677:仕様書無しさん
12/05/12 14:25:20.15
いや、だからだよ
今の言語はブロック制御に則ったジャンプ命令があるのに
いつまでALGOL時代の「goto」という命令に捕らわれてるんだって意味
678:仕様書無しさん
12/05/12 14:34:49.81
>>675
いつまで構造化プログラミングの呪縛に縛られてるの？
679:仕様書無しさん
12/05/12 15:23:16.21
>>678
アウフヘーベンするならともかく、goto使うところに戻るんじゃただの退化じゃん。
680:仕様書無しさん
12/05/12 15:47:39.09
>>677
それらで出来ないことだって有るだろ。
681:仕様書無しさん
12/05/12 16:08:22.41
>>679
今更gotoがどうとかどっちでもいいじゃん
682:仕様書無しさん
12/05/12 16:55:46.12
>>673
return (exp) ? true : false;
かな
でも、おれ、三項演算子好きじゃない
こまった・・・
683:仕様書無しさん
12/05/12 17:30:18.41
三項演算子を好んで使うやつなんか存在するのか？
684:仕様書無しさん
12/05/12 18:02:26.13
bool func(){
bool result = false
if(exp){
result = true;
}
return result;
}
685:仕様書無しさん
12/05/12 18:08:45.16
return exp;
686:仕様書無しさん
12/05/12 18:13:32.23
>>683
エレキ屋あがりが「オブジェクトファイルを開いてみろ！if-elseと比べてこんなにシンプルだぞ！」と
しきりに勧めてくるのだが・・・・・実際どうなんだろうと思う
687:仕様書無しさん
12/05/12 18:38:40.32
最近カンスト付きの加減算で好んで使ってたりしてる。
無理に使えとは言わないｗ
num = ((num+hoge) > max) ? max : (num+hoge);
688:仕様書無しさん
12/05/12 23:08:11.15
ifが戻り値を返したいって時は
三項演算子使うだろ。
var a;
if(exp1) {
a = 1;
} else if(exp2) {
a = 2;
} else {
a = 3
}
var a = (exp1) ? 1 :
(exp2) ? 2 :
3;
どっちが見やすいかなんて一目瞭然だと思うが？
689:仕様書無しさん
12/05/12 23:15:57.08
>>688
複数の判定がいるならswichかテーブル使ってしまうなぁ
690:仕様書無しさん
12/05/12 23:19:05.66
三項演算子を使って一行で書ける時はよく使う。
>>688はイラッ
691:仕様書無しさん
12/05/12 23:21:21.33
>>689
switchだって戻り値返せないだろ？
var a;
switch(exp) {
case cond1 : a = 1; break;
case cond2 : a = 2; break;
default : a = 3; break;
}
var a = (exp == cond1) ? 1 :
(exp == cond2) ? 2 :
3;
値を返すならこっちのほうがシンプル
692:仕様書無しさん
12/05/12 23:23:03.00
処理を分岐させたいなら
if、switch
条件に応じて値を返したいなら
三項演算子
693:仕様書無しさん
12/05/12 23:42:10.01
一番のネックは三項演算子をやたらに憎む奴らが多い事なんだよな
まあ、ＩＦの変わりに使うひとが大量に居たせいだと恨んでるけとw
694:仕様書無しさん
12/05/13 00:05:26.98
三項演算子くらいラムダ式に比べたらまだまだまだまだ可愛い。
695:仕様書無しさん
12/05/13 00:07:43.98
>>693
関数型言語では三項演算子（風）の記述が主流
三項演算子を嫌うような老害は
このあと消える。
696:仕様書無しさん
12/05/13 00:09:47.61
老害って言葉好きだね。いつまでケツが青いままのつもり？
697:仕様書無しさん
12/05/13 00:14:04.30
>>676
一緒じゃねぇよ全然ちげぇよ。
ダイクストラが提起した問題は、gotoそのものや、ジャンプじゃない。
処理ブロック(forやifといった分岐反復のまとまり)のネストを無視して、
処理ブロックから、処理ブロックに飛べる事が問題なんだ。
なんでgotoがあるのにbreakやcontinueがあるか解ってんのか？
698:仕様書無しさん
12/05/13 00:15:36.69
>>688
3講演子の条件式をカッコでくくってんのがイラっとする
699:仕様書無しさん
12/05/13 00:18:57.46
>>698
カッコがないと見難い
700:仕様書無しさん
12/05/13 00:20:09.10
>>697
ダイクストラが提起した問題は、gotoそのものや、ジャンプじゃない。
処理ブロック(forやifといった分岐反復のまとまり)のネストを無視して、
処理ブロックから、処理ブロックに飛べる事が問題なんだ。
だから、処理ブロックから、処理ブロックに飛ぶようなことをしなければ
gotoを使ってもいい