ふざけた変数名を使う奴

■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
垢版 |
2008/08/23(土) 21:45:16
var1、2、…とか、ふざけてるの？
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
> こんなのが一箇所でもあったら

他の部分が完璧で、一箇所だけがそれだったら、笑うしかないな。
2014/10/31(金) 23:32:40.42
>>835
「よっしゃー、サーチ結果ゲット！」とか言いながら書いたに違いない
2014/11/12(水) 07:35:57.30
>>6
sSQL これ使っていいよ
844839
垢版 |
2014/11/20(木) 20:07:00.65
>>840

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

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

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

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

そもそもコメントが不足してるコードで曖昧な型宣言されると
修正が難しくなるんだよ。
2014/11/20(木) 20:41:45.25
>>844
＞variant型ってのはC#でいうならObject型だろ
ここもしかして笑うとこ？
2014/11/20(木) 22:34:25.17
>>845
http://msdn.microsoft.com/ja-jp/library/office/gg251448%28v=office.15%29.aspx
2014/11/21(金) 15:03:04.47
図の一つ下って事はExcelとかか
だとするとセルに何が入っているか予測が付かない事も想定して引数にVariant使うのは別に間違いではないと思うが
というか普通じゃね？
否定してるヤツはメインルーチンのほうでわざわざ型を判定させる処理でも入れるのかね
848仕様書無しさん
垢版 |
2014/11/26(水) 07:27:13.45
てめぇらと結婚する身にもなってみろ
【知的財産と契約料金の搾取助長者ばかり】
［受注系SI生涯損害促進者を排除すべき］
偽装請負従犯SEの動機
コミ障
趣味
高卒
文系大卒
低偏差値大卒
低知能

偽装請負従犯SEの迷惑
不当指示遵守
悪徳期限遵守
裁判苦手
残業見積
無料追加
安売競争
利益提供
人格障害
健康障害
孤独死

偽装請負従犯SEの代償
デスマ
技術低下
収入低下
失業
非婚
離婚
鬱病
早死
2014/11/28(金) 06:15:40.76
消費者金融ソフトにはYフラグがある
893のYだ
2015/04/26(日) 10:53:05.40
>>3
クスッときた
851仕様書無しさん
垢版 |
2015/08/25(火) 15:10:21.65
{
auto o = some_weak_ptr.lock()
...
}

ってのなら普通に一文字の変数使う。
アルゴリズム的なコードなら多重ループは普通に使う。
2015/08/25(火) 15:15:39.46
some_weak_ptrって書いたけど、実際変数oを使うときは
auto o = owner_.lock()
ってのが多い
2015/09/15(火) 20:35:39.02
HBM-REC-ID
HBM-REC-HINMEI
HBM-REC-TANKA

HBMとはHinBan Masutaaの略
こういう名前の付け方を見るとほっこりする
854ﾄﾝﾄｶｲﾓ名無しさん
垢版 |
2015/10/23(金) 02:53:30.94
SEGA Mastaa Sisutemu
2016/05/17(火) 00:16:16.39
関数名だけど・・・
Chenge_Language_Setting_Engrish()
856仕様書無しさん
垢版 |
2017/06/12(月) 06:33:13.78
いいえ
2017/06/12(月) 08:43:14.00
>>36
まさか......trueをTypo?
2017/06/20(火) 13:58:57.34
そのまま見れば何かの処理をスルーするフラグって意味かと思うがどうなんだろう
2017/06/21(水) 01:33:12.78
thru = true; ならわかるが、
thtuFlag = thru; は嫌だな
2017/06/21(水) 01:33:57.99
ストゥーになっちまった
861仕様書無しさん
垢版 |
2017/12/29(金) 20:09:50.23
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

WAHY6659LR
862仕様書無しさん
垢版 |
2018/05/22(火) 14:48:27.25
とても簡単な自宅で稼げる方法
参考までに書いておきます
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

BU06O
863仕様書無しさん
垢版 |
2020/01/20(月) 09:28:21.15
２物体の相対速度ベクトルrvをx方向に分解して衝突面の法線方向に分解してz方向に分解した変数を vxnz としているけどふざけていますか？
同じような変数が無数に並んでいます
いちいちrelativeとかvelocityとか書くべきなの？見にくくなるよ？
864仕様書無しさん
垢版 |
2020/01/20(月) 15:05:51.11
>>814
得意気に、この話をする人は信用しないことにしている。
これは、”私は単体テストしません！”って言っているの同じようなもの。
2020/01/20(月) 21:01:52.56
>>863
ええんちゃう？
個人的にはアンダーバーをはさむところだけど。
2020/01/21(火) 02:14:49.98
三次元ベクトルの領域で説明コメント書いたり、変数名を入射だの反射だの法線だの英語で書いても読めないヤツの方が多い
いちいち書く方が行が変わったりして視認性が悪くなるから略した方が作りやすい
可読性とか数学わからないヤツが騒がないでほしい
867仕様書無しさん
垢版 |
2020/01/21(火) 23:45:03.74
// 『線形代数』○○著　を読め
でいいよな？
2020/01/22(水) 00:04:40.63
>>3
そんな大人、修正してやる!
2020/01/22(水) 00:48:38.70
リーダブルコード読んでからはどんな変数にもサボらず名前をつける意識がついた

ループ内のカウンタにcntなんて名前付けたところでそんなことはわかっとるわ！って思うもんね
2020/01/22(水) 00:57:36.02
細かいループ内なら一文字でいい。
どうでもいいものは簡単に。
871仕様書無しさん
垢版 |
2020/01/25(土) 23:45:46.01
難読化のため日本語を使って何が悪いんだ？
別に読めないわけでもないだろ？
2020/01/26(日) 17:20:39.20
難読化が目的なら、書き終わった後で
a1,a2,a3 とかに書き直せばいいだけでは?
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況