ふざけた変数名を使う奴

■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
垢版 |
2008/08/23(土) 21:45:16
var1、2、…とか、ふざけてるの？
2014/03/30(日) 23:13:05.91
>>739
オレは変数名については言ってないよ。メソッド名についてだ。
それに機械語で書く必要はない。そんなことしたらかえって抽象度が下がってしまうだろ。

>>741
それは一部その通り。
2014/03/30(日) 23:35:13.13
>>741
それは命名以前の問題じゃないかね
2014/03/30(日) 23:45:19.74
>>741
それはおれも・・・
と書いていた途中で>>743に釘刺されてしまったｗ
2014/03/30(日) 23:50:52.96
>>739, 740
誤解してたら悪いんだが、君たちってさ、
bool func〜(string sourceString, string targetString);
bool func〜(string targetString, string sourceString);
のどっちにしようか？って問題に対して、

「どちらでも統一されていればよい。意味は変数名に込められているから明確。」
とか考えるの？
2014/03/31(月) 00:11:57.17
>>745
標準関数に合わせてtarget, srcにする
2014/03/31(月) 00:25:40.39
>>746
それは正しいのかもしれないが、回答としてはちょっとずれてる。
2014/03/31(月) 02:40:40.06
中途半端に天邪鬼な俺は、
「fooとかbarとか使いたくねえな」
と思ってpooとかparとか使ってる。
2014/03/31(月) 07:03:16.24
そりゃどっちがソースでどっちがターゲットかが構造だけで
明らかになるなら名前なんて余計だけど、いつもいつもやってられん。
命名法はルールだけでいつでも実践できる。
2014/03/31(月) 10:13:28.23
アセンブラだとsrcとdstの順番は言語仕様として決まっているが、
nasmとgasでその並びが真逆だという。
2014/03/31(月) 22:12:53.69
>>748 の使う poo は
実に適切な名前だと思う。
2014/03/31(月) 23:27:17.43
energy = mass * (speed_of_light * speed_of_light)

より

E = mc^2

の方が直感に響くような気がするな
2014/04/03(木) 11:55:36.97
メソッド名の頭に全部fuckって付けてまわってたら怒られた・・・
2014/04/03(木) 21:52:13.61
>>751
俺は（今は）pooじゃないぜ。parだけど。
2014/04/03(木) 22:02:25.34
>>745
結局これはなんだったの？
src, targetとかfrom, toみたいに順序が明らかなのに名前つけるのが冗長ってこと？
2014/04/03(木) 23:39:12.50
>>755
> bool func〜(string sourceString, string targetString);
こういう形式にしてしまうと、意味を名前に求めることになるから、ほかの構造を考えよう
ってことじゃね？
>>749が反論してるが。
2014/04/06(日) 13:35:54.95
ほかの構造を考えるための工数を出してくれるんなら、いくらでも考えまっせ。
2014/04/12(土) 00:27:47.01
>>757
100円やるから、
bool func〜(string sourceString, string targetString);
の適切な構造ってのをプリーズ。
2014/04/12(土) 03:01:16.73
どうやって支払うの？
2014/04/30(水) 02:41:31.63
投擲。
761仕様書無しさん
垢版 |
2014/05/16(金) 11:48:00.48
嶋崎慎太郎
http://fishki.net/upload/post_temp/201405/16/1_000.jpg

東京電機大学中学校　評判
http://fishki.net/upload/post_temp/201405/16/1_000.jpg

早稲田住友商事
http://fishki.net/upload/post_temp/201405/16/1_000.jpg

嶋崎慎太郎
http://fishki.net/upload/post_temp/201405/16/001.jpg

嶋崎亮介
http://fishki.net/upload/post_temp/201405/16/1_111.jpg

稲城サッカースポーツ少年団　評判　稲城SSS　評判
http://fishki.net/upload/post_temp/201405/16/500.jpg

稲城市立向陽台小学校　評判　Y子
http://fishki.net/upload/post_temp/201405/16/1_001.jpg
762仕様書無しさん
垢版 |
2014/05/16(金) 23:59:47.50
>>752
mcと2の排他的論理和ですね。
2014/05/17(土) 01:06:17.21
>>753
コーヒー吹いたじゃねーかｗｗｗ
2014/05/28(水) 00:00:55.58
昔（20年ほど前）、変な後輩の新人君がいた。

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

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

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

ああ、ただの馬鹿じゃないなと。
2014/05/28(水) 10:54:48.65
ただのバカじゃないか。
2014/06/02(月) 20:24:48.19
Cからプログラム始めたのになんで自分はハンガリアン大好きっ子に育ったんだろう
昔書いたソースをメンテしてる人に申し訳ない

今はpooだけど
2014/06/04(水) 02:38:37.25
「自分のジョブ」を目立たせようとしたのはナゼなんだ？
2014/06/04(水) 20:24:38.43
本番に乗せる前のテストだったんだろ。
なら何でもいいな。自分が判りやすければ。
2014/06/23(月) 05:08:59.52
>>49
マクシムだったら黄金の舟になれた
770仕様書無しさん
垢版 |
2014/07/11(金) 21:08:24.55
変数名を考えるのがじゃまくさい
なんとかならんのか
771仕様書無しさん
垢版 |
2014/07/11(金) 21:35:28.52
変数名は20文字まで
772仕様書無しさん
垢版 |
2014/07/12(土) 20:20:15.36
>変数名を考えるのがじゃまくさい なんとかならんのか

俺の場合、画面表示だったらDispなんとかになる。その関数はDsip**となる
俺は関数一覧を使うが、そこにDisp**がずらりと並ぶ。そこから目的の関数名をつかむ
でも、作業が進むと関数が増えてくる。
すると、表示クラスが独立させるわけよ。
しかし、相変わらずそのクラスの関数群はDsip**のままだな
2014/07/12(土) 20:25:53.81
>>772
典型的な間違ったモジュールの分け方してそうでワロタｗ

間違った分け方をしている奴は真逆に分ける。
たとえば「○を表示する。」だったら、
○でグループを作るのではなく表示でグループを作る。

なんとかの表示、なんたらの表示、表示、表示、
そして表示を担当するモジュールが出来るｗｗｗ

真逆だよ真逆。
774仕様書無しさん
垢版 |
2014/07/12(土) 21:35:15.98
>>773
そっちのほうが合理的だと思うんだけどダメなのか？
775仕様書無しさん
垢版 |
2014/07/12(土) 22:06:43.67
>>774

関数が多くなってくる時、関数名を覚えきれない。
で、あの処理する関数名なんだったけーとなる。
命名のしかたは、探しやすい、かだな
ソースの保守がしやすいというのが基準
2014/07/12(土) 22:41:58.71
>>775
悪いけど意味が分からないっす
2014/07/12(土) 23:02:16.09
普通は処理内容じゃなくて処理対象で分けるだろ
それがオブジェクト指向なんだから
2014/07/13(日) 00:43:06.05
>>774
最近俺もわかったことなんだけどね。
正反対に実装する奴が多いこと多いこと。

　　Aに関する表示、Bに関する表示、Cに関する表示、

これらを一つのモジュール（ファイル）にまとめる考え方だと、

今度は

　　Aに関する入力、Bに関する入力、Cに関する入力、

という風にモジュールにまとめる。他にも処理ごとにまとめたモジュールが出来るだろう。

そうすると、次にDに関する処理が増えた時、表示モジュール、入力モジュール
なんたらモジュールっていう風に、複数のモジュールに処理を追加することになる。
逆に消そうとした時、複数のモジュールから○に関する処理を探しだして消さなきゃいけない。

システム全体に散らばった、○に関する処理をあちこち探すはめになる。
追加削除はあまりしないとしても、デバッグの時に○に関する処理をあちこちと。
2014/07/13(日) 00:48:12.12
　　Aに関する表示、Bに関する表示、Cに関する表示、

これらを一つのモジュール（ファイル）にまとめる考え方をしていると
でてくるのが、似たような処理はまとめようといういうもの。
一見良さそうに思えるが・・・。

　　Aに関する表示、Bに関する表示、Cに関する表示、 に
共通する部分をルーチンにまとめる。

　　「Aに関する表示、Bに関する表示、Cに関する表示」 ＋ 共通ルーチン

本来、AとBとCは全く無関係なのに、処理の内容が似ているからという理由で
共通ルーチンが作られる。そうすると、その共通ルーチンでAの場合だけ
必要な処理が出来た時に破綻する。

何が起きるかというと、共通ルーチンに変なフラグを追加される。

「共通ルーチン」の中に、Aの場合だけ必要な処理、つまりif A thenというコードが追加される。
同様に、Bなら、Cなら。それはもはや共通ルーチンではなくなる。
2014/07/13(日) 00:50:12.44
理解
2014/07/13(日) 00:59:28.50
ただしいモジュールの分け方をしていれば、

処理の、[START] → から → [END] までほぼ一本道。

つまり、Aの処理しか行わない道になるから、
この道を修正しても、BやCに影響ないことは明らかになる。

真逆ののモジュールの分け方をすると

　　　　　　　　　　　　　┌───┬───┐
[START] ─┬───┴┬──┴──┬┴───[END]
.　　　　　　　└────┴─────┘

この中から正しいAの道はどれかな？みたいなことをするハメになる。
どれが共通の部分で、どれがAのコードかわからないから、
しだいに共通らしき道に「if A then」が増えていき、
すべての処理がごちゃごちゃ混ざりまくる。
2014/07/13(日) 01:15:04.78
>>779,>>781で書いたことをもうちょっと丁寧に書くと、
真逆のモジュールの分け方をしている奴の開発の流れはこう。

1. まず、Aの処理を作る。そのコードの量は適当でいいが500行ぐらいとしよう。
2. 次にBの処理を作る。似ているからAの処理をコピペする。
3. そこで少し力がついた初心者は、コピペするのはよくない、AとBは
似ているからまとめるべきだ。という考えになる。

ここまで来た典型的なコードは
　　Aの前処理 → 約400行の共通処理 → Aの後処理
　　Bの前処理 → 約400行の共通処理 → Bの後処理
というようになる。

（この共通処理というのは、AとBの共通の処理であって、汎用関数ではないことに注意ね。）

次に少し似ているCが加わる。だいたい似ているが、共通処理でやる内容が少しだけ違う。

　　Aの前処理 → 約400行の共通処理 → Aの後処理
　　Bの前処理 → 約400行の共通処理 → Bの後処理
　　Cの前処理 → 約400行の共通処理 → Cの後処理

　　「約400行の共通処理の内訳」
　　　　　AとBの共通処理 → C専用の処理 → AとBの共通処理

そしてD,Eと増えるたびに

　　「約400行の共通処理の内訳」
　　　　　全ての共通処理 → AとBの共通処理 → C専用の処理 → D専用の処理 → 全ての共通処理 → AとBの共通処理 → AとDの共通処理

みたいにカオスになる。

おいEはいったいどの部分が実行されるんだよ？ ってなっていく。
2014/07/13(日) 01:23:09.10
さらにコードがの行数が増えていくと関数に分けようと考える。

「 約400行の共通処理」はもはや「4000行のA〜Eの処理が絡みあった処理」になる。

さあ、長くなったから関数に分けようか。

　　Aの前処理 → 約400行の絡み合った入力処理 → 約400行の絡み合ったメイン処理 → 約400行の絡み合った出力処理 → Aの後処理
　　Bの前処理 → 約400行の絡み合った入力処理 → 約400行の絡み合ったメイン処理 → 約400行の絡み合った出力処理 → Bの後処理
　　Cの前処理 → 約400行の絡み合った入力処理 → 約400行の絡み合ったメイン処理 → 約400行の絡み合った出力処理 → Cの後処理
　　　　　：

そして次に入力、他、出力を別モジュールに分けようとしだす。

　　Aの前処理 → 入力モジュール → メインモジュール → 出力モジュール → Aの後処理
　　　　： (以下同)

そして出来上がるのが、各モジュール（ファイル）に含まれた、if A thenの嵐

広大なシステム全体から、Aに関するコードを探し出さないといけない。
Aに関する処理をあちこちにジャンプして調べることになる。
共通と思われるコードを修正した時、それが本当にB〜Eに影響しないのか？と考えることになる。

これは、実は、コピペしてAの処理だけで終わるコード、よりも悪い結果になっていたりする。
（もちろんコピペはダメ）
2014/07/13(日) 01:31:05.58
じゃあ何が正しいんだよ？と言われそうだから
どうするのがいいかも答えよう。

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

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

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

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

そうやってコードが長くなるたびに、汎用関数に追いやってA処理を短くしつつ
処理を増やしていく。そしてこのAの処理は決してB〜Eと混ざることはない。
Aの処理には入力、メイン、他、出力の処理が一直線に並ぶ。
785仕様書無しさん
垢版 |
2014/07/13(日) 11:35:37.37
>「 約400行の共通処理」はもはや「4000行のA〜Eの処理が絡みあった処理」になる。さあ、長くなったから関数に分けようか。

400行の共通処理はありえんだろう。その時点でスパゲッティ。
25行の関数に分けてあるなら理想的。

で、4000行からは、1000行のクラス(関数の集まり）を作っていくわけよ

>そして出来上がるのが、各モジュール（ファイル）に含まれた、if A thenの嵐

お前の言う処理は400ぎょうもある。そうなら、嵐になるといっていい。
お前は、ネストを深くしない、と考えたことないだろ。
ネストが深けりゃ読みにくいのは当然
786仕様書無しさん
垢版 |
2014/07/13(日) 13:46:29.99
ネストを深くしないということは、こういうことだな
Disp(){
int a;
for( int i = 0; i< 10; i++){
　DispA(&a, i);
for( int ii = 0; ii< a; ii++){

　　DispB(ii);
　　}
　　： (以下
　}
}
787仕様書無しさん
垢版 |
2014/07/13(日) 13:47:16.21
上のは読みにくいからこのように変える

Disp(){

for( int i = 0; i< 10; i++){
DispSub( i);
}
}
//Disp関数のこども
DispSub(int i)
{
int a;
DispA(&a, i);
for( int ii = 0; ii< a; ii++){
DispB(ii);
}
： (以下

}
788仕様書無しさん
垢版 |
2014/07/13(日) 14:05:01.12
関数名や変数名にはくどいぐらい説明的な名前をつけておいた方がいい
書いてる時は冗長だなと思ってもプロジェクトがでかくなると1週間前に書いた部分ですらいまいちピンとこなくなる
2014/07/13(日) 22:01:22.18
メソッド定義のところの引数名は辞書引いてすごい長ったらしい名前つけてるけど
中の変数とかはぐちゃぐちゃだな

世間と逆なんかしらん
2014/07/14(月) 01:51:32.77
スコープが小さければ短い名前で良い。
スコープが広くなければなるほど長い名前。
もちろん、名前空間やクラスがあれば、その分短くて良い。

って考えると、関数の頭で宣言するやり方は
スコープが広いから、長い名前になりがちで
使う直前に宣言しましょうってなる。
2014/07/14(月) 08:08:48.17
つか、書き出す前にちゃんと設計しろよ…
792仕様書無しさん
垢版 |
2014/07/14(月) 20:19:27.89
８０年代の頃は
変数にakinaとか使うバカがいたなｗ
2014/07/14(月) 20:47:59.79
>>791
> つか、書き出す前にちゃんと設計しろよ…

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

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

常に小さな再設計をし続けないと破綻する。
2014/07/16(水) 13:01:49.92
あほかｗアジャイルだって設計くらいするわな。
795仕様書無しさん
垢版 |
2014/07/16(水) 13:05:52.01
>>793
こういうアジャイルを勘違いしているバカがのさばっているので
ウォーターフォール厨のバカ上司がアジャイルを誤解していって
どんどん環境が悪くなる
796仕様書無しさん
垢版 |
2014/07/16(水) 14:23:46.71
メンバ関数の名前なんかは、grep 検索の際の利便性を考えると、
たとえ クラスが別だから同じ名前であってもいい場合でも違って
いた方が便利な場合も有るかも。
797仕様書無しさん
垢版 |
2014/07/16(水) 14:28:24.97
>>795
「バカ」は必要ない。
798仕様書無しさん
垢版 |
2014/07/16(水) 14:30:21.21
ごめん。

「バカ」な人が必要ないのではなく、「バカ」だと書く必要が無い
という意味だけど。
2014/07/28(月) 00:37:49.10
>>58
一瞬どこがマヌケなのかわからなくてドキッとしたが
さすがにこれは無いわ
800仕様書無しさん
垢版 |
2014/07/28(月) 01:10:32.66
if (result == true) {…}
は結構みるなぁ。な
801仕様書無しさん
垢版 |
2014/07/30(水) 03:14:20.02
そういう話じゃないんじゃ？

public String func(XXXXXXXX){　← 8文字

　　if(XXXXXX){　　　　　　　　　　　← 6文字
　　　　　　return "false";
　　}

　　return "true";
}
2014/07/30(水) 03:16:00.94
スレタイ通りじゃねえかｗｗｗ
2014/07/30(水) 04:40:41.87
4年越しで明かされる真実……！
2014/07/30(水) 09:13:31.18
>>800
{}の中身が a=true; でelseの中身が a=false; だろw
805仕様書無しさん
垢版 |
2014/07/30(水) 10:18:28.88
>{}の中身が a=true; でelseの中身が a=false; だろw

おめーは、北京原人か？
806仕様書無しさん
垢版 |
2014/07/31(木) 22:57:48.13
下記は正常に動作しているコードの一部である。
if (result == true) {
…
}
これを次のように修正しても、異常をきたす事は無い。
if (result) {
…
}
正か誤か。

java初心者向けの問題。
2014/08/02(土) 17:18:55.70
ぬるぽとかそういう話？
808仕様書無しさん
垢版 |
2014/08/02(土) 19:11:19.08
違う話だよ。
809仕様書無しさん
垢版 |
2014/08/02(土) 21:24:03.58
ﾌﾌｯ
2014/08/02(土) 22:14:42.06
>>806
こういう問題を言っちゃう奴はコミュ力が無いんだと思う。
可読性かシンプル化でどちらも間違いではないし。
811仕様書無しさん
垢版 |
2014/08/02(土) 22:25:20.68
いや、そういう問題じゃ無いってw
プログラムが（必ず）正しく動作するか否かの問題。
2014/08/02(土) 22:28:05.46
それは上の方が必ず動くよ。
下は上までの肯定でresultに変なもんが入ってたらヤバいだろ。
813仕様書無しさん
垢版 |
2014/08/02(土) 22:47:16.14
具体的には？
814仕様書無しさん
垢版 |
2014/08/02(土) 22:51:47.89
if (result == true) {
の形は、
if (result = true) {
と間違えてもエラーが出ないからあまりお勧めしない。
コーディング規約で禁止した方がいい。
2014/08/02(土) 22:56:24.85
まあ>>806はjavaの話だけどな
816仕様書無しさん
垢版 |
2014/08/02(土) 23:33:30.09
まあ>>814もjavaの話だけどな
817815
垢版 |
2014/08/02(土) 23:41:05.84
マジだ…orz
818仕様書無しさん
垢版 |
2014/08/02(土) 23:57:45.80
>>816
Javaって>>814でwarningも出してくれない欠陥言語なの？
819仕様書無しさん
垢版 |
2014/08/03(日) 00:08:49.47
>>818
(a = 3)の値は3なんだ。
同様に、
(result = true)の値もtrue。
式の評価がそうなってるんで仕方ないというかなんというか。
2014/08/03(日) 13:55:24.25
>>806
Javaのバージョンで多少ハナシが変わるね。
最新なら実行時エラーの可能性。
ちょっと古いとコンパイルエラーだな。
さらに古い場合は問題無しw
2014/10/14(火) 21:27:46.36
wrok、cunt、befer、strFragが4傑かな

あと、RDBで表定義のnをnumberに一括置換したらしく
列名がすべからく
hoge_name→hoge_numberame
になってたのもヤバかった
2014/10/15(水) 02:19:06.93
「すべからく」は「全部」という意味じゃないぞ
2014/10/15(水) 02:23:01.01
すべてが辛いって意味なんだ。
2014/10/15(水) 03:17:28.33
本来の意味でも通じるやん
2014/10/16(木) 11:50:47.68
全然違うだろ
826仕様書無しさん
垢版 |
2014/10/18(土) 12:29:16.13
変数じゃないけど
コメントの自分の名前に勝手なミドルネームを入れる人がいた

「何コレ？」って聞いてみたら

「イギリス人の友人が僕をこう呼んでいるんです」

という返答だった
2014/10/19(日) 11:59:50.49
>>819
まともなコンパイラなら if( foo = true )は ==と間違えてないすかって警告がでる
2014/10/19(日) 12:17:39.30
メソッド名だけどcheckParam(〜)でbooleanを返すのはアリ？
2014/10/19(日) 12:32:41.47
オブジェクト指向ならメソッドでIsParam()にするべきでは
他は知らん
2014/10/19(日) 13:26:21.00
そーね。うちの規約だとisValidParamになるとおもうんだけど
ぶっちゃけcheck〜のほうが分かりやすいと思うのよね
規約破ってまでこだわることでもないんだけど
2014/10/20(月) 01:36:13.58
適切なメソッド名が決まらなくて、とりあえず書き始める時、
だいたい nekoで始める俺
もし最終的なソースコードにnekoって見つけたら、俺が書いたのだからﾖﾛｼｸ
832仕様書無しさん
垢版 |
2014/10/24(金) 04:11:15.49
bool flagBufferTransportationIsAboutToFinish;
bool flagBufferTransportationIsFinishing;
bool flagBufferTransportationHasBeenFinished;
bool flagBufferTransportationFinished;
2014/10/25(土) 06:40:10.69
それらのステートを識別する必要があるにしてもboolはないなぁ
2014/10/25(土) 15:44:44.33
enum flagBufferTransportation : bool {
IsAboutToFinish,
IsFinishing,
HasBeenFinished,
Finished,
};
2014/10/28(火) 06:45:30.89
void serchKekkaGet();

今時こんなのが一箇所でもあったら、プログラム全体の質を疑う
2014/10/28(火) 06:46:53.05
メソッド名はスレ違いだったらｽﾏｿ
2014/10/30(木) 00:41:05.54
まずsearchじゃん
2014/10/30(木) 02:06:11.69
>>835だけど、そう、スペルミスも込みなんだよ
839仕様書無しさん
垢版 |
2014/10/30(木) 21:12:37.30
俺の会社のvbaマクロとか酷いぞ

sub 図の１つ下のデータを計算(data as Variant)

こんなんだから

１．日本語関数
２．何する関数か推測できない
３．private publicがない
４．引数が汎用型

最悪だよ
2014/10/31(金) 16:25:05.22
>>839
２．以外は別に問題ないんじゃ？

１．日本語だと何が問題？
３．VBAには『Public』『Private』『指定なし』の3種類があって、これはその一番最後というだけの話だが、何が問題？
４．引数がVariant型だと何が問題？
2014/10/31(金) 16:28:20.11
>>835
> こんなのが一箇所でもあったら

他の部分が完璧で、一箇所だけがそれだったら、笑うしかないな。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況