ふざけた変数名を使う奴

気分です、気分

if (result == true) {
の形は、
if (result = true) {
と間違えてもエラーが出ないからあまりお勧めしない。
コーディング規約で禁止した方がいい。

そういうや学生の時に家庭教師をしてた時の事を思い出したが、
数学できない子っていうのはこういう思考するんだよな確かに。
しかしいくら2chでもレベル低すぎる話題だなw

>>790
> つか、書き出す前にちゃんと設計しろよ…

その発想はウォーターフォール型だぞ。

ウェブアプリとかリリースサイクルが短いソフトとか
頻繁にバージョンが上がっていくタイプだと
最初に設計をしておくのは無理。

常に小さな再設計をし続けないと破綻する。

>>834だけど、そう、スペルミスも込みなんだよ

>>300
区別がつかなくなるようなコードにしなければいいんじゃない？

ハンガリアンについて語るスレって無かったっけ？

prt

ひぃ？

>>818
まともなコンパイラなら if( foo = true )は ==と間違えてないすかって警告がでる

何だAlgol時代の化石野郎かｗ

おっとconstじゃないのにCが入っちまった

本当のド素人が作ったプログラムなんだな。
今そんなの作ったら瑕疵責任ものだな。

変数名という仕様を全否定してるな
依存したくないならもう機械語で書けよ

標準ライブラリのヘッダでtypedefが使われているから
例えば32ビットから64ビットへコンパイルし直すだけで
対応できるともいえる。まプログラムがちゃんと書かれて
いればの話だけど。

辞書引けよ

>>289
名称が動詞(Employ)って事は、そのテーブルはエンティティじゃなくて
関連を表すテーブルなんじゃね？
それが「データテーブル」だって言うのはおかしくね？

Lispで「S式(S-Expression)」(Lispの概念のひとつ)という語を識別子に
含めるときは sexp と略すという習慣があるなー。

ついでにいうと、真偽を問う述語(predicate)関数には、語尾に p を付
けるという習慣もある((evenp 10) => 真 (oddp 10) => 偽 など)。

つまり sexp で「やらないか」

>>126を脳内スルーしてたけど
ようやく分かった俺アfホフ

日本語版foo,barじゃないのかね
調べてみたら
momotaro
urashimataro
kintaro
あたり使って解説してるページはいくつかあった

つまり、>>158は不幸になるべきである

>>416>>418
無知って恥ずかしいな。
例えば分析 “anal.”とでも検索すればどれだけ一般的な表現か猿でも分かる。
もちろんこれは日本独特の略し方でもない。

顔真っ赤www

int szTmp

となってたらなんかヘンじゃね？、みたいなそんなノリ。

>>130
アプリケーションハンガリアンの話なら、規約として規定されるのが前提だろうから、
略称そのものから意味を推測出来るようにする必要はないのでは？
利点はあるかも知れないけど、本質じゃないかと。

そもそも略ですらある必要ないですよね。
リンク先の例では、意味を持つ記号(プレフィクス)に略称の文字列を割り当てただけで

ﾌﾌｯ

昔（20年ほど前）、変な後輩の新人君がいた。

ホストのTSSで待機ジョブに「KOKINJI」てジョブIDがあったから
「○○君、このジョブ名は？」って聞いたら
「それは秘密です」

しばらく意味わからんかった。桂小金治のこととは。

一見、真面目そうに見える子だったんで、
「なんでこんなジョブ名にしてるの？規約に従わんの！？」って聞いたら
「命名規約に沿ったら全部同じに見えるから、自分のジョブが目立つようにしたんです！」ってマジレス。

ああ、ただの馬鹿じゃないなと。

ほかの構造を考えるための工数を出してくれるんなら、いくらでも考えまっせ。

ただのバカじゃないか。

>{}の中身が a=true; でelseの中身が a=false; だろw

おめーは、北京原人か？

>>720
意味を持たせることが出来るように考えられたのが、
変数名という仕組みだ。

>>722
>基本的に自然言語には依存しないようにしてる。
それが乱数とかならば、まぁ認めてやる。
連番なら殺す。

>>735
＞意味を名前に求めるなんてよくないよ。
ずいぶんラジカルな思想だな。それともストイックと言うべきか。

>>427
>>3

489って何かのコピペ？
違う意味でレベルが高すぎるので突っ込みにくいんだが

なんか偉そうに言ってるが、
signed と unsigned　じゃ大違いだろ
printfなんかでの出力のされ方が違うのはもちろん、
shift演算に対する動作が異なるのを知らんのか？

＞ちなみに、そのババアが電話番として得ていた給料は
＞おれが作成したブツを換金することで得ていたわけだが・・・

利益を生む活動だけで会社が成り立ってると思ってんの？
金にならない雑用もたくさんあって、誰かがそれをやらなきゃいけないわけだが。

これだからガキは(笑)

はい

まずsearchじゃん

if (result == true) {…}
は結構みるなぁ。な

>323
審議拒否（ＡＡ略

このスレは異常にVB廚が多いな。
>>306の
>GUI部品は(1)少数のクラスを、(2)頻繁に使う分野だからbtnHogeとかtxtHoge
>といった命名法が実際適合的だ。
なんてレスがあるが、btnとtxtを一つにしてHoge用コントロール作るとかいう発想はVB
屋には無いのか？
hoge.button
hoge.text
と使えるようにした方が可読性も実用性も高井田ろうに。
あと、ハンガリアンネタだが。システムハンガリアン使う奴は、
型が変更になったときどうするんだろうね？
仮に一関数10箇所でその変数が使われていたら全部修正すんのかね？
まぁ。プリフィックス自体は否定しないからプロジェクト上整数の意味でi
を定義し、
Dim ix as Short,iy as Long
の様に使うのは構わんと思う。整数以外(ビットフラグやディスクリプタ)の混入を防げる。

不良品を扱う関数で変数名をDQNって書いてる同僚がいた

thru = true; ならわかるが、
thtuFlag = thru; は嫌だな

>>465
ｶﾞｯ

変数じゃねーし

オブジェクト指向ならメソッドでIsParam()にするべきでは
他は知らん

>>30
#define thru 1
は見たことある。スルーってなんだ？と思った

>>794
「バカ」は必要ない。

おれはあえて直さないが、雑談のときに「そういえばこういう変数名があったけど、
あれってスペル間違ってますよね」って言う。

じゃあ何が正しいんだよ？と言われそうだから
どうするのがいいかも答えよう。

1. まず、Aの処理を作る。そのコードの量は適当でいいが500行ぐらいとしよう。
2. 次にBの処理を作るがここからが違う。

長いと思ったらAの処理のダイエットすること。

AとBの内容が似ているからといって、まとめるのではなく、
Aの中から汎用関数、つまりそれはAやB以外でもまったく別のプロジェクトでも
使えるような汎用関数。一つ一つはとても小さな処理になる。
そうするとAの処理はかなり少なくなる。

Bの処理ではもちろんその汎用関数を使って書くからAと同等に短くなる。
一見似ているように思えるが、汎用関数あるため、その処理にAやB特有の
コードが入る余地はなくなる。

そうやってコードが長くなるたびに、汎用関数に追いやってA処理を短くしつつ
処理を増やしていく。そしてこのAの処理は決してB〜Eと混ざることはない。
Aの処理には入力、メイン、他、出力の処理が一直線に並ぶ。

>>746
それは正しいのかもしれないが、回答としてはちょっとずれてる。

添付ファイルにtmpFileって付けたアホ氏ね

家の会社にカウンタにijkを使う馬鹿がいる

足りなくなったらii,ij…って具合に増やしていく…

そんなソースの修正頼まれたらこんな時間になったよ！、死ねよ禿

ass はともかくanalは別に普通だな。
むしろそれで妙なモノしか思い浮かばない奴のお里が知れる。

ヘイジャーップ！

アセンブラだとsrcとdstの順番は言語仕様として決まっているが、
nasmとgasでその並びが真逆だという。

VBにGlobalなんてキーワードないぞ

>>18
ゲーム屋乙

Cで書いたからってプログラムが最速になるわけでもない

>>554
そんなことをわざわざ書き込まんでよろしい

つ〜か、Ｃ知らずにコンピュータを理解できんだろ。

>>31
えええ？一体何処でこんな変なプログラムに出会うんだ？
書いた人よりもむしろ出会った場所をを知りたい。

メールとかでもanalにするのか？
スパムとして扱われても文句言えないと思うが

>>414
つかわねーよ

>>530
ちょっと横レスで申し訳ないんだけど、
皆ある程度「前提」を踏まえてああしようこうしようって話してるのに、
なんで分子やら何やらまで戻って考えなきゃいけないの？

そうすることでスレタイの疑問が解決することにどう繋がっていくの？

>>337
ああすまん、リアルで間違ってたねw

対偶をとっていえることは、
「ハンガリアンを禁止しなくてもよい場面では略称から元の意味がわかる」
に過ぎないわけで俺が主張するようなことは確かに言えないわ。

みんな本当ごめんｗ

しかしまぁ、将来型が変更になるのをみこしてtypedefを使うのは
決して間違いじゃないわな。つうかむしろ常套手段ともいえる。

int型のappleという名前の変数は実はその実体が色即是空であり、
ライオンから見たらただの2値論理にすぎないから大して意味は無いんだけど、
でもコンパイラから見たらやっぱりint型のappleなんだから、
いくら人間が物事に対して究極的実体を信じていても、
型を変更したりする時は置換機能なんか使わないでtypedefを使ってあげなさい。

ごめん。

「バカ」な人が必要ないのではなく、「バカ」だと書く必要が無い
という意味だけど。

>>315
残念ならが俺もそのように感じる。
俺も基本ハンガリアンなんて使うな、って立場でその上でしかし
馬鹿の一つ覚えはどうか、と言ってるつもりなんだけど
そこを理解してもらえないみたいだね。

実際問題Windows Form上のコントロール名の命名をハンガリアンでやることの
有用性っていうのはやってみればほとんどのプログラマが納得することだと
思うんだけど。

txtFileName
fileNameTextBox

mnuEnterFileName
menuItemToEnterFileName

まあでも教条主義的に「馬鹿の一つ覚え」で食わず嫌いな奴もいるからなあ実際。

>>314
それもそうだし、やっぱり同じ名前の違うものが混在するコードというのは混乱を招く。
にもかかわらず、しばしば(Control.Fontのように)型名と同じ名前のプロパティを
作りたい場面がある。

だったらやっぱり型名をCなりSなりEなりでプリフィクスすべきだろう。
プロパティをキャメルにすることがよいアイデアとは思えない。

あと、ドトネドだと型がクラスなのか構造体なのかを強く意識する必要があるわけで、
その役にも立つ。