ふざけた変数名を使う奴

**仕様書無しさん** · 2008/08/23(土) 21:45:16

var1、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
マクシムだったら黄金の舟になれた

**仕様書無しさん** · 2014/07/11(金) 21:08:24.55

変数名を考えるのがじゃまくさい
なんとかならんのか

**仕様書無しさん** · 2014/07/11(金) 21:35:28.52

変数名は20文字まで

**仕様書無しさん** · 2014/07/12(土) 20:20:15.36

>変数名を考えるのがじゃまくさいなんとかならんのか

俺の場合、画面表示だったらDispなんとかになる。その関数はDsip**となる
俺は関数一覧を使うが、そこにDisp**がずらりと並ぶ。そこから目的の関数名をつかむ
でも、作業が進むと関数が増えてくる。
すると、表示クラスが独立させるわけよ。
しかし、相変わらずそのクラスの関数群はDsip**のままだな

**仕様書無しさん** · 2014/07/12(土) 20:25:53.81

>>772
典型的な間違ったモジュールの分け方してそうでワロタｗ

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

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

真逆だよ真逆。

**仕様書無しさん** · 2014/07/12(土) 21:35:15.98

>>773
そっちのほうが合理的だと思うんだけどダメなのか？

**仕様書無しさん** · 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の処理には入力、メイン、他、出力の処理が一直線に並ぶ。

**仕様書無しさん** · 2014/07/13(日) 11:35:37.37

>「約400行の共通処理」はもはや「4000行のA～Eの処理が絡みあった処理」になる。さあ、長くなったから関数に分けようか。

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

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

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

お前の言う処理は400ぎょうもある。そうなら、嵐になるといっていい。
お前は、ネストを深くしない、と考えたことないだろ。
ネストが深けりゃ読みにくいのは当然

**仕様書無しさん** · 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);
　　}
　　： (以下
　}
}

**仕様書無しさん** · 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);
}
： (以下

}

**仕様書無しさん** · 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

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

**仕様書無しさん** · 2014/07/14(月) 20:19:27.89

８０年代の頃は
変数にakinaとか使うバカがいたなｗ

**仕様書無しさん** · 2014/07/14(月) 20:47:59.79

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

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

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

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

**仕様書無しさん** · 2014/07/16(水) 13:01:49.92

あほかｗアジャイルだって設計くらいするわな。

**仕様書無しさん** · 2014/07/16(水) 13:05:52.01

>>793
こういうアジャイルを勘違いしているバカがのさばっているので
ウォーターフォール厨のバカ上司がアジャイルを誤解していって
どんどん環境が悪くなる

**仕様書無しさん** · 2014/07/16(水) 14:23:46.71

メンバ関数の名前なんかは、grep 検索の際の利便性を考えると、
たとえクラスが別だから同じ名前であってもいい場合でも違って
いた方が便利な場合も有るかも。

**仕様書無しさん** · 2014/07/16(水) 14:28:24.97

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

**仕様書無しさん** · 2014/07/16(水) 14:30:21.21

ごめん。

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

**仕様書無しさん** · 2014/07/28(月) 00:37:49.10

>>58
一瞬どこがマヌケなのかわからなくてドキッとしたが
さすがにこれは無いわ

**仕様書無しさん** · 2014/07/28(月) 01:10:32.66

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

**仕様書無しさん** · 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

**仕様書無しさん** · 2014/07/30(水) 10:18:28.88

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

おめーは、北京原人か？

**仕様書無しさん** · 2014/07/31(木) 22:57:48.13

下記は正常に動作しているコードの一部である。
if (result == true) {
…
}
これを次のように修正しても、異常をきたす事は無い。
if (result) {
…
}
正か誤か。

java初心者向けの問題。

**仕様書無しさん** · 2014/08/02(土) 17:18:55.70

ぬるぽとかそういう話？

**仕様書無しさん** · 2014/08/02(土) 19:11:19.08

違う話だよ。

**仕様書無しさん** · 2014/08/02(土) 21:24:03.58

ﾌﾌｯ

**仕様書無しさん** · 2014/08/02(土) 22:14:42.06

>>806
こういう問題を言っちゃう奴はコミュ力が無いんだと思う。
可読性かシンプル化でどちらも間違いではないし。

**仕様書無しさん** · 2014/08/02(土) 22:25:20.68

いや、そういう問題じゃ無いってw
プログラムが（必ず）正しく動作するか否かの問題。

**仕様書無しさん** · 2014/08/02(土) 22:28:05.46

それは上の方が必ず動くよ。
下は上までの肯定でresultに変なもんが入ってたらヤバいだろ。

**仕様書無しさん** · 2014/08/02(土) 22:47:16.14

具体的には？

**仕様書無しさん** · 2014/08/02(土) 22:51:47.89

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

**仕様書無しさん** · 2014/08/02(土) 22:56:24.85

まあ>>806はjavaの話だけどな

**仕様書無しさん** · 2014/08/02(土) 23:33:30.09

まあ>>814もjavaの話だけどな

**815** · 2014/08/02(土) 23:41:05.84

マジだ…orz

**仕様書無しさん** · 2014/08/02(土) 23:57:45.80

>>816
Javaって>>814でwarningも出してくれない欠陥言語なの？

**仕様書無しさん** · 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

全然違うだろ

**仕様書無しさん** · 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って見つけたら、俺が書いたのだからﾖﾛｼｸ

**仕様書無しさん** · 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だけど、そう、スペルミスも込みなんだよ

**仕様書無しさん** · 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 これ使っていいよ

**839** · 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使うのは別に間違いではないと思うが
というか普通じゃね？
否定してるヤツはメインルーチンのほうでわざわざ型を判定させる処理でも入れるのかね

**仕様書無しさん** · 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
クスッときた

**仕様書無しさん** · 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の略
こういう名前の付け方を見るとほっこりする

**ﾄﾝﾄｶｲﾓ名無しさん** · 2015/10/23(金) 02:53:30.94

SEGA Mastaa Sisutemu

**仕様書無しさん** · 2016/05/17(火) 00:16:16.39

関数名だけど・・・
Chenge_Language_Setting_Engrish()

**仕様書無しさん** · 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

ストゥーになっちまった

**仕様書無しさん** · 2017/12/29(金) 20:09:50.23

誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』というブログで見ることができるらしいです。

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

WAHY6659LR

**仕様書無しさん** · 2018/05/22(火) 14:48:27.25

とても簡単な自宅で稼げる方法
参考までに書いておきます
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

BU06O

**仕様書無しさん** · 2020/01/20(月) 09:28:21.15

２物体の相対速度ベクトルrvをx方向に分解して衝突面の法線方向に分解してz方向に分解した変数を vxnz としているけどふざけていますか？
同じような変数が無数に並んでいます
いちいちrelativeとかvelocityとか書くべきなの？見にくくなるよ？