1 :仕様書無しさん2012/03/10(土) 22:20:29.12
文法的には何ひとつ間違ってはいないし、本人なりに見やすくしようとする意図は汲み取れるのだが、
どうにも気持ち悪くて、「修正してやる!」と叫びながらキーボードを激しく連打したくなる
そういう薄気味悪いコーディングスタイルを発見したら書き込むスレッド
どうにも気持ち悪くて、「修正してやる!」と叫びながらキーボードを激しく連打したくなる
そういう薄気味悪いコーディングスタイルを発見したら書き込むスレッド
16 :仕様書無しさん2012/03/11(日) 16:11:30.97
>>1の条件に該当するヤツは
一行が長くならないようにコメントを適当に改行してるんだけど
単語の途中を改行でぶった切られてのぐらいしか思いつかない
あとはイラッっとするので
> 本人なりに見やすくしようとする意図は汲み取れるのだが
で該当したものはない
一行が長くならないようにコメントを適当に改行してるんだけど
単語の途中を改行でぶった切られてのぐらいしか思いつかない
あとはイラッっとするので
> 本人なりに見やすくしようとする意図は汲み取れるのだが
で該当したものはない
5 :仕様書無しさん2012/03/11(日) 01:07:15.09
スレタイがイラッつとする
98 :仕様書無しさん2012/03/19(月) 13:33:57.93
>>97
あからさまに仕様上あるわけだが>C#のポインタ
そんなことより、スレタイに関しては >>5 で既出なんだが
ホントに直近のレスだけしか見てないんだなあ(´・ω・`)
あからさまに仕様上あるわけだが>C#のポインタ
そんなことより、スレタイに関しては >>5 で既出なんだが
ホントに直近のレスだけしか見てないんだなあ(´・ω・`)
8 :仕様書無しさん2012/03/11(日) 02:43:59.61
String hoge
=
null
;
hoge
=
getSQL(
flg1
flg2
)
;
=
null
;
hoge
=
getSQL(
flg1
flg2
)
;
9 :仕様書無しさん2012/03/11(日) 02:44:47.10
>>8の9行目訂正
flg1,
flg1,
11 :仕様書無しさん2012/03/11(日) 06:31:52.11
コードの書き方にこだわるようじゃ3流だな。
こだわるべきはアルゴリズムだろ。
そこがきちっとしていればコードが短くなる。コードが短くなれば自然と読みやすくなる。
早くその領域に達するといいな。
こだわるべきはアルゴリズムだろ。
そこがきちっとしていればコードが短くなる。コードが短くなれば自然と読みやすくなる。
早くその領域に達するといいな。
13 :仕様書無しさん2012/03/11(日) 09:14:43.77
>>11
既知のパターンで書かれているかも重要
パターンとパターンをつないでいくような作りであると、読みながら何をしたいのかが分かる。
既知のパターンで書かれているかも重要
パターンとパターンをつないでいくような作りであると、読みながら何をしたいのかが分かる。
14 :仕様書無しさん2012/03/11(日) 12:56:09.17
>11
コードを短くするにはアルゴリズムではなく
関数にすることが重要。
どんなに長いコードでもたった一行にできる。
しかもすごく読みやすくなる。
コードを短くするにはアルゴリズムではなく
関数にすることが重要。
どんなに長いコードでもたった一行にできる。
しかもすごく読みやすくなる。
95 :仕様書無しさん2012/03/19(月) 01:56:27.12
>>14
ちゃんと意味のある関数ならいいけどな。
ちゃんと意味のある関数ならいいけどな。
17 :仕様書無しさん2012/03/11(日) 17:29:28.29
古来から言われていることだが、ポインタ変数と普通の変数をいっぺんに宣言するとまぎらわしい。
18 :仕様書無しさん2012/03/11(日) 18:26:18.08
>>17
int* ptr_A, B;
こんな感じ?
int* ptr_A, B;
こんな感じ?
19 :仕様書無しさん2012/03/11(日) 18:34:53.32
K&R流では
int *pa, b;
だね
*(アスタリスク)の前に空白を入れるのか後に入れるのかという違いだけど、
>>18のスタイルの発祥はどこなんだろ?
int *pa, b;
だね
*(アスタリスク)の前に空白を入れるのか後に入れるのかという違いだけど、
>>18のスタイルの発祥はどこなんだろ?
20 :仕様書無しさん2012/03/11(日) 19:02:06.53
>>18
>int* ptr_A, B;
これで両方ポインタになるべきだと
俺は思うのだが
>int* ptr_A, B;
これで両方ポインタになるべきだと
俺は思うのだが
22 :仕様書無しさん2012/03/11(日) 22:13:55.60
>>20
ていう思い違いをしやすいから*は識別名にくっつけろ、という話じゃね?
ていう思い違いをしやすいから*は識別名にくっつけろ、という話じゃね?
96 :仕様書無しさん2012/03/19(月) 01:57:43.43
>>20
C#はなるんじゃなかった?
C#はなるんじゃなかった?
21 :仕様書無しさん2012/03/11(日) 19:45:40.12
クラスのプロトタイプ宣言ファイルにそのクラスが使う複数の構造体の宣言を一緒に入れる
クラスのプロトタイプ宣言のなかにそのクラスが使う構造体の宣言をごっそり入れる
どう思う?
クラスのプロトタイプ宣言のなかにそのクラスが使う構造体の宣言をごっそり入れる
どう思う?
23 :仕様書無しさん2012/03/11(日) 22:39:10.87
いやそうじゃなく文法自体が不適切なんじゃないのかって話
24 :仕様書無しさん2012/03/11(日) 23:25:48.90
>>23
そりゃあ「コンパイラに優しい言語仕様」を目指したわけだし
てかそもそもそういうスレじゃないし
そりゃあ「コンパイラに優しい言語仕様」を目指したわけだし
てかそもそもそういうスレじゃないし
25 :仕様書無しさん2012/03/12(月) 02:04:41.58
if(hoge != null) {
if(hoge.length() > 0) {
// 糞処理
}
}
ネスト深くせずreturnしてほしいわ
if(hoge != null && hoge.lenght() > 0) { return; }
// 糞処理
if(hoge.length() > 0) {
// 糞処理
}
}
ネスト深くせずreturnしてほしいわ
if(hoge != null && hoge.lenght() > 0) { return; }
// 糞処理
26 :仕様書無しさん2012/03/12(月) 02:11:39.25
>>25
バカっ☆
バカっ☆
144 :仕様書無しさん2012/03/21(水) 00:44:15.06
>>25
式の評価順が気になって安全に振ってんだろ
式の評価順が気になって安全に振ってんだろ
27 :仕様書無しさん2012/03/12(月) 02:39:19.67
定数宣言で=の位置を縦に揃えるのがあまり好きじゃない
29 :仕様書無しさん2012/03/12(月) 13:02:39.61
>27
俺は逆に、揃えてないほうが不快。
俺は逆に、揃えてないほうが不快。
32 :仕様書無しさん2012/03/12(月) 15:10:16.44
>>27 and >>29,30
縦揃えにTabを使わないのが問題なんじゃね?
自分はタブ幅4(:se ts=4 sw=4 ai)だけど、全く苦にならない
縦揃えにTabを使わないのが問題なんじゃね?
自分はタブ幅4(:se ts=4 sw=4 ai)だけど、全く苦にならない
36 :仕様書無しさん2012/03/12(月) 21:11:14.76
indentのデフォルトは2じゃね?
43 :仕様書無しさん2012/03/13(火) 09:01:52.99
>>36
インデントは2でも4でも8でもいいけど、タブのサイズを4とかにしてタブでインデントしてるヤツは
イラっとするわ。
インデントは2でも4でも8でもいいけど、タブのサイズを4とかにしてタブでインデントしてるヤツは
イラっとするわ。
47 :仕様書無しさん2012/03/13(火) 22:54:43.60
>>43
MS「(;゚Д゚)エッ…」
MS「(;゚Д゚)エッ…」
48 :仕様書無しさん2012/03/13(火) 23:50:12.33
>>43
なんで?
なんで?
49 :仕様書無しさん2012/03/13(火) 23:52:59.28
>>43
なんで?
なんで?
50 :仕様書無しさん2012/03/13(火) 23:57:17.22
>>43はRuby使いなんじゃね?
Rubyには標準ライブラリを含めてインデント2で書かれたコードが多い
Rubyには標準ライブラリを含めてインデント2で書かれたコードが多い
52 :仕様書無しさん2012/03/14(水) 00:35:03.78
>>43
チカンすればいいじゃん
チカンすればいいじゃん
53 :仕様書無しさん2012/03/14(水) 02:52:09.84
>>52
おまわりさんこっちです
おまわりさんこっちです
55 :仕様書無しさん2012/03/14(水) 13:02:41.26
>>47-49
タブサイズは8に決まってるだろ。
タブサイズを8以外にしてるやつは迷惑だわ。
インデントを8以外にしたいときにはスペース使え。
>>52
どっちにしても面倒だし、チカンするくらいならエディタの設定を変えたほうが速いだろ。
タブサイズは8に決まってるだろ。
タブサイズを8以外にしてるやつは迷惑だわ。
インデントを8以外にしたいときにはスペース使え。
>>52
どっちにしても面倒だし、チカンするくらいならエディタの設定を変えたほうが速いだろ。
37 :仕様書無しさん2012/03/12(月) 21:35:49.34
=の位置で簡単に揃えられない
エディタを使う奴が無能なだけ。
エディタを使う奴が無能なだけ。
38 :仕様書無しさん2012/03/12(月) 21:38:11.18
そもそも変数名の長さがまちまちなところに問題の根本が潜んでいる気がする
39 :仕様書無しさん2012/03/12(月) 21:53:50.70
だからコボラーはCOL001,COL002,COL003…みたいな変数にしてたんだろ
42 :仕様書無しさん2012/03/13(火) 07:26:43.39
>>39
変数の長さを規約で決めてしまうのか
ソースを見やすくするっていう規約の存在意義を考えるとアリだな
変数の長さを規約で決めてしまうのか
ソースを見やすくするっていう規約の存在意義を考えるとアリだな
40 :仕様書無しさん2012/03/13(火) 00:48:50.68
エディタ表示部が勝手に検知して勝手に揃えて表示するというのはありなような気はする
画面表示がディスク上のファイルのバイナリ列と完全に一致しなければならないわけじゃないしな
画面表示がディスク上のファイルのバイナリ列と完全に一致しなければならないわけじゃないしな
44 :仕様書無しさん2012/03/13(火) 13:39:53.08
>41
それは//のほうが正しいだろ。
/*〜*/で普段のコメントが書いてあると、一部の処理を殺して試したいときに、普段のコメントがそれを邪魔する。
関数の中身に書くコメントは//じゃないと邪魔だ。
JavaDoc形式については別だぞ。
それは//のほうが正しいだろ。
/*〜*/で普段のコメントが書いてあると、一部の処理を殺して試したいときに、普段のコメントがそれを邪魔する。
関数の中身に書くコメントは//じゃないと邪魔だ。
JavaDoc形式については別だぞ。
45 :仕様書無しさん2012/03/13(火) 19:40:55.20
for(i = 0; i < max; i++); ←※
{
// 云々
}
こーゆーミスするなら中括弧の前に改行入れんじゃねえよハゲ
{
// 云々
}
こーゆーミスするなら中括弧の前に改行入れんじゃねえよハゲ
51 :仕様書無しさん2012/03/14(水) 00:10:57.34
インデント2は明らかに少なすぎ。
デザイン的に空間が分かれてるように見えない。
デザイン的に空間が分かれてるように見えない。
54 :仕様書無しさん2012/03/14(水) 07:34:18.44
生ポインタとusingを禁止で全て書き直せとのお達し
配列長が必要なので、shared_arrayは使えない
vector<Hoge*>* hoge;
↓
boost::shared_ptr<std::vector<boost::shared_ptr<Hoge>>> hoge;
マジキチ
下手すりゃdelete漏れを探すよりもカオスなことになりそうだぜ
配列長が必要なので、shared_arrayは使えない
vector<Hoge*>* hoge;
↓
boost::shared_ptr<std::vector<boost::shared_ptr<Hoge>>> hoge;
マジキチ
下手すりゃdelete漏れを探すよりもカオスなことになりそうだぜ
145 :仕様書無しさん2012/03/21(水) 01:18:59.93
>>54
これって、typedefつかっちゃダメなのか?
これって、typedefつかっちゃダメなのか?
170 :仕様書無しさん2012/03/22(木) 08:33:09.39
>>54
thisポインタ使われてたら終わるなw
thisポインタ使われてたら終わるなw
56 :仕様書無しさん2012/03/14(水) 16:12:41.42
インデントはタブサイズの設定関係ないだろ
インデント以外のレイアウトにタブ使うヤツがクソ野郎
インデント以外のレイアウトにタブ使うヤツがクソ野郎
60 :仕様書無しさん2012/03/14(水) 19:30:13.99
>>56
関係あるだろ。
タブサイズ4前提でインデントしてて、8に設定してあるエディタで見ると崩れるやつとかいる。
関係あるだろ。
タブサイズ4前提でインデントしてて、8に設定してあるエディタで見ると崩れるやつとかいる。
65 :仕様書無しさん2012/03/14(水) 23:14:52.71
>>60
すまん、インデントの意味を間違えてた
段落を意図したインデントのみタブを使えって言いたかった
こういうこと言いたかったんです
ttp://ameblo.jp/argv/entry-10000648280.html
すまん、インデントの意味を間違えてた
段落を意図したインデントのみタブを使えって言いたかった
こういうこと言いたかったんです
ttp://ameblo.jp/argv/entry-10000648280.html
66 :仕様書無しさん2012/03/15(木) 01:23:10.20
>>65
正しい日本語使おうな。
たしかに、タブとスペース混ぜられたり、後ろに不要な空白残したりされると殴りたくなる。
てめーのことだぜ先輩!
正しい日本語使おうな。
たしかに、タブとスペース混ぜられたり、後ろに不要な空白残したりされると殴りたくなる。
てめーのことだぜ先輩!
59 :仕様書無しさん2012/03/14(水) 17:57:48.38
コーディングルール・コーディングスタイル議論は山のようにあって正直ウンザリなので、
このスレでは「イラッつとする」かどうかのみで判断した感情的なレスをお願いします
このスレでは「イラッつとする」かどうかのみで判断した感情的なレスをお願いします
61 :仕様書無しさん2012/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)
でいいじゃないか。
なんか意味あるのか。
function hoge($arg1, $arg2, $arg3)
{
$weight = arg1;
$height = arg2;
$age = arg3;
}
と必ず$arg1, $arg2…みたいな意味の無い名前の変数でうけて、関数の中で意味のある
名前の変数に移してるんだけど、
普通に
function hoge($weight, $height, $age)
でいいじゃないか。
なんか意味あるのか。
64 :仕様書無しさん2012/03/14(水) 20:42:50.52
>>61
Perl厨のせいなんじゃね?
Perlには仮引数がないから
sub hoge {
$weight = shift;
$height = shift;
$age = shift;
}
ってやるよ。
Perl厨のせいなんじゃね?
Perlには仮引数がないから
sub hoge {
$weight = shift;
$height = shift;
$age = shift;
}
ってやるよ。
62 :仕様書無しさん2012/03/14(水) 19:47:25.12
コードを追うと突如現る謎の空白行
ふと右を見ると変数の頭文字らしきものがニョキっと生えてる
タブ8とか3階層ネストするだけで宇宙に行ってまうわ
気持ち悪いったらありゃしない
ふと右を見ると変数の頭文字らしきものがニョキっと生えてる
タブ8とか3階層ネストするだけで宇宙に行ってまうわ
気持ち悪いったらありゃしない
67 :仕様書無しさん2012/03/15(木) 02:07:12.65
いえ、わたくしは、イライラしながらフォーマッタでポチポチ揃えてる側の人間ですが。
68 :仕様書無しさん2012/03/15(木) 09:47:40.20
昔はタブサイズは8にするべきだって思ってたんだけどね
今は1か2がちょうどよく思えてきたよ
今は1か2がちょうどよく思えてきたよ
69 :仕様書無しさん2012/03/15(木) 10:36:11.89
タブのサイズを1に設定してタブを使うなら、ふつーにスペース使ったほうがよくね?
70 :仕様書無しさん2012/03/15(木) 11:36:52.65
bool hoge(){
if( fuga() != false ){ return false; }
else{ return true; }
}
なぜreturn !fuga();としないのだ……。
if( fuga() != false ){ return false; }
else{ return true; }
}
なぜreturn !fuga();としないのだ……。
72 :仕様書無しさん2012/03/15(木) 12:26:17.66
>>70
A:論理値をリテラルと比較するような阿呆だから
A:論理値をリテラルと比較するような阿呆だから
71 :仕様書無しさん2012/03/15(木) 12:14:05.59
/* 2011.3.11 なんかエラーになるのでとりあえず外す
return false;
*/
}
return true;
return false;
*/
}
return true;
73 :仕様書無しさん2012/03/15(木) 13:45:30.08
>>71
3.11・・・
3.11・・・
74 :仕様書無しさん2012/03/15(木) 14:00:09.04
>>73
rev.666 2011-03-11 15:47
ほぼ100%職場おわるので中間コミット
SyntaxError出るけどこれ以上はやばいのでかんべんしてください
去年下請けと組んでやった案件の作業ログにこんなのあったの思い出したわ
rev.666 2011-03-11 15:47
ほぼ100%職場おわるので中間コミット
SyntaxError出るけどこれ以上はやばいのでかんべんしてください
去年下請けと組んでやった案件の作業ログにこんなのあったの思い出したわ
75 :仕様書無しさん2012/03/15(木) 14:05:41.36
修正したり追加した行に日付と名前が書いてあるのは
お前の名前分かっても意味無いんじゃ、って思うな。
お前の名前分かっても意味無いんじゃ、って思うな。
76 :仕様書無しさん2012/03/15(木) 18:26:58.01
日付は何故そう修正したか雰囲気がわかったりするから無いよりはマシ
それよりはまともなコメントを書けよハゲって話なんだが
担当者を入れるのは責任問題の押し付け合いをするためのものと理解している
それよりはまともなコメントを書けよハゲって話なんだが
担当者を入れるのは責任問題の押し付け合いをするためのものと理解している
77 :仕様書無しさん2012/03/15(木) 19:03:15.35
日付と名前は必須だろ
どこにバグがあるか特定する時に一番役に立つ
どこにバグがあるか特定する時に一番役に立つ
78 :仕様書無しさん2012/03/15(木) 20:25:45.12
修正履歴なんて入れてないでソース管理ツール使えよって感じだけど、ドカタの現場だとただのファイル共有ツールって認識だし使っても同じか。
79 :仕様書無しさん2012/03/15(木) 21:04:29.64
わざわざソース管理ツールをインストールするの面倒じゃん
おまえらすぐ管理ツールを変更しちゃうから古いソースを見る時に大変なんだよ
おまえらすぐ管理ツールを変更しちゃうから古いソースを見る時に大変なんだよ
80 :仕様書無しさん2012/03/15(木) 21:12:59.59
やっぱり新しいツールや技術についていけない無能に合わせるしかないよな
81 :仕様書無しさん2012/03/15(木) 21:13:26.95
名前がファミリーネームどころかファーストネームですらなく、
親しい間でなければ使わないような愛称
鼻穴に5センチほど割り箸突っ込んでグググと水平に近づけて
後遺症が残らない程度に苦痛を与えることで反省を促したい
親しい間でなければ使わないような愛称
鼻穴に5センチほど割り箸突っ込んでグググと水平に近づけて
後遺症が残らない程度に苦痛を与えることで反省を促したい
84 :仕様書無しさん2012/03/16(金) 11:17:23.41
返却値の柔軟性を奪っておいた方が後々不具合が少ない気はしないでもない。
85 :仕様書無しさん2012/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 */
こんなのを見ると腹立つ
消すなって言われると帰りたくなる
/*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 :仕様書無しさん2012/03/16(金) 20:10:41.24
>>85
え?なんで修正した箇所のソースが残ってないの?
普通はコメントアウトして残すだろ?
コメントアウトした部分を削除する時は日付も削除するし
そんな状態にはならない
え?なんで修正した箇所のソースが残ってないの?
普通はコメントアウトして残すだろ?
コメントアウトした部分を削除する時は日付も削除するし
そんな状態にはならない
87 :仕様書無しさん2012/03/16(金) 20:15:05.66
>>86
>普通はコメントアウトして残すだろ?
普通は…な…。
>普通はコメントアウトして残すだろ?
普通は…な…。
91 :仕様書無しさん2012/03/17(土) 07:04:29.13
全体の設計があきらかにアレなコードで
いちいち修正をコメントで残されてもなー
いちいち修正をコメントで残されてもなー
92 :仕様書無しさん2012/03/17(土) 10:36:26.07
ありきたりだけど、コメントが疑問系のやつ
一回それに対する回答コメントがあってワラタ
一回それに対する回答コメントがあってワラタ
93 :仕様書無しさん2012/03/18(日) 07:15:33.32
LINQの使い方を知って以来、foreachまみれのソースは基本的にイラつく
94 :仕様書無しさん2012/03/18(日) 19:33:17.18
foreach?gotoでループを表現しているコードをいじらされるよりだいぶマシだな
97 :仕様書無しさん2012/03/19(月) 11:49:33.84
C#にはポインタはありません(すくなくとも表面的には)
それよりもここのタイトルの「イラッつと」って書き方にいらっと来た。
それよりもここのタイトルの「イラッつと」って書き方にいらっと来た。
100 :仕様書無しさん2012/03/19(月) 15:44:51.04
スレタイの「イラッつと」は「イラッと」の間違い?
なんかいらっと来た
なんかいらっと来た
101 :仕様書無しさん2012/03/19(月) 18:12:57.12
if (0 == hoge)
102 :仕様書無しさん2012/03/19(月) 19:25:54.13 BE:1248768735-2BP(0)
>>101
これはわからなくはないが見にくい
これはわからなくはないが見にくい
103 :仕様書無しさん2012/03/19(月) 20:01:41.88
>>101
if (0 < hoge && hoge < fuga)
これは許してちょんまげ
if (0 < hoge && hoge < fuga)
これは許してちょんまげ
104 :仕様書無しさん2012/03/19(月) 20:29:56.00
>>103
それは普通
それは普通
115 :仕様書無しさん2012/03/20(火) 11:01:41.79
>>101
これをコーディング規約にするのは
「ウチのプロジェクトには、代入と比較を間違える間抜けがいます」
つってるようなもんだよなあ。
これをコーディング規約にするのは
「ウチのプロジェクトには、代入と比較を間違える間抜けがいます」
つってるようなもんだよなあ。
119 :仕様書無しさん2012/03/20(火) 13:06:39.30
>>115は根性と精神力でプログラミングするんだろうなあ
お近づきにはなりたくない
お近づきにはなりたくない
120 :仕様書無しさん2012/03/20(火) 13:40:45.28
まぁ普通は静的解析ツール使ってチェックするよなぁ。
>>101 みたいなプログラマの注意力に依存したスタイルは今どき流行らないよ。
>>101 みたいなプログラマの注意力に依存したスタイルは今どき流行らないよ。
121 :仕様書無しさん2012/03/20(火) 13:54:35.84
>>101
頭の中で0がhogeだったらって考えちゃうけど、こう書いたときにどう考えてるんだろ
頭の中で0がhogeだったらって考えちゃうけど、こう書いたときにどう考えてるんだろ
124 :仕様書無しさん2012/03/20(火) 14:19:18.43
>>119
なんで根性と精神力があると間違えないと思うの?
バカなの?
なんで根性と精神力があると間違えないと思うの?
バカなの?
128 :仕様書無しさん2012/03/20(火) 16:13:54.00
>>103
むしろそうしないコードにイラッつとするわ
むしろそうしないコードにイラッつとするわ
129 :仕様書無しさん2012/03/20(火) 16:14:36.45
>>124
こんなもん静的解析ツールが見つけ出してくれるだろ
こんなもん静的解析ツールが見つけ出してくれるだろ
105 :仕様書無しさん2012/03/19(月) 20:57:03.45
もしかして、"<" は良くて ">"
は使わないの?
は使わないの?
107 :仕様書無しさん2012/03/19(月) 21:59:50.74
void hoge()
{
if(this.expr) return;
hogehoge();
fugafuga();
...
}
俺も7年前までこう書いていたんだが、
今ではイラッとまで来ないが、なんかもやっとする。
入口一つに出口一つ、例外的に途中抜けするから例外、
と考えているんだが、そういう考えは少数派なのだろうか
{
if(this.expr) return;
hogehoge();
fugafuga();
...
}
俺も7年前までこう書いていたんだが、
今ではイラッとまで来ないが、なんかもやっとする。
入口一つに出口一つ、例外的に途中抜けするから例外、
と考えているんだが、そういう考えは少数派なのだろうか
108 :仕様書無しさん2012/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文も全面的に禁止するのではなく、
必要に応じて使い分ける(=必要な場合に限って使う)ことを考えればいいのではないかと
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文も全面的に禁止するのではなく、
必要に応じて使い分ける(=必要な場合に限って使う)ことを考えればいいのではないかと
110 :仕様書無しさん2012/03/19(月) 23:21:53.63
>>107
> 入口一つに出口一つ
これを守るためにフラグ変数導入したり、do〜while(0)使ったりするコードは
イラッとする。
> 入口一つに出口一つ
これを守るためにフラグ変数導入したり、do〜while(0)使ったりするコードは
イラッとする。
111 :仕様書無しさん2012/03/20(火) 00:23:49.93
>>110
>これを守るためにフラグ変数導入したり、do〜while(0)使ったりするコードは
>イラッとする。
御意
>これを守るためにフラグ変数導入したり、do〜while(0)使ったりするコードは
>イラッとする。
御意
113 :仕様書無しさん2012/03/20(火) 03:16:51.32
>>107
出口一つにしたければ、
void hoge()
{
if(this.expr) goto EXIT;
hogehoge();
fugafuga();
...
EXIT:
}
こう書けばいいよw
つか、returnなんてこの書き方の短縮形でしか
ないんだから出口を一つにする意味はない。
出口一つにしたければ、
void hoge()
{
if(this.expr) goto EXIT;
hogehoge();
fugafuga();
...
EXIT:
}
こう書けばいいよw
つか、returnなんてこの書き方の短縮形でしか
ないんだから出口を一つにする意味はない。
122 :仕様書無しさん2012/03/20(火) 13:54:57.90
>>113
その手の奴で、それぞれ脱出する箇所によって終了処理が異なるから
EXIT1: EXIT2: …と、returnの前に4つくらいラベルが書かれたソースを
見たことがあるな。
ネストが深くなるのがそんなに嫌なのか。
その手の奴で、それぞれ脱出する箇所によって終了処理が異なるから
EXIT1: EXIT2: …と、returnの前に4つくらいラベルが書かれたソースを
見たことがあるな。
ネストが深くなるのがそんなに嫌なのか。
109 :1082012/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
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
114 :仕様書無しさん2012/03/20(火) 07:23:02.48
場合わけが多岐にわたり、なおかつ「通常」の抜け方が唯一の関数だと
末尾に「通常」のreturn、そこまでのあちこちにif文と抱き合わせで複数のreturn
というのは必然
末尾に「通常」のreturn、そこまでのあちこちにif文と抱き合わせで複数のreturn
というのは必然
116 :仕様書無しさん2012/03/20(火) 12:20:25.49
代入と比較を 書き 間違える人なら
全員当てはまると思いますが?
全員当てはまると思いますが?
117 :仕様書無しさん2012/03/20(火) 12:35:19.18
たしかVisualBasicだと比較も = 1個だけだったと思う
BASIC系全部そうかな
BASIC系全部そうかな
118 :仕様書無しさん2012/03/20(火) 12:43:43.70
BASICは、ifで代入できるなんて
あほらしい仕様がないからね。
あほらしい仕様がないからね。
125 :仕様書無しさん2012/03/20(火) 15:25:25.39
if (sysfn(...) < 0) {エラー処理} //sysfn()は、エラー時に"-1"を返す関数
なぜすなおに-1を使わない?
なぜすなおに-1を使わない?
127 :仕様書無しさん2012/03/20(火) 15:40:00.90
>>125
負の整数をエラーコードとしている場合、新たなエラーコードが追加されたときにもエラー処理を実行させるため
負の整数をエラーコードとしている場合、新たなエラーコードが追加されたときにもエラー処理を実行させるため
130 :仕様書無しさん2012/03/20(火) 17:55:49.64
>>127
sysfn()は、「失敗時に-1」と定義されたシステムコールです
sysfn()は、「失敗時に-1」と定義されたシステムコールです
139 :仕様書無しさん2012/03/20(火) 21:40:17.74
>>125
成功時に0以上の値を返す関数だから。
成功時に0以上の値を返す関数だから。
126 :仕様書無しさん2012/03/20(火) 15:30:15.28
ネットで似たような処理を探してきて、意味もわからず貼り付けて、
「出来ました」
とかいうスタイル。 技術者なめとんのか
「出来ました」
とかいうスタイル。 技術者なめとんのか
133 :仕様書無しさん2012/03/20(火) 19:44:21.26
「失敗Aが-1だけど失敗Bは3を返す」
という構造になる確率よりも
「失敗Aが-1なので失敗Bは-2を返す」
という構造になる確率のほうがたぶん高い
とにかく失敗ならヒットしたいという場合、とりあえず負かどうかチェックするのはいちおうはアリだ
「失敗なんだけど、既存のエラー処理では処理しきれない新失敗」という可能性もあるんだけど、
それはたぶんエラーコードがなにになっても結局うまく動かないだろうからどうでもいい
という構造になる確率よりも
「失敗Aが-1なので失敗Bは-2を返す」
という構造になる確率のほうがたぶん高い
とにかく失敗ならヒットしたいという場合、とりあえず負かどうかチェックするのはいちおうはアリだ
「失敗なんだけど、既存のエラー処理では処理しきれない新失敗」という可能性もあるんだけど、
それはたぶんエラーコードがなにになっても結局うまく動かないだろうからどうでもいい
134 :仕様書無しさん2012/03/20(火) 19:47:28.02
>130
それならsysfn()のヘッダに
#define SYSFN_ERROR -1
って書かれてるだろうから俺はそれを使う。
書いてなければsysfn()を作った奴が無能。
それならsysfn()のヘッダに
#define SYSFN_ERROR -1
って書かれてるだろうから俺はそれを使う。
書いてなければsysfn()を作った奴が無能。
136 :仕様書無しさん2012/03/20(火) 20:25:09.56
int mCode = 0; // 変数mCodeの宣言
そんなの見りゃ分かる。
mCodeが何の変数かを書いてほしかった。
そんなの見りゃ分かる。
mCodeが何の変数かを書いてほしかった。
137 :仕様書無しさん2012/03/20(火) 20:55:44.58
>>136
もう一歩踏み込んで変数名だけでわかるようにしないと
もう一歩踏み込んで変数名だけでわかるようにしないと
138 :仕様書無しさん2012/03/20(火) 21:34:41.41
日本語で書かないとわけがわからなくなる値の入る変数名というのは結構あったりする
142 :仕様書無しさん2012/03/20(火) 23:54:41.16
CのベテランがJavaにきても成功/失敗を、0/-1で返してたな。
関数名も chkHoge() みたいな感じだし。
イラっとするっていうか懐かしい感じがした。
関数名も chkHoge() みたいな感じだし。
イラっとするっていうか懐かしい感じがした。
146 :仕様書無しさん2012/03/21(水) 03:45:59.92
ループの全てをdoループで処理したらイラッとするって言われた。
forとかwhileとか使えって(´・ω・`)
ループ前に変数初期化、ループの最初と最後にifで必要に応じてbreak。
ループカウンタ進めるタイミングとか、ループ抜ける条件を一覧(風)に並べられたりとか、見やすいと思うんだけどな。
イラッとするもの?
forとかwhileとか使えって(´・ω・`)
ループ前に変数初期化、ループの最初と最後にifで必要に応じてbreak。
ループカウンタ進めるタイミングとか、ループ抜ける条件を一覧(風)に並べられたりとか、見やすいと思うんだけどな。
イラッとするもの?
151 :仕様書無しさん2012/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ってのがよくわからんが。
もしそうなら今までで1、2を争うイラッつとレベル
> ループの全てをdoループで処理したらイラッとするって言われた。
イメージが沸き辛いんだけど、
for (int i = 0; i < N; ++i) { /* something */ }
を
int i = 0;
do {
if (i >= N) break;
/* something */
i++;
} while (true);
みたいに書いてるのか?
ループの最後にifってのがよくわからんが。
もしそうなら今までで1、2を争うイラッつとレベル
152 :仕様書無しさん2012/03/21(水) 13:22:32.98
>>146
イラッつとするって言うか、死ねって思う。
do whileだと終了判定とカウンタの処理の2か所でバグ仕込む可能性が上がって
解析する場合に余計なコストがかかる。
ただのfor文だと分かった場合であっても、それ以前と仕様が変わって
そうせざるを得なかった場合まで考えるから鬱陶しい。
イラッつとするって言うか、死ねって思う。
do whileだと終了判定とカウンタの処理の2か所でバグ仕込む可能性が上がって
解析する場合に余計なコストがかかる。
ただのfor文だと分かった場合であっても、それ以前と仕様が変わって
そうせざるを得なかった場合まで考えるから鬱陶しい。
153 :仕様書無しさん2012/03/21(水) 17:20:34.42
>>146
俺なら全部書きなおさせる。
俺なら全部書きなおさせる。
154 :仕様書無しさん2012/03/21(水) 18:13:00.78
>>146
命令の数が増えたら読みにくいじゃん
ループはforで統一するのがいいんだよ
命令の数が増えたら読みにくいじゃん
ループはforで統一するのがいいんだよ
155 :仕様書無しさん2012/03/21(水) 18:28:43.38
>>154
えっ?そんな理由でforに統一してるの?
絶対一緒に仕事したくないなぁ〜
えっ?そんな理由でforに統一してるの?
絶対一緒に仕事したくないなぁ〜
160 :仕様書無しさん2012/03/21(水) 23:01:01.13
>>154
for統一ってのは無いな
for統一ってのは無いな
147 :仕様書無しさん2012/03/21(水) 06:16:44.32
たかがループで
> ループ前に変数初期化、ループの最初と最後にifで必要に応じてbreak。
> ループカウンタ進めるタイミングとか、ループ抜ける条件を一覧(風)に並べられたり
こんなことやらないといけないのは、何かおかしいと直感的に感じる。
条件などをきちんと整理すれば普通の forとか whileになるんじゃないか?
> ループ前に変数初期化、ループの最初と最後にifで必要に応じてbreak。
> ループカウンタ進めるタイミングとか、ループ抜ける条件を一覧(風)に並べられたり
こんなことやらないといけないのは、何かおかしいと直感的に感じる。
条件などをきちんと整理すれば普通の forとか whileになるんじゃないか?
148 :仕様書無しさん2012/03/21(水) 06:28:26.77
いちいちインクリメンタに意味のある名前をあたえているせいで
forの宣言行が長くなっていると予想
forの宣言行が長くなっていると予想
150 :仕様書無しさん2012/03/21(水) 09:41:20.56
C++やC99 or laterなら問題になるがC89までなら問題ない
それより関数定義のほうを見たらびっくりするだろ
それより関数定義のほうを見たらびっくりするだろ
159 :仕様書無しさん2012/03/21(水) 22:59:55.17
俺はwhile統一派
変数初期化やインクリメントは単独の式でやったほうがいい
変数初期化やインクリメントは単独の式でやったほうがいい
161 :仕様書無しさん2012/03/21(水) 23:01:23.71
>>159
処理系によって遅くなるぞ
処理系によって遅くなるぞ
162 :仕様書無しさん2012/03/21(水) 23:05:05.67
forとwhileの統一なんかは別にどーでもいいが
do whileで統一はまじでやめほしい
do whileで統一はまじでやめほしい
164 :仕様書無しさん2012/03/21(水) 23:24:25.39
>161
forとwhileの違いごときで体感レベルで遅くなるような処理系って現存するのか……?
forとwhileの違いごときで体感レベルで遅くなるような処理系って現存するのか……?
168 :仕様書無しさん2012/03/22(木) 01:38:23.47
>>164
現存するかは知らんけど、数年前のC++ Builderに付いてたコンパイラは
forで加減算してる場合しかループ展開しなかった
現存するかは知らんけど、数年前のC++ Builderに付いてたコンパイラは
forで加減算してる場合しかループ展開しなかった
167 :仕様書無しさん2012/03/22(木) 00:27:49.79
for(;;)は条件式の省略が認められてるが、while(true)は定数のboolで条件式を代用してる
169 :仕様書無しさん2012/03/22(木) 06:24:32.18
gotoが使える言語で
1回だけしか実行しないループとbreakで疑似goto
多重ループを抜ける為の大量に設置された判定文
gotoは使わないでね☆ミみたいなのにとらわれすぎだと思った
コメントにしっかり書くならいいと思うんだけどなぁ
1回だけしか実行しないループとbreakで疑似goto
多重ループを抜ける為の大量に設置された判定文
gotoは使わないでね☆ミみたいなのにとらわれすぎだと思った
コメントにしっかり書くならいいと思うんだけどなぁ
171 :仕様書無しさん2012/03/22(木) 09:38:41.47
>>169
複数回のメンテを受けた後がGOTOの本領発揮
共同作業でGOTO使うなっていうのは鉄の掟
あがっている例ではその部分を関数化すれば解決するんじゃないだろうか
returnによるgotoも賛否がわかれる所ではあるけれど
複数回のメンテを受けた後がGOTOの本領発揮
共同作業でGOTO使うなっていうのは鉄の掟
あがっている例ではその部分を関数化すれば解決するんじゃないだろうか
returnによるgotoも賛否がわかれる所ではあるけれど
172 :仕様書無しさん2012/03/22(木) 09:56:37.14
>breakで疑似goto
別モンだろw
別モンだろw
173 :仕様書無しさん2012/03/22(木) 10:58:08.82
>>172
上から下に流れるだけのgotoと言うかなんと言うか
どっちかと言うと1回のループでなんでこんなもんが…と混乱した後に
「ただbreakで飛びたいだけでしたーwww」ってのがな…
上から下に流れるだけのgotoと言うかなんと言うか
どっちかと言うと1回のループでなんでこんなもんが…と混乱した後に
「ただbreakで飛びたいだけでしたーwww」ってのがな…
175 :仕様書無しさん2012/03/22(木) 13:13:43.25
goto使うなというのは、あなたのために言っているのではない
あなたの次の次の次の人くらいのために言っている
あなたの次の次の次の人くらいのために言っている
179 :仕様書無しさん2012/03/22(木) 13:51:40.67
>>175
コメントはしっかり書くと言t
俺のコメントが…消えた…?
関数にするほどの処理じゃないor関係性があった処理で戻り値無しの関数終了をイメージした何かだったんだろう
調査だったからそれで動いてたし触らないが吉としてスルーした
コメントはしっかり書くと言t
俺のコメントが…消えた…?
関数にするほどの処理じゃないor関係性があった処理で戻り値無しの関数終了をイメージした何かだったんだろう
調査だったからそれで動いてたし触らないが吉としてスルーした
176 :仕様書無しさん2012/03/22(木) 13:23:26.07
> 1回だけしか実行しないループとbreakで疑似goto
なんで if 使わないの?
なんで if 使わないの?
178 :仕様書無しさん2012/03/22(木) 13:40:20.34
エラー時に関数抜ける場合とかの解放忘れ防止に goto もありかな、と思う事はある。
180 :仕様書無しさん2012/03/22(木) 13:56:27.17
>>178
解放なんて例外でキャッチしてやればいいじゃん
というかそれ以外の方法だとどうやっても抜ける可能性でるだろ
解放なんて例外でキャッチしてやればいいじゃん
というかそれ以外の方法だとどうやっても抜ける可能性でるだろ
182 :仕様書無しさん2012/03/22(木) 14:55:17.06
>>180
Exception Safetyって知ってる?
知らずにレスしてるならもっと勉強しろ。
知ってるなら、そう簡単な話ではないことくらいわかるだろ。
Exception Safetyって知ってる?
知らずにレスしてるならもっと勉強しろ。
知ってるなら、そう簡単な話ではないことくらいわかるだろ。
183 :仕様書無しさん2012/03/22(木) 17:38:53.68
gotoが「絶対ダメ」なのなら、例外だって「かなりダメ」だろう
どっちにしても大域脱出なのは変わりがないのだから、極めて慎重に設計されて極めて慎重に使用されるべき
「gotoはダメだけど例外ならいいよ」なんてことはあって欲しくない
あって欲しくないってことは実際にはあるってことなんだが
どっちにしても大域脱出なのは変わりがないのだから、極めて慎重に設計されて極めて慎重に使用されるべき
「gotoはダメだけど例外ならいいよ」なんてことはあって欲しくない
あって欲しくないってことは実際にはあるってことなんだが
184 :仕様書無しさん2012/03/22(木) 17:56:13.71
>>183
君、何の言語ができるの?
君、何の言語ができるの?
185 :仕様書無しさん2012/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:
}
try-catchが無い場合の例外処理に限られるわな。
goto禁止ってのはそもそも、gotoが悪いんじゃなくて
処理ブロックの中を行き来するのが悪いって話だからなぁ。
ダイクストラ本人はgotoがダメとは言ってないし。
あと、breakは本来の意味では問題あるgotoになり得ない。
if( x )
{
goto label1;
label2:
goto label3
}
while( n )
{
label1:
goto label2
label3:
}
186 :仕様書無しさん2012/03/23(金) 23:51:50.59
カッコの内側にスペース入れてるのとカンマの後ろにスペース入れてないのがイラっとするわ。
187 :仕様書無しさん2012/03/24(土) 07:42:22.62
これか
foo( aaa,bbb,ccc )
なんか、AKBにそういう顔をしたメンバーが居るそうだな
( ∵ )
foo( aaa,bbb,ccc )
なんか、AKBにそういう顔をしたメンバーが居るそうだな
( ∵ )
190 :仕様書無しさん2012/03/25(日) 22:03:08.33
a = a + 1;
191 :仕様書無しさん2012/03/26(月) 11:06:32.52
>>190
Luaとかはそう書かないとダメだと思った
Luaとかはそう書かないとダメだと思った
192 :仕様書無しさん2012/03/26(月) 20:21:29.78
>>190
宣言型言語に慣れるとイラッとするのかもしれない
【関数型言語(Haskell)】
a' = a + 1
【論理型言語(Prolog)】
A1 = A + 1
宣言型言語に慣れるとイラッとするのかもしれない
【関数型言語(Haskell)】
a' = a + 1
【論理型言語(Prolog)】
A1 = A + 1
193 :仕様書無しさん2012/03/27(火) 09:04:29.30
1ならインクリしろって事なのかマジックナンバーだからなのか
一定の数値足すならそれが記述方法として正しいし理解しやすいと思う
一定の数値足すならそれが記述方法として正しいし理解しやすいと思う
194 :仕様書無しさん2012/03/27(火) 09:08:07.35
あぁ同じ変数に突っ込むってのもあったか
何かしら足してるなら別物になる事が多いしなぁ…
何かしら足してるなら別物になる事が多いしなぁ…
199 :仕様書無しさん2012/04/07(土) 18:55:20.54
コメントをテンプレートを使って強制するとおこりがちなこと
/************************************
* 関数名 Initialize
* 日本語名 初期化関数
* 概要 初期化を行う
* 機能 パラメータの初期化
* 備考 特になし
*************************************/
InitStatus (...) {
}
/************************************
* 関数名 Initialize
* 日本語名 初期化関数
* 概要 初期化を行う
* 機能 パラメータの初期化
* 備考 特になし
*************************************/
InitStatus (...) {
}
203 :仕様書無しさん2012/04/11(水) 21:01:07.00
俺がおかしいんだろうけど
privateかつ仮想関数でもない関数がstatic関数じゃ無かったとき。
てか、できるだけクラス内部で呼ぶオブジェクト自身の関数は、
static関数であって欲しい。
まず、インターフェースとして外に見せてる関数じゃないんだから、
static関数で十分だし、コード追うときメンバー変数弄ってる関数は
見た目がグローバル変数中で使ってる関数と同じなんで読みづらい。
privateかつ仮想関数でもない関数がstatic関数じゃ無かったとき。
てか、できるだけクラス内部で呼ぶオブジェクト自身の関数は、
static関数であって欲しい。
まず、インターフェースとして外に見せてる関数じゃないんだから、
static関数で十分だし、コード追うときメンバー変数弄ってる関数は
見た目がグローバル変数中で使ってる関数と同じなんで読みづらい。
207 :仕様書無しさん2012/04/11(水) 21:32:49.03
>>203
うん、君がおかしい。
でもそれがイラッつとするなら
そりゃ感情論だから仕方ない。
うん、君がおかしい。
でもそれがイラッつとするなら
そりゃ感情論だから仕方ない。
204 :仕様書無しさん2012/04/11(水) 21:13:17.77
this使えよとしか
208 :仕様書無しさん2012/04/11(水) 21:38:44.72
>>204
thisもどうかと思うわ。5個メンバー変数あっても、
実際一つのprivate関数が必要とするのは2〜3って事が多いし。
だったら直接その変数を引数渡しした方がましじゃん。
thisもどうかと思うわ。5個メンバー変数あっても、
実際一つのprivate関数が必要とするのは2〜3って事が多いし。
だったら直接その変数を引数渡しした方がましじゃん。
209 :仕様書無しさん2012/04/11(水) 21:55:57.48
>>208
メンバー変数をわざわざ引数で渡す必要性がわからん。
メンバー変数をわざわざ引数で渡す必要性がわからん。
210 :仕様書無しさん2012/04/11(水) 22:21:59.19
>>209
グローバル変数と同じ理由
// ここだけ見ていつループが終了するか解るか?
for( point = 0; 100 > point; ++point ) Function();
グローバル変数と同じ理由
// ここだけ見ていつループが終了するか解るか?
for( point = 0; 100 > point; ++point ) Function();
212 :仕様書無しさん2012/04/11(水) 22:30:07.16
数年前のコード追うときとか楽なんだよ
>>210の例でいうFunctionで実際に値が
変更されるかどうか、Functionの中身
見ないで判断することができるからね。
>>210の例でいうFunctionで実際に値が
変更されるかどうか、Functionの中身
見ないで判断することができるからね。
214 :仕様書無しさん2012/04/11(水) 22:38:55.94
> >>210の例でいうFunctionで実際に値が
> 変更されるかどうか、Functionの中身
> 見ないで判断することができるからね。
意味がわからない。
> 変更されるかどうか、Functionの中身
> 見ないで判断することができるからね。
意味がわからない。
216 :仕様書無しさん2012/04/11(水) 22:44:24.83
>>214
pointがフィールドだった場合Functionメソッドが何もしなければ100回でループを抜ける
もしFunctionがpointに対し何かしていればループの回数はFunctionの実装を確認するまで不明となる
pointがフィールドだった場合Functionメソッドが何もしなければ100回でループを抜ける
もしFunctionがpointに対し何かしていればループの回数はFunctionの実装を確認するまで不明となる
205 :仕様書無しさん2012/04/11(水) 21:19:09.81
this->〜();ってしてても他のヤツ保守するときサボるし
this省いてもコンパイルエラーにならんし
this省いてもコンパイルエラーにならんし
291 :205-2062012/04/12(木) 22:18:30.30
ごめん、眠くて>>205-206にいい加減な事書いた。
thisじゃなくてメンバー変数を明示的に引数で渡せば十分だった。
別にthis->
thisじゃなくてメンバー変数を明示的に引数で渡せば十分だった。
別にthis->
294 :仕様書無しさん2012/04/12(木) 22:25:38.38
>>291-293
いや違うって。
引数で渡そうが渡すまいが、
同じクラス内のメソッドだとメンバ変数に自由にアクセスできてしまうから
まずは他所へ追いやるのが先だろ。
その追いやる先というのはthis.〜から始まるサブクラスしかあり得ない。
それ以外から始まるクラスはぱっと見でスコープわからんだろ。
いや違うって。
引数で渡そうが渡すまいが、
同じクラス内のメソッドだとメンバ変数に自由にアクセスできてしまうから
まずは他所へ追いやるのが先だろ。
その追いやる先というのはthis.〜から始まるサブクラスしかあり得ない。
それ以外から始まるクラスはぱっと見でスコープわからんだろ。
295 :仕様書無しさん2012/04/12(木) 22:27:43.50
>>294
既にさんざん出てるけどstatic関数なら制限できるよ
既にさんざん出てるけどstatic関数なら制限できるよ
296 :仕様書無しさん2012/04/12(木) 22:34:18.14
>>295
でもそれがstaticかどうかってぱっと見わからないよね。
staticじゃなくてもコンパイル通るよね。
でもそれがstaticかどうかってぱっと見わからないよね。
staticじゃなくてもコンパイル通るよね。
297 :仕様書無しさん2012/04/12(木) 22:40:31.22
>>296
通るだけならグローバル変数だってコンパイル通るじゃん
じゃなくて、ルールでそう規制するんでしょ
レビューとかでさ
通るだけならグローバル変数だってコンパイル通るじゃん
じゃなくて、ルールでそう規制するんでしょ
レビューとかでさ
298 :仕様書無しさん2012/04/12(木) 22:47:24.21
>>296
簡単な文を一行書くだけで簡単にグローバル変数は使える。
でも現実には、みんな引数渡しを使う。
組織内でダメという風潮を作れるかどうかよ。
簡単な文を一行書くだけで簡単にグローバル変数は使える。
でも現実には、みんな引数渡しを使う。
組織内でダメという風潮を作れるかどうかよ。
206 :仕様書無しさん2012/04/11(水) 21:23:10.50
Objective-Cとかjavascriptだと
selfやthis強制するから便利だよな
selfやthis強制するから便利だよな
242 :仕様書無しさん2012/04/11(水) 23:33:20.27
>>241
言語を選ぶ自由があるなら>>206でFAじゃね
言語を選ぶ自由があるなら>>206でFAじゃね
244 :仕様書無しさん2012/04/11(水) 23:35:04.92
>>242
参照で返してもいいよ
参照で返してもいいよ
213 :仕様書無しさん2012/04/11(水) 22:37:37.22
グローバル変数は目の敵にするくせに
メンバ変数にしただけで安心しちゃってる人は
グローバル変数の何が悪いのかもう一度考え直したほうがいいね。
メンバ変数にしただけで安心しちゃってる人は
グローバル変数の何が悪いのかもう一度考え直したほうがいいね。
215 :仕様書無しさん2012/04/11(水) 22:42:45.84
>>213
普通は必要があるからメンバ変数として保持するわけで。
メンバ変数として保持する必要がない変数までメンバ変数として保持してる
コードは、そもそもそれ自体が変だとは思わないか?
普通は必要があるからメンバ変数として保持するわけで。
メンバ変数として保持する必要がない変数までメンバ変数として保持してる
コードは、そもそもそれ自体が変だとは思わないか?
217 :仕様書無しさん2012/04/11(水) 22:46:03.03
>>215
問題点が違うよ。
無駄じゃないメンバーでも問題は変わらないんだから。
問題点が違うよ。
無駄じゃないメンバーでも問題は変わらないんだから。
218 :仕様書無しさん2012/04/11(水) 22:46:26.79
>>215
メンバ変数は状態を保持するための苦肉の策でしょ
本当は禁止したほうがいいくらいだよ
メンバ変数は状態を保持するための苦肉の策でしょ
本当は禁止したほうがいいくらいだよ
222 :仕様書無しさん2012/04/11(水) 22:50:07.26
>>218
全部の変数をmain関数から引き渡せば状態を保持するメンバ変数なんていらない
っていう主張だったっけ?
全部の変数をmain関数から引き渡せば状態を保持するメンバ変数なんていらない
っていう主張だったっけ?
221 :仕様書無しさん2012/04/11(水) 22:50:04.98
インターフェースとしてクラスを使うのか、thisを省略するためにクラスを使うのかじゃ全然違うしな
223 :2222012/04/11(水) 22:51:28.59
あぁ、ちょっと違った。
main関数じゃなくて、上位の関数だったかな。
main関数じゃなくて、上位の関数だったかな。
224 :仕様書無しさん2012/04/11(水) 22:52:52.35
>>223
インターフェースになる関数の中で呼ぶ自分のメンバーには
引数でメンバー変数を渡せって話。
インターフェースになる関数の中で呼ぶ自分のメンバーには
引数でメンバー変数を渡せって話。
230 :仕様書無しさん2012/04/11(水) 23:03:17.37
>>224
そもそもそんな関数をメンバ関数にしてる設計がおかしいんじゃない?
インスタンスに関係ない関数なら、クラスに入れないのが正しいのでは?
そもそもそんな関数をメンバ関数にしてる設計がおかしいんじゃない?
インスタンスに関係ない関数なら、クラスに入れないのが正しいのでは?
231 :仕様書無しさん2012/04/11(水) 23:04:30.58
>>230
Javaとか.Net系統じゃ無理だし
Javaとか.Net系統じゃ無理だし
232 :仕様書無しさん2012/04/11(水) 23:04:36.84
>>230
インスタンスに関係ないわけじゃなくて
お行儀良くしましょうってことだよ
インスタンスに関係ないわけじゃなくて
お行儀良くしましょうってことだよ
233 :仕様書無しさん2012/04/11(水) 23:07:35.43
>>230
あるクラス内でしか使わない関数なら
不要になったとき捨てやすいように
クラススコープに隠しておきたい
あるクラス内でしか使わない関数なら
不要になったとき捨てやすいように
クラススコープに隠しておきたい
234 :仕様書無しさん2012/04/11(水) 23:11:24.14
>>231
別クラスにするとかあるでしょ。
>>232
基本的にはオブジェクト指向である限り、インスタンスと相互作用が
ないものはクラス内に入れないほうがいい。
まぁコーディング上の都合でちょっとしたことをさせる
(インスタンスと関係ない)小さなメソッドを入れることはあるけど。
別クラスにするとかあるでしょ。
>>232
基本的にはオブジェクト指向である限り、インスタンスと相互作用が
ないものはクラス内に入れないほうがいい。
まぁコーディング上の都合でちょっとしたことをさせる
(インスタンスと関係ない)小さなメソッドを入れることはあるけど。
235 :仕様書無しさん2012/04/11(水) 23:11:57.08
>>233
同意。
整理整頓しようってだけの話。
同意。
整理整頓しようってだけの話。
236 :仕様書無しさん2012/04/11(水) 23:14:21.42
>>234
別クラスで公開してしまったら他から使われる可能性があるからな
別クラスで公開してしまったら他から使われる可能性があるからな
237 :仕様書無しさん2012/04/11(水) 23:15:16.96
>>234
メンバ変数を直接いじるよりは、引数と戻り値を通じてやり取りしたほうが良い。
プライベートであっても、副作用があるより無いほうが良い。
メンバ変数を直接いじるよりは、引数と戻り値を通じてやり取りしたほうが良い。
プライベートであっても、副作用があるより無いほうが良い。
238 :仕様書無しさん2012/04/11(水) 23:23:21.29
>>236
副作用を起こすことを目的とした関数の場合には、
結局メンバ変数を参照渡しするか何かして副作用をおこすんだろ?
そんなに変わるとは思えないな。
副作用を起こすことを目的とした関数の場合には、
結局メンバ変数を参照渡しするか何かして副作用をおこすんだろ?
そんなに変わるとは思えないな。
225 :仕様書無しさん2012/04/11(水) 22:53:08.84
なぜグローバル変数が嫌われるかといえば
変数のスコープがブロックを超越するために
生成消滅のタイミングを把握できないからだ。
メンバ変数にしたところで
スコープがクラス内に限定されるだけで
メソッドというブロックを超越する問題は解決されていない。
変数のスコープがブロックを超越するために
生成消滅のタイミングを把握できないからだ。
メンバ変数にしたところで
スコープがクラス内に限定されるだけで
メソッドというブロックを超越する問題は解決されていない。
226 :仕様書無しさん2012/04/11(水) 22:54:56.26
>>225
消滅というか変更全般だろ
下手すりゃ無限ループも起こすし
消滅というか変更全般だろ
下手すりゃ無限ループも起こすし
227 :仕様書無しさん2012/04/11(水) 22:54:57.12
まあオブジェクト指向も所詮道具なんだから
良い所悪い所判って使えばいいんだけどね
良い所悪い所判って使えばいいんだけどね
228 :仕様書無しさん2012/04/11(水) 22:58:14.63
オブジェクト指向は関係なくね
もっと構造化レベルの原始的な話でしょ
もっと構造化レベルの原始的な話でしょ
229 :仕様書無しさん2012/04/11(水) 22:59:28.54
>>228
その通り。
この話題に違和感を感じるならオブジェクト指向以前に
構造化を判ってない証拠。
その通り。
この話題に違和感を感じるならオブジェクト指向以前に
構造化を判ってない証拠。
240 :仕様書無しさん2012/04/11(水) 23:31:11.70
操作するのが一つでよければね。
241 :仕様書無しさん2012/04/11(水) 23:32:16.97
>>240
戻り値が一つしか返せないから不便というのであれば
タプルを持つ言語を使えば良い
戻り値が一つしか返せないから不便というのであれば
タプルを持つ言語を使えば良い
251 :仕様書無しさん2012/04/11(水) 23:58:36.37
>>240
戻り値がオブジェクト一個で済まないなら
それこそ別クラスにすりゃよくね
クラス内部でprivateメソッドにするような
内容じゃないでしょ
戻り値がオブジェクト一個で済まないなら
それこそ別クラスにすりゃよくね
クラス内部でprivateメソッドにするような
内容じゃないでしょ
243 :仕様書無しさん2012/04/11(水) 23:34:54.43
before:
for( point = 0; 100 > point; ++point ) Function();
after:
for( point = 0; 100 > point; ++point ) point = Function( point );
多少明示的にするだけでかなり違うね。
for( point = 0; 100 > point; ++point ) Function();
after:
for( point = 0; 100 > point; ++point ) point = Function( point );
多少明示的にするだけでかなり違うね。
245 :仕様書無しさん2012/04/11(水) 23:38:10.17
>>243
ループ中にループ変数に代入する(かつ下位関数で書き変える?)
っていうコーディングスタイルがそもそもありえない。
ループ中にループ変数に代入する(かつ下位関数で書き変える?)
っていうコーディングスタイルがそもそもありえない。
247 :仕様書無しさん2012/04/11(水) 23:39:34.35
>>245
forの例は極端だろうけどwhileとか
ループ中で副作用が発生すんのはよくあるよ
forの例は極端だろうけどwhileとか
ループ中で副作用が発生すんのはよくあるよ
250 :仕様書無しさん2012/04/11(水) 23:54:05.04
>>245
「ループ変数」てのがすでにおかしい。
それはただの変数だ。
「ループ変数」てのがすでにおかしい。
それはただの変数だ。
254 :仕様書無しさん2012/04/12(木) 00:11:39.58
>>250
ただの変数pointで
> for( point = 0; 100 > point; ++point ) point = Function( point );
こんなコード書いてきたら何も言わずに書き直すわ。
ただの変数pointで
> for( point = 0; 100 > point; ++point ) point = Function( point );
こんなコード書いてきたら何も言わずに書き直すわ。
257 :仕様書無しさん2012/04/12(木) 00:13:27.56
>>254
わざわざ問題を単純化して話をしやすくしているのに
話をすり替えるな
わざわざ問題を単純化して話をしやすくしているのに
話をすり替えるな
258 :仕様書無しさん2012/04/12(木) 00:15:04.57
>>254
それを書き直すのは構わんが
こういうケースだって問題はかわらんのよ
while( 100 > point )
{
FunctionA();
FunctionB();
FunctionC();
}
while( 100 > point )
{
FunctionA();
point = FunctionB( point );
FunctionC();
}
それを書き直すのは構わんが
こういうケースだって問題はかわらんのよ
while( 100 > point )
{
FunctionA();
FunctionB();
FunctionC();
}
while( 100 > point )
{
FunctionA();
point = FunctionB( point );
FunctionC();
}
265 :仕様書無しさん2012/04/12(木) 00:28:19.01
>>258
どうも、例にあげてるコード自体が何となく臭いんだけど。。
メンバ変数pointが100未満の場合ループするよっていう
仕様なら(=pointがそれだけ重要な意味を持ってるなら)、
前者でいいと思う。
どうも、例にあげてるコード自体が何となく臭いんだけど。。
メンバ変数pointが100未満の場合ループするよっていう
仕様なら(=pointがそれだけ重要な意味を持ってるなら)、
前者でいいと思う。
267 :仕様書無しさん2012/04/12(木) 00:29:42.46
>>265
マジで?
マジで?
268 :仕様書無しさん2012/04/12(木) 00:32:31.44
>>265
問題は直すとき。今後者のループを見ればpointを
書き換えてる関数は一発で解るけど
前者だと3個とも疑わしい
実際の具体的な名前の関数ならすぐ解ると思うかもしれないけど
具体的な名前の関数でも分かりづらい事が多い
問題は直すとき。今後者のループを見ればpointを
書き換えてる関数は一発で解るけど
前者だと3個とも疑わしい
実際の具体的な名前の関数ならすぐ解ると思うかもしれないけど
具体的な名前の関数でも分かりづらい事が多い
271 :仕様書無しさん2012/04/12(木) 00:36:45.59
>>267
別スレッドでpointを書き換える関数(publicかもしれない)が
呼ばれたときのこととか考えるとね。
意味としては、
100 > pointが成り立っている間、
FunctionA(), FunctionB(), FunctionC()を実行しつづけるよ
っていうのが重要だとおもうんで。
別スレッドでpointを書き換える関数(publicかもしれない)が
呼ばれたときのこととか考えるとね。
意味としては、
100 > pointが成り立っている間、
FunctionA(), FunctionB(), FunctionC()を実行しつづけるよ
っていうのが重要だとおもうんで。
273 :仕様書無しさん2012/04/12(木) 00:39:17.57
>>271
そんな例外(プログラム的な意味ではなく)を考えたところで意味が無いでしょ。
例外は例外らしく処理を切り分けるべき。
ここでは変数pointがどの関数によって影響を受けるか
明示されていることが大事なんだ。
そんな例外(プログラム的な意味ではなく)を考えたところで意味が無いでしょ。
例外は例外らしく処理を切り分けるべき。
ここでは変数pointがどの関数によって影響を受けるか
明示されていることが大事なんだ。
274 :仕様書無しさん2012/04/12(木) 00:43:07.32
>>273
後者の書き方でも、結局は明示されてないということ。
むしろ、
point = FunctionB( point );
だけをチェックすればいいんだと間違えるかもしれない。
後者の書き方でも、結局は明示されてないということ。
むしろ、
point = FunctionB( point );
だけをチェックすればいいんだと間違えるかもしれない。
275 :仕様書無しさん2012/04/12(木) 00:43:13.34
>>271
どうしても無理っていうなら別だけど
できる状況なら分かりやすくしとけばいいでしょ
どうしても無理っていうなら別だけど
できる状況なら分かりやすくしとけばいいでしょ
276 :仕様書無しさん2012/04/12(木) 00:43:17.04
>>258の流れから
while( 100 > point )
{
this.proc.FunctionA();
this.proc.FunctionB(&point);
this.proc.FunctionC();
}
これで文句あるまい。
while( 100 > point )
{
this.proc.FunctionA();
this.proc.FunctionB(&point);
this.proc.FunctionC();
}
これで文句あるまい。
277 :仕様書無しさん2012/04/12(木) 00:43:52.25
>>274
だけをチェックすればいいようにするんだよ。
だけをチェックすればいいようにするんだよ。
282 :仕様書無しさん2012/04/12(木) 12:03:48.69
>>243
実際に動かしてから死ねよって思うかソース見た瞬間に死ねよって思うかぐらいの違いしかないが
この違いのおかげでおおごとにならずに済むこともまあまあある
実際に動かしてから死ねよって思うかソース見た瞬間に死ねよって思うかぐらいの違いしかないが
この違いのおかげでおおごとにならずに済むこともまあまあある
299 :仕様書無しさん2012/04/12(木) 23:24:28.33
>>282
バグに限った話じゃないけどな
改修しやすさも大きく変わる
5個関数がならんでて、5個の関数の中身調べなきゃ
改修する変数の影響が解からん場合と、
2個関数調べれば変数の動作を完全に把握できる場合とじゃ
作業に掛ける時間が大きく異なる
バグに限った話じゃないけどな
改修しやすさも大きく変わる
5個関数がならんでて、5個の関数の中身調べなきゃ
改修する変数の影響が解からん場合と、
2個関数調べれば変数の動作を完全に把握できる場合とじゃ
作業に掛ける時間が大きく異なる
246 :仕様書無しさん2012/04/11(水) 23:39:25.25
別にこんなものは絶対こうしなくちゃていうものじゃなくて
方便で使い分ければ良いんだけど
意識してるかどうかは別の話だからな
方便で使い分ければ良いんだけど
意識してるかどうかは別の話だからな
249 :仕様書無しさん2012/04/11(水) 23:42:47.37
whileがループじゃなかったら何なんだw
253 :仕様書無しさん2012/04/12(木) 00:08:32.12
問題の本質はあるクラスメソッドにおいて
メンバ変数にアクセスしてるのかグローバル変数にアクセスしてるのか
ぱっと見区別が付かないということだったはず。
thisを強制すれば済む話だけど、
社内の統制がクソでコーディングスタイルが統一できないのであれば
何を提案しようが無駄な気もする。
メンバ変数にアクセスしてるのかグローバル変数にアクセスしてるのか
ぱっと見区別が付かないということだったはず。
thisを強制すれば済む話だけど、
社内の統制がクソでコーディングスタイルが統一できないのであれば
何を提案しようが無駄な気もする。
256 :仕様書無しさん2012/04/12(木) 00:12:21.59
>>253
問題の本質は
引数と戻り値を使わず、メンバ変数を直接いじるプログラムを書くことによって
思わぬ副作用に見舞われることがあるってことだよ。
問題の本質は
引数と戻り値を使わず、メンバ変数を直接いじるプログラムを書くことによって
思わぬ副作用に見舞われることがあるってことだよ。
259 :仕様書無しさん2012/04/12(木) 00:16:14.07
>>253
それこそスレ的には
「アプリケーションハンガリアン使え」
で済む話じゃね?
それこそスレ的には
「アプリケーションハンガリアン使え」
で済む話じゃね?
261 :仕様書無しさん2012/04/12(木) 00:20:05.29
>>259
システムハンガリアンじゃね?
アプリケーションハンガリアンってと
pxSize ptSize emSizeみたいな単位とか
変数の型(とスコープ)じゃなく中身の情報含ませるものだから
システムハンガリアンじゃね?
アプリケーションハンガリアンってと
pxSize ptSize emSizeみたいな単位とか
変数の型(とスコープ)じゃなく中身の情報含ませるものだから
255 :仕様書無しさん2012/04/12(木) 00:12:07.49
グローバル変数と問題が同じというだけで
もとからメンバー変数とグローバル変数が紛らわしいという話じゃないよ
もとからメンバー変数とグローバル変数が紛らわしいという話じゃないよ
260 :仕様書無しさん2012/04/12(木) 00:19:35.71
ハンガリアンは、型を表すプリフィックスであって
スコープを表すプリフィックスはハンガリアンではありません。
プリフィックスが付けばなんでもハンガリアンだと思うバカが多くて困る。
ぶっちゃけ、::や->や.を記号ではなく文字として捉えれば、
nantoka::fooとかの nantoka::もプリフィックスだってーの。
スコープを表すプリフィックスはハンガリアンではありません。
プリフィックスが付けばなんでもハンガリアンだと思うバカが多くて困る。
ぶっちゃけ、::や->や.を記号ではなく文字として捉えれば、
nantoka::fooとかの nantoka::もプリフィックスだってーの。
262 :仕様書無しさん2012/04/12(木) 00:20:46.53
>>260-261
266 :仕様書無しさん2012/04/12(木) 00:29:10.29
>>260
恥ずかしいな
恥ずかしいな
272 :仕様書無しさん2012/04/12(木) 00:37:42.86
>>266
お前がなw
お前がなw
263 :仕様書無しさん2012/04/12(木) 00:24:14.52
話を戻そう。
プリフィクスを付けたところで
ある関数で、メンバー変数やグローバル変数が
書き換えられている事は解らないので意味がない。
プリフィクスを付けたところで
ある関数で、メンバー変数やグローバル変数が
書き換えられている事は解らないので意味がない。
269 :仕様書無しさん2012/04/12(木) 00:35:21.54
while( 100 > point )
{
this.proc.FunctionA(&point);
this.proc.FunctionB(&point);
this.proc.FunctionC(&point);
}
もうこれでいいよ。
{
this.proc.FunctionA(&point);
this.proc.FunctionB(&point);
this.proc.FunctionC(&point);
}
もうこれでいいよ。
270 :仕様書無しさん2012/04/12(木) 00:36:24.40
>>269
渡さなくても良い関数には無理して渡さなくても良いんだよ
渡さなくても良い関数には無理して渡さなくても良いんだよ
278 :仕様書無しさん2012/04/12(木) 00:48:40.72
http://logsoku.com/thread/hibari.2ch.net/tech/1308106024/941-
http://logsoku.com/thread/hibari.2ch.net/tech/1308106024/956
パラダイム未修得のトーシロらしいぞお前ら
http://logsoku.com/thread/hibari.2ch.net/tech/1308106024/956
パラダイム未修得のトーシロらしいぞお前ら
280 :仕様書無しさん2012/04/12(木) 00:56:18.33
>>278
同じような話だけど、バカが水差して終わってるだけじゃん
同じような話だけど、バカが水差して終わってるだけじゃん
279 :仕様書無しさん2012/04/12(木) 00:51:55.39
オブジェクト指向はインターフェースの外の話しだし
パラダイムがどうのとかどうでもいいよ
飽くまで構造化と実用的な保守スタイルの話しだし
パラダイムがどうのとかどうでもいいよ
飽くまで構造化と実用的な保守スタイルの話しだし
281 :仕様書無しさん2012/04/12(木) 07:00:21.99
何か随分と伸びてると思ったら、ゆうべはおたのしみでしたね。
メンバ変数の書き換えについては、小規模なら良い様な気もするけども、
ループカウンタを途中でいじられるのはイラッつとするな。
This必須とか制限を増やしてコーディングの自由度を下げて
誰が書いても似たコードになるようにするのが今の言語の流れかね。
メンバ変数の書き換えについては、小規模なら良い様な気もするけども、
ループカウンタを途中でいじられるのはイラッつとするな。
This必須とか制限を増やしてコーディングの自由度を下げて
誰が書いても似たコードになるようにするのが今の言語の流れかね。
287 :仕様書無しさん2012/04/12(木) 21:28:30.63
>>281
> This必須とか制限を増やしてコーディングの自由度を下げて
逆に言えばさ、thisを書かなくても良くなったら
自由度があがるってことになると思うんだけどさ、
「thisを書かなくてよくなった、俺は自由だ!」って思う奴いるの?
つまりね、俺が言いたいのはthis必須と自由度とは全く関係ないよってこと。
× 「コーディングの自由度を下げて 」
○ 「コーディングの面倒くささを下げて」
君が本当に言いたいことはこうでしょ?
で、問題はthis省略で本当に面倒くささが下がったかどうか。
確かに書くときの面倒さはなくなったが、逆に読むときは
正確な意図がすぐには分からず面倒さは増えることになる。
これは、どっちがいいかって話。トレードオフの話でしかない。
なぜ俺が最初に「自由度とは無関係」と言ったのかというと、自由度は
上がるか下がるかしか無い。そうするとトレードオフの話ではないように見えてしまう。
本当は、this必須かどうかってのは、トレードオフの問題なのに、
this省略できたほうが優れてるような印象になってる。
> This必須とか制限を増やしてコーディングの自由度を下げて
逆に言えばさ、thisを書かなくても良くなったら
自由度があがるってことになると思うんだけどさ、
「thisを書かなくてよくなった、俺は自由だ!」って思う奴いるの?
つまりね、俺が言いたいのはthis必須と自由度とは全く関係ないよってこと。
× 「コーディングの自由度を下げて 」
○ 「コーディングの面倒くささを下げて」
君が本当に言いたいことはこうでしょ?
で、問題はthis省略で本当に面倒くささが下がったかどうか。
確かに書くときの面倒さはなくなったが、逆に読むときは
正確な意図がすぐには分からず面倒さは増えることになる。
これは、どっちがいいかって話。トレードオフの話でしかない。
なぜ俺が最初に「自由度とは無関係」と言ったのかというと、自由度は
上がるか下がるかしか無い。そうするとトレードオフの話ではないように見えてしまう。
本当は、this必須かどうかってのは、トレードオフの問題なのに、
this省略できたほうが優れてるような印象になってる。
286 :仕様書無しさん2012/04/12(木) 21:28:30.37
ここまで読み流した
ループカウンタをメンバ変数にするな
ループカウンタをメンバ変数にするな
289 :仕様書無しさん2012/04/12(木) 21:52:32.47
解釈の自由度ってなに?
まさか、書いた本人が
どう解釈されてもいいように書いた!
なんて言うわけないしw
まさか、書いた本人が
どう解釈されてもいいように書いた!
なんて言うわけないしw
392 :仕様書無しさん2012/04/14(土) 18:26:10.67
>>55 同意
>>249 あくせる
>>289 解釈の自由度が下がる=誤解が減る
>>249 あくせる
>>289 解釈の自由度が下がる=誤解が減る
290 :仕様書無しさん2012/04/12(木) 21:57:34.84
> 誰が書いても似たコードになるようにするのが今の言語の流れかね。
これもよくわからんね。
ですます調でかけ!と言われても
似たような小説にはならんだろ?
オリジナリティがある小説を書く場合、
そのストーリーでオリジナリティを出すのであって
そんな語尾をどうするか程度で、似てる似てないなんて
判断しないだろ。
これもよくわからんね。
ですます調でかけ!と言われても
似たような小説にはならんだろ?
オリジナリティがある小説を書く場合、
そのストーリーでオリジナリティを出すのであって
そんな語尾をどうするか程度で、似てる似てないなんて
判断しないだろ。
293 :205-206 2012/04/12(木) 22:21:26.76
途中で送信してしまった
別にthis->〜を強制する意味はなかった。
せめてthisでも明示的に渡せば書き換えが
分り易くなると思ったが無駄だった。
別にthis->〜を強制する意味はなかった。
せめてthisでも明示的に渡せば書き換えが
分り易くなると思ったが無駄だった。
300 :仕様書無しさん2012/04/12(木) 23:26:48.40
実装の安易さと、保守と、バグ発生の回避を同時に満たすコーディングか。
301 :仕様書無しさん2012/04/12(木) 23:45:09.36
スマポにするとコンストラクタでthis使えないからな
どんどんソースが汚くなる
どんどんソースが汚くなる
302 :仕様書無しさん2012/04/12(木) 23:46:30.95
1段メンバー呼び出してるだけでも面倒だが、
メンバー呼び出し階層が2段でその先で
書き換えられてるとか相当辛いよな
そもそも階層増えるなら自分のクラスじゃなく
他のクラスメンバー呼べって話だろうけど
メンバー呼び出し階層が2段でその先で
書き換えられてるとか相当辛いよな
そもそも階層増えるなら自分のクラスじゃなく
他のクラスメンバー呼べって話だろうけど
303 :仕様書無しさん2012/04/12(木) 23:51:13.90
if(null == hoge)
C言語屋の年寄りってこう書くよね
最高にウザいんだけど
C言語屋の年寄りってこう書くよね
最高にウザいんだけど
304 :仕様書無しさん2012/04/12(木) 23:52:57.20
>>303
お前の周りだけ。
類は友を呼ぶ
お前の周りだけ。
類は友を呼ぶ
306 :仕様書無しさん2012/04/13(金) 00:51:18.01
>>303
一生懸命アラ探ししてやっと見つけたのがそんなどうでもいいことなのなら
その先輩は結構デキる奴だな
もしくはお前がダメすぎて他のアラが見えないか
一生懸命アラ探ししてやっと見つけたのがそんなどうでもいいことなのなら
その先輩は結構デキる奴だな
もしくはお前がダメすぎて他のアラが見えないか
309 :仕様書無しさん2012/04/13(金) 06:15:22.90
>>303
定数を先に書くのはC初心者の象徴だろう。
定数を先に書くのはC初心者の象徴だろう。
310 :仕様書無しさん2012/04/13(金) 06:41:06.79
>>309
俺も定数先に書くわ
何か問題あんの?
俺も定数先に書くわ
何か問題あんの?
305 :仕様書無しさん2012/04/13(金) 00:11:15.56
C言語ならなおさら書かないんじゃないか?
文字列を==で比較する感覚に似ている
文字列を==で比較する感覚に似ている
311 :仕様書無しさん2012/04/13(金) 06:52:14.05
「定数を先に書いておくと、
比較と代入を間違えて記述したときエラーになるので
間違いを見つけ易い」
という理由でそういう記述の仕方をする人は散見するけども、
それは
「私は比較と代入を間違える可能性があります」
と宣言してるようなもんで、他の部分もちょっと信用ならないよねーという
ただの経験則。
比較と代入を間違えて記述したときエラーになるので
間違いを見つけ易い」
という理由でそういう記述の仕方をする人は散見するけども、
それは
「私は比較と代入を間違える可能性があります」
と宣言してるようなもんで、他の部分もちょっと信用ならないよねーという
ただの経験則。
313 :仕様書無しさん2012/04/13(金) 07:14:55.68
>>311
0 > ExampleFunction( ・・・, ・・・, ・・・, ・・・, ・・・ )
定数左に書けば条件見やすいけど
ExampleFunction( ・・・, ・・・, ・・・, ・・・, ・・・ ) < 0
定数右に書くと条件が右端に行くんで見づらい
0 > ExampleFunction( ・・・, ・・・, ・・・, ・・・, ・・・ )
定数左に書けば条件見やすいけど
ExampleFunction( ・・・, ・・・, ・・・, ・・・, ・・・ ) < 0
定数右に書くと条件が右端に行くんで見づらい
314 :仕様書無しさん2012/04/13(金) 07:39:34.94
>>313
下のが見やすいんだが
下のが見やすいんだが
315 :仕様書無しさん2012/04/13(金) 08:45:33.13
>>313
変数使えばいいやん。
条件式に直接使うぐらいなら、ほとんどの場合はExampleFunctionは意味のある名前の「はず」だから
文脈そのまま読める方が読みやすいと思うが・・・まぁ慣れれば慣れるんだろうな。
変数使えばいいやん。
条件式に直接使うぐらいなら、ほとんどの場合はExampleFunctionは意味のある名前の「はず」だから
文脈そのまま読める方が読みやすいと思うが・・・まぁ慣れれば慣れるんだろうな。
317 :仕様書無しさん2012/04/13(金) 14:45:34.51
>>311
> 「私は比較と代入を間違える可能性があります」
> と宣言してるようなもんで、他の部分もちょっと信用ならないよねーという
== とタイプしようとして = とタイプしてしまう可能性は誰にでもある
「俺は間違えるかもしれない」と言ってる奴は、「俺は絶対間違えない」って奴よりも信用できる
たとえコンパイルオプションやツールでチェックできるとしても、 (0 == foo) って書くのは悪いことじゃない
そもそも、(0 == foo) が理解し辛いって奴は、数学的センスに欠けている
地図を読むときに、常に進行方向が上になるように地図をぐるぐる回す奴に通じるものがある
そんな奴とも一緒に仕事をしなければならない以上、 規約で (foo == 0) って記法に統一するってのはあるかもしれないが、
そんな奴はお荷物だということを自覚すべき
> 「私は比較と代入を間違える可能性があります」
> と宣言してるようなもんで、他の部分もちょっと信用ならないよねーという
== とタイプしようとして = とタイプしてしまう可能性は誰にでもある
「俺は間違えるかもしれない」と言ってる奴は、「俺は絶対間違えない」って奴よりも信用できる
たとえコンパイルオプションやツールでチェックできるとしても、 (0 == foo) って書くのは悪いことじゃない
そもそも、(0 == foo) が理解し辛いって奴は、数学的センスに欠けている
地図を読むときに、常に進行方向が上になるように地図をぐるぐる回す奴に通じるものがある
そんな奴とも一緒に仕事をしなければならない以上、 規約で (foo == 0) って記法に統一するってのはあるかもしれないが、
そんな奴はお荷物だということを自覚すべき
318 :仕様書無しさん2012/04/13(金) 14:52:53.94
>>317
> 「俺は間違えるかもしれない」と言ってる奴は、「俺は絶対間違えない」って奴よりも信用できる
俺なら、コンパイラがチェックしてくれるのに、「俺は間違えるかもしれない」から(0 == foo)とか書く奴は、
間抜けか頭堅い奴と判断する。
> たとえコンパイルオプションやツールでチェックできるとしても、 (0 == foo) って書くのは悪いことじゃない
悪いことだよ。
> そもそも、(0 == foo) が理解し辛いって奴は、数学的センスに欠けている
数学的センスなんか関係無いよ。言語の話をしてるんだよ。
「if foo is zero」と「if zero is foo」を同じように同じ速度で紛れがなく誰でも判断できるかどうかの話。
> そんな奴はお荷物だということを自覚すべき
お前がお荷物だよ、全く。
> 「俺は間違えるかもしれない」と言ってる奴は、「俺は絶対間違えない」って奴よりも信用できる
俺なら、コンパイラがチェックしてくれるのに、「俺は間違えるかもしれない」から(0 == foo)とか書く奴は、
間抜けか頭堅い奴と判断する。
> たとえコンパイルオプションやツールでチェックできるとしても、 (0 == foo) って書くのは悪いことじゃない
悪いことだよ。
> そもそも、(0 == foo) が理解し辛いって奴は、数学的センスに欠けている
数学的センスなんか関係無いよ。言語の話をしてるんだよ。
「if foo is zero」と「if zero is foo」を同じように同じ速度で紛れがなく誰でも判断できるかどうかの話。
> そんな奴はお荷物だということを自覚すべき
お前がお荷物だよ、全く。
325 :仕様書無しさん2012/04/13(金) 16:55:33.94
>>311
ちょっと頭悪すぎ
hoge == null の方がいい理由は、null == hoge と書いたときに得られるわずかな利点よりも、
直感的に理解しづらいという欠点の方が大きいから
もちろん if (hoge = null) みたいなミスを検出できる開発環境下が前提だが
ちょっと頭悪すぎ
hoge == null の方がいい理由は、null == hoge と書いたときに得られるわずかな利点よりも、
直感的に理解しづらいという欠点の方が大きいから
もちろん if (hoge = null) みたいなミスを検出できる開発環境下が前提だが
326 :仕様書無しさん2012/04/13(金) 17:11:28.77
>>325
いや、お前が頭悪すぎだから
>>311を百回読め
いや、お前が頭悪すぎだから
>>311を百回読め
328 :仕様書無しさん2012/04/13(金) 17:27:01.97
>>326
俺は 0 == x と書く人に対して、用心深いとは思っても
> 「私は比較と代入を間違える可能性があります」
> と宣言してるようなもんで、他の部分もちょっと信用ならないよねーという
みたいな感想は抱かないがね
俺は 0 == x と書く人に対して、用心深いとは思っても
> 「私は比較と代入を間違える可能性があります」
> と宣言してるようなもんで、他の部分もちょっと信用ならないよねーという
みたいな感想は抱かないがね
329 :仕様書無しさん2012/04/13(金) 17:31:55.14
>>325=>>328だとしたら、ちょっと何言ってるのかわからないレベル
331 :仕様書無しさん2012/04/13(金) 17:42:57.72
>>328
俺なら、そんなくだらん用心深さなんか発揮しないで、読みやすいコード書けアホと思うな。
俺なら、そんなくだらん用心深さなんか発揮しないで、読みやすいコード書けアホと思うな。
333 :仕様書無しさん2012/04/13(金) 17:50:49.33
>>331
で、お前は 0 == x と書く人の他の部分のコードが信用ならないと思うのか?
俺は他の部分にも同様の用心深さを期待できてむしろ信用できると思うがね
で、お前は 0 == x と書く人の他の部分のコードが信用ならないと思うのか?
俺は他の部分にも同様の用心深さを期待できてむしろ信用できると思うがね
334 :仕様書無しさん2012/04/13(金) 17:53:34.46
>>333
全く信用できない。
そいつは、
・コンパイラが教えてくれるのを知らない無知
・それは知ってるが、「念のため」とかいう訳のわからない理由でスタイルを崩さない馬鹿
のどちらかだから。
全く信用できない。
そいつは、
・コンパイラが教えてくれるのを知らない無知
・それは知ってるが、「念のため」とかいう訳のわからない理由でスタイルを崩さない馬鹿
のどちらかだから。
341 :仕様書無しさん2012/04/13(金) 18:08:09.13
>>311
コーディング標準とか禁じ手を全否定?
コーディング標準とか禁じ手を全否定?
344 :仕様書無しさん2012/04/13(金) 19:14:49.43
>>317
>== とタイプしようとして = とタイプしてしまう可能性は誰にでもある
自分のを発見して「ホントにあるんだ・・・」と、変な感動を覚えた記憶がある
>== とタイプしようとして = とタイプしてしまう可能性は誰にでもある
自分のを発見して「ホントにあるんだ・・・」と、変な感動を覚えた記憶がある
352 :仕様書無しさん2012/04/13(金) 22:13:55.77
>>315
やだよ一時変数で済むもんワザワザ宣言するなんて
あと、具体的な名前書いても条件が画面右寄りになることで到底分かりやすくなったとも思えん
while( 0 < GetMessage( &message, 0, 0, 0 ) ){}
やだよ一時変数で済むもんワザワザ宣言するなんて
あと、具体的な名前書いても条件が画面右寄りになることで到底分かりやすくなったとも思えん
while( 0 < GetMessage( &message, 0, 0, 0 ) ){}
354 :仕様書無しさん2012/04/13(金) 23:48:50.81
まだそのネタが続いてるのか
0 == hoge か hoge == 0 かなんてどうでもいい
>>311の頭おかしいのは
> 「私は比較と代入を間違える可能性があります」
> と宣言してるようなもんで、他の部分もちょっと信用ならないよねーという
の部分
もっと言うと、>>311は一切typoしない、typoする奴は信用ならねーって言ってること
0 == hoge か hoge == 0 かなんてどうでもいい
>>311の頭おかしいのは
> 「私は比較と代入を間違える可能性があります」
> と宣言してるようなもんで、他の部分もちょっと信用ならないよねーという
の部分
もっと言うと、>>311は一切typoしない、typoする奴は信用ならねーって言ってること
357 :仕様書無しさん2012/04/14(土) 01:29:53.09
>>352
while (GetMessage(&message, 0, 0, 0) > 0) { }
ふぅ。
while (GetMessage(&message, 0, 0, 0) > 0) { }
ふぅ。
359 :仕様書無しさん2012/04/14(土) 02:18:18.91
>>358
>>334
>>334
376 :仕様書無しさん2012/04/14(土) 12:44:31.81
>>357
それ何が見やすいの?
それ何が見やすいの?
312 :仕様書無しさん2012/04/13(金) 07:07:50.84
==は「〜が一致する」的な読み方だから「1とaが一致」より「aと1が一致」がaの中身を調べてるって文章になり読みやすい…気がするから変数先だな完全に個人的な理由だが
319 :仕様書無しさん2012/04/13(金) 14:56:55.59
マジックナンバーを直書きすることはほとんどないし
定数なのにconstを忘れる可能性もあるな
定数なのにconstを忘れる可能性もあるな
320 :仕様書無しさん2012/04/13(金) 15:17:29.57
0 == fooと書いたとしても、問題の解決になっていないからねぇ。
手癖みたいなもんで、書くのは勝手だとおもうが
「0 == fooのほうがいい」と主張する奴の話は当てにしない。
手癖みたいなもんで、書くのは勝手だとおもうが
「0 == fooのほうがいい」と主張する奴の話は当てにしない。
322 :仕様書無しさん2012/04/13(金) 16:12:14.85
誰も 0 == foo の方が良いって主張してないと思うが
foo == 0 の方が良いって主張してる奴はいるけど
foo == 0 の方が良いって主張してる奴はいるけど
323 :仕様書無しさん2012/04/13(金) 16:17:01.34
>>322
日本語の読解力に甚だしく欠けてます
日本語の読解力に甚だしく欠けてます
324 :仕様書無しさん2012/04/13(金) 16:28:25.79
>>322
お前にイラッつとしたわ
お前にイラッつとしたわ
327 :仕様書無しさん2012/04/13(金) 17:18:36.25
if (0 == hoge)の件は、ある程度の分量の文章を一度読んだだけでは理解できないIQの層の奴らの
琴線に触れる何かをもってるんだろうな
琴線に触れる何かをもってるんだろうな
330 :仕様書無しさん2012/04/13(金) 17:37:41.05
え?
「私は比較と代入を間違える可能性があります」から、用心深く0 == x と書く人が糞だとみんな言ってんじゃないの?
「私は比較と代入を間違える可能性があります」から、用心深く0 == x と書く人が糞だとみんな言ってんじゃないの?
332 :仕様書無しさん2012/04/13(金) 17:50:48.47
雨が降る可能性が0%でないからと言って、毎日レインコートと長靴で生活する馬鹿
335 :仕様書無しさん2012/04/13(金) 17:53:44.63
>>332
> 雨が降る可能性が0%でないからと言って、毎日レインコートと長靴で生活する馬鹿
ソフトウェア開発においては、それが普通
> 雨が降る可能性が0%でないからと言って、毎日レインコートと長靴で生活する馬鹿
ソフトウェア開発においては、それが普通
336 :仕様書無しさん2012/04/13(金) 17:56:18.69
if (0 == hoge)と書く奴を「用心深い奴」と評価する奴に初めて会ったわ
337 :仕様書無しさん2012/04/13(金) 17:59:37.08
if (0 == x)と書くことが良いことだと思うような間抜けのコードが信頼できるわけないだろ
338 :仕様書無しさん2012/04/13(金) 18:00:54.32
条件式は左辺が評価対象じゃないとな
左読みで重要な情報を先に目に入るようにしないと、思考の効率が格段に悪くなる
左読みで重要な情報を先に目に入るようにしないと、思考の効率が格段に悪くなる
339 :仕様書無しさん2012/04/13(金) 18:03:58.21
returnやsizeofで不要な括弧を「その方がわかりやすいから」と取ろうとしない奴とか、
if (hoge == true)を「その方がわかりやすいから」という奴と同じ臭いがする
if (hoge == true)を「その方がわかりやすいから」という奴と同じ臭いがする
347 :仕様書無しさん2012/04/13(金) 21:18:11.51
>>339
sizeofは括弧付けちゃうなあ・・・
sizeofは括弧付けちゃうなあ・・・
356 :仕様書無しさん2012/04/14(土) 01:27:09.14
>>339
ちなみに、「sizeof 識別子」と「sizeof(型)」は別物ですよ?
混在してると解り難いってゆーなら括弧必須のルールでもいいけど。
ちなみに、「sizeof 識別子」と「sizeof(型)」は別物ですよ?
混在してると解り難いってゆーなら括弧必須のルールでもいいけど。
343 :仕様書無しさん2012/04/13(金) 18:17:26.07
括弧や演算子の前後に一切スペースを入れず、空行も一切入れないスタイルにいらつく
346 :仕様書無しさん2012/04/13(金) 19:18:48.78
3 x 4 と 4 x 3 は意味が違うんだ、という小学校の話を思い出した。
348 :仕様書無しさん2012/04/13(金) 21:30:47.51
>>346
3+3+3+3と4+4+4は確かに違うといえば違う
3+3+3+3と4+4+4は確かに違うといえば違う
350 :仕様書無しさん2012/04/13(金) 21:51:32.59
regist
351 :仕様書無しさん2012/04/13(金) 21:55:31.92
>>350
あるあるw
あるあるw
353 :仕様書無しさん2012/04/13(金) 23:05:38.21
hoge == 0 でも 0 == hoge でも何とかなるのだが、
hoge == 0 で統一されたソースに 0 == hoge で
追加修正された時はイラッつとした
hoge == 0 で統一されたソースに 0 == hoge で
追加修正された時はイラッつとした
358 :仕様書無しさん2012/04/14(土) 01:47:16.66
100%ミスしない人間が存在しているという前提がもう頭おかしいだろ。
0==hogeが見難いのは単なる慣れ。
オレの気に入る書き方以外はクソとかどんだけ自己中なのか。
0==hogeが見難いのは単なる慣れ。
オレの気に入る書き方以外はクソとかどんだけ自己中なのか。
364 :仕様書無しさん2012/04/14(土) 05:24:52.86
>>358
スレタイ読め
スレタイ読め
362 :仕様書無しさん2012/04/14(土) 04:40:43.71
0==hogeって書く奴は定数がdefineされててもFUGA==hugeってやるんだよな。キモイ…
つか、==じゃない比較演算子もそうすんの?HOME>=hageとか。==だけ?
つか、==じゃない比較演算子もそうすんの?HOME>=hageとか。==だけ?
363 :仕様書無しさん2012/04/14(土) 05:22:19.96
>>362
不等号に関しては、複数並ぶときに向きを揃えるっていう
数学的なお約束があるんで、それに合わせることも多いんじゃね。
定数1 <= 変数A && 変数A <= 定数2
みたいに。
不等号に関しては、複数並ぶときに向きを揃えるっていう
数学的なお約束があるんで、それに合わせることも多いんじゃね。
定数1 <= 変数A && 変数A <= 定数2
みたいに。
366 :仕様書無しさん2012/04/14(土) 09:10:49.83
それは慣れていない所だから有効なんだろう。
違和感が無くなるほど使用されている現場ならミス防止には役に立たない。
削除の時の確認ダイアログと同じ話。
違和感が無くなるほど使用されている現場ならミス防止には役に立たない。
削除の時の確認ダイアログと同じ話。
367 :仕様書無しさん2012/04/14(土) 09:28:16.94
>365
>本質的に「わざと違和感を抱かせてミスを防ぐ」トリックだから
>やむをえないかもしれない
そんな理由付けが許されるならば、
int func0005()
とかも許されるな。
「これも、わざと違和感をもたらせてミスを防ぐトリックですよ」とか
「関数名がもたらす思い込みを排することでミスを防いでいます」とか。
>本質的に「わざと違和感を抱かせてミスを防ぐ」トリックだから
>やむをえないかもしれない
そんな理由付けが許されるならば、
int func0005()
とかも許されるな。
「これも、わざと違和感をもたらせてミスを防ぐトリックですよ」とか
「関数名がもたらす思い込みを排することでミスを防いでいます」とか。
368 :仕様書無しさん2012/04/14(土) 09:38:57.26
>>367
違和感を抱かせて「あぁ。そういうことね」と思い出させる。
0==hogeを見れば、「hogeに代入しないように」ということを思い出す。
さて、int func0005()
違和感は感じるが、肝心の「思い出す」ことはなんだ?
違和感を抱かせて「あぁ。そういうことね」と思い出させる。
0==hogeを見れば、「hogeに代入しないように」ということを思い出す。
さて、int func0005()
違和感は感じるが、肝心の「思い出す」ことはなんだ?
371 :仕様書無しさん2012/04/14(土) 10:56:45.31
>>368
「動作を知りたければ仕様書にあたれ」とか?
「動作を知りたければ仕様書にあたれ」とか?
381 :仕様書無しさん2012/04/14(土) 13:53:02.05
>>368
>違和感は感じるが、肝心の「思い出す」ことはなんだ?
一言では言い表せない、その関数の振る舞い全て。
>>371
その通り。
>違和感は感じるが、肝心の「思い出す」ことはなんだ?
一言では言い表せない、その関数の振る舞い全て。
>>371
その通り。
382 :仕様書無しさん2012/04/14(土) 14:06:32.51
>>381
そう思うならプログラムなんて適当に書けば?
ここにいる必要ないし、この板にいる必要もない。
プログラマ辞めちまえよ。
そう思うならプログラムなんて適当に書けば?
ここにいる必要ないし、この板にいる必要もない。
プログラマ辞めちまえよ。
383 :仕様書無しさん2012/04/14(土) 14:11:37.03
>>381
真性の馬鹿だな。死んで欲しい。
真性の馬鹿だな。死んで欲しい。
384 :仕様書無しさん2012/04/14(土) 14:25:13.34
>>381
> 一言では言い表せない
じゃあダメだろw
一言で言い表せることが重要なんだから。
> 一言では言い表せない
じゃあダメだろw
一言で言い表せることが重要なんだから。
386 :仕様書無しさん2012/04/14(土) 17:15:42.21
>>382-384
お前は何と戦っているんだ?
お前は何と戦っているんだ?
395 :仕様書無しさん2012/04/14(土) 19:18:26.96
>>381は敢えて仕様書を読ませる為に
プログラムを読みにくくすると言ってるんだぞ。
まるでコボラーだな。
プログラムを読みにくくすると言ってるんだぞ。
まるでコボラーだな。
398 :仕様書無しさん2012/04/14(土) 22:32:45.64
>>395
もう関数名を「仕様書嫁123」とかにすればいいのに。
もう関数名を「仕様書嫁123」とかにすればいいのに。
402 :仕様書無しさん2012/04/14(土) 22:54:21.47
>>395
有象無象のソルジャーというか土方というか、そういうのを束ねて開発する
方法論としてはアリだと思うがな。やらされる立場になったら負けということで。
有象無象のソルジャーというか土方というか、そういうのを束ねて開発する
方法論としてはアリだと思うがな。やらされる立場になったら負けということで。
369 :仕様書無しさん2012/04/14(土) 09:52:09.53
hogeには代入してもいいんじゃないの?
代入したくないんだったらconstでも付けとけばいい話では。
(言語によってはできないのもあるのかな)
代入したくないんだったらconstでも付けとけばいい話では。
(言語によってはできないのもあるのかな)
370 :仕様書無しさん2012/04/14(土) 10:27:21.14
if( 0 == hoge ) はほとんどお目にかかった事無いから気にして無い。
if( hoge = 0 ) はWarning出てるのに放置されてたのをこの前見かけた。
Warning出てるのにコミットする奴にイラッつとする。
if( hoge = 0 ) はWarning出てるのに放置されてたのをこの前見かけた。
Warning出てるのにコミットする奴にイラッつとする。
378 :仕様書無しさん2012/04/14(土) 12:53:40.47
他の言語と違って、標準的なコーディングスタイルってものがないから。
380 :仕様書無しさん2012/04/14(土) 13:11:52.79
比較演算に順序が決まってる言語なんてそもそも有っただろうか
385 :仕様書無しさん2012/04/14(土) 17:06:28.29
イラッつとした相手が上司だったり先輩だったりすると何て言えばいいかわからない
387 :仕様書無しさん2012/04/14(土) 17:17:27.90
>>385
イラッとしたら何か言わなくてはいけないという
法律でもあるのか?
イラッとしたら何か言わなくてはいけないという
法律でもあるのか?
393 :仕様書無しさん2012/04/14(土) 18:28:55.84
>>386
イラッつとしたら人に当たり散らすタイプなんだろう。
>>385
言い返す権利はないのよ?(´・ω・`)
イラッつとしたら人に当たり散らすタイプなんだろう。
>>385
言い返す権利はないのよ?(´・ω・`)
388 :仕様書無しさん2012/04/14(土) 17:23:41.06
普通イラッてしたら
イラって言うだろ?
昨日も満員電車で
イラって何回も言ったわ
イラって言うだろ?
昨日も満員電車で
イラって何回も言ったわ
390 :仕様書無しさん2012/04/14(土) 17:59:30.27
>>388
うわーキモいw
そういう中二病のやついたなー学生の時w
うわーキモいw
そういう中二病のやついたなー学生の時w
391 :仕様書無しさん2012/04/14(土) 18:25:54.65
>>388
言わねえよww
言わねえよww
389 :仕様書無しさん2012/04/14(土) 17:30:20.61
昔ある中華料理のチェーン店でバイトしてたせいか
内装の同じ店に行くと新しい客が来たとき「イラッ」って言ってしまう
内装の同じ店に行くと新しい客が来たとき「イラッ」って言ってしまう
394 :仕様書無しさん2012/04/14(土) 18:54:49.16
>>389
しゃーせー
しゃーせー
396 :仕様書無しさん2012/04/14(土) 20:06:14.10
ソース暗号化しといて、readmeに「複合鍵は仕様書の中に隠されているよ!頑張ってね☆ミ」で解決
397 :仕様書無しさん2012/04/14(土) 21:10:03.59
while (GetMessage(&message, 0, 0, 0) > 0) { }
が
while( 0 < GetMessage( &message, 0, 0, 0 ) ){}
になるだけで仕様書読まなきゃならんのか
が
while( 0 < GetMessage( &message, 0, 0, 0 ) ){}
になるだけで仕様書読まなきゃならんのか
399 :仕様書無しさん2012/04/14(土) 22:37:11.11
コンパイルしてしまえばコーディングスタイルなんて気にしなくてもよくなるだろ
401 :仕様書無しさん2012/04/14(土) 22:44:20.94
コンパイルした後のコードを読んで修正してメンテナンスし続けるのならそうかもなw
405 :仕様書無しさん2012/04/15(日) 15:19:30.14
if (VeryLongoLongFunctionName(var1,var2,var3,var4) > 3)
みたいにクソ長い名称と比較するときは、定数を左辺に置いたほうが見やすい。
みたいにクソ長い名称と比較するときは、定数を左辺に置いたほうが見やすい。
406 :仕様書無しさん2012/04/15(日) 15:26:58.70
int value = VeryLongoLongFunctionName(var1,var2,var3,var4);
if (value > 3)
こうすればいいだけ
if (value > 3)
こうすればいいだけ
411 :仕様書無しさん2012/04/15(日) 19:29:26.29
>>406
いちいち変数に入れるなよイラッとする
いちいち変数に入れるなよイラッとする
412 :仕様書無しさん2012/04/15(日) 19:33:24.86
>>411
デバッガ使わない (使えない) 人特有の症状だね>一時変数を嫌う
デバッガ使わない (使えない) 人特有の症状だね>一時変数を嫌う
408 :仕様書無しさん2012/04/15(日) 15:46:23.75
引数が多くて横に長くなる時にどう書いたら見やすいかでイラッつとする。
func( var1,
var2,
var3 );
funcがやたら長い名前だと何か変な感じになるしで困る。
func( var1,
var2,
var3 );
funcがやたら長い名前だと何か変な感じになるしで困る。
409 :仕様書無しさん2012/04/15(日) 16:19:41.22
func( val1, val2, val3, val4,
val5, val6, val7, val8) {
}
って書けばいいだけ
val5, val6, val7, val8) {
}
って書けばいいだけ
410 :仕様書無しさん2012/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();
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();
414 :仕様書無しさん2012/04/15(日) 20:06:06.00
>>409
こいつ馬鹿
>>410
何回も変数書いてバカっぽい。
どんだけタイピング好きなの?
こいつ馬鹿
>>410
何回も変数書いてバカっぽい。
どんだけタイピング好きなの?
417 :仕様書無しさん2012/04/15(日) 20:33:53.56
>>414
うん、それで?
続き言わないとお前が恥をかくよ。
うん、それで?
続き言わないとお前が恥をかくよ。
418 :仕様書無しさん2012/04/15(日) 20:39:41.62
>>414は構造体に入れて渡すと言いだす
413 :仕様書無しさん2012/04/15(日) 19:56:25.02
おまえがいってるのは一時変数じゃないだろ
それはともかく、whileやifの条件ならどっちの分岐に進んだか、
ループを抜けたか抜けないかで判断できる。
それによほどしょぼいデバッガーじゃなけりゃ戻り値確認できるし。
それはともかく、whileやifの条件ならどっちの分岐に進んだか、
ループを抜けたか抜けないかで判断できる。
それによほどしょぼいデバッガーじゃなけりゃ戻り値確認できるし。
419 :仕様書無しさん2012/04/15(日) 20:41:52.50
構造体にいれたら
関数のインターフェース変わるじゃんw
関数のインターフェース変わるじゃんw
422 :仕様書無しさん2012/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);
}
こうなります。これがカリー化ですw
カリー化がわからない人へ。
class Foo {
Foo(x, y, z);
}
↓Foo(コンストラクタ)をカリー化すると
class Foo {
Foo(x, y) { Foo(x, y, 1) }
Foo(x, y, z);
}
こうなります。これがカリー化ですw
425 :仕様書無しさん2012/04/15(日) 21:04:36.87
>>422
違うだろ。
これだよ。
void foo(x, y, z)
↓ カリー化
#define foo1(x, y) foo(x, y, 1)
関数fooの引数のいくつかを埋めた、
”新しい関数を作る”こと
違うだろ。
これだよ。
void foo(x, y, z)
↓ カリー化
#define foo1(x, y) foo(x, y, 1)
関数fooの引数のいくつかを埋めた、
”新しい関数を作る”こと
426 :仕様書無しさん2012/04/15(日) 21:09:58.81
>>425
変わらんだろ
変わらんだろ
427 :仕様書無しさん2012/04/15(日) 21:13:27.79
つかいま出てるのってカリー化モドキだよな
F(1, 2, 3, 4, 5);
F(1)(2)(3)(4, 5);
本来のカリー化なら呼び出し方を変えられるだけ
新しい関数を定義する必要はない
1つ関数を定義すれば自動で2通りの書き方ができる
F(1, 2, 3, 4, 5);
F(1)(2)(3)(4, 5);
本来のカリー化なら呼び出し方を変えられるだけ
新しい関数を定義する必要はない
1つ関数を定義すれば自動で2通りの書き方ができる
428 :仕様書無しさん2012/04/15(日) 21:37:46.36
>>427
ほう、それは便利だ!
なにが?
ほう、それは便利だ!
なにが?
429 :仕様書無しさん2012/04/15(日) 21:47:58.06
F(1, 2, 3, 4, 5);
F(1)(2)(3)(4, 5);
単に数学の概念上この2つが別である事がおかしいって話だよな
プログラム的にはこれが出来るとアダプター作る手間が省けて格段に楽になるんだが
F(1)(2)(3)(4, 5);
単に数学の概念上この2つが別である事がおかしいって話だよな
プログラム的にはこれが出来るとアダプター作る手間が省けて格段に楽になるんだが
430 :仕様書無しさん2012/04/15(日) 22:01:57.19
実際にはアダプタ作るとか
ラッパー関数作れば終わりなんだけどな。
ラッパー関数作れば終わりなんだけどな。
432 :仕様書無しさん2012/04/15(日) 22:48:31.36
引数の多い関数が嫌だ。
引数が多いだけならともかく、多機能にして省略可能な引数を作るクズを絞め殺したい。
引数が多いだけならともかく、多機能にして省略可能な引数を作るクズを絞め殺したい。
433 :仕様書無しさん2012/04/16(月) 00:22:40.42
「コーディングスタイル」以外の話はスレ違いですよ莫迦共。
435 :仕様書無しさん2012/04/18(水) 14:38:45.93
int GetSize()という関数を使うのに
if (!GetSize()) {
…
}
if (!GetSize()) {
…
}
436 :仕様書無しさん2012/04/18(水) 15:37:32.74
>>435
ああ、これはイラッつとするな
ああ、これはイラッつとするな
437 :仕様書無しさん2012/04/18(水) 19:50:50.31
>>435
Javaで、java.beansを使うわけでもなく、
それどころかCかC++なのにいちいちGet付けてんのがイラッとする。
Qtやらboostみたいにobject.Size();か、〜Size( object );でいいだろうに。
Javaで、java.beansを使うわけでもなく、
それどころかCかC++なのにいちいちGet付けてんのがイラッとする。
Qtやらboostみたいにobject.Size();か、〜Size( object );でいいだろうに。
438 :仕様書無しさん2012/04/18(水) 21:35:43.22
>>437には同意
だが、
if (! foo.size()) {
// fooが空でないときの処理
}
の書き方は全く問題なし
だが、
if (! foo.size()) {
// fooが空でないときの処理
}
の書き方は全く問題なし
439 :仕様書無しさん2012/04/18(水) 21:50:25.96
え?
>>438
コメントかコードのどちらかが間違ってるんじゃね?
>>438
コメントかコードのどちらかが間違ってるんじゃね?
440 :仕様書無しさん2012/04/18(水) 23:13:07.07
>>439
そのsize()はboolean型で、オブジェクトが空のときにtrueを返すという仕様という罠。
そのsize()はboolean型で、オブジェクトが空のときにtrueを返すという仕様という罠。
441 :仕様書無しさん2012/04/18(水) 23:15:14.67
>>435
とりあえず、Gが大文字なのがイラッつとする
とりあえず、Gが大文字なのがイラッつとする
442 :仕様書無しさん2012/04/18(水) 23:26:48.71
それは言語によって推奨されとる命名規則が違うんでなんとも
443 :仕様書無しさん2012/04/19(木) 07:03:01.65
Type.newと書ける言語でもないのに
関数名のキャメルケースがコンストラクターの
キャメルケースと違うのがイラッとする
const Example &object = Type();
const Example &object = Function();
関数名のキャメルケースがコンストラクターの
キャメルケースと違うのがイラッとする
const Example &object = Type();
const Example &object = Function();
444 :仕様書無しさん2012/04/20(金) 05:38:44.65
どうでもいいが、
for (i = 0; i < point; i++) {...}
は許せるが、
for (i = 0; point > i; i++) {...}
はイラッとくる。
あと、K&Rスタイルじゃないコーディングもイラッと来るおっさんですが。
for (i = 0; i < point; i++) {...}
は許せるが、
for (i = 0; point > i; i++) {...}
はイラッとくる。
あと、K&Rスタイルじゃないコーディングもイラッと来るおっさんですが。
447 :仕様書無しさん2012/04/20(金) 19:59:13.79
見やすく書く、
呼び出し構造を追いかけやすくする
インデントを揃える
こういう書き方ができない奴は
プログラマに向いていない。
美意識が無いやつは消えろ。
呼び出し構造を追いかけやすくする
インデントを揃える
こういう書き方ができない奴は
プログラマに向いていない。
美意識が無いやつは消えろ。
448 :仕様書無しさん2012/04/20(金) 20:04:12.06
hoge禁止
fooは許せるがhogeはイラッつとする俺だが、表立ってhogeを禁じられるのはそれはそれでイラッつとする
fooは許せるがhogeはイラッつとする俺だが、表立ってhogeを禁じられるのはそれはそれでイラッつとする
450 :仕様書無しさん2012/04/20(金) 23:55:09.79
>>448
お前hageだな?w
お前hageだな?w
455 :仕様書無しさん2012/04/21(土) 18:57:29.69
a.set(b.getHoge())
こういう戻り値を直接引数に渡しているコード
デバッグしずらいんだよね
こういう戻り値を直接引数に渡しているコード
デバッグしずらいんだよね
456 :仕様書無しさん2012/04/21(土) 19:43:40.18
どうすべきだと思う?
いったん器に入れてから食う?
いったん器に入れてから食う?
462 :仕様書無しさん2012/04/22(日) 19:02:15.91
>>456
戻り値を表示できるデバッガを使うのが一番楽
戻り値を表示できるデバッガを使うのが一番楽
459 :仕様書無しさん2012/04/21(土) 22:53:11.51
デバッガ使わないやつはまったく使わないからな。
オレなら一時変数に1度いれるようにする。
オレなら一時変数に1度いれるようにする。
463 :仕様書無しさん2012/04/22(日) 19:29:33.48
int getHoge(){ return Fuga; }
ってのがヘッダに書いてあってもデバッグし辛い時があるけど、諦めてる。
ってのがヘッダに書いてあってもデバッグし辛い時があるけど、諦めてる。
464 :仕様書無しさん2012/04/22(日) 21:44:00.17
それはインライン展開があるからしょうがない。
でも行を分けてないとデバッグしにくいよね。使わないやつには判らんだろうが。
でも行を分けてないとデバッグしにくいよね。使わないやつには判らんだろうが。
471 :仕様書無しさん2012/04/23(月) 08:01:12.26
>>464
コンパイラにまかせろよ
ライブラリとして外部に譲渡すること考えたらキモチ悪いだろ
コンパイラにまかせろよ
ライブラリとして外部に譲渡すること考えたらキモチ悪いだろ
466 :仕様書無しさん2012/04/23(月) 00:33:12.37
一時変数にいれる一手間を加えると美味しいソースが出来るの?
同じ味が出せるなら手抜きした方がいいと思うんだけど。
同じ味が出せるなら手抜きした方がいいと思うんだけど。
467 :仕様書無しさん2012/04/23(月) 00:38:58.96
> 一時変数にいれる一手間を加えると美味しいソースが出来るの?
簡単に味見ができる。
簡単に味見ができる。
469 :仕様書無しさん2012/04/23(月) 04:46:41.50
そんなに手間っていうより、無駄な手間って感じ。
関数名が正しければ一時変数にいれない方が文章として読みやすいし。
あと、処理系によつまては処理が早そうだし。
と書いたけど、俺も一時変数にいれた方がその後のコードが読みやすくなる場合は一時変数にいれてるな。
入れる入れないの判断基準が「デバッグ出力しやすいか」ってのと「読みやすいか」ってのとの違いか。
関数名が正しければ一時変数にいれない方が文章として読みやすいし。
あと、処理系によつまては処理が早そうだし。
と書いたけど、俺も一時変数にいれた方がその後のコードが読みやすくなる場合は一時変数にいれてるな。
入れる入れないの判断基準が「デバッグ出力しやすいか」ってのと「読みやすいか」ってのとの違いか。
470 :仕様書無しさん2012/04/23(月) 07:43:18.44
副作用を消せば返ってくる値が同じなので変数に入れる必要すらなくて
ただ関数の結果をピークすればいい。
ただ関数の結果をピークすればいい。
472 :仕様書無しさん2012/04/23(月) 13:55:23.45
一時変数に入れるのはいいが、temp だの value だの ret なんて名前だったり、const つけてなかったりしてるとイラッつとする。
473 :仕様書無しさん2012/04/23(月) 22:00:40.40
>>472
そんな奴が一時変数の効能考えて使ってるとは思えないわw
そんな奴が一時変数の効能考えて使ってるとは思えないわw
474 :仕様書無しさん2012/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() ) );
名前考えるのマンドクセ
template<class type> type &Check( type &value )
{
return value;
}
template<class type> const type &Check( const type &value )
{
return value;
}
FunctionB( Check( FunctionA() ) );
475 :仕様書無しさん2012/04/23(月) 22:44:57.33
>>474
そうするくらいならFunctionAの結果を直接見るよね
そうするくらいならFunctionAの結果を直接見るよね
478 :仕様書無しさん2012/04/24(火) 10:32:44.75
>>474
これはイラッとするわ
これはイラッとするわ
476 :仕様書無しさん2012/04/23(月) 23:11:32.50
今どき戻り値が見れないデバッガとか何を使ってるの?
16bit環境?
16bit環境?
479 :仕様書無しさん2012/04/27(金) 18:52:57.59
if(!strcmp(foo,bar)){
482 :仕様書無しさん2012/04/28(土) 11:01:56.73
>>479
ふつーに使う
ふつーに使う
480 :仕様書無しさん2012/04/27(金) 21:16:24.59
strcmpが真偽値を結果とするような関数じゃないから不自然だね。仕方ないね。
484 :仕様書無しさん2012/04/28(土) 13:21:59.68
>>480
真偽値などという型がないCが不自然なのであって
Cとしてはあれで正しい、といえなくもない。
真偽値などという型がないCが不自然なのであって
Cとしてはあれで正しい、といえなくもない。
486 :仕様書無しさん2012/04/28(土) 14:40:19.32
>>484
不自然か?真偽値なんて、真偽値がオブジェクトだったり、
オーバーロードが必要と言う理由じゃなければ独立した型である必要ないだろ
単なる名前付けした定数で充分なぐらいじゃん
不自然か?真偽値なんて、真偽値がオブジェクトだったり、
オーバーロードが必要と言う理由じゃなければ独立した型である必要ないだろ
単なる名前付けした定数で充分なぐらいじゃん
485 :仕様書無しさん2012/04/28(土) 13:36:00.81
strequal関数を作ればいいだけの話
どちらが大きいか比較して
真だった場合。
意味がわからないだろ。
if(strcmp(a,b)) とはそのように読む。
どうしてもstrcmpを使いたいなら==0とするのが正解。
0をSTRMATCHと定義し、==STRMATCHとするのがベター
どちらが大きいか比較して
真だった場合。
意味がわからないだろ。
if(strcmp(a,b)) とはそのように読む。
どうしてもstrcmpを使いたいなら==0とするのが正解。
0をSTRMATCHと定義し、==STRMATCHとするのがベター
487 :仕様書無しさん2012/04/28(土) 14:42:23.28
真偽値という別の名前を与えている以上
別のものであると我々人間が解釈しているのですよ。
コンピュータに合わせない。
人間に合わせる。
別のものであると我々人間が解釈しているのですよ。
コンピュータに合わせない。
人間に合わせる。
490 :仕様書無しさん2012/04/28(土) 15:07:33.70
外国人にはこのように見えています
もし(文字列比較(a,b)の否定) なら
もし(文字列比較(a,b)の否定) なら
491 :仕様書無しさん2012/04/28(土) 15:17:02.25
コードかきなれてるやつで、自然言語に近づけたいと
思ってるヤツなんてほとんど居ないだろ
慣れて気になるのは合理的か、回りくどくないか(考える手間が増えないか)
ぐらいだろ
思ってるヤツなんてほとんど居ないだろ
慣れて気になるのは合理的か、回りくどくないか(考える手間が増えないか)
ぐらいだろ
492 :仕様書無しさん2012/04/28(土) 15:21:04.96
じゃあなんで関数名、変数名、キーワードは
英語なんですか?
英語=自然言語ですよ。
英語なんですか?
英語=自然言語ですよ。
493 :仕様書無しさん2012/04/28(土) 15:24:41.47
>>492
名前だけだろ
文章の体をなしてない
名前だけだろ
文章の体をなしてない
495 :仕様書無しさん2012/04/28(土) 15:24:59.39
>>492
英語じゃなくてもいいけど
英語じゃなくてもいいけど
496 :仕様書無しさん2012/04/28(土) 15:26:26.29
>>493
でも、名前は英語ですよね。
その名前から連想できるものは何でしょうか?
そこは変わらなはずですが。
むしろ、自然言語から連想できるように
キーワードを選んでいるわけだけど。
でも、名前は英語ですよね。
その名前から連想できるものは何でしょうか?
そこは変わらなはずですが。
むしろ、自然言語から連想できるように
キーワードを選んでいるわけだけど。
498 :仕様書無しさん2012/04/28(土) 15:28:31.58
>>493
Javaなどでは、オブジェクト.動詞目的語
という命名規則が普通ですね。
Javaなどでは、オブジェクト.動詞目的語
という命名規則が普通ですね。
499 :仕様書無しさん2012/04/28(土) 15:50:55.83
>>496
日本語でも、イスラム語でもフランス語でもいいぞ。
日本語でも、イスラム語でもフランス語でもいいぞ。
500 :仕様書無しさん2012/04/28(土) 15:53:58.39
>>496
構文に自然言語を求めてないと言ってるんだが。
大体、Unixのソースコードとか英語名称に準拠してるか?
アルファベット使ってるだけで略語だらけじゃねぇか。
アルファベット使ってりゃ自然言語だというなら、そりゃ全部自然言語だろうよ。
構文に自然言語を求めてないと言ってるんだが。
大体、Unixのソースコードとか英語名称に準拠してるか?
アルファベット使ってるだけで略語だらけじゃねぇか。
アルファベット使ってりゃ自然言語だというなら、そりゃ全部自然言語だろうよ。
503 :仕様書無しさん2012/04/28(土) 16:05:57.41
>>500
> 構文に自然言語を求めてないと言ってるんだが。
あなたわかってるじゃないですかw
自然言語を求めてないのは構文でしょう?
単語には自然言語を求めてるんですよ。
> 構文に自然言語を求めてないと言ってるんだが。
あなたわかってるじゃないですかw
自然言語を求めてないのは構文でしょう?
単語には自然言語を求めてるんですよ。
505 :仕様書無しさん2012/04/28(土) 16:22:10.58
>>492 は、「アルファベット」を見ると「英語」と言ってしまう
ローマ字未修得の小学生、あるいは戦中派に違いない。
ローマ字未修得の小学生、あるいは戦中派に違いない。
506 :仕様書無しさん2012/04/28(土) 16:25:09.14
>>505
え? 普通言語って英語を元にしてるでしょw
え? 普通言語って英語を元にしてるでしょw
508 :仕様書無しさん2012/04/28(土) 16:32:49.85
>>506
UKとUSAの人間が読めなくても英語なのか?
UKとUSAの人間が読めなくても英語なのか?
535 :仕様書無しさん2012/04/28(土) 17:13:37.49
>>534
俺は最初から構文は英語じゃないからコードが英文に準じる必要はないと言っている
まぁ、>>500で余計なことは書いたが。
俺は最初から構文は英語じゃないからコードが英文に準じる必要はないと言っている
まぁ、>>500で余計なことは書いたが。
494 :仕様書無しさん2012/04/28(土) 15:24:54.62
if(!strcmp(foo,bar)){
これで、実効時間が一クロックでも違うのなら意味があると思うけど、
== 0 と変わらないのであれば、採用するメリットがない。
これで、実効時間が一クロックでも違うのなら意味があると思うけど、
== 0 と変わらないのであれば、採用するメリットがない。
497 :仕様書無しさん2012/04/28(土) 15:28:25.70
例えばifという名前が、繰り返すという意味だったりしたら
わけがわからないことになる。
そんな事するぐらいなら、ifもforもやめて、
A01、B02 とかいうキーワードの方がまだまし。
でもそうしないで、ifという単語を割り当てているというのは、
ifという単語の本来の意味が重要だってこと。
わけがわからないことになる。
そんな事するぐらいなら、ifもforもやめて、
A01、B02 とかいうキーワードの方がまだまし。
でもそうしないで、ifという単語を割り当てているというのは、
ifという単語の本来の意味が重要だってこと。
501 :仕様書無しさん2012/04/28(土) 16:00:09.18
馬鹿って絶対に自分の非を認めないよね
故に馬鹿なのか
故に馬鹿なのか
502 :仕様書無しさん2012/04/28(土) 16:04:07.16
英語で書いてある部分なんて機能が解るシンボルとしてしか見ないな
言語自体が英語らしいかどうかなんてどうでもいいや
COBOL見たいなの見せられたら吐き気がするし
言語自体が英語らしいかどうかなんてどうでもいいや
COBOL見たいなの見せられたら吐き気がするし
507 :仕様書無しさん2012/04/28(土) 16:27:30.60
俺の大得意な言語は
日本語を元にしてますよ。
なんてなーwwww
日本語を元にしてますよ。
なんてなーwwww
509 :仕様書無しさん2012/04/28(土) 16:33:55.58
>508
if が読めないのですか?
if が読めないのですか?
513 :仕様書無しさん2012/04/28(土) 16:36:21.62
>>509
"if"だけじゃなぁ。interfaceの略かもしれんし、
イタリア語かもしれんし、フランス語かもしれんし。
"if"だけじゃなぁ。interfaceの略かもしれんし、
イタリア語かもしれんし、フランス語かもしれんし。
515 :仕様書無しさん2012/04/28(土) 16:38:06.09
>>509
ifとかdefaultとか予約語じゃない言語もいっぱいあるぞ
関数型系とかSmalltalkの派生とか
ifとかdefaultとか予約語じゃない言語もいっぱいあるぞ
関数型系とかSmalltalkの派生とか
516 :仕様書無しさん2012/04/28(土) 16:38:10.51
>>513
英語と考えれば辻褄が合うでしょw
だからほとんどの言語=英語が元になっているわけです。
英語と考えれば辻褄が合うでしょw
だからほとんどの言語=英語が元になっているわけです。
517 :仕様書無しさん2012/04/28(土) 16:39:29.02
>>516
if( a == b )
これをよめるヤツはプログラマーぐらいだろ
if( a == b )
これをよめるヤツはプログラマーぐらいだろ
518 :仕様書無しさん2012/04/28(土) 16:40:07.42
>>515
予約語かどうかは本質じゃねーw
プログラム言語はほとんど英単語が
元になってるってことだろ。
英単語そのものか、英単語の略語ばかりだ。
よってコーディングする時は
英語の意味を考えなさいということ。
予約語かどうかは本質じゃねーw
プログラム言語はほとんど英単語が
元になってるってことだろ。
英単語そのものか、英単語の略語ばかりだ。
よってコーディングする時は
英語の意味を考えなさいということ。
519 :仕様書無しさん2012/04/28(土) 16:41:12.04
>>517
ifが英語だからプログラマーは読めるよね。
gtaweg( a == b)
これ、読めるかい?
ifが英語だからプログラマーは読めるよね。
gtaweg( a == b)
これ、読めるかい?
520 :仕様書無しさん2012/04/28(土) 16:41:29.02
>>518
cat と cdr はどういう意味?
cat と cdr はどういう意味?
521 :仕様書無しさん2012/04/28(土) 16:42:12.07
>>519
言語仕様読めば解るんじゃね?
言語仕様読めば解るんじゃね?
522 :仕様書無しさん2012/04/28(土) 16:43:51.60
>>519
プログラマー外の英語圏の人間はすぐ解らんだろうと
いう意味で書いたんだが
プログラマー外の英語圏の人間はすぐ解らんだろうと
いう意味で書いたんだが
524 :仕様書無しさん2012/04/28(土) 16:44:53.93
>>522
そりゃそうだろ。
そんな話はしていない。
ほとんどのプログラム言語は
英語が元になってることに異論はないね?
そりゃそうだろ。
そんな話はしていない。
ほとんどのプログラム言語は
英語が元になってることに異論はないね?
526 :仕様書無しさん2012/04/28(土) 16:48:37.26
>>524
COBOLレベルなら英語が元になってるとは言えるかもしれんが
シンボルだけ英語使ってるものを英語が元になってると言われると
違和感が有るぞ
COBOLレベルなら英語が元になってるとは言えるかもしれんが
シンボルだけ英語使ってるものを英語が元になってると言われると
違和感が有るぞ
511 :仕様書無しさん2012/04/28(土) 16:34:34.45
TSUNAMI, HENTAIは英語だけど
Heigh Visionは日本語という不思議。
Heigh Visionは日本語という不思議。
514 :仕様書無しさん2012/04/28(土) 16:36:57.36
>>511
英語わからないならムリしないほうがいいよw
英語わからないならムリしないほうがいいよw
512 :仕様書無しさん2012/04/28(土) 16:35:51.86
英語が分かる人
「strcmpって何?」
「string compare の略だよ」
「なるほど!」
「strcmpって何?」
「string compare の略だよ」
「なるほど!」
523 :仕様書無しさん2012/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
Contents of the Address part of Register number
Contents of the Decrement part of Register number
525 :仕様書無しさん2012/04/28(土) 16:45:31.86
>>523
やっぱりcatやcdrも英語の略なんだね。
やっぱりcatやcdrも英語の略なんだね。
527 :仕様書無しさん2012/04/28(土) 16:49:23.26
> シンボルだけ英語使ってる
あ、認めたw
シンボルだけじゃなくて
意味も英語の意味を使ってる。
あ、認めたw
シンボルだけじゃなくて
意味も英語の意味を使ってる。
530 :仕様書無しさん2012/04/28(土) 16:59:31.80
>>527
俺は構文が英語じゃないから、言語全体は自然言語に近い必要はないと
いう意味でしかレスしてない。名前云々のレスといっしょにすんな。
俺は構文が英語じゃないから、言語全体は自然言語に近い必要はないと
いう意味でしかレスしてない。名前云々のレスといっしょにすんな。
533 :仕様書無しさん2012/04/28(土) 17:06:08.67
>>530
俺は単語が英語だから
その英語の通りの使い方をしろと言ってる。
俺は単語が英語だから
その英語の通りの使い方をしろと言ってる。
528 :仕様書無しさん2012/04/28(土) 16:51:22.35
文法は英語じゃなくが
単語は英単語だし
意味も英単語だ。
なのだからその意味に当てはまらない使い方をしたらダメ。
単語は英単語だし
意味も英単語だ。
なのだからその意味に当てはまらない使い方をしたらダメ。
529 :仕様書無しさん2012/04/28(土) 16:56:57.83
>>528
> 意味も英語だけど
int 変数 = 0;
classs Type { public Type(){} }
英語の意味でどう読むんだ?
> 意味も英語だけど
int 変数 = 0;
classs Type { public Type(){} }
英語の意味でどう読むんだ?
531 :仕様書無しさん2012/04/28(土) 17:04:57.39
>>529
変数は日本語ですが?
int ・・・ integerの略。なるほど整数か!
class ・・・種類
Type・・・型
public・・・公開
英語だと考えれば、辻づまがあう。
変数は日本語ですが?
int ・・・ integerの略。なるほど整数か!
class ・・・種類
Type・・・型
public・・・公開
英語だと考えれば、辻づまがあう。
532 :仕様書無しさん2012/04/28(土) 17:05:54.91
>>531
単語の意味じゃなく英文として読めよ
単語の意味じゃなく英文として読めよ
534 :仕様書無しさん2012/04/28(土) 17:07:24.65
>>532
なぜ英文として読まないといけないの?
俺は最初から構文は英語じゃないが
単語が英語であり、
その意味のとおりに使えと言ってるだけですが?
なぜ英文として読まないといけないの?
俺は最初から構文は英語じゃないが
単語が英語であり、
その意味のとおりに使えと言ってるだけですが?
537 :仕様書無しさん2012/04/28(土) 17:15:57.31
英単語の意味を無視していいなら、
英単語を使う理由はない。
英単語を使う理由はない。
538 :仕様書無しさん2012/04/28(土) 17:19:33.03
名前と構文をごっちゃにするなって
ダンボールに英語のラベルはってあったら、
ダンボールが英語に準拠してんのかよ
ダンボールに英語のラベルはってあったら、
ダンボールが英語に準拠してんのかよ
539 :仕様書無しさん2012/04/28(土) 17:21:25.05
そうですが何か
541 :仕様書無しさん2012/04/28(土) 17:28:03.72
>>539
XSLTとXMLの仕様をごっちゃにしてそうな発言だな
XSLTとXMLの仕様をごっちゃにしてそうな発言だな
542 :仕様書無しさん2012/04/28(土) 17:30:35.83
多分最近のaviにはH.264が入ってることが多いから
>>539にとってaviはH.264がなんだろうな
>>539にとってaviはH.264がなんだろうな
540 :仕様書無しさん2012/04/28(土) 17:21:47.37
つられて英語と書いてしまったが
そもそも、自然言語に準じる必要が無いといだけで
英語かどうかは重要じゃないだろ。
そもそも、自然言語に準じる必要が無いといだけで
英語かどうかは重要じゃないだろ。
543 :仕様書無しさん2012/04/28(土) 18:55:32.75
ダンボールの中身が英語に準拠しているかもしれないと期待することは出来るかな
544 :仕様書無しさん2012/04/28(土) 20:41:52.10
プログラムは自然言語ではないが
自然言語に似せて書くのが上手い書き方だろ。
何故なら、コンピュータが読むものであると同時に、人間が読むものでもあるからだ。
自然言語に似せて書くのが上手い書き方だろ。
何故なら、コンピュータが読むものであると同時に、人間が読むものでもあるからだ。
545 :仕様書無しさん2012/04/28(土) 21:33:26.78
>>544
「個人的見解」って頭につけといた方がいいですよ。
「個人的見解」って頭につけといた方がいいですよ。
546 :仕様書無しさん2012/04/28(土) 21:34:38.61
>>545
まずお前から実践なw
まずお前から実践なw
547 :仕様書無しさん2012/04/28(土) 21:53:43.30
>>544
人間が読む場合と、コンピュータが読む場合があるところまではいい。
ただし、人間が読む場合は、人間らしい人間が読む場合と、コンパイラみたいな人間が読む場合と、宇宙人が読む場合があるんだよな…
「個人的見解だが」
すべての人間に読みやすいプログラムというものは存在しないと思う。
なので、読む人に合わせた書き方が求められる。
これは、もはやソースコードを介したコミュニケーションであって、そういう意味では、やはりプログラマは物書きだなーと思うし、コミュニケーション能力が求められる仕事だなと思う。
人間が読む場合と、コンピュータが読む場合があるところまではいい。
ただし、人間が読む場合は、人間らしい人間が読む場合と、コンパイラみたいな人間が読む場合と、宇宙人が読む場合があるんだよな…
「個人的見解だが」
すべての人間に読みやすいプログラムというものは存在しないと思う。
なので、読む人に合わせた書き方が求められる。
これは、もはやソースコードを介したコミュニケーションであって、そういう意味では、やはりプログラマは物書きだなーと思うし、コミュニケーション能力が求められる仕事だなと思う。
548 :仕様書無しさん2012/04/28(土) 22:17:18.20
>>547
すべての人間ではなく、
大部分の人間といえばいいだけの話。
すべての人間ではなく、
大部分の人間といえばいいだけの話。
549 :仕様書無しさん2012/04/28(土) 22:40:44.94
>>544
COBOLが読みやすいか?
ならCOBOL使えばいい。
ひまわりでもかまわんぞ
COBOLが読みやすいか?
ならCOBOL使えばいい。
ひまわりでもかまわんぞ
550 :仕様書無しさん2012/04/28(土) 22:51:04.29
551 :仕様書無しさん2012/04/28(土) 22:56:54.08
>>550
すごいな。
たまたま英文風に読める文章を
持ってきて全てを語るなんてw
すごいな。
たまたま英文風に読める文章を
持ってきて全てを語るなんてw
552 :仕様書無しさん2012/04/28(土) 22:58:44.27
>>550
そのページが読みにくいのはなんでだ?w
そのページが読みにくいのはなんでだ?w
553 :仕様書無しさん2012/04/28(土) 23:04:43.00
>>550は
自然言語とプログラム言語は白と黒のようにはっきり分かれておらず
プログラマは皆、灰色の領域で仕事をしているのだと判らせてくれる。
自然言語とプログラム言語は白と黒のようにはっきり分かれておらず
プログラマは皆、灰色の領域で仕事をしているのだと判らせてくれる。
554 :仕様書無しさん2012/04/28(土) 23:05:57.12
>>550
>['toast', 'cheese', 'wine'].each { |food| print food.capitalize }
英文まねても読みづらいだけだな。
>['toast', 'cheese', 'wine'].each { |food| print food.capitalize }
英文まねても読みづらいだけだな。
555 :仕様書無しさん2012/04/28(土) 23:07:10.90
>>554
そもそも英語が読みやすい言語かっつうのもあるしな
そもそも英語が読みやすい言語かっつうのもあるしな
556 :仕様書無しさん2012/04/28(土) 23:11:55.82
しかし、単語は英単語であり、
その英単語の意味通りを使い方をしているのは
どの言語も同じなのだ。
その英単語の意味通りを使い方をしているのは
どの言語も同じなのだ。
558 :仕様書無しさん2012/04/28(土) 23:30:53.03
じゃあ、話を最初に戻そう
if(!strcmp(foo,bar)){
問題はこれ。
strcmpは文字 比較の略であり、
ifはもし。
つまり、「もし(文字比較)なら」
という意味になるので、これはイラッとするコーディングである。
if(!strcmp(foo,bar)){
問題はこれ。
strcmpは文字 比較の略であり、
ifはもし。
つまり、「もし(文字比較)なら」
という意味になるので、これはイラッとするコーディングである。
560 :仕様書無しさん2012/04/28(土) 23:38:06.42
>>558
! が Not ならいいの?
! が Not ならいいの?
559 :仕様書無しさん2012/04/28(土) 23:33:13.51
この話に対して、プログラム言語は、
英語の文法と違うとか的外れのこといいだして、
そうじゃなくて、単語は英語であり
単語の意味通りの使い方をするべきという
話だよって教えてるだけ。
それを分からず、文法が〜文法が〜と
的外れのことを言い続けてる。
英語の文法と違うとか的外れのこといいだして、
そうじゃなくて、単語は英語であり
単語の意味通りの使い方をするべきという
話だよって教えてるだけ。
それを分からず、文法が〜文法が〜と
的外れのことを言い続けてる。
562 :仕様書無しさん2012/04/29(日) 00:00:23.13
>>559
英単語と名前の話が一番ずれてる
英単語と名前の話が一番ずれてる
563 :仕様書無しさん2012/04/29(日) 00:02:23.85
>>559
>つまり、「もし(文字比較)なら」
>という意味になるので、これはイラッとするコーディングである。
問題は、文としての書き方なのに何でお前は名前に拘ってんだ?
>つまり、「もし(文字比較)なら」
>という意味になるので、これはイラッとするコーディングである。
問題は、文としての書き方なのに何でお前は名前に拘ってんだ?
564 :仕様書無しさん2012/04/29(日) 00:08:33.22
> 問題は、文としての書き方なのに
どこ見てそう思いましたか?
どこ見てそう思いましたか?
565 :仕様書無しさん2012/04/29(日) 00:09:46.10
>>564
「もし(文字比較)なら」
「もし(文字比較)なら」
567 :仕様書無しさん2012/04/29(日) 00:11:05.12
>>564
文の話じゃねーよ。
真偽値を返さないものを
ifで使うのが気持ち悪いという話だよ。
文の話じゃねーよ。
真偽値を返さないものを
ifで使うのが気持ち悪いという話だよ。
568 :5672012/04/29(日) 00:11:30.38
× >>564
○ >>565
○ >>565
570 :仕様書無しさん2012/04/29(日) 00:17:59.45
>>567
だからif文の中で真偽値を返さないものを返してる文の書き方がおかしいんでしょ
だからif文の中で真偽値を返さないものを返してる文の書き方がおかしいんでしょ
571 :仕様書無しさん2012/04/29(日) 00:21:13.19
>>570
文がおかしい?
じゃあ、どういう文ならおかしくないというの?
”文”ですよね?
文がおかしい?
じゃあ、どういう文ならおかしくないというの?
”文”ですよね?
572 :仕様書無しさん2012/04/29(日) 00:28:03.95
>>571
真偽値を返す関数を使った文だったらよろしいんじゃないでしょうか
真偽値を返す関数を使った文だったらよろしいんじゃないでしょうか
573 :仕様書無しさん2012/04/29(日) 00:29:31.39
>>572
つまり、式を変えるってことですねw
あれ?文の話じゃなかったのかいw
つまり、式を変えるってことですねw
あれ?文の話じゃなかったのかいw
576 :仕様書無しさん2012/04/29(日) 00:37:31.36
>>573
文として分かり辛いから文の中の式を直すってのがおかしいか?
文として分かり辛いから文の中の式を直すってのがおかしいか?
578 :仕様書無しさん2012/04/29(日) 00:39:49.83
>>576
文はおかしくなかったから、文はそのままで
式を書きなおしたんだろw
お前、文がなにかわかってるのか?
if文の定義・・・if (条件式) 真文
仕様書見てもこんな感じでしか書いてないぞ。
文はおかしくなかったから、文はそのままで
式を書きなおしたんだろw
お前、文がなにかわかってるのか?
if文の定義・・・if (条件式) 真文
仕様書見てもこんな感じでしか書いてないぞ。
582 :仕様書無しさん2012/04/29(日) 00:43:04.40
>>578
仕様書には書いてないから実現は可能だが、プログラムには意図を込める事が出来る。
プロなら使わない手はない。
仕様書には書いてないから実現は可能だが、プログラムには意図を込める事が出来る。
プロなら使わない手はない。
583 :仕様書無しさん2012/04/29(日) 00:44:04.46
>>582
で、何が言いたいの?
で、何が言いたいの?
584 :仕様書無しさん2012/04/29(日) 00:44:39.33
>>583
より分かりやすく書けって話だよ。
より分かりやすく書けって話だよ。
591 :仕様書無しさん2012/04/29(日) 01:05:32.77
>>578
if文 = if statement
CやC++だと、そもそも式も文も同じ意味なんだが
if文 = if statement
CやC++だと、そもそも式も文も同じ意味なんだが
593 :仕様書無しさん2012/04/29(日) 01:12:18.69
>>591
文と式の違いも知らん奴が
さっきから喚いていたんだなw
文と式の違いも知らん奴が
さっきから喚いていたんだなw
566 :仕様書無しさん2012/04/29(日) 00:10:20.91
strcmpの戻り値が真偽値ではない、
真偽値ではないものを、もし(if)で使うなという
話ですよね?
真偽値ではないものを、もし(if)で使うなという
話ですよね?
569 :仕様書無しさん2012/04/29(日) 00:12:46.49
なぜ真偽値じゃないものをifで使うのが気持ち悪いかというと
ifが、もし〜なら という意味だからでしょうね。
ifが、もし〜なら という意味だからでしょうね。
574 :仕様書無しさん2012/04/29(日) 00:31:34.03
直感と反するのが気持ち悪い
一緒だったらって判定に!使うな
一緒だったらって判定に!使うな
575 :仕様書無しさん2012/04/29(日) 00:32:25.05
strcmpは「一緒だったら」ではなく、
「比較したら」
「比較したら」
580 :仕様書無しさん2012/04/29(日) 00:40:50.64
>>575
大元のif文はどう見ても一致してるかの判定
それ以外の意図で書いてたらなお悪い
大元のif文はどう見ても一致してるかの判定
それ以外の意図で書いてたらなお悪い
585 :仕様書無しさん2012/04/29(日) 00:45:43.69
>>580
> 大元のif文はどう見ても一致してるかの判定
もし(否定 比較する(a,b))
これを「aとbが一致した場合」と解釈するのは難しい。
> 大元のif文はどう見ても一致してるかの判定
もし(否定 比較する(a,b))
これを「aとbが一致した場合」と解釈するのは難しい。
587 :仕様書無しさん2012/04/29(日) 00:49:40.01
>>585
書き方のぜひはともかく文字列一致判定の定型文だろ
書き方のぜひはともかく文字列一致判定の定型文だろ
589 :仕様書無しさん2012/04/29(日) 00:59:33.34
>>587
こんなのを定型文と言わなきゃいけない事自体がおかしい。
こんなのを定型文と言わなきゃいけない事自体がおかしい。
577 :仕様書無しさん2012/04/29(日) 00:38:41.57
もし(おなじである(a, b))なら
なら気にならない。
なら気にならない。
579 :仕様書無しさん2012/04/29(日) 00:40:38.23
>>577
つまり、英単語の意味と合っていないということか。
つまり、英単語の意味と合っていないということか。
586 :仕様書無しさん2012/04/29(日) 00:47:20.56
もし( 比較する(a,b) == 差が0なら)
こう書けばわかりやすい。
こう書けばわかりやすい。
588 :仕様書無しさん2012/04/29(日) 00:52:37.27
>>586
どんな顔してこんな当たり前の書き込みするのか興味深い
どんな顔してこんな当たり前の書き込みするのか興味深い
590 :仕様書無しさん2012/04/29(日) 01:00:23.87
>>588
え? 当たり前のことを言ったような顔を
しているだけですが・・・?
え? 当たり前のことを言ったような顔を
しているだけですが・・・?
592 :仕様書無しさん2012/04/29(日) 01:10:42.27
C/C++のif文は、値を返さないので式として使えませんよ?
if式っていうのはこういうものです。(Scalaの例)
val msg = if (true) "true dayo" else "false dayo"
if式っていうのはこういうものです。(Scalaの例)
val msg = if (true) "true dayo" else "false dayo"
594 :仕様書無しさん2012/04/29(日) 01:37:33.40
日本語として正しいテキストのやり取りでこれだけ揉めてるんだから、
言語としての正しさは、意思疎通の効率化の一要素でしかないってのを
自ら証明してる罠
言語としての正しさは、意思疎通の効率化の一要素でしかないってのを
自ら証明してる罠
595 :仕様書無しさん2012/04/29(日) 01:37:58.64
>>594
日本語でおk?
日本語でおk?
596 :仕様書無しさん2012/04/29(日) 01:40:09.09
>>595
日本語の議論でもこれだけ揉めるのだから、やはりプログラムは奥深くて楽しい。
日本語の議論でもこれだけ揉めるのだから、やはりプログラムは奥深くて楽しい。
598 :仕様書無しさん2012/04/29(日) 01:48:55.76
何か伸びてると思ったら、何の話してんの?
602 :仕様書無しさん2012/04/29(日) 05:30:53.97
>>598
理系のボクにはよくわからないお話。
理系のボクにはよくわからないお話。
603 :仕様書無しさん2012/04/29(日) 05:32:15.06
>>602
理系とか関係なく
単にあなたがお馬鹿であるだけ。
理系とか関係なく
単にあなたがお馬鹿であるだけ。
600 :仕様書無しさん2012/04/29(日) 05:25:20.32
↑ここまでイラッとするレススタイルの話
↓ここからイラッとするコーディングスタイルの話
↓ここからイラッとするコーディングスタイルの話
606 :仕様書無しさん2012/04/30(月) 11:28:44.34
ハンガリアン記法を使うなら使うで統一してればまだいいが、
ハンガリアンな変数名とそうでない変数名が混在しているソースコードはバカだと思う。
ハンガリアンな変数名とそうでない変数名が混在しているソースコードはバカだと思う。
609 :仕様書無しさん2012/04/30(月) 15:26:03.24
>>606
ハンガリアン記法で統一されていても、記法が実態と合っていないと、
もっとイラッつとする。不具合修正後にたまに見かけるんだが……。
ハンガリアン記法で統一されていても、記法が実態と合っていないと、
もっとイラッつとする。不具合修正後にたまに見かけるんだが……。
610 :仕様書無しさん2012/05/01(火) 04:35:45.89
システムハンガリアンをコーディング規約に盛り込む連中は漏れなく無能。
611 :仕様書無しさん2012/05/01(火) 09:48:20.21
プログラムのお勉強的な意味でどうしてこんな事が必要だったのかを
若手に学習させるためにシステムハンガリアンは割りと良いんだよなw
若手に学習させるためにシステムハンガリアンは割りと良いんだよなw
612 :仕様書無しさん2012/05/01(火) 13:26:21.50
システムハンガリアン使ってるヤツは、ハンガリアン使うときどうするんだ?
例えば、↓とかどう修飾してる?
ptX; // ポイント単位のX軸
cmX; // センチメートル単位のX軸
dbY; // デシベル単位のY軸
例えば、↓とかどう修飾してる?
ptX; // ポイント単位のX軸
cmX; // センチメートル単位のX軸
dbY; // デシベル単位のY軸
615 :仕様書無しさん2012/05/01(火) 14:30:32.62
他人のコーディングスタイルは常にイラッつとするものなんだよ
616 :仕様書無しさん2012/05/02(水) 21:39:30.85
なにがハンガリアンだよハムスターかよ!
俺はローマ字で変数を使うからな!
俺はローマ字で変数を使うからな!
617 :仕様書無しさん2012/05/02(水) 22:13:12.04
だったら日本語でかきゃいいのに
最近のコンパイラーは日本語使えるんだぞ
#define 整数 int
#define 無 void
#define 本体 main
#define 戻す return
整数 本体(無)
{
整数 値 = 0;
戻す 値;
}
最近のコンパイラーは日本語使えるんだぞ
#define 整数 int
#define 無 void
#define 本体 main
#define 戻す return
整数 本体(無)
{
整数 値 = 0;
戻す 値;
}
622 :仕様書無しさん2012/05/03(木) 04:29:44.89
>>617
マクロの謝った使用法の中でも最悪だなこれ。
マクロの謝った使用法の中でも最悪だなこれ。
619 :仕様書無しさん2012/05/03(木) 00:05:17.09
そうか?
英語で命名しても認識する時は日本語だからそんなに気にならないけど。
英語で命名しても認識する時は日本語だからそんなに気にならないけど。
623 :仕様書無しさん2012/05/03(木) 05:00:42.74
変数名に$aとか$bとかマジ勘弁
624 :仕様書無しさん2012/05/03(木) 05:13:27.17
>>623
VMS「…(´・ω・`)」
VMS「…(´・ω・`)」
625 :仕様書無しさん2012/05/03(木) 10:37:35.39
>>623
でも $i は良いんでしょ?
でも $i は良いんでしょ?
631 :仕様書無しさん2012/05/07(月) 03:22:45.46
Perlは頭に何付けるか考えなきゃいけないから
他の言語を直前までやってたときに新規でソースファイル起こしたときの最初の数分だけかな忘れるのは
他の言語を直前までやってたときに新規でソースファイル起こしたときの最初の数分だけかな忘れるのは
633 :仕様書無しさん2012/05/07(月) 07:09:08.37
よくあるコード改善本の指摘に「できるだけマクロを使うな(コンパイラを働かせろ)」というのがあるけれど
実際どれくらいメリットがあるのだろう・・・?
実際どれくらいメリットがあるのだろう・・・?
639 :仕様書無しさん2012/05/07(月) 23:53:37.14
>>633
知らない方がいいよ。それを知ったとき、おまえは地獄にいる。
知らない方がいいよ。それを知ったとき、おまえは地獄にいる。
650 :仕様書無しさん2012/05/09(水) 21:39:26.50
>>633
1.オーバーロード可能になる
2.using宣言、もしくは名前空間の別名で短い名前が使える
この2点だけでも結構楽になる。
1.オーバーロード可能になる
2.using宣言、もしくは名前空間の別名で短い名前が使える
この2点だけでも結構楽になる。
634 :仕様書無しさん2012/05/07(月) 19:42:52.59
「マクロを使わない=コンパイラを働かせる」
の意味がわかんないんで教えて
の意味がわかんないんで教えて
635 :仕様書無しさん2012/05/07(月) 20:36:38.67
Cの本読めば最初の章に出てくるだろ
マクロの部分を処理するのは、コンパイラではなくプリプロセッサ
(気を利かせることができて賢い)コンパイラを使え = (単純で馬鹿な)プリプロセッサを使うな
マクロの部分を処理するのは、コンパイラではなくプリプロセッサ
(気を利かせることができて賢い)コンパイラを使え = (単純で馬鹿な)プリプロセッサを使うな
636 :仕様書無しさん2012/05/07(月) 21:30:39.56
てか、マクロを多用するコードの方がコンパイラの仕事が増えるような気が。
640 :仕様書無しさん2012/05/07(月) 23:56:57.94
>>636
ようは、コンパイラをプログラマの道具として使えってことだよ。
コンパイラが分かる形にしておくと、
コンパイルした時にミスを色々教えてくれる。
静的型付け言語ならではの、コンパイラを使った
快適プログラミングテクニックが生かせる。
ようは、コンパイラをプログラマの道具として使えってことだよ。
コンパイラが分かる形にしておくと、
コンパイルした時にミスを色々教えてくれる。
静的型付け言語ならではの、コンパイラを使った
快適プログラミングテクニックが生かせる。
638 :仕様書無しさん2012/05/07(月) 22:28:35.51
マクロ展開した後のソースがどんだけデカくなるのか見たことないのかよ!
コンパイラさん凄い頑張ってんぞ!
コンパイラさん凄い頑張ってんぞ!
641 :仕様書無しさん2012/05/08(火) 10:40:28.54
プリプロセッサを働かせずにコンパイラを働かせろということだと思うが、
コードの肥大を防ぐのが目的なのかなんなのか
コードの肥大を防ぐのが目的なのかなんなのか
642 :仕様書無しさん2012/05/08(火) 10:47:16.38
マクロは基本的に定数定義とか、移植性の向上のために使ってるな。
643 :仕様書無しさん2012/05/08(火) 12:20:14.89
マクロ禁止って暗にCをディスってるような気がする。
C++かC#陣営の策略に違いない。
C++かC#陣営の策略に違いない。
644 :仕様書無しさん2012/05/08(火) 16:18:08.66
コメントは40カラム目から
645 :仕様書無しさん2012/05/08(火) 17:30:22.51
>>644
うわ、それ強制されたことあるわ
うわ、それ強制されたことあるわ
647 :仕様書無しさん2012/05/09(水) 08:32:49.88
それ嫌いだわぁ
else書いといて中身無しとか
せめてプログラミング作法くらいは皆読んで欲しいところだ
else書いといて中身無しとか
せめてプログラミング作法くらいは皆読んで欲しいところだ
648 :仕様書無しさん2012/05/09(水) 11:01:52.47
switch () {
default:
;
}
これはあり。というか、俺はいつもそうやってる。
defaultの考慮漏れはしていないし、defaultではやることないよという表明。
> ifには必ずelseをつけるべし
これはあまり見たこと無いな。
「if〜else if〜には必ずelseをつけるべし」なら、見たことあるし、俺も実践してる。
switchのdefaultと同じ理由。
default:
;
}
これはあり。というか、俺はいつもそうやってる。
defaultの考慮漏れはしていないし、defaultではやることないよという表明。
> ifには必ずelseをつけるべし
これはあまり見たこと無いな。
「if〜else if〜には必ずelseをつけるべし」なら、見たことあるし、俺も実践してる。
switchのdefaultと同じ理由。
653 :仕様書無しさん2012/05/11(金) 00:07:09.59
>>648
> defaultの考慮漏れはしていないし、defaultではやることないよという表明。
オレだったら、それはコメントに記述するなあ
> defaultの考慮漏れはしていないし、defaultではやることないよという表明。
オレだったら、それはコメントに記述するなあ
657 :仕様書無しさん2012/05/11(金) 14:08:06.49
>>653
defaultが無いとwarning出す静的解析ツールとかありがちなんで、俺はコードで書く。
defaultが無いとwarning出す静的解析ツールとかありがちなんで、俺はコードで書く。
658 :仕様書無しさん2012/05/11(金) 17:24:17.65
>>653
俺はdefaultに assert(false) を入れとくなあ。
ミスの検出にも役立つし。
俺はdefaultに assert(false) を入れとくなあ。
ミスの検出にも役立つし。
660 :仕様書無しさん2012/05/11(金) 17:54:19.52
>>658
いや、来ないのでは無くて、来ることもあるが処理は無しよ、って意味なんだけど。
来ないはずならエラー処理入れるわ。
いや、来ないのでは無くて、来ることもあるが処理は無しよ、って意味なんだけど。
来ないはずならエラー処理入れるわ。
649 :仕様書無しさん2012/05/09(水) 11:27:41.36
たまに頭が回らん時とか、if文の条件が書きづらい時とか
if( !(条件) ){ 処理 }
ってしないで
if( 条件 ){}else{ 処理 }
って書くのも他人から見たらイラッつとさせてるんだろうなと思った。
if( !(条件) ){ 処理 }
ってしないで
if( 条件 ){}else{ 処理 }
って書くのも他人から見たらイラッつとさせてるんだろうなと思った。
652 :仕様書無しさん2012/05/10(木) 22:36:52.26
>>649
何もやることないよ
というより
書き忘れたのかと思ってしまう。
何もやることないよ
というより
書き忘れたのかと思ってしまう。
651 :仕様書無しさん2012/05/09(水) 23:27:06.14
リポジトリからソースを落とすとThumbs.dbがついて来た。
システムに必要なファイルだろうから消すなだと。
システムに必要なファイルだろうから消すなだと。
654 :仕様書無しさん2012/05/11(金) 00:34:49.93
そういえば以前の上司がどうしても『defaultは最後に書け』と言ってゆずらなかったな。
659 :仕様書無しさん2012/05/11(金) 17:28:42.09
そこに
assert(false); // 来ないはず
とか書いてあるソースは見た事ある。
来ないはずの所に来るバグがあるって事なんだろうな、と思った。
assert(false); // 来ないはず
とか書いてあるソースは見た事ある。
来ないはずの所に来るバグがあるって事なんだろうな、と思った。
665 :仕様書無しさん2012/05/12(土) 04:31:07.25
>>659
assertionはdefaultだけで使うものではない。
何のためにassertionを使っているかを考えれば分かる。
assertionはdefaultだけで使うものではない。
何のためにassertionを使っているかを考えれば分かる。
663 :仕様書無しさん2012/05/12(土) 04:08:02.61
でふぉるとさんはどんな条件にも引っ掛からなかったダメな子を許容してくれるお姉さんキャラ
たまに「絶対に書いておけ」と言う参考書がある為に
//ここに来る事は無い
と言う書き残しをして居る時があるが
nullやDBNull判定をすり抜けて来た0や空白さんがたまに来る
初期値はシステムで統一しろ
たまに「絶対に書いておけ」と言う参考書がある為に
//ここに来る事は無い
と言う書き残しをして居る時があるが
nullやDBNull判定をすり抜けて来た0や空白さんがたまに来る
初期値はシステムで統一しろ
664 :仕様書無しさん2012/05/12(土) 04:28:51.61
ifにelseは必要ない。
なぜなら、条件を満たしているか?という質問をするならば
みたいしていない場合が存在するのは明らかだから。
switchに関しては、case一個だけ書くことなんてまずない
Aの場合、Bの場合、Cの場合、じゃあそれ以外はどうなるんだ?
ということになる。
取りうる値がA、B、Cの三つしかないというのであれば、
Aの場合、Bの場合、それ以外(default)。でいいはず。
defaultがないということは、なにか意味があるということなので
それを明記するのが良い。
なぜなら、条件を満たしているか?という質問をするならば
みたいしていない場合が存在するのは明らかだから。
switchに関しては、case一個だけ書くことなんてまずない
Aの場合、Bの場合、Cの場合、じゃあそれ以外はどうなるんだ?
ということになる。
取りうる値がA、B、Cの三つしかないというのであれば、
Aの場合、Bの場合、それ以外(default)。でいいはず。
defaultがないということは、なにか意味があるということなので
それを明記するのが良い。
666 :仕様書無しさん2012/05/12(土) 04:52:54.88
>>664
>ifにelseは必要ない。
お前は何を言っているんだ
>ifにelseは必要ない。
お前は何を言っているんだ
669 :仕様書無しさん2012/05/12(土) 06:49:59.39
>>666
あれじゃないか○○であるの条件のelseは明示的に書かれていないだけで○○ではないのif文
つまり読みやすいとは別として理解しやすいと言う部分、何がしたいかをはっきりさせたい場合はifを2回書いた方がいい
つまりelseは要らない
あれじゃないか○○であるの条件のelseは明示的に書かれていないだけで○○ではないのif文
つまり読みやすいとは別として理解しやすいと言う部分、何がしたいかをはっきりさせたい場合はifを2回書いた方がいい
つまりelseは要らない
670 :仕様書無しさん2012/05/12(土) 06:55:40.08
>>669
「それ以外」の条件をいちいち列挙するの?面倒くせえ
「それ以外」の条件をいちいち列挙するの?面倒くせえ
668 :仕様書無しさん2012/05/12(土) 05:52:39.62
途中で書き込んでしまった。。
bool値を返す関数で
bool func(){
if(exp){
return true;
}else{
return false;
}
}
って書いてるのがイラッとする。
bool値を返す関数で
bool func(){
if(exp){
return true;
}else{
return false;
}
}
って書いてるのがイラッとする。
672 :仕様書無しさん2012/05/12(土) 09:42:39.16
>>668
どう書けばいいのでしょう・・・
ご教授していただけると嬉しいです
どう書けばいいのでしょう・・・
ご教授していただけると嬉しいです
671 :仕様書無しさん2012/05/12(土) 08:26:14.32
面倒くさいだけじゃ済まないぞ
わざわざ別に書いてる位だから、本当は別の条件があるのに記述漏れがあんじゃねーかって疑念が湧くし、
ifに入る条件がより限定されるような修正する際に、
else使うなら一箇所の修正だけで済むものを、使わない場合はelse相当のif文も修正が必要になる
どう考えてもバグの誘因になる
言語仕様でelseが無いとか、switchのdefaultが無いならともかく、
言語仕様としてあって、更にそれを使うのに適した場面なら、それを使う方が良いと思う
まぁ、全部にelseやdefaultを入れろって縛りはどうかと思うけど
わざわざ別に書いてる位だから、本当は別の条件があるのに記述漏れがあんじゃねーかって疑念が湧くし、
ifに入る条件がより限定されるような修正する際に、
else使うなら一箇所の修正だけで済むものを、使わない場合はelse相当のif文も修正が必要になる
どう考えてもバグの誘因になる
言語仕様でelseが無いとか、switchのdefaultが無いならともかく、
言語仕様としてあって、更にそれを使うのに適した場面なら、それを使う方が良いと思う
まぁ、全部にelseやdefaultを入れろって縛りはどうかと思うけど
673 :仕様書無しさん2012/05/12(土) 10:23:26.26
return (bool)exp;
だろ?
だろ?
682 :仕様書無しさん2012/05/12(土) 16:55:46.12
>>673
return (exp) ? true : false;
かな
でも、おれ、三項演算子好きじゃない
こまった・・・
return (exp) ? true : false;
かな
でも、おれ、三項演算子好きじゃない
こまった・・・
675 :仕様書無しさん2012/05/12(土) 13:21:10.78
gotoは基本的に使用しないこと
ただしエラー処理や多重ループから抜ける場合などは使用した方が見やすくなる
・・・ったく、いつまでクヌースの呪縛に捕らわれてんの?
全面禁止だろ、いまどき
ただしエラー処理や多重ループから抜ける場合などは使用した方が見やすくなる
・・・ったく、いつまでクヌースの呪縛に捕らわれてんの?
全面禁止だろ、いまどき
676 :仕様書無しさん2012/05/12(土) 14:00:43.31
>>675
全面禁止ってことは、
breakもcontinueもreturnもダメってこと?
これらはgotoと同じ事出来るんだけど。
全面禁止ってことは、
breakもcontinueもreturnもダメってこと?
これらはgotoと同じ事出来るんだけど。
678 :仕様書無しさん2012/05/12(土) 14:34:49.81
>>675
いつまで構造化プログラミングの呪縛に縛られてるの?
いつまで構造化プログラミングの呪縛に縛られてるの?
679 :仕様書無しさん2012/05/12(土) 15:23:16.21
>>678
アウフヘーベンするならともかく、goto使うところに戻るんじゃただの退化じゃん。
アウフヘーベンするならともかく、goto使うところに戻るんじゃただの退化じゃん。
681 :仕様書無しさん2012/05/12(土) 16:08:22.41
>>679
今更gotoがどうとかどっちでもいいじゃん
今更gotoがどうとかどっちでもいいじゃん
697 :仕様書無しさん2012/05/13(日) 00:14:04.30
>>676
一緒じゃねぇよ全然ちげぇよ。
ダイクストラが提起した問題は、gotoそのものや、ジャンプじゃない。
処理ブロック(forやifといった分岐反復のまとまり)のネストを無視して、
処理ブロックから、処理ブロックに飛べる事が問題なんだ。
なんでgotoがあるのにbreakやcontinueがあるか解ってんのか?
一緒じゃねぇよ全然ちげぇよ。
ダイクストラが提起した問題は、gotoそのものや、ジャンプじゃない。
処理ブロック(forやifといった分岐反復のまとまり)のネストを無視して、
処理ブロックから、処理ブロックに飛べる事が問題なんだ。
なんでgotoがあるのにbreakやcontinueがあるか解ってんのか?
700 :仕様書無しさん2012/05/13(日) 00:20:09.10
>>697
ダイクストラが提起した問題は、gotoそのものや、ジャンプじゃない。
処理ブロック(forやifといった分岐反復のまとまり)のネストを無視して、
処理ブロックから、処理ブロックに飛べる事が問題なんだ。
だから、処理ブロックから、処理ブロックに飛ぶようなことをしなければ
gotoを使ってもいい
ダイクストラが提起した問題は、gotoそのものや、ジャンプじゃない。
処理ブロック(forやifといった分岐反復のまとまり)のネストを無視して、
処理ブロックから、処理ブロックに飛べる事が問題なんだ。
だから、処理ブロックから、処理ブロックに飛ぶようなことをしなければ
gotoを使ってもいい
677 :仕様書無しさん2012/05/12(土) 14:25:20.15
いや、だからだよ
今の言語はブロック制御に則ったジャンプ命令があるのに
いつまでALGOL時代の「goto」という命令に捕らわれてるんだって意味
今の言語はブロック制御に則ったジャンプ命令があるのに
いつまでALGOL時代の「goto」という命令に捕らわれてるんだって意味
680 :仕様書無しさん2012/05/12(土) 15:47:39.09
>>677
それらで出来ないことだって有るだろ。
それらで出来ないことだって有るだろ。
683 :仕様書無しさん2012/05/12(土) 17:30:18.41
三項演算子を好んで使うやつなんか存在するのか?
686 :仕様書無しさん2012/05/12(土) 18:13:32.23
>>683
エレキ屋あがりが「オブジェクトファイルを開いてみろ!if-elseと比べてこんなにシンプルだぞ!」と
しきりに勧めてくるのだが・・・・・実際どうなんだろうと思う
エレキ屋あがりが「オブジェクトファイルを開いてみろ!if-elseと比べてこんなにシンプルだぞ!」と
しきりに勧めてくるのだが・・・・・実際どうなんだろうと思う
687 :仕様書無しさん2012/05/12(土) 18:38:40.32
最近カンスト付きの加減算で好んで使ってたりしてる。
無理に使えとは言わないw
num = ((num+hoge) > max) ? max : (num+hoge);
無理に使えとは言わないw
num = ((num+hoge) > max) ? max : (num+hoge);
688 :仕様書無しさん2012/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;
どっちが見やすいかなんて一目瞭然だと思うが?
三項演算子使うだろ。
var a;
if(exp1) {
a = 1;
} else if(exp2) {
a = 2;
} else {
a = 3
}
var a = (exp1) ? 1 :
(exp2) ? 2 :
3;
どっちが見やすいかなんて一目瞭然だと思うが?
689 :仕様書無しさん2012/05/12(土) 23:15:57.08
>>688
複数の判定がいるならswichかテーブル使ってしまうなぁ
複数の判定がいるならswichかテーブル使ってしまうなぁ
690 :仕様書無しさん2012/05/12(土) 23:19:05.66
三項演算子を使って一行で書ける時はよく使う。
>>688はイラッ
>>688はイラッ
691 :仕様書無しさん2012/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;
値を返すならこっちのほうがシンプル
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;
値を返すならこっちのほうがシンプル
698 :仕様書無しさん2012/05/13(日) 00:15:36.69
>>688
3講演子の条件式をカッコでくくってんのがイラっとする
3講演子の条件式をカッコでくくってんのがイラっとする
699 :仕様書無しさん2012/05/13(日) 00:18:57.46
>>698
カッコがないと見難い
カッコがないと見難い
692 :仕様書無しさん2012/05/12(土) 23:23:03.00
処理を分岐させたいなら
if、switch
条件に応じて値を返したいなら
三項演算子
if、switch
条件に応じて値を返したいなら
三項演算子
693 :仕様書無しさん2012/05/12(土) 23:42:10.01
一番のネックは三項演算子をやたらに憎む奴らが多い事なんだよな
まあ、IFの変わりに使うひとが大量に居たせいだと恨んでるけとw
まあ、IFの変わりに使うひとが大量に居たせいだと恨んでるけとw
695 :仕様書無しさん2012/05/13(日) 00:07:43.98
>>693
関数型言語では三項演算子(風)の記述が主流
三項演算子を嫌うような老害は
このあと消える。
関数型言語では三項演算子(風)の記述が主流
三項演算子を嫌うような老害は
このあと消える。
694 :仕様書無しさん2012/05/13(日) 00:05:26.98
三項演算子くらいラムダ式に比べたらまだまだまだまだ可愛い。
あと関係ないけど
if (hoge()) {
}
が嫌いなんだよね。(hoge() != false(FALSE))位は書いてもバチあたらないよ。
一瞬あれってなって思考が止まる。一々MSDN確認しないといけないし
あとif文に中かっこ付けない奴はしね。