X

ふざけた変数名を使う奴

■ このスレッドは過去ログ倉庫に格納されています
0001仕様書無しさん
垢版 |
2008/08/23(土) 21:45:16
var1、2、…とか、ふざけてるの？
0747仕様書無しさん
垢版 |
2014/03/31(月) 00:25:40.39
>>746
それは正しいのかもしれないが、回答としてはちょっとずれてる。
0748仕様書無しさん
垢版 |
2014/03/31(月) 02:40:40.06
中途半端に天邪鬼な俺は、
「fooとかbarとか使いたくねえな」
と思ってpooとかparとか使ってる。
0749仕様書無しさん
垢版 |
2014/03/31(月) 07:03:16.24
そりゃどっちがソースでどっちがターゲットかが構造だけで
明らかになるなら名前なんて余計だけど、いつもいつもやってられん。
命名法はルールだけでいつでも実践できる。
0750仕様書無しさん
垢版 |
2014/03/31(月) 10:13:28.23
アセンブラだとsrcとdstの順番は言語仕様として決まっているが、
nasmとgasでその並びが真逆だという。
0752仕様書無しさん
垢版 |
2014/03/31(月) 23:27:17.43
energy = mass * (speed_of_light * speed_of_light)

より

E = mc^2

の方が直感に響くような気がするな
0753仕様書無しさん
垢版 |
2014/04/03(木) 11:55:36.97
メソッド名の頭に全部fuckって付けてまわってたら怒られた・・・
0755仕様書無しさん
垢版 |
2014/04/03(木) 22:02:25.34
>>745
結局これはなんだったの？
src, targetとかfrom, toみたいに順序が明らかなのに名前つけるのが冗長ってこと？
0756仕様書無しさん
垢版 |
2014/04/03(木) 23:39:12.50
>>755
> bool func〜(string sourceString, string targetString);
こういう形式にしてしまうと、意味を名前に求めることになるから、ほかの構造を考えよう
ってことじゃね？
>>749が反論してるが。
0757仕様書無しさん
垢版 |
2014/04/06(日) 13:35:54.95
ほかの構造を考えるための工数を出してくれるんなら、いくらでも考えまっせ。
0758仕様書無しさん
垢版 |
2014/04/12(土) 00:27:47.01
>>757
100円やるから、
bool func〜(string sourceString, string targetString);
の適切な構造ってのをプリーズ。
0761仕様書無しさん
垢版 |
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
0762仕様書無しさん
垢版 |
2014/05/16(金) 23:59:47.50
>>752
mcと2の排他的論理和ですね。
0764仕様書無しさん
垢版 |
2014/05/28(水) 00:00:55.58
昔（20年ほど前）、変な後輩の新人君がいた。

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

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

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

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

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

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

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

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

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

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

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

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

今度は

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

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

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

システム全体に散らばった、○に関する処理をあちこち探すはめになる。
追加削除はあまりしないとしても、デバッグの時に○に関する処理をあちこちと。
0779仕様書無しさん
垢版 |
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なら。それはもはや共通ルーチンではなくなる。
0781仕様書無しさん
垢版 |
2014/07/13(日) 00:59:28.50
ただしいモジュールの分け方をしていれば、

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

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

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

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

この中から正しいAの道はどれかな？みたいなことをするハメになる。
どれが共通の部分で、どれがAのコードかわからないから、
しだいに共通らしき道に「if A then」が増えていき、
すべての処理がごちゃごちゃ混ざりまくる。
0782仕様書無しさん
垢版 |
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はいったいどの部分が実行されるんだよ？ ってなっていく。
0783仕様書無しさん
垢版 |
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の処理だけで終わるコード、よりも悪い結果になっていたりする。
（もちろんコピペはダメ）
0784仕様書無しさん
垢版 |
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の処理には入力、メイン、他、出力の処理が一直線に並ぶ。
0785仕様書無しさん
垢版 |
2014/07/13(日) 11:35:37.37
>「 約400行の共通処理」はもはや「4000行のA〜Eの処理が絡みあった処理」になる。さあ、長くなったから関数に分けようか。

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

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

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

お前の言う処理は400ぎょうもある。そうなら、嵐になるといっていい。
お前は、ネストを深くしない、と考えたことないだろ。
ネストが深けりゃ読みにくいのは当然
0786仕様書無しさん
垢版 |
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);
　　}
　　： (以下
　}
}
0787仕様書無しさん
垢版 |
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);
}
： (以下

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

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

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

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

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

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

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

public String func(XXXXXXXX){　← 8文字

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

　　return "true";
}
0805仕様書無しさん
垢版 |
2014/07/30(水) 10:18:28.88
>{}の中身が a=true; でelseの中身が a=false; だろw

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

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

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

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

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

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

今時こんなのが一箇所でもあったら、プログラム全体の質を疑う
0839仕様書無しさん
垢版 |
2014/10/30(木) 21:12:37.30
俺の会社のvbaマクロとか酷いぞ

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

こんなんだから

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

最悪だよ
0840仕様書無しさん
垢版 |
2014/10/31(金) 16:25:05.22
>>839
２．以外は別に問題ないんじゃ？

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

他の部分が完璧で、一箇所だけがそれだったら、笑うしかないな。
0842仕様書無しさん
垢版 |
2014/10/31(金) 23:32:40.42
>>835
「よっしゃー、サーチ結果ゲット！」とか言いながら書いたに違いない
0844839
垢版 |
2014/11/20(木) 20:07:00.65
>>840

１．
日本語だと海外のwindowsで動作しない。
理由はVBAはunicodeじゃないから

２．
moduleも一切認めたくない派の俺は
基本的に省略表現はバグの元だから許さん

３．
variant型ってのはC#でいうならObject型だろ
よくわからんけど何でも入る変数にぶちこめというのは
VBerがよくやる悪習だと思う。

関数の入力はそれが不可能で無い限りにおいて
引数の型は厳格にするのは当たり前。

そもそもコメントが不足してるコードで曖昧な型宣言されると
修正が難しくなるんだよ。
0845仕様書無しさん
垢版 |
2014/11/20(木) 20:41:45.25
>>844
＞variant型ってのはC#でいうならObject型だろ
ここもしかして笑うとこ？
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況