一文字変数を使うバカは人生の敗北者part1

[1 仕様書無しさん 2013/03/30(土) 11:01:29.14]

int i;←バカ意味わかんねーよ

[134 おじゃばさま 2013/04/01(月) 09:55:28.31]

>>133
それは型の方だから関係ないだろうし、クラス名は長くて普通だろう。

[135 仕様書無しさん 2013/04/01(月) 10:07:46.81]

型変数という変数なんだが...

[136 仕様書無しさん 2013/04/01(月) 11:45:25.10]

>>133
もちろん、ContainerType とか AllocatorType とか、それが何なのかを書くべき。


それとは別に数学などの慣例なら i j k n x y z などはそのまま使うのが当然。
vt = v0 + g * t;
で十分わかりやすい。

[137 おじゃばさま 2013/04/01(月) 19:13:57.38]

>>136
学生の組み方だな。
単純な数式ならマクロにすべきで、
複雑な数式なら関数にして長い変数名を使うべきだ。

[138 仕様書無しさん 2013/04/01(月) 19:32:22.27]

マクロってC言語のか？
C++ではDeprecatedなのだが。

[139 おじゃばさま 2013/04/01(月) 20:14:04.66]

>>138
マクロはレガシーCの場合だな。
クラス型言語の場合は、まず算術クラスにないか探す。
なければ自分で作るが、長い変数名を使うのがいいだろう。

[140 仕様書無しさん 2013/04/01(月) 20:58:24.66]

ドカタは数学の素養が無い文系が多いから
数学の慣例なんて意味が無いよね

[141 仕様書無しさん 2013/04/01(月) 21:11:04.05]

>>118はコピペだぞ
ttp://archive.linux.or.jp/JF/JFdocs/kernel-docs-2.2/CodingStyle

[142 仕様書無しさん 2013/04/01(月) 21:53:26.30]

>>140
自己紹介乙ｗ

[143 おじゃばさま 2013/04/01(月) 22:03:06.01]

>>140
ああ、意味ない。
学校の授業ではないのだから。

[144 仕様書無しさん 2013/04/01(月) 22:07:57.60]

>>141
だからどうした？

「コンパイラが知っている」ということに
意味が無いのは本当だろ？

ソースコードは汚くても、コンパイラは適切に処理できる。
だからって汚いコードでOKということにはならない。

人間が理解しやすいコードを綺麗なコードと言うんだ。
人間のことを一番に考えましょう。


ハンガリアンがだめなのは、コンパイラが知っているからではなく別の理由。

btnRun、buttonRun、runBtn、runButton、run_button
color_number、numColor、nColor、iColor
これらはハンガリアンか、それとも単に名前を略しただけか、
前につけるのはNGで、後ならOKなのか？
ハンガリアンの本当の問題点は何か。それを本当に理解している人は少ない。

[145 仕様書無しさん 2013/04/01(月) 22:15:29.99]

>>144を読む限り>>144はハンガリアンを理解しているようには見えない。

[146 仕様書無しさん 2013/04/01(月) 22:17:39.01]

初出が「ハンガリー方式」な時点で察してあげなよ

[147 仕様書無しさん 2013/04/01(月) 22:21:11.68]

>>145
バカか？

俺は理解している、なんて一言も書いていない。
こういう完全に理解していない奴は議論をするなという風潮が
日本をダメにした。

[148 仕様書無しさん 2013/04/01(月) 22:22:45.09]

>>145
そういうことだ。>>144がどうかではなく、
お前はどうなんだ？ってことだ。

[149 仕様書無しさん 2013/04/01(月) 22:26:12.17]

そんなこと理解する必要ない
ユーザーからは一切触れることのないどっちでもいいことだ

[150 仕様書無しさん 2013/04/01(月) 22:27:40.23]

>>146
念の為に言っておくと、初出はこれの英語版

Encoding the type of a function into the name (so-called Hungarian notation) is brain
damaged - the compiler knows the types anyway and can check those, and it only
confuses the programmer. No wonder Microsoft makes buggy programs.

って書いてあるから、Hungarian notation

Hungarian notationの日本語訳がハンガリアン記法

[151 仕様書無しさん 2013/04/01(月) 22:35:38.56]

Hungary とはどこにも。

[152 仕様書無しさん 2013/04/01(月) 22:44:17.08]

Hungarianってかいてあるよ

> なお、ハンガリアン記法の名称は考案者チャールズ・シモニーがハンガリー出身であることに由来する。

[153 仕様書無しさん 2013/04/01(月) 23:17:45.02]

すぐに話題がそれるのが、オマエラの悪いところ

[154 仕様書無しさん 2013/04/01(月) 23:42:47.59]

ハンガリアンでもアプリケーションハンガリアンはOKとされている。
ただ最近の言語はクラスや名前空間できっちりオブジェクトを識別できるので
アプリケーションハンガリアンは出番がなくなった。

[155 仕様書無しさん 2013/04/01(月) 23:44:10.81]

742 名前：仕様書無しさん 投稿日：2013/03/31(日) 22:03:39.55
>>692,>>699
思い込みで勝手にニュアンスを付加するな。
正確に訳すと、以下のようになる。

One-character variable names should be avoided except for temporary "throwaway" variables.
一文字名の変数の使用は避けるべき。ただし、一時的な「使い捨て」変数は除く。

747 名前：仕様書無しさん 投稿日：2013/04/01(月) 05:01:24.13
>>742
なにその中学レベルの訳文w

A should be B except for C の
except for Cは「Cは除く」よりは「Cの場合はその限りではない」のほうが原語の意味に近い。
もし「Cは除く」ぐらい強い除外をするのであれば、
A except for C should be B.
もう少し柔らかめな表現なら
A other than C should be B.
という英文になる。こんぐらいわかっとけ。

749 名前：仕様書無しさん 投稿日：2013/04/01(月) 09:02:33.58
>>747
＞except for Cは「Cは除く」よりは「Cの場合はその限りではない」のほうが原語の意味に近い。

勝手に自説に有利なように訳語を捻じ曲げるな。
そういう意味になる場合もならない場合もなる。
特にそういうニュアンスを示す表現が前後に無いのであれば、
except forはプレーンな「除く」という言葉を使うべき。

[156 仕様書無しさん 2013/04/01(月) 23:45:13.89]

749 名前：仕様書無しさん 投稿日：2013/04/01(月) 09:02:33.58
>>747
＞except for Cは「Cは除く」よりは「Cの場合はその限りではない」のほうが原語の意味に近い。

勝手に自説に有利なように訳語を捻じ曲げるな。
そういう意味になる場合もならない場合もなる。
特にそういうニュアンスを示す表現が前後に無いのであれば、
except forはプレーンな「除く」という言葉を使うべき。


750 名前：仕様書無しさん 投稿日：2013/04/01(月) 10:04:55.71
＞もし「Cは除く」ぐらい強い除外をするのであれば、

ほとんど英語じゃなくて日本語力の問題だな。
「除く」は単に除外の意味であって、強いも弱いも無いよ。


752 名前：仕様書無しさん 投稿日：2013/04/01(月) 11:54:17.90
まあどっちにしても除かれてるのなら使っていいってことじゃん。


753 名前：仕様書無しさん 投稿日：2013/04/01(月) 12:11:16.23
そう。 この文が意味するところは、それ以上でもそれ以下でもない。


754 名前：仕様書無しさん 投稿日：2013/04/01(月) 22:10:17.14
いや、歴史的経緯でしかたなく見逃してあげる。というニュアンスが含まれているのだよ


764 名前：仕様書無しさん 投稿日：2013/04/01(月) 23:15:40.21
>>754
訳者による過剰な深読みって奴だな。

[157 仕様書無しさん 2013/04/01(月) 23:47:56.25]

２行にまとめろゴミ

[158 仕様書無しさん 2013/04/01(月) 23:51:53.03]

一文字変数
使用禁止

[159 仕様書無しさん 2013/04/01(月) 23:54:14.57]

ハムスターの話題と聞いて

[160 仕様書無しさん 2013/04/02(火) 00:16:24.55]

>>157
は屑

[161 仕様書無しさん 2013/04/02(火) 00:58:20.95]

>>152
ハンガリアンとはあるがハンガリーとはありませんね？

[162 仕様書無しさん 2013/04/02(火) 02:21:11.83]

プログラマは人生の敗北者

[163 仕様書無しさん 2013/04/02(火) 02:39:01.34]

何を今更

[164 仕様書無しさん 2013/04/02(火) 03:01:46.10]

>>161
アメリカンとは書いてあるがアメリカ人とはありませんね。みたいなこと言うなよｗ
ハンガリアンで、ハンガリー人って意味なんだよ。

[165 仕様書無しさん 2013/04/02(火) 03:02:20.13]

訂正

ハンガリアンで、「ハンガリー人」や「ハンガリーの」って意味なんだよ。

[166 仕様書無しさん 2013/04/02(火) 03:05:33.49]

http://www.knonline.net/d/?date=20090515

> ハンガリー記法はマイクロソフトの技術者、チャールズ・シモニイが
> 考案し彼がハンガリー人だったのでこんな名前で呼ばれるようになりました。
>
> この人はWordなどの開発に携わった人で優れた実績を上げました。
>
>
>
> 彼が考えたハンガリー記法の本来意図は変数の種類・用途を示すことであって、
> 実は型を示すことではありませんでした。
>
> 種類というのの例をあげると、座業系などがあげられます。

> これが本来チャールズ・シモニイが意図したハンガリアン記法でした。
>
> 同じ型でも混同してはいけない変数の意味（種類）を変数名に与えるというアイデアです。
>
> これなら誰が見ても変数の意味が明確に分ります。
>
> 現在ではアプリケーションハンガリアンと呼ばれたりします。


読んでおくといいよ。

[167 仕様書無しさん 2013/04/02(火) 03:23:15.95]

だめだこりゃ

[168 仕様書無しさん 2013/04/02(火) 03:24:35.22]

なにがだめなの？

[169 おじゃばさま 2013/04/02(火) 08:19:35.91]

型を変数名に入れる習慣は、レガシーCの業務プログラムのコーディング規約に多い。
その名残でC++のコーディング規約に入っている場合もあるが、基本的に無意味だ。
しかし無意味でもコーディング規約に入っていれば無視できない。
その場合はコーディング規約を変更する事だ。
理由と歴史を説明すれば大体変更になるが、変更出来なかった場合は、従うしかない。
まあ、普通の仕様書と同じだな。
問題があれば指摘し、それでも問題なしと判断されれば従う。

[170 仕様書無しさん 2013/04/02(火) 08:25:32.47]

システムハンガリアンは最初から不要
phantom typeが使えればアプリケーションハンガリアンも不要かも

[171 おじゃばさま 2013/04/02(火) 08:40:14.61]

一文字変数が禁止されている場合も、もし使いたいならコーディング規約を変更する必要がある。
しかし、現在は単語で区切に大文字を使う、理解しやすさ優先が主流なので、変更出来る可能性は低い。
禁止されていない場合は、ルール上は使用可能だ。
しかしその場合でも略号使って3文字程度にした方がいいだろう。
それ程冗長ならず、理解しやすさもそれなりに確保される。

[172 仕様書無しさん 2013/04/02(火) 09:13:37.69]

ドカタとそれ以外で別々のコーディング規約を使えば
このスレの問題は解決する

[173 仕様書無しさん 2013/04/02(火) 11:30:52.99]

>>172
ドカタとそれ以外が混在してるプロジェクトがほとんどなんだけど

[174 おじゃばさま 2013/04/02(火) 20:23:47.51]

>>172
それでは、コーディング規約の意味がないな。

ところで一文字変数の利点は何だ？
本人が見やすいだけか？

[175 仕様書無しさん 2013/04/02(火) 20:30:30.22]

どうせドカタの書いたコードなんて汎用性のかけらも無くて
書いたドカタ本人しか読まないんだから
好きにしたら良いんだよ

[176 仕様書無しさん 2013/04/02(火) 20:54:10.89]

ループカウンタ程度なら i, j, k でもいいだろ
それとも TheLoopCounter0, TheLoopCounter1, TheLoopCounter2 とかを使ってるのか？

[177 仕様書無しさん 2013/04/02(火) 21:14:23.97]

文系のやつらって数式でもx, y, zとか使わずに
単語使って書くじゃん？それと同じことだよ

[178 仕様書無しさん 2013/04/02(火) 21:28:54.93]

プログラミング"言語"なんだから文系の書き方のほうが適切じゃね？

[179 仕様書無しさん 2013/04/02(火) 21:30:10.04]

"プログラミング"言語なんだから文系の書き方のほうが適切じゃね？

[180 仕様書無しさん 2013/04/02(火) 21:38:32.19]

プログラミングは数学である

[181 仕様書無しさん 2013/04/02(火) 22:22:13.47]

んなこたーない

[182 仕様書無しさん 2013/04/02(火) 22:31:23.49]

「言語を用いるのだからプログラミングは文系分野である」という主張が真なら、
「量子論の論文は言語を用いて書くのだから物理学は文系分野である」ということになる

[183 おじゃばさま 2013/04/02(火) 22:42:03.09]

>>176
だから、それではi、jと変わらないだろう。
何のループか分かるような変数名をつけるんだよ。
1 payment = price[containerNo] * quantity;
読取れないか？

[184 仕様書無しさん 2013/04/02(火) 22:49:00.93]

>>183
ループカウンタなんだから、priceという配列なりvectorなりの要素を総なめるんだろ？
その場合は i でいいんじゃね？

for (int i = 0; i < price.size(); ++i) {
　payment = price[i] * quantity;
　doSomething(payment);
}

たまたまpriceの添字がcontainerNoと一致するような仕様だったとしても、
ここでその意義を強調する必要性は薄いんじゃね？

[185 仕様書無しさん 2013/04/02(火) 23:12:18.94]

理屈を言語で記述したりルールや命名規則を策定するなんてまさに文系の お仕事 じゃないか！
プログラミングなんてめんどくさい作業は文系にやらせて俺ら理系はもっとまともなことしようぜ。
理系技術者ばっかり迫害されるのなんてもうこりごりだ！

[186 仕様書無しさん 2013/04/02(火) 23:40:08.85]

Stay Hungary,
Stay Foolish.

[187 おじゃばさま 2013/04/02(火) 23:54:58.29]

>>184
確かに配列1つをなめるのならそれでもいいかもしれない。
しかしサンプルはprice以外にも配列があり、コンテナ数分回す想定だ。

[188 おじゃばさま 2013/04/02(火) 23:58:54.74]

>>185
理系とか文系とかは学生の発想だな。
PG5年もやればそんな区別は無意味だと気が付くだろう。

[189 仕様書無しさん 2013/04/03(水) 00:57:03.05]

アイム ハングリー。

[190 仕様書無しさん 2013/04/03(水) 01:03:53.06]

>>176
一文字禁止に反論するときなぜいつもすごく長い変数名にするのか
なんだよ、Theってw

[191 仕様書無しさん 2013/04/03(水) 02:08:07.52]

>>190
TheLoopCounter0、LoopCounter1、LoopCounter2 とかなら使ってるのか？

[192 仕様書無しさん 2013/04/03(水) 02:22:40.80]

>>191
なんか残念な読解力だね

[193 仕様書無しさん 2013/04/03(水) 03:33:28.75]

一文字変数名が出てきて困る場合、一文字変数名よりもそのメソッドの実装がそもそもうんｋって事が多い
もちろん、中身が明確でない場合の一文字変数名なんかは糞だがな

つか、よほど頭が悪すぎる奴でもない限り、
ループカウンタや狭いスコープ内での一文字変数名が原因でコードが複雑化してるって思う奴は居ない

[194 仕様書無しさん 2013/04/03(水) 07:40:23.83]

でもFizzBuzzレベルですら書けないアホも居るからなぁ
このスレの一文字変数禁止派は多分書けないし

[195 おじゃばさま 2013/04/03(水) 08:05:46.29]

>>194
変数名を長く書ける人は、短くも書けるし、短く書く人は、長くも書ける。
スキルは関係ないだろう。

[196 仕様書無しさん 2013/04/03(水) 08:52:24.80]

>>194
こういう、議論で勝ち目がないからって必死にレッテル貼りしてるのって
恥ずかしくないのかね？

[197 仕様書無しさん 2013/04/03(水) 09:23:15.68]

能書きはいいからFizzBuzz書いてみろ

[198 仕様書無しさん 2013/04/03(水) 09:38:34.76]

おらよ
i=1;main(){for(;i<31;++i){((i%3?0:printf("Fizz"))|(i%5?0:printf("Buzz")))?0:printf("%d",i);puts("");}}

[199 仕様書無しさん 2013/04/03(水) 10:43:34.81]

>>198
| の右辺と左辺の評価順に依存してる

[200 仕様書無しさん 2013/04/03(水) 12:54:34.07]

>>183
> 1 payment = price[containerNo] * quantity;
なんだこれ、恥ずかしくないのか。
説明してみろ。

[201 仕様書無しさん 2013/04/03(水) 13:01:05.28]

>>199
C の仕様に依存していることを指摘して何の意味があるんだ？

[202 仕様書無しさん 2013/04/03(水) 13:38:56.30]

Cの仕様で「未規定」の動作に依存していることが指摘されているんだが。

[203 仕様書無しさん 2013/04/03(水) 13:42:45.76]

だからそれを指摘したところで意味がないだろ？

[204 仕様書無しさん 2013/04/03(水) 14:03:39.60]

バグを指摘することに意味がない？
バグだらけのアプリを使い続けることに何の苦痛も感じない変な人か？

[205 仕様書無しさん 2013/04/03(水) 14:52:47.73]

そもそも未規定ではないし

[206 仕様書無しさん 2013/04/03(水) 15:13:50.92]

JIS X 3010-1993 より
6.3 式
（略）
構文で示されているか（注35），又は（関数呼出し演算子 ()，&&，||，? : 及びコンマ演算子に
対して）後で規定する場合を除いて，部分式の評価順序及び副作用が生じる順序は
未規定とする。
（以下略）

[207 仕様書無しさん 2013/04/03(水) 15:16:06.45]

そこ全然違う話

[208 仕様書無しさん 2013/04/03(水) 16:15:02.86]

じゃあ、| の右辺と左辺の評価順が規定されているという証拠を出せよ。

[209 仕様書無しさん 2013/04/03(水) 17:20:52.18]

言語仕様自体は未規定でも各コンパイラが決めてるだろ

[210 仕様書無しさん 2013/04/03(水) 19:32:48.03]

コンパイラが決めてる（決めなきゃならない）のは、規格で「処理系定義」となっていること。
「未規定」の事項は、例えばこの例なら左右のどちらが先かランダムであっても、規格上は問題ない。

[211 仕様書無しさん 2013/04/03(水) 19:47:53.10]

はいはい
じゃあそのランダムな処理系の具体例を出して

[212 仕様書無しさん 2013/04/03(水) 19:57:38.01]

だから未規定じゃないってば

[213 仕様書無しさん 2013/04/03(水) 20:36:38.57]

>>211
バージョンアップで非公開仕様が変わって嵌ったことがない幸せな人なんだねw

>>212
| と || を混同してない？

[214 仕様書無しさん 2013/04/03(水) 20:54:09.01]

しつこいなぁ
キミが信じようが信じまいが、どんなコンパイラでも同じ解釈なんだよ

[215 仕様書無しさん 2013/04/03(水) 20:59:18.64]

>>213
非公開仕様じゃないし

[216 仕様書無しさん 2013/04/03(水) 21:08:58.53]

じゃあ | の左右の評価順序を、コンパイラの仕様としてドキュメンテーションされてる例があるなら出してみろよ。
どっかの言語設計者みたいにソースコードが仕様とか言うなよw

[217 仕様書無しさん 2013/04/03(水) 21:12:40.88]

なんでもかんでもドキュメンテーションされている世界、いいよね。

[218 仕様書無しさん 2013/04/03(水) 21:13:51.85]

>>216
>>211

[219 仕様書無しさん 2013/04/03(水) 21:16:03.22]

規格とdefacto standardどっちが強い的な話？

[220 仕様書無しさん 2013/04/03(水) 21:22:03.64]

ランダムであっても問題はない　それはわかる
だが動きがランダムになるコンパイラはないだろ
あるなら持って来いよ
可哀想だからバージョンアップで変わった例でも容認してやる
さっさと持って来い

[221 おじゃばさま 2013/04/03(水) 21:35:00.81]

>>200
実際に使われるのは配列をなめるパターンが多いが、
ループは必ず1つの配列をなめるために使われるとは限らない。
そのため、配列とは無関係な名前をカウンタに使った。
カウンタには配列が分かる名前でなく、ループが分かる名前にすべきと言いたかった。
もし1つの配列をなめる処理ならは、cntでもいいと思う。

[222 仕様書無しさん 2013/04/03(水) 21:38:57.71]

>>221
cnt？countryの略か？なんで国が回るんだ？

[223 おじゃばさま 2013/04/03(水) 21:45:23.62]

>>222
カウンタだよ、iとおなじ。
俺はiじゃなくて、cntつかう。

[224 仕様書無しさん 2013/04/03(水) 21:48:38.61]

>>223
だったらcounterだろ。何cntって。countinueだかcountryだか
わからんじゃん。バカ？

[225 仕様書無しさん 2013/04/03(水) 21:51:38.19]

cntならだいぶ市民権を得ていると思うが、
自分勝手に単語略すのはやめてほしいよな。

[226 仕様書無しさん 2013/04/03(水) 21:58:55.46]

cntがcountryだとｗバカだこいつｗ

[227 おじゃばさま 2013/04/03(水) 22:08:02.35]

>>220
俺が昔調べた限りでは、評価順は左から右だった。
調べたのは、gcc/Linux、cc/Solaris、aCC/HP-UX、VC/Windows。
不定要素で違いがあったのは、関数引数の実行順ぐらいだったな。

[228 仕様書無しさん 2013/04/03(水) 22:12:42.58]

「非公開仕様じゃないし」ていうから「公開されてる仕様ある」んだろ？

[229 おじゃばさま 2013/04/03(水) 22:18:23.04]

結局、一文字変数の利点は、本人が見やすいだけか？

[230 仕様書無しさん 2013/04/03(水) 22:34:15.41]

昔からの慣例なんだから、別に問題ない

それを否定する目新しい事のほぼ１００％は、すたれて行く

[231 仕様書無しさん 2013/04/03(水) 22:34:55.85]

他人も見やすい

[232 仕様書無しさん 2013/04/03(水) 22:36:02.99]

昔からの慣例とか、せめて100年は続いてから言ってくれよ。
現状慣例でも何でもなく、そういうのが読みやすい奇特な人が
いて、奇特な人の信者がいるというだけのこと。

[233 仕様書無しさん 2013/04/03(水) 22:47:45.29]

AND/ORの評価順はUNIXシェルが左からって規定されてるからそれで一般的なんじゃないの

[234 仕様書無しさん 2013/04/03(水) 23:08:46.92]

>>232
ドッグイヤー換算なら十分じゃね？