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が汚いのはもうしょうがないよ。
あれはそういう人力で何とかしましょう、っていうアーキテクチャだと思う。
さっさと諦めて他人に押し付けた方がいい。