07/05/10 09:36:17
private宣言してもリアルタイムデバッグではアクセス可能だろ？
意味なくね？
101:仕様書無しさん
07/05/10 11:00:05
>>100
はあ？
102:仕様書無しさん
07/05/10 11:49:46
全然privateじゃないってこと
103:仕様書無しさん
07/05/10 12:24:19
カプセル化の意味も判らないんなら口挟まない方がいいんじゃね？
104:仕様書無しさん
07/05/10 12:31:25
そこで防御策として
#ifdef private
#undef private
#endif
#ifdef protected
#undef protected
#endif
と自分のヘッダの先頭に書く必要が出てくる。
もはや冷戦だな。
105:仕様書無しさん
07/05/10 17:55:41
>>104
勘弁してください……
106:仕様書無しさん
07/05/10 18:57:15
>>104
その後にインクルードされるヘッダファイルの中で
#ifndef private
#define private public
#endif
#ifndef protected
#define protected public
#endif
と書かれてないか調べたか？
ｗ
107:仕様書無しさん
07/05/10 19:19:40
嫌な職場だなぁ
108:仕様書無しさん
07/05/10 22:26:52
まさに冷戦。 誰が核のボタンを押すのか、押せるのか。 いやまて核は何なのか。
109:仕様書無しさん
07/05/10 23:18:03
#define FIRE FILE なんての見て鬱になってたところだが、
ここ見てたらなんだか元気が出てきた。ウチはまだ大丈夫だ！
110:仕様書無しさん
07/05/10 23:48:01
>>106
オワットルwww
111:仕様書無しさん
07/05/11 00:48:52
>>109
知らぬ間に
#define FILE FIRE
になっているかもしれんぞ。
112:仕様書無しさん
07/05/11 01:38:14
大丈夫。
展開コードを参照すればｗ
113:仕様書無しさん
07/05/11 10:34:47
１つのプロジェクト内にファイルが1800個あったから、一体何かと思ったら
履歴を全部別ファイルにして残していて、わざわざコンパイルしない設定対象に1780個ぐらい加えているという・・・
バージョン管理ソフト使っていてこれかよ。出向先なので辞めるわけにはいかない、
明日から通勤時間に3年程かけようかとか本気で思った
114:仕様書無しさん
07/05/12 01:22:44
>>111
sonyのバッテリーが発火した原因はそれか。
115:仕様書無しさん
07/05/13 07:16:31
やめよう思うほどじゃないが
よく見るキモチワルイコード
if (a == 1) {
} else {
なんかのしょり
なんかのしょり
}
116:仕様書無しさん
07/05/13 08:38:20
>>115
俺、よくこういうコード書きかけてしまう…
具体的にはこんなんですが。
if (a == 1) {
/* ～ということやりたいけど後で考える */
} else {
なんかのしょり
なんかのしょり
}
(a == 1) の時の処理考えなくてよければ、こんなんかな。
if (a != 1) {
なんかのしょり
なんかのしょり
}
117:仕様書無しさん
07/05/13 14:21:06
>>116
コーディング中には俺もよくやる。
問題は納品後のソースにそれが残ってることだと思います。
//TODO:この機能いらなくね？？
とか
//TODO:うんこしたい
とか
//TODO:仕様はやくきめろやぼけ！！殺すぞ！！
とか
他人にはとても見せられないようなコメント
入れといて実装漏れ、修正漏れは絶対起こさないようにすべき
このコメントを納品した後のソースで、見たらその人は
この会社やめようって思うんだろうなー
でも、顧客の悪口は洒落にならないから書かないぜ！
118:仕様書無しさん
07/05/13 14:26:10
んなコメント入れんなよ
119:仕様書無しさん
07/05/13 17:13:43
普通、if(a)って書かね？
120:仕様書無しさん
07/05/13 17:20:56
>119
出た～～～っ！
121:仕様書無しさん
07/05/13 17:41:28
>>119
それキモい。
aはあくまでデータであり、真偽をあらわす値ではない。
122:仕様書無しさん
07/05/13 17:44:10
ところでいつ a が boolean になったんだ？
123:仕様書無しさん
07/05/13 17:44:34
C#とかだとコンパイルも出来ない。
124:仕様書無しさん
07/05/13 17:47:02
ifは0かそうじゃないかだけしか見ないんだから>>119で何の問題もないだろ
C#はｼﾗﾈ
125:仕様書無しさん
07/05/13 17:51:42
ifは0かそうじゃないかだけしか見ないんだから
ifは0かそうじゃないかだけしか見ないんだから
ifは0かそうじゃないかだけしか見ないんだから
ifは0かそうじゃないかだけしか見ないんだから
ifは0かそうじゃないかだけしか見ないんだから～
お前とは組みたくない。
126:仕様書無しさん
07/05/13 17:56:10
組込みマイコンのコンパイラでは常識的手法。
if(a)なら JNZ命令一行ですむ。
127:仕様書無しさん
07/05/13 17:59:30
>>121
まじすか。
ただ、適切な変数名をつけて問題領域で考えれば分かりやすいと思うんだけどなぁ
int型でも俺はそうやってる
128:仕様書無しさん
07/05/13 18:07:33
if (a) って書いたら a == 1 以外のケースでも真と判定されることに気づかないかね。
>>126
if (a != 0) を if (a) に最適化するのはコンパイラの仕事ですよ。
より効率の良く等価な記述に変換する最適化はコンパイラにさせて
人間は正しい意味論に則った保守しやすいコードの記述に努めるべき。
129:仕様書無しさん
07/05/13 18:17:16
で、aの型は・・・？
130:仕様書無しさん
07/05/13 18:19:03
お前ら、if (isdigit(c) == 1)って書くの？
131:仕様書無しさん
07/05/13 18:23:03
>>121
何か変なことになった場合に
if(a)の時点でa=0になっていると保証されてるなら
それでいいと思うが。
132:仕様書無しさん
07/05/13 18:25:26
>>130
isdigit関数の戻り値の意味は真偽値だとわかっているから if (isdigit(c)) で無問題。
ちなみに 真==1 とは限らないので、敢えて書くなら if (isdigit(c) != 0) が正解。
133:仕様書無しさん
07/05/13 18:27:44
>>128
int型でもブール変数として使う場合は
むしろ、a == 1 以外のケースでも真と判定されなきゃまずいと思うけど
134:仕様書無しさん
07/05/13 18:32:31
if(a)って書くとバグの温床になるからやめろ
等号式書いても、今のコンパイラなら８０年代と違って等価のコード出す。
今、最適化意識して各のはアルゴリズムの性能と無駄なシーケンス省くことだけ。
きもいくて古い書き方は捨てろ。恥だ
135:仕様書無しさん
07/05/13 18:38:06
>>134
>if(a)って書くとバグの温床になるからやめろ
まぁif((hFile = CreateFile()))とかやってハマってた奴とかいたし、気持ちはわかるw
136:仕様書無しさん
07/05/13 18:38:38
isdigit
ｗｗｗ
137:仕様書無しさん
07/05/13 18:38:42
だーかーらー前提としてaの型を明らかにして話を進めろ
138:仕様書無しさん
07/05/13 18:47:19
＞１３５
じつはｈFileの実体がスマートハンドルで、
operator boolみたいなのが定義されているとか
139:仕様書無しさん
07/05/13 18:51:44
>137
新人はだまってROMしてなさい！
140:仕様書無しさん
07/05/13 18:55:15
>>137
・aがブールを意味する値なら if (a) でおｋ
・そうでなければ比較の意図を明示的に表明すべし
でFA
141:仕様書無しさん
07/05/13 19:04:34
>140
上の連中それをごっちゃにして噛み合わない議論してねぇ？
142:仕様書無しさん
07/05/13 19:08:37
>>134
むしろ、バグの温床になるのは
if (a==0)
とかの方なんだがな・・・
typo で
if (a=0)
になってしまうから。
143:仕様書無しさん
07/05/13 19:12:33
はいはいif(0==a)
144:仕様書無しさん
07/05/13 19:28:00
つか
if( a == b )を間違えないように定数比較したいなら
if( NULL == a)って書けばいいだろ。定数は必ず初項として記述すればいいだろ
仮にif( NULL = a)ってやればコンパイルエラー出る。
つうか2000年ぐらいまでのコーディング規約でいいものだけ取り入れて
かけよ。一般人ができる最低限度のコーディングの礼節だと思うがな。
145:仕様書無しさん
07/05/13 19:34:08
>>144 読んで
ふと思ったんだが、
fj って今でもあるの？
146:仕様書無しさん
07/05/13 19:35:09
確かにその書き方なら間違いが防げるけど、何故か普及してないな。
147:仕様書無しさん
07/05/13 19:36:49
if( NULL == a)
と書くのはお断りだ
148:仕様書無しさん
07/05/13 19:38:54
>>146
昔から議論はあるけど、警告が出るからそんなヘンな書き方をすることは無いってことで落ち着いてる。
149:仕様書無しさん
07/05/13 19:40:09
>>144
きもいくて古い書き方は捨てろ。恥だ
150:仕様書無しさん
07/05/13 20:18:41
if(a)
が一番美しい。
151:仕様書無しさん
07/05/13 20:25:30
>>150
>>121
152:仕様書無しさん
07/05/13 20:31:36
>151
>127
153:仕様書無しさん
07/05/13 20:36:17
プログラムってのはデータと命令しかないわけよ。
そのデータが真偽値であるとか整数であるとかあるいは文字列であるとかの意味付けは
言語処理系上でのみ行われている文脈上のものでしかないの。
文法的に許されているなら>>150を支持する。実際、美しい。
キモイとか許せないと思うなら
if(a)
という記述を許さない言語を使えば良いでしょ。
154:仕様書無しさん
07/05/13 20:37:43
無限ループって怖くね？ｗ
155:仕様書無しさん
07/05/13 20:38:51
最初の書き込みで、aに入ってるのがbool値(0かそれ以外)か、ただの数値(たとえば0～100とか)とか何も
書いてないのに、いきなり
「if (a) と書く」とか言うのは変だって言ってるんだろ。
156:仕様書無しさん
07/05/13 20:45:37
個人的に
if(a)
で書ける状況でもこういう書き方はしないなぁ。
たまたま文法的に成立するってだけだから。
古い書き方だと思う。
今はベタに、ちゃんと==使わないとダメだと思う。
157:仕様書無しさん
07/05/13 20:45:46
ねえ、今は False =0, True = 1 であたりまえなの？
昔はそれぞれ 0, 0xff って実装もありだったと思うんで、
True のつもりで a == 1 なんて怖くて書けない。
せめて a == True とするのが、他人が読む時も精神衛生的にいいんジャマイカ？
158:仕様書無しさん
07/05/13 20:46:32
>>155
>「if (a) と書く」とか言うのは変だって言ってるんだろ。
別に。
また、プログラムの読み手にとっても、
aに入ってるのがbool値か、ただの数値か
なんて考える必要はない。
a の評価値が 0 かそれ以外かさえ分かればよい。
こんな単純な話はない。
159:仕様書無しさん
07/05/13 20:49:42
>>158
でも, bool値以外のデータだったら、
if (a == 1) を
if (a) にしたら、動作が違ってくるだろ?
160:仕様書無しさん
07/05/13 20:50:14
a == 1 の比較だろ
a = 0 or 1 ならともかく
a = 2 のときは？
a = 100 のときは？
161:仕様書無しさん
07/05/13 20:50:16
>>158
その場合、if(a) は発端>>115 の if (a==1) と同一ではない。
発端の if (a==1) はあなたの「単純な話」にあてはまらない。
元の話わかってる？
162:仕様書無しさん
07/05/13 20:52:26
aには、0か1が入ってるとか、
1,2,3のどれかが入ってるとか、なんら前提が示されてないのに、
if (a == 1) を if(a) と書き直したらダメだろ。
163:仕様書無しさん
07/05/13 20:53:39
凡庸なプログラマってこうした思い込みしてコーディングしてんのかな…
164:仕様書無しさん
07/05/13 20:54:14
なんかトンデモねぇ馬鹿が一匹迷い込んでないか
俺コイツと一緒に仕事すんのはマジで嫌
想定外の修正されてぶち壊されそう
165:仕様書無しさん
07/05/13 20:54:56
初心者の俺にはよく分からんのだが
aの型について触れずに論議が進められるのは何故なの？
166:仕様書無しさん
07/05/13 20:55:46
>165
何度か指摘してるんだが何故かまともに取り合ってくれないんだ(´･ω･`)
167:仕様書無しさん
07/05/13 20:56:02
aには、0か1が入ってるとか、
1,2,3のどれかが入ってるとか、なんら前提が示されてないのに、
if(a)をif (a == 1) と書き直したらダメだろ。
168:仕様書無しさん
07/05/13 20:57:42
>>167
＞if(a)をif (a == 1) と書き直したらダメだろ。
それは誰もしてない。
169:仕様書無しさん
07/05/13 20:59:43
>>165
少なくともCにおいては、if()の中身は式であって、その型は無関係だから。
170:仕様書無しさん
07/05/13 21:01:13
>165
>166
>139
171:仕様書無しさん
07/05/13 21:02:10
>>157
＞せめて a == True とするのが、他人が読む時も精神衛生的にいいんジャマイカ？
bool値のある言語でそれをやったら、ちょっとヘタクソっぽい。
Cだと、
#define TRUE 0
#define FALSE -1
とか、ありえるので、わからなくもない。
172:仕様書無しさん
07/05/13 21:04:05
キモイとか言える次元かよｗ
感覚上身についているかどうかのレベルの問題じゃね？
(センスというにはあまりに次元が低すぎる)
#include <stdio.h>
char* a;
int main(){
if (!a){
printf("a");
}
}
とかどうすんだよ。aが初期化されて無い判定は。
まさかbool型とか、コンパイラがうまくやってくれるからとか言っちゃって0で、==するのか？ｗｗｗ
ショッペーーー
173:仕様書無しさん
07/05/13 21:05:31
今日はとくに変だな
このスレｗ
174:仕様書無しさん
07/05/13 21:05:35
この人なんで火病ってんの？
175:仕様書無しさん
07/05/13 21:06:28
でさー 115 がいつ C って決まったの？
176:仕様書無しさん
07/05/13 21:08:32
>>175
暗黙の前提。ああいう構文の言語は全部がCから派生しているからね。
177:仕様書無しさん
07/05/13 21:09:17
まあ細かいことはプログラム書く人の自由ということで、115の場合はひとつの例として、
if aが1のとき{何もしない} else {何かの処理}がキモチワルイコードと言っているだけだ。
178:仕様書無しさん
07/05/13 21:14:59
じゃあここは間とって三項演算子で書こうぜ
179:仕様書無しさん
07/05/13 21:15:01
>>115 の主張は
if (a == 1) {
/* ～ということやりたいけど後で考える */
} else {
で、「/* ～ということやりたいけど後で考える */ を書くのが嫌だ」って話であって、
今の話題は >>119 が言う所の、
「if 文の括弧の中では、明示的に論理式を書く必要がない」か否か
って話だろ？
180:仕様書無しさん
07/05/13 21:16:07
＞暗黙の前提。
こういう自分勝手な解釈をするヤツが一番手におえない
181:仕様書無しさん
07/05/13 21:19:37
>>180
>>115 ≠ >>176 というのも、暗黙の前提だな。
182:仕様書無しさん
07/05/13 21:23:04
それも勝手な解釈だな
その場合は前提を提示していないという意味で自分勝手な以下同文
183:仕様書無しさん
07/05/13 21:23:42
>>179
俺が
> /* ～ということやりたいけど後で考える */
を追加した >>116 だけど、>>115 はそんなこと主張してないぞ。
>>115 の if (a == 1) {} else { ... } の解釈はいろいろありえるが、俺は
「if (a == 1) の時何もやらない」だと解釈した。
俺は別なつもりで同じようなコードを書いてしまうとコメントしたつもりだったんだが、
俺が余計なこと書いて議論を混乱させたのか？ すまんかった。
184:119
07/05/13 21:28:36
正直すまんかった。
俺が勝手に>>115のaをブール値を表現する変数だと勘違いして>>119を書いた。
でも、よく考えたら>>115は明示的にa == 1って書いてるんでブール値ではないわな。
ブール値なら少なくともa == TRUEとか書かなきゃいかんはずだし。
まぁ、俺が言うのもなんだが>>140->>141でFAで
185:けーつえーき
07/05/13 21:58:00
>>184
その辺って熟練のPGでも考え方に違いが出てくるので
PLの考えに合わせるのが無難と思う。
そういえば、MSの環境でBOOLって型があって
#define TRUE (1)
#define FALSE (0)
と定義されてるんだけど
APIで返す値に1以外の0じゃない値が返るものがあったりするねw
186:仕様書無しさん
07/05/13 22:10:58
>>185
Windows APIのBOOL型の戻り値は、だいたい「成功すると0以外の値を返す」と
ドキュメントに記されているわけで、特定の定数TRUEを返すとは書かれていないんで
if (HogeHoge() == TRUE)
は間違い。普通はこういう書き方しないだろうけど。
ところでその#defineの括弧は不要なんじゃ...
187:仕様書無しさん
07/05/13 22:18:46
どころか、GetMessageみたいな３値を返すBOOLもある
188:仕様書無しさん
07/05/13 22:21:39
> ところでその#defineの括弧は不要なんじゃ...
まあ括弧でくくるクセをつけてあるのは良いことだと思う。
189:仕様書無しさん
07/05/13 22:26:24
おう。そういう例があるから だいたい とさりげなく断っておいた。
俺はそれに嵌ったクチだし。
（ウィンドウの生成に失敗しているのにGetMessageして-1が返って無限ループorz）
190:仕様書無しさん
07/05/13 23:17:00
>>186
APIリファレンスにも普通に-1を返すと記述されてたりするw
>>189
他にも罠wがいろいろあるのがMS仕様という印象
191:仕様書無しさん
07/05/14 05:41:07
スレタイが「この会社辞めようと思ったソースコード」なのになんで素人が混じってんだ？
192:仕様書無しさん
07/05/14 08:03:15
>>191
プロはこんな板見てないからじゃないか？
193:仕様書無しさん
07/05/14 08:26:50
>>191
素人とプロの違いは技量の違いではない。
「それが生活基盤であるか否か」だけである。
だからいくら素人に見えても実態はプロである事は多い。
194:仕様書無しさん
07/05/14 08:58:01
>>193
てことは>>191もプロになるんだろうな。
195:仕様書無しさん
07/05/14 11:30:47
とりあえず最悪の事態を考えてaはValiant型を想定しておくか
196:仕様書無しさん
07/05/14 11:44:27
>>195
ちょっｗｗｗｗｗ
SUGEEEEEEEEE
そんな先のことまで想定してコーディングするとはｗｗｗ
俺絶対入社するわ
全部Variantで書いとくんで保守たのんますｗｗｗ
197:仕様書無しさん
07/05/14 12:29:41
なんかスレが延びているとおもったら、またよくわからん話題で盛り上がってるのか
えーっと
ぬるぽ
198:仕様書無しさん
07/05/14 12:35:31
がっ
199:仕様書無しさん
07/05/14 16:51:48
// ここからそこまで何をしているのか不明
そこって何処よ…('A`)
200:仕様書無しさん
07/05/14 17:52:51
' SOKOってラベルふってあんだろ
201:仕様書無しさん
07/05/14 17:56:16
底でしょ
202:仕様書無しさん
07/05/14 17:58:54
プロシージャ内と予測してみる
203:仕様書無しさん
07/05/14 19:31:37
ここってCの人が多いみたいね。
じゃあ、vb系を代表して：
Dim a, b As Integer
Cとは違います。多分正しくありませんよ～
204:仕様書無しさん
07/05/14 19:34:04
>>203
普通にそう書いてる奴多いな
俺はメンテの時に困るから書いてないけど
205:仕様書無しさん
07/05/14 19:37:00
>>203 aはIntegerと見せかけて、バリバリのバリアントだな。
そういう紛らわしい書き方ができてしまうVBの言語仕様はどうみても糞だな。
206:仕様書無しさん
07/05/14 19:37:30
上の方でtrue=1, false=0とかあってけど、VBAではTrue=-1ね
多分VBも
207:仕様書無しさん
07/05/14 19:44:45
>>203
そーいや専門学校で教師がそのソース書いてたな。
208:仕様書無しさん
07/05/14 19:45:10
やめて～（実話）
For i=1 To 10000
Cells(i,1) = "なんたらかんたら"
Next
ExcelVBA だが、行は何行あるか分からないらしい。動けばいいのかな？
上級SEさんのコードでした。
209:仕様書無しさん
07/05/14 19:51:16
>>205
更に、.NET 以降はあれで「どっちも Integer」という軽い罠。
>>208
まあSﾖなら普通。
210:仕様書無しさん
07/05/14 19:52:34
>>209
そうなの？違うんじゃない？
211:仕様書無しさん
07/05/14 20:01:01
ソースじゃないけど聞いていい？
PL/SQLとTransact-SQLって同義なの？
前者はOracleで後者はSQLServerに使うものだと思っていたんだけど。
今日、面談で言われたよ～
212:仕様書無しさん
07/05/14 20:01:03
>>209
セル１つ１つに値を入れる奴はヘタレ。
213:仕様書無しさん
07/05/14 20:33:28
>>210
…あのさ、君が前段と後段のどっちに疑問を呈しているのか解るのって君だけなんだが。
(7:3 で前段と踏んだ)
>>211
ここが質問ｽﾚじゃないことくらい理解してほしいところなんだが。
>PL/SQLとTransact-SQLって同義なの？
「ストアドプロシージャの記述に使用できる」という一点のみが共通項。
214:仕様書無しさん
07/05/14 20:39:13
>>213
>>210 どす。
前段どす。
Dim a, b As Integer
って.netでもaはVariantじゃないの？
215:仕様書無しさん
07/05/14 20:41:35
「VB.NET 変数宣言」でぐぐれかす
216:仕様書無しさん
07/05/14 21:03:36
ホントだ。知らんかった。
217:仕様書無しさん
07/05/14 21:21:01
Dimってさ、もともとDimensionの略で、配列の次元を宣言するための
ものだったのにどーしてVBは一般の変数宣言に使うようになっちゃった
んだろう。
218:仕様書無しさん
07/05/14 21:30:23
RubyとかLispとか動的型付けの言語でもコードが書かれてるんだから、
Variantでもいいじゃないか。
219:仕様書無しさん
07/05/14 21:31:21
>>218
底辺乙
220:仕様書無しさん
07/05/14 21:55:27
そもそもoption explicitにしない奴もいるわな。
いいんじゃない？最近のPCは性能がいいから。
221:仕様書無しさん
07/05/14 22:00:50
>195
Variant
222:仕様書無しさん
07/05/14 23:14:36
>220
ハードウェアの進化には楽天的であれ
ソフトウェアの進化には悲観的であれ
エンジニアの技術力の進化には絶望的であれ
# 上の2つは201の鉄則より
223:仕様書無しさん
07/05/14 23:59:36
ｽﾚﾘﾝｸ(prog板:711番)
224:仕様書無しさん
07/05/15 10:31:23
昨日を
today-1
と書くか
dateadd("d",-1,today)
と書くか
225:仕様書無しさん
07/05/15 10:56:39
普通下だと思ってた俺はどうなのよ？
226:仕様書無しさん
07/05/15 10:59:04
反省しろ
227:仕様書無しさん
07/05/15 11:36:02
ボリューム（D：）
↑
このへんがやる気ナイ・・
228:仕様書無しさん
07/05/15 11:43:17
>>225
すまん。Date-1だった。最近、VBやってないから忘れてた。
229:仕様書無しさん
07/05/15 12:07:08
>>203
あれ？ 確かVB4か5までは a = variant, b = integerになるが、
VB5か6からは両方ともintegerになるような解釈になってなかったっけ
ま、毎回１つ１つきっちり書いている俺には関係ないが
230:仕様書無しさん
07/05/15 12:17:15
ならん
231:仕様書無しさん
07/05/15 12:23:57
今確認したけど
dim a,b as integer
ってVB6SP6でやると
a=Empty
b=0
になってたからaの型はVariantになってるね
232:仕様書無しさん
07/05/15 12:27:45
バージョンで仕様が変わったら、やってられないだろ～
.netはいいチャンスだと思ったんじゃない？
233:仕様書無しさん
07/05/15 13:35:50
>206
その解釈は微妙。（VB(A)でもCでも）
どちらも、0が偽でそれ以外が真。
ただし、比較式などが返す値が、Cでは1、VB系は-1てこと。
>206自身はわかってるならそれはいいんだけど、
わかってない人が>206みたいな記述を読むと勘違いしたりする('A`)
234:229
07/05/15 16:09:20
>>231
ああ、.NETからの間違いだったかも
すまそ、ちょっとunicode変換されてくるは
235:仕様書無しさん
07/05/15 22:23:41
>>228
そんなの書けたか？
236:仕様書無しさん
07/05/15 22:37:00
>>235
今ちょっと試してみたけど、Excel VBA で Date 型だと書けてしまうな。気持ち悪い。
整数が日付、小数点以下が時刻ってことか…
俺はDateAddの方がどんな変数を操作してるかわかりやすいので安心できる。
237:仕様書無しさん
07/05/16 00:22:54
真値を数値として扱うと-1になることを利用した演算式が
昔のBASICにゃたんまりあってのう……
a = a + (h > 3) * 1
とか
238:仕様書無しさん
07/05/16 00:44:08
Oracle とかもDate型は数値扱いだろ
よくあるよくある
239:仕様書無しさん
07/05/16 07:10:34
>>237
むしろ条件式を使うことがコード量を節約する手法の一つだったのさ。
240:仕様書無しさん
07/05/16 09:46:11
>>237
の動作ってどうなるんだ?
こんな書き方しらねぇ････
(h > 3)
この部分の解釈
241:仕様書無しさん
07/05/16 10:15:20
>>240
真なら -1 で偽なら 0 になる。
つまり C で書きなおせば
if (h > 3) a += 1;
ってこと。
この例だとコード量節約にもならないような。
242:仕様書無しさん
07/05/16 10:35:26
BASICならIF文使うと遅いからじゃね？
243:仕様書無しさん
07/05/16 10:41:02
サンクス
なるほど そういう解釈になるのか！
しかし・・・可読性が落ちるな(；´Д｀)
昔は遅かったからその辺のテクなんだろうなぁ･･･
244:仕様書無しさん
07/05/16 12:02:18
最近のCPUで当時のBASICコードが動かせるとすると
ループで時間稼いだりしてた部分が瞬時に終わったり
笑える動作になるんだろうな
245:仕様書無しさん
07/05/16 12:03:41
>>238 は何を言ってるんだ…？
246:仕様書無しさん
07/05/16 12:06:52
>>244
ウチは実際にそれで問題が出てたｗｗｗｗ
247:仕様書無しさん
07/05/16 12:47:25
>>244
昔でもあったぞ。
ゲームでPC-9801VM(V30)でスピード最適化したシューティングゲームを
PC-9801RA(i386)で動作させてみたらレーシングゲームになった、とか
248:仕様書無しさん
07/05/16 13:30:20
MSXturboRの通常モード(8ビットモード)で普通に出来たゲームが
高速モード(16ビットモード)では早すぎてゲームにならなかったり。
249:仕様書無しさん
07/05/16 19:37:21
>>237
俺は Pascal(Delphi) で似たようなコードをよく書く。
Salary := BaseSalary + 1500 * OverHours * Ord(chkOvertimePaid.Checked);
Pascal では Ord(False) = 0、Ord(True) = 1 と言語で定義されている。
でも確かに 8 ビット時代の悪しき習慣のような感じもするな。
250:仕様書無しさん
07/05/16 20:39:53
俺は同じ書き方やって言語で動作が違うような書き方はしないように心がけてる
251:仕様書無しさん
07/05/16 20:44:09
じゃあ、Cで短絡評価は使わないってこと？
252:仕様書無しさん
07/05/16 20:50:09
>>251
C・C++は別格
253:仕様書無しさん
07/05/16 20:51:54
>>251
短絡的な発想だな
254:仕様書無しさん
07/05/16 20:57:30
>>253
だれがうまいこと言えとｗｗｗ
255:仕様書無しさん
07/05/17 11:43:10
>>250
言語が変わったら、同じ書き方は出来ないと思うんだが。
256:仕様書無しさん
07/05/17 12:56:49
>>255
なにその柔軟すぎる発想
お前PGとかこの業界やめたほうがいいよ
それとも釣りですか？
257:仕様書無しさん
07/05/17 14:00:51
>>256
「同じ言語で、同じ書き方をして、違う動作をするような書き方」
であれば、しないのが当たり前。素人じゃあるまいし。
258:仕様書無しさん
07/05/17 14:17:15
>>257
日本語嫁よｗｗｗｗｗｗ
259:仕様書無しさん
07/05/17 14:53:11
おいおい
COBOLでかちゅーしゃ作れねーだろ
260:仕様書無しさん
07/05/17 15:32:20
.netコボルならできるんじゃね？
261:仕様書無しさん
07/05/17 15:42:57
COBOLでJavaのVM作ればOK。
262:仕様書無しさん
07/05/17 16:12:45
Valiantをブリリアントと読んでいた。
そんな時期もありました。
263:仕様書無しさん
07/05/17 17:02:51
━ a. 勇敢な.
ひょっとして: variant valiantly Valerian
264:仕様書無しさん
07/05/17 17:58:31
今年入社した会社のコード
if(《BOOL型変数》!= TRUE)
{
}else
{
処理;
}
もっと簡潔に書いてくれ・・・
265:仕様書無しさん
07/05/17 18:14:47
BOOLというのが実は独自定義の真偽値型で、
TRUE==0でそれ以外がFALSEだとか？
266:仕様書無しさん
07/05/17 18:15:54
>>264
既出のものかと思いきや応用編か……。
267:仕様書無しさん
07/05/17 18:48:13
>>265
それにしたってブロックからっぽにするんだったら
条件ひっくりかえしてelse削除でしょう。
268:仕様書無しさん
07/05/17 18:52:06
>>267
ご指摘の通りだけど。else部分は省略禁止という規約も実在するしｗ
269:仕様書無しさん
07/05/17 19:07:26
いや、条件に一致した場合の処理も後で書き加える可能性があるとか。
コメント残せよって話だけど。
270:仕様書無しさん
07/05/17 19:39:21
Dim bFlag As Boolean = False
If bHoge Then bFlag = True
If bMoge Then bFlag = True
If bNuge Then bFlag = True
If bHage Then bFlag = True
：
：
If bFlag = False Then CB.Checked = True
なんつーか、下っ手くそなコードだなあ…
271:仕様書無しさん
07/05/17 22:03:48
真偽定数と比較する奴ウザイ。
272:仕様書無しさん
07/05/17 22:30:17
おれ明示的に描くようにしてるわ
273:仕様書無しさん
07/05/17 22:50:57
真偽値と比較するのならなぜその結果をさらに真偽値と比較しないのか。
そしてその結果をさらに……
274:仕様書無しさん
07/05/18 00:13:13
>>270
こういう、似たような処理をひたすら羅列して、ウォーリーを探せみたいな
ソース書いてる人って、どんな気持ちで書いてるんだろう？
275:仕様書無しさん
07/05/18 00:14:06
あーめんどくせー
276:仕様書無しさん
07/05/18 01:57:47
>275
きっと本気でそう思ってるんだろうなぁ……
恐らく「コピペでガンガンコードが書けて俺様ってば超Cool!!」とは思ってない気がする
277:仕様書無しさん
07/05/18 07:36:40
コピペでコード書くのは全くCoolでない件
278:仕様書無しさん
07/05/18 08:12:42
>>277
おまけにバグまでコピッてるのを見ると殴り殺したくなる。
こういう時はgrepするとワラワラと湧いてくるんだよな。orz
279:仕様書無しさん
07/05/18 09:16:43
>>276
しかしどこぞの馬鹿に言わせると
馬鹿でも理解できるため良質なコードということになる。
良質なコードを生み出すことが超Coolでないわけなかろう。
280:仕様書無しさん
07/05/18 09:26:30
正しくは「馬鹿だけ」が最小コストで理解できるコードだろ
281:仕様書無しさん
07/05/18 09:31:22
>280
何か問題でも？
282:仕様書無しさん
07/05/18 09:41:40
>>281
一般人には理解できないコードなのだが。
283:仕様書無しさん
07/05/18 09:46:16
自分が一般人に含まれると勘違いしているのはイタさ倍増
284:仕様書無しさん
07/05/18 10:26:37
多分、板住民同士でレビューしたら自称一般人だらけだろうなｗ
自分の知識が普通とか一般だと思うのは非常に危険だぞ。
285:仕様書無しさん
07/05/18 11:19:51
>>274
ステップ単価だったりして。
ステップ単価の文化に浸った人はコピペ多いよなぁ。
286:仕様書無しさん
07/05/18 17:23:52
人月の狼
287:仕様書無しさん
07/05/18 17:25:39
ほら吹き狼
288:仕様書無しさん
07/05/18 19:41:19
>>270
こういうふうに書き換えるのは、上手普通下手で言えばどれですかね？
Dim bFlag As Boolean = False
If (bHoge Or bMoge Or bNuge Or bHage Or ...) Then
bFlag = True
End if
If Not bFlag Then CB.Checked = True
他の人のコード見て勉強する機会があまりないので。
270は、どれか１つのフラグがいらなくなったら１行削ればいいので、
案外上手なのかもしれんと思いました
289:仕様書無しさん
07/05/18 19:56:25
Dim bFlag As Boolean = False
If (False _
Or bHoge _
Or bMoge _
Or bNuge _
Or bHage _
Or ..._
) Then
bFlag = True
End if
290:288
07/05/18 20:11:38
>>289
ナルホド、これなら１行で消せますね。
他のコードで同じ書き方してました。
If 条件式でやるのはためらいますが。
291:仕様書無しさん
07/05/18 20:52:54
hogeとかmageをセットしてるコードのほうが気になる。
292:仕様書無しさん
07/05/18 23:47:38
自分はＶＢ（でしょ？）知らないんだけど
bFlag = bHoge Or bMoge Or bNuge Or bHage Or ...
とは書けないの？
293:仕様書無しさん
07/05/19 00:04:03
そこまで分岐するならビット演算とかどうよ？
294:仕様書無しさん
07/05/19 01:06:41
VBScript環境やまして.netはよー知らんが、レガシVBとかVBAでは
s = "hogehoge" _
'& "piyopiyo" _
& "fugafuga"
は文法エラーということを忘れてる人はおらんか。
いや忘れていいなら忘れてしまいたい貴方♪だが。
>292
書けるお。
295:仕様書無しさん
07/05/19 02:05:39
>>288
cb.checked = cb.checked Or ( Not ( _
bHoge _
Or bHage _
Or bHuge _
:
) )
296:仕様書無しさん
07/05/19 02:28:24
C言語で。
typedef void (*func)(void);
・
・中略
・
func pFunc = (func)0x00010000;
pFunc();
辞めよう、とまでは思わないが、組み込みってこえぇ、と思った。
他には
void free(struct Data *pstData){
struct Memory *pstMemory;
if(pstData==NULL)return;
pstMemory = (struct Memory *)(((char *)pstData) - sizeof(struct Header));
pstMemory->stHeader.nUsed = 0;
}
とか
value = array[-2];
とか
自分が今まで覚えてきたことを色々否定された気分になった。
297:仕様書無しさん
07/05/19 02:49:14
>>296
俺も怖い。組み込みは鬼門と考えるようにする。
298:仕様書無しさん
07/05/19 02:56:53
>>296
スマン。
2つ目のやつの問題点を教えてくれ。
これよくあったよ・・・＠携帯電話の網の中の人
299:仕様書無しさん
07/05/19 03:10:34
というか普通のfreeも大雑把に見ると>>296の二つ目みたいなもんだ。
300:仕様書無しさん
07/05/19 03:15:26
せめて
(uintptr_t)pstData - (unsigned)(&(((Memory*)0)->データ));
にできないかねぇ。
301:仕様書無しさん
07/05/19 03:20:18
>>298
プログラム全体で見ると整合性が取れてるんだけど、
free関数単体で見ると、引数pstDataからさらに前のアドレスってことは
一見アクセス出来る範囲外のアドレスを叩いてるように見える。
極端な話すると
int main(int argc, char *argv[])
{
char *str = argv[-1];
printf("%s\n",str);
return 0;
}
みたいなコトをしてるように見えるわけだ。
302:仕様書無しさん
07/05/19 03:29:37
>>300
うは・・・。
構造体のアライメントを運用で気ぃつけるとかはあったけど、
そういう発想は無かったな・・・。
さんきぅ。参考になります。
303:仕様書無しさん
07/05/19 08:47:17
>>296
value = array[-2];
これの動作は未定義なのでは？
304:仕様書無しさん
07/05/19 08:56:50
バグ、それも謎の挙動が多いと評判最悪のシステムのメンテを担当する事になった。
普通に順繰りに実行すればいい処理1～3をわざわざ
for(i=1; i<=3; i++){
switch (i){
case 1 : 処理1
case 2 : 処理2
case 3 : 処理3
}
}
みたいな謎のロジックで実行していたりしてアタマ痛い…他にも
char *hoge(char *s, const char *ct, int n){
if n==0{
strcpy(s, ct);
} else {
strcat(s, ct);
}
retuen s;
}
を遥かに大規模にしたような、標準関数を1つに纏めて、引数で実行する関数を
選択するようなのもあって、作った本人はかなり自慢げに
「これで標準関数を覚える必要が無くなり、ソースの可読性も増した」と
94年当時の日付入りでコメントを残しているんだが、
その問題の関数の前後で情け容赦なく素でstrcpyとか使われていて、
もう何が何だが･･･
リファインして良いか責任者に聞いたら、結構重要な部分だから、
汚いソースでも動いている以上手直し不可だって。
305:仕様書無しさん
07/05/19 09:11:22
>>304
上はよく見る。
下もよく見・・・るわけねえええええ
306:仕様書無しさん
07/05/19 09:13:56
>>304
上は各処理の後にbreak;はあるの？
あったらただの馬鹿だな。
307:仕様書無しさん
07/05/19 09:14:24
>>304
Fの仕事の後では全然なんでもないと感じる。
やつら車輪の再発明大好きで、標準関数同等品の再開発はもちろん、
それを作ったのが同じF内でも課が違えば、自分ところで再開発するからな。
一つのシステムに同じ機能が何箇所も独立してコーディングされてて、
成績上位者が軒並み逃げるのも判る気がする、と思った。
308:仕様書無しさん
07/05/19 09:33:28
>306
>上は各処理の後にbreak;はあるの？
実はある…orz
完璧、思いつきで組んでみた的な無駄なロジックいっぱい。
一つの関数内でローカル変数を初めはインデックスカウンタ、
下の方では値の交換のための受け皿に使ってたりもするし。
309:仕様書無しさん
07/05/19 09:57:15
>>308
>一つの関数内でローカル変数を初めはインデックスカウンタ、
>下の方では値の交換のための受け皿に使ってたりもするし。
この誘惑に駆られちゃうことがあるな…
新しい目的のローカル変数が欲しいんだけど、既にいくつものローカル変数があって
新しく宣言するのは気が引ける時とか。
「おやこの変数この処理の後は使ってないや、使っちゃえ」って感じで。
保守を優先するなら、目的が違えば新しく宣言すべき？（規約にもよるだろうけど、一般論として）
310:仕様書無しさん
07/05/19 10:28:46
>>309
> 保守を優先するなら、目的が違えば新しく宣言すべき？（規約にもよるだろうけど、一般論として）
当然だ。
ローカル変数多すぎってのは、リファクタリングの必要がある可能性があるよ。
311:仕様書無しさん
07/05/19 11:06:29
クソみたいなソースをリファインするのは我慢できるが、
クソみたいなソースと付き合うのは苦痛だな。
312:仕様書無しさん
07/05/19 11:34:09
>>309
確認したいが。
その関数内のローカル変数の現在の個数はいくつか？
（一般論を知りたいか？ｗ）
313:仕様書無しさん
07/05/19 11:53:02
>>309
ジジイみたいに関数の先頭でどっさり宣言するからだろ。
スコープ絞って宣言すれば、ほとんどそんなことにはならん。
314:仕様書無しさん
07/05/19 12:23:41
＞２９６
freeってそんなもんでしょ。組み込みじゃなくても
GNU libcのmalloc/freeはもっとスゴイ、という話を聞くけど。
315:仕様書無しさん
07/05/19 12:34:29
>>312
１０個かな。
２次元矩形の現在の開始～終了座標と更新前の同座標を保持する必要があって、
元データの構造体１個と、それぞれ単独変数に追い出した４個×２で９個。
それに、問題の変数１個。他にもあったかも。
単独変数に追い出した４個×２はなくてもいいと思うんだけど、それないとコード追いにくいって
メンバがいるもんで、残してる。
リファクタリングの精神忘れてました。ありがと。見直してみる。
316:仕様書無しさん
07/05/19 12:45:31
>>314
組み込みじゃなければmalloc/freeを使えば良いわけで。
317:仕様書無しさん
07/05/19 12:55:01
そういや昔居た会社での事。
引数の数が8個9個が当たり前で、うち6個はどの関数でもやり取りされてるから、
「構造体にまとめませんか？」って提案したら、「難しくなるから駄目」って却下。
やたら構造体とかポインタだとかに拒絶反応のあるところだった。
318:仕様書無しさん
07/05/19 13:03:11
>>306
>>304の上の処理はbreakが
あるかないかよりもswitchの後に続く処理が
あるかないかが重要なんでは？
319:仕様書無しさん
07/05/19 13:05:28
>>296
malloc/free周りは基本はそんなかんじでしょ。
俺も自作したとき、似たようなコード書いた。
320:仕様書無しさん
07/05/19 13:13:34
>>309
俺は、単純なカウンタ変数やインデックスの
受け皿の変数は使いまわしてもいいと思う。
例えば
int i, j, k;
を意味ごとに
int hoge_i;
みたいに名前を変えたくないしな。
321:仕様書無しさん
07/05/19 13:18:12
そんな素人コーディングだめだろ
俺等のところ同じようにしろ
int int_id_0000001, int_id_0000002, int_id_00000003
こうやって全部定義すれば仕様書みれば全部意味がわかる
322:仕様書無しさん
07/05/19 13:52:56
>320
必要な時にブロックを生成して、なかで
int iを幾らでも定義すりゃいいじゃん。
323:仕様書無しさん
07/05/19 13:58:09
>>309
グローバル変数として宣言すれば、宣言は１回で済むぞ。
同じものを幾らでも使いまわせる。
これは便利。覚えておけ。
324:仕様書無しさん
07/05/19 14:53:47
後輩がそのパターンをやてってくれて頭抱えてるんだが。
学歴あってもセンスないやつはダメだ('A`)
325:仕様書無しさん
07/05/19 14:57:01
>>323
そういう時は、自分で同じパターンの
読みにくいコードを書いてやって、
後輩に読ませれてみればよい。
326:仕様書無しさん
07/05/19 15:04:14
本人はそれがわかりやすいと思って書いてるんだから
意図が理解できるはずもない
327:仕様書無しさん
07/05/19 15:09:48
仮に>>324みたいな事をやって、
そいつがそのソースを即理解できたのなら、
文句ないんじゃねえの？
だって本当に分かり易かったんだろ？
328:仕様書無しさん
07/05/19 15:12:24
とりあえずLispとかPrologとかマイナー系言語で書いて
「俺には判りやすいんだからいいだろ」といっとけ
329:仕様書無しさん
07/05/19 15:29:50
>>327
自分が見て分かり易いかどうかより、
他人が見て分かり易いかどうかの方が重要なんじゃないか？
330:仕様書無しさん
07/05/19 15:32:20
「俺はいつも"他人が見て分かり易いコード"を書くように努めている」
という奴に限って糞コードを書く件について、どう思う？
331:仕様書無しさん
07/05/19 16:10:17
>330
そこの会社のわかりやすいコードのレベル＝クソコードなだけ。
書いているうちにそれしかかけなくなる罠
332:仕様書無しさん
07/05/19 16:31:38
みんないろいろなコメントありがとう。一般論もっと聞けるとうれしいけど。
>>320
i, j, k で思い出した。
漏れは i と j がぱっと見た目で区別しづらいことがあるから、
一文字変数は i, k, m, n, x, y, z, a, b みたいに、区別しやすい飛び飛びの
アルファベット使ってる。l も大文字の I と混乱すると嫌だから使わない。
i, j, k のように一文字アルファベット連続で使うのは、どんな理由があるのかな？
333:仕様書無しさん
07/05/19 16:33:59
>>323
遠慮しときます。
ウッカリ、ある関数で使った後にもかかわらず別の関数で以前の値を保持しているつもりで
使おうとする実装をやってしまって、デバッグで痛い目にあったことがある。
334:仕様書無しさん
07/05/19 16:41:27
>>332
大昔のFOTRANでI,J,K,L,M,Nで始まる変数は宣言なしで整数型になったから
335:仕様書無しさん
07/05/19 16:53:02
>>334
とてもためになりました、ありがとうございます。
会社に入ってから勉強した文系プログラマなのでこうした基礎教養がないです。
336:仕様書無しさん
07/05/19 17:13:00
N M
Σ Σ Aij
i=0 j=0
こっちの法の使い方がもとだとおもうけどねー
337:仕様書無しさん
07/05/19 17:19:11
元来FORTRAN（FORmula TRANslation）ってのは数式の処理目的だから当然だな
338:仕様書無しさん
07/05/19 17:25:33
飛び飛びって初めて見たな。
それはそれで激しく嫌だ。
339:仕様書無しさん
07/05/19 17:28:06
>>336
そして数式でiから始まる文字を使うのはiがindex(添え字)の頭文字だからだろうか。
iterationのiだと主張してる人もいたが数学に元を辿ると違いそうだなぁ。
340:仕様書無しさん
07/05/19 17:32:41
元FORTRAN屋なんて自分以外には何人生き残ってるか知らんが、
いまだにi～nで始まる変数名を見ると「整数型」と思ってしまう。
たぶん、一生治らんなw
341:仕様書無しさん
07/05/19 17:44:36
index
j
k
length
m
number
一文字変数ならi～nは整数だと感じる
342:仕様書無しさん
07/05/19 18:26:05
それは普通だろ。
むしろ、「倍精度実数型」や「文字列型」とか定数のiを作るほうがどうかしてる。
何でうちの会社はこういうのがいるんだろう…。難読化か？
343:仕様書無しさん
07/05/19 18:33:01
逆にaやbが整数だと気持悪い
344:仕様書無しさん
07/05/19 21:20:44
>>338
漏れもすっきりしてるわけでありません。
i と j を打ち間違えてチェックに時間をとられたり、i I と l の区別に一瞬
ためらうことがあるので、そういうところで時間ロスしたくないと思って、
ぱっと見ても視認しやすい文字だけ使うようになりました。
皆さんはそういうことないですか？ 漏れが下手なんでしょうね。
345:仕様書無しさん
07/05/19 21:58:25
>>344
そーゆー時はフォントを書き換えると良いよ
346:仕様書無しさん
07/05/19 21:59:34
>>344
うちのコーディング規約では、そもそも1文字の変数名が禁止。
それと意味の無い変数名も禁止。
例えば表を処理する二元配列のループ回すカウンタとかなら、
int nCntRaw,nCntCol;
とかになるかな。
347:仕様書無しさん
07/05/19 22:13:21
>>345
そういう意見出ると思ってました。
開発環境が固定されてなくて、設定を持ち歩いたり、いちいちフォントを設定しなおすのが
面倒なんです。
使える開発環境のデフォルトの設定ですぐ読めるコードを優先してます。
>>346
普段は漏れもそうです。一文字変数は、ループカウンタのような限定された状況だけですね。
こんな感じ。
for ( i = nStartRow; i <= nEndRow; i++ ) {
for ( k = nStartCol; k <= nEndCol; k++ ) {
348:仕様書無しさん
07/05/19 22:17:07
寿命の短かったり重要でない、変数名が短いほうがいい。
ソースがうるさくなる。
349:仕様書無しさん
07/05/19 22:19:17
>意味の無い変数名
だったら nXXXXって意味ないからやめろ
int CntRaw,CntCol;
でおけ
350:仕様書無しさん
07/05/19 22:21:05
int CR, CCでいいじゃん
351:仕様書無しさん
07/05/19 22:24:06
>>349
あー、説明不足で申し訳ナス。
メインC言語なんだが、「決まったプリフィクス」をつけることになってんだ。
癖でつけてしもた。
例えばこんなのが変数の先頭に付く
int → n
char → c
void * → p
int * → pn
構造体 → st
列挙型 → e
グローバル変数 g_
352:仕様書無しさん
07/05/19 22:28:17
ハンガリアンはいまどき、はやらないな。
353:仕様書無しさん
07/05/19 22:30:05
>>351
つか、M$すら使わなくなったDQN記法をなぜ採用する？
おまえの会社頭おかしくね？
354:仕様書無しさん
07/05/19 22:35:42
>>353
さぁ？そうなってる背景は知らんし、今んトコ困って無い。
良かったらどこがDQNなのか教えて貰えんか？
355:仕様書無しさん
07/05/19 22:45:41
一文字変数禁止なんてルールきめたやつって、コードを読み書きした経験がろくにないんだろうな。
356:仕様書無しさん
07/05/19 22:50:14
URLﾘﾝｸ(local.joelonsoftware.com)
ハンガリアン記法の暗黒面が支配権を得たのだ。
それがなぜなのか、どういう経緯でそうなったのか誰も知らないのだが、
どうやらWindowsチームのドキュメントライターたちが、不用意にシステム
ハンガリアンとして知られるようになるものを作り出したということらしい。
システムハンガリアンはlongを意味する"l"、unsigned longを意味する"ul"、
double word(これは、実際は、その、unsigned longと同じものだ)を意味する
"dw"のような、あまり役に立たないプレフィックスを使う。
システムハンガリアンでは、プレフィックスが教えてくれるのは変数のデータ型だけだ。
プログラマたちは、自分たちの使っているハンガリアン記法の誤解されたサブセット
がはなはだ煩わしくほとんど役立たずであることに気づき、反旗を翻したのだ。
Microsoftはついには人々に言い始めたのだ。「ハンガリアン記法は推奨しない」。
357:仕様書無しさん
07/05/19 22:55:28
うちの会社にもいまだにハンガリアンしてるやつがいて
ﾜﾛﾀ
358:仕様書無しさん
07/05/19 22:59:08
現在進行中の糞プロジェクトなんか、コーディング規約がめちゃハンガリアン
でかけりゃでかいほどハンガリアン率が高いと思う
359:仕様書無しさん
07/05/19 23:05:14
俺できるよねって感じで売り込んでるじじぃPGなんかは
ハンガリアン率が高い。
360:仕様書無しさん
07/05/19 23:07:36
JavaとかUnix系とかはハンガリアン使わないんじゃないの?
361:仕様書無しさん
07/05/19 23:08:03
int cntRaw,cntCol;
俺はこうかな。
362:仕様書無しさん
07/05/19 23:08:49
つかRawって何だ。Rowだよな。
363:仕様書無しさん
07/05/19 23:40:25
>>356を読んでみたが、デメリットが良く分からんかった。
個人的には変数名でデータの型がわかるだけで大分便利なんだが。
慣れてしまったら煩わしくも無いし。
慣れるまでに掛かるコストがメリットと釣りあわない(or無い)ので
ハンガリアンなコーディング規約はクソだ、ということか？
364:仕様書無しさん
07/05/19 23:47:00
>>362
冷凍と生のカウンタなんだろ
365:仕様書無しさん
07/05/19 23:51:15
>>363
型情報は名前にのせるほど重要じゃないってことだろ。
366:仕様書無しさん
07/05/20 00:07:38
>>362
フツーに間違えた・・・。
よく間違える。
>>365
JAVAとかRubyとかはさておき、C言語じゃ大事だと思ってたんだが、
世間的にはそういう認識なんか・・・。
勉強になりました。
367:仕様書無しさん
07/05/20 00:12:50
MSも捨てた記法だし
368:仕様書無しさん
07/05/20 00:18:39
MSはC言語自体捨ててる
369:仕様書無しさん
07/05/20 00:29:43
>>360
それが未だに使われてるから困る
死ねばいいと思う
370:仕様書無しさん
07/05/20 00:33:01
>>366
型情報を変数名に入れると、
型が変わる度に名前が変わる事になる。
そんなのおかしい、不自然だと思わないか？
例えば、「身長」がmm単位からcm単位に仕様変更され、
型が整数型から浮動小数点数になっても、身長は身長だろ？
371:仕様書無しさん
07/05/20 00:33:53
>>362
cunt rawの略。つまり生まんこってことだ。
>>363
変数の型を変えたい時に面倒なんだよ。
あと、型情報が重要じゃないわけではない。
変数の宣言箇所を見るのが面倒くさくなるほど
ソースをでかくする設計をまず見直せって事でしょ。
プリフィクスなんていらん。
372:仕様書無しさん
07/05/20 01:03:05
読み返してみたけど。
プレフィックスをつけるべきだ
という発言は誰もしていないね
373:仕様書無しさん
07/05/20 01:10:10
>>363
変数名って適当な長さがあるでしょ。
その中に重要な情報を載せていくと型名を載せる余地が無くなるわけだ。
型名は探せばわかるが、変数名に載せないとわからない情報がある。
あとは、機械的にチェックするツールが無きゃ信用できないから意味が無いと思う。
374:仕様書無しさん
07/05/20 01:11:44
>>372
皆>>354の質問に答えてるだけ
375:仕様書無しさん
07/05/20 02:09:24
if(i==0){
foo();
}else{
//空文
}
376:仕様書無しさん
07/05/20 02:18:26
規約でelse省略不可だったんじゃないの
377:仕様書無しさん
07/05/20 02:34:42
もともと処理あったけどいらなくなって消して、elseだけが残ったとか？
378:仕様書無しさん
07/05/20 02:42:21
>>269の逆バージョンという可能性も
379:仕様書無しさん
07/05/20 02:59:30
if(i!=0){
//空文
}else{
huu();
}
380:仕様書無しさん
07/05/20 07:10:11
Javaでハンガリアンやりたがる奴は頃してもいいよね。
381:仕様書無しさん
07/05/20 07:23:06
>>370
型が変わると変数名も変えないといけないってのはハンガリアン否定論としてよく聞くけど、
実際問題、型を変える頻度ってどれくらいあるもの？
変えるのだって、「拡張する必要があって止むを得ず」ならともかく、「使い方を間違ってたから
変更」みたいなのなら、それは設計をちゃんとやってないただのバカだと思う。
変数名の他の部分で、以前の型に依存した処理をやってて、バグを招く可能性がある。
それに、「変数名の型を変える」だけなら、今はエディタやIDEがマシになってるんだから、
一括置換ですむのでは？
>>356のリンク先で議論されている「チェックのしやすさ」の点で、システムハンガリアンも
有効活用できると思うんだけどな。こだわりすぎるとよくないけど。
382:仕様書無しさん
07/05/20 10:15:33
変数名を変えられるエディタなら、
変数の型もでてくるんでねーの。
＃ま、クラス・構造体に対して、システムハンガリアンは
＃大抵のところ無力だから、どーでもいいけど
383:仕様書無しさん
07/05/20 12:51:14
>>380
Yes
384:仕様書無しさん
07/05/20 12:54:09
ハンガリアン使ってるのはうざいなぁ…
醜くて仕方がない
385:370
07/05/20 13:01:44
>>381
頻度とかは無関係。
別に同じシステム内に限った話じゃなく、
全く別のシステムでも、同じ物を表す変数の名前を付ける場合でもいい。
同じ物を示すなら、当然同じ名前を付けるだろ？
名前に表現方法を入れるのは不自然だと言ってるんだよ。
身長の例でいくと、
単位がmmでもcmでもｲﾝﾁでも尺でも、身長は身長だ。
混在して使う必要がないなら、名前に表現方法など不要だろ？
386:仕様書無しさん
07/05/20 13:33:41
>>385
単位がmm、cm → 基本型
身長 → クラス
わざと混同してるのか？
387:仕様書無しさん
07/05/20 14:16:48
＞ハンガリアン
どーでも良いが、そろそろ大分スレ違いじゃまいか？
388:仕様書無しさん
07/05/20 15:06:41
相変わらずヴァカだなM$
389:仕様書無しさん
07/05/20 15:47:53
だから素人に文献書かせるとろくなことにならない
390:仕様書無しさん
07/05/20 15:51:12
自分が今書いてるところの変数の型も覚えてられないような奴とか、
覚えてられなくなるような無駄に長い処理書くような奴は
プログラム書く資格ねぇよ。
こう言うと「他人が書いたのを解析するときにいいじゃないか」とか出てくるが、
「そのハンガリアンで書かれてる型が実際の型と一致してること」はまったく保証されないんだが？
>>381
頻度は確かに低い。低いが、無いわけじゃないだろ？
それに、型に依存した処理をやってて型変更時バグるってのは、「変更時にチェックしたか」が問題であって、
変数名をハンガリアンで書いてようが書いてまいが同じこと。
391:仕様書無しさん
07/05/20 16:51:49
ハンガリアンは
その変数が出てくるたびに
いちいち/*コメント*/つけるようなもんだ。
392:仕様書無しさん
07/05/20 16:58:58
宣言部分を検索すれば済む話だよね
393:仕様書無しさん
07/05/20 17:12:54
検索するようでは駄目だ。
もう関数（メソッド）の長さの話になってしまうが。
394:仕様書無しさん
07/05/20 18:23:13
っつーかIDE使ってれば変数の型なんぞすぐに知ることができるだろうに
いったいいつの時代の開発環境なんでつか？
395:仕様書無しさん
07/05/20 18:32:51
viつこーてます
396:仕様書無しさん
07/05/20 18:53:55
VisutalStudio を使いまわしてると
わかるとおもうが、勝手に変数名に
dwとか付いたり開発者が言いくる
められたのかどうかしらないが、
仕様的にヴァカすぎる
その仕様を疑いなくそのまま放置する
M$の幹部どもも率直にヴァカまっしぐら
というかハンガリアン広めておいて
元の文献の趣旨理解していないとは
どういうカラクリになったらそうなる
んじゃい！
397:仕様書無しさん
07/05/20 21:08:12
>>390
型変更した時に変数名を変えれば、それによる挙動のチェックを
モレが出ないようにフレームワーク化出来る。
あと
＞「そのハンガリアンで書かれてる型が実際の型と
＞ 一致してること」はまったく保証されないんだが？
コーディング規約守れボケ。
約束事が守られてない前提で仕事出来ん。
規約に無いのにハンガリアンに頼る奴のことは知らん。
398:仕様書無しさん
07/05/20 21:36:53
IDE全盛の今となってはハンガリアンが嫌われるのもよくわかるけど、
他人のコードがハンガリアンだからと言って貶す資格はないよね。
まあ、結局はコーディング規約守れって話だよね。
399:仕様書無しさん
07/05/20 21:57:44
いや、だからハンガリアンがコーディング規約に無い以上、使ってもらっては困るんだがw
>型変更した時に変数名を変えれば、それによる挙動のチェックを
>モレが出ないようにフレームワーク化出来る。
あほか？これのどこがハンガリアンに関連すんだ？テストフレームワークとかコンパイラの仕事だろが
よけいな仕事をやっておいて自己満足してんじゃねえぞ
400:仕様書無しさん
07/05/20 22:02:40
このスレは基地外が多いですね
401:仕様書無しさん
07/05/20 22:07:41
>>399
コーディング規約にハンガリアンを入れるのを否定してるんじゃないの？
＞あほか？これのどこがハンガリアンに関連すんだ？テストフレームワークとかコンパイラの仕事だろが
型変える→宣言箇所の変数名を変える
→変数を使ってるところをチェックしたら、使用箇所の変数名を変える
という風にルール化すると、未チェック部分があったらコンパイルが通らない
402:仕様書無しさん
07/05/20 22:22:48
すべてを置換
403:仕様書無しさん
07/05/20 22:25:42
面倒だから、みんなboost::anyにしようぜ。それでハンガリアンも問題無し。
404:仕様書無しさん
07/05/20 22:29:26
わかった。
荒れる元ってだけでも
ハンガリアンは使わない方が吉、と。
論争する時間がもったいないわい。
405:仕様書無しさん
07/05/20 22:34:29
ええー、組み込みならシステムシステムハンガリアンは結構有効だよぉ
406:仕様書無しさん
07/05/20 22:37:43
Win16でFARポインタとNEARポインタを区別したいときには良かったけど
組み込みだとなにがいいのさ。
407:仕様書無しさん
07/05/20 22:44:41
Microsoftはついには人々に言い始めたのだ。「ハンガリアン記法は推奨しない」。
408:仕様書無しさん
07/05/20 22:53:52
ポインタのアラインとか、データ範囲（-0x80~0x7F）とか。
リソース少ないとなんでもかんでもlongにはできん。
409:仕様書無しさん
07/05/20 23:34:36
:
:
int i = 0;
array[i] = i++;
今までよく動いてたと思う。危なっかしいったら。
410:仕様書無しさん
07/05/20 23:45:08
なんかようわからんけど、変数名の頭にintとかfloatとか付けるのは
それが的確な名前ならそれでもいいという考え。
ハンガリアンが愚かなのはint型だからintってprefixを付ければ良い
とかいう思考停止故だと思ってる。
411:仕様書無しさん
07/05/20 23:56:50
ポインタの p とかはあった方がいいなーと思うことが多いな
それより vector が困る。
std::vector<HOGE> hogeVec;
HOGE hoge;
hogeVec.push_back(hoge);
Vec とかつけるのあまり好きでないんだが、他にいい案が浮かばない
412:仕様書無しさん
07/05/21 00:05:03
それあとでやっぱりdequeにしよう、とかいったときどーするの？
413:仕様書無しさん
07/05/21 00:07:05
>>411
うん、だから困ってるんだよ
変えるべきは下の HOGE hoge; なのかもしれないけど、いい案が浮かばないの
414:仕様書無しさん
07/05/21 00:15:38
名前の変更なんか、IDEのリファクタリングで一発じゃん。
hogeVecはいかがなものかとは思うが。
415:仕様書無しさん
07/05/21 00:29:39
ハンガリー人はテンプレートパラメータにどんな
プリフィックスをつけるの？
416:仕様書無しさん
07/05/21 00:54:41
>411
月並みだがVecを何の目的で使うかジャマイカ
ListでもBagでもCollectionでもお好きなのをだうぞ
417:仕様書無しさん
07/05/21 01:34:11
ﾊﾝｶﾞﾘｱﾝ、ﾊﾝｶﾞﾘｱﾝとか言うﾔｼに限って、
ｸﾗｽのﾌﾟﾘﾌｨｯｸｽがclsだったり、構造体のﾌﾟﾘﾌｨｯｸｽがstrとかだったりする。
ﾊﾝｶﾞﾘｱﾝの意味、利点を履き違えてるとしか思えない。
そこが、ﾊﾝｶﾞﾘｱﾝが愚かである所以だと思われ。
418:仕様書無しさん
07/05/21 01:36:11
>>414
それいったら型が何かなんて
IDEなら一発ジャン。
いいっこなしよ。
419:仕様書無しさん
07/05/21 01:59:42
>>417
strはstringとかぶるぞ。
420:仕様書無しさん
07/05/21 02:10:00
自分はその
「IDEが無ければ開発作業自体が出来ないPGを多量生産するような考え方」
は承服しない。
421:仕様書無しさん
07/05/21 02:12:34
>>420
テキストエディターが神
の派閥なわけ？？？？
422:仕様書無しさん
07/05/21 02:21:36
>>421
そんなものに派閥なんかあるか！ｗ
エディタが使われていないころから仕事をしているPGさ。
423:仕様書無しさん
07/05/21 02:28:19
>>422
「emacsは最高のIDE」という派閥がある
424:仕様書無しさん
07/05/21 02:31:00
>>422
あ・・・あれか？？
ベタでCやベーシック書いてた時代なのか？？
MSX世代の予感・・・・
425:仕様書無しさん
07/05/21 02:40:13
テキストエディタが神とは言わんが、
現局に行ってviしか無い環境でソース弄くるというのはある・・・
#もちろんデスマ中
426:仕様書無しさん
07/05/21 02:41:12
>>425
おまｗｗｗ
こんなところ書き込んでる場合じゃねええええ
427:仕様書無しさん
07/05/21 08:22:04
>>424
BASICにはエディタが組み込まれてたがな（俗にカーソルエディタと呼ばれてた）
エディタなしっつーとパンチカードの時代になるな
428:仕様書無しさん
07/05/21 08:33:23
コーディング用紙に書いてパンチャーに渡す
そんな時代もあ～ったねと～♪
429:仕様書無しさん
07/05/21 09:50:33
辞めようってほどじゃないんだけど、もうとっくに辞めてった奴が残した遺産。
BOOL InitInstance( HANDLE hInstance, int nCmdShow )
{
HANDLE hWnd;
hWnd = CreateWindow( 中略 );
if ( hWnd == NULL ) return ( FALSE );
ShowWindow( hWnd, nCmdShow );
UpdateWindow( hWnd );
return ( TRUE );
}
なんだその無駄な改行は。
430:仕様書無しさん
07/05/21 10:31:15
昔から一行おき／二行おきに書く人はいたけどねｗ
431:仕様書無しさん
07/05/21 10:46:14
コメント行を機械的に取り除いた跡かもしれない。
…UpdateWindowに何行コメント書いてたんだｙｐ！
432:仕様書無しさん
07/05/21 10:58:15
ハンガリアン云々と高尚な話題で議論出来る人たちが裏山しい。
俺なんか、今戦ってるソースが
Select Case Ret
Case 1
Call FuncA( 1 )
Case 2
Call FuncA( 2 )
Case 3
Call FuncA( 3 )
Case 4
Call FuncA( 4 )
Else
End Select
こんなんばっかりだぜ('A`)
433:仕様書無しさん
07/05/21 10:58:58
あ、>432の一番下のElseは無しね。
434:仕様書無しさん
07/05/21 12:38:48
>>432
とても見やすいコードダネ
435:仕様書無しさん
07/05/21 13:56:54
>>427
>パンチカードの時代になるな
紙テープもお忘れなく。
ソースの修正ツールはハサミとノリだ。
436:仕様書無しさん
07/05/21 14:06:17
>>435
磁気テープもお忘れなく。
修正ツールはユーティリティ起動とそれに対するバッチスクリプトを含むJCLだ。
437:仕様書無しさん
07/05/21 14:26:36
宇宙戦艦ヤマトの記憶媒体は磁気テープだぞ！
438:仕様書無しさん
07/05/21 14:39:23
jspとjavascriptでコードが汚いのは最悪だ、、、
439:仕様書無しさん
07/05/21 16:58:08
紙テープを目視で読んで東京湾に出現した怪獣を特定する。
440:仕様書無しさん
07/05/21 20:06:28
JSPとかJavaScriptが汚いのはもうしょうがないよ。
あれはそういう人力で何とかしましょう、っていうアーキテクチャだと思う。
さっさと諦めて他人に押し付けた方がいい。