クラス名・変数名に迷ったら書き込むスレ。Part28 [無断転載禁止]©2ch.net

**ネミ子** · 2017/05/07(日) 18:01:52.03

クラス名、変数名のつけ方に悩んだら書き込むスレです。

命名規則や設計の善し悪しについて議論するのは基本的に禁止。

前スレ
クラス名・変数名に迷ったら書き込むスレ。Part27
http://echo.2ch.net/test/read.cgi/tech/1476572490/

**デフォルトの名無しさん** · 2018/08/18(土) 01:00:41.41

混同というのはID:nnyWdGJKに対して言ったんだけどな
余計な飛び火をさせてしまった

**デフォルトの名無しさん** · 2018/08/18(土) 01:06:13.96

>>305
英語にも外来語は多いよね
新しい概念に対して語彙を増やさないというのが何を指してるのか詳しく知りたい
漢字がない分、同音異義語が多いという話なら分かる

**デフォルトの名無しさん** · 2018/08/18(土) 01:10:28.56

>>308
if (sky is blue) earth.evolute()
プログラミングで述語は書くと思うよ

**デフォルトの名無しさん** · 2018/08/18(土) 01:13:07.29

あらゆるメソッド名、クラス名にSentenceと名付けてしまうかのような暴挙

**デフォルトの名無しさん** · 2018/08/18(土) 01:14:41.34

あらゆるメソッド名、クラス名にSentenceと名付けたらコンパイル通らんやんwwww
アホしかおらんのかここはwwww

**デフォルトの名無しさん** · 2018/08/18(土) 01:16:34.23

その理屈で言えば>>266もコンパイル通らんやろ…

**デフォルトの名無しさん** · 2018/08/18(土) 01:18:38.83

>>316
スコープ内で一意なら普通にコンパイル通るわw
おまえプログラミングしたことあるんかwwwww

**デフォルトの名無しさん** · 2018/08/18(土) 01:25:33.36

>>317
その理屈で言えばSentenceも通るやろ

マジレスするとプレフィックスないしサフィックスの話やろ

**デフォルトの名無しさん** · 2018/08/18(土) 01:27:40.92

>>318
どの理屈やねんwwww
言い訳すんなアホw

**デフォルトの名無しさん** · 2018/08/18(土) 01:28:57.12

つーか何度も言ってるが、C#で多用されるLINQの引数型としてPredicateはあちらこちらで使われるんだから
それに別の意味を持たせて再定義してる時点で脳味噌スッカスカだろと

**デフォルトの名無しさん** · 2018/08/18(土) 01:30:10.58

>>319
スコープ内でSentenceが一意ならコンパイルが通ることも知らんのかいな（呆れ）
プログラミングしたことあるか？

**デフォルトの名無しさん** · 2018/08/18(土) 01:44:39.95

delegate（委任、委譲）とpredicate（断定）の区別すら出来ない子がいるとは…一般名詞とか言語仕様以前の問題だろう
中学生ぐらいで英語力が止まってるのか？

**デフォルトの名無しさん** · 2018/08/18(土) 01:56:59.73

>>312
何を指すも英語はそんな文脈に依存して意味が変わる単語だらけ
atomic, bit, function

日本語は英語より文脈に依存する表現を好まない傾向が強い

分割不可能性みたいに明示的な漢語を作り出すか、ビットのようにカタカナ表記にするか
（日本語でビットといえば普通文脈に関係なくそのビットしかない）関数のように音訳する

**デフォルトの名無しさん** · 2018/08/18(土) 02:12:07.58

電動ドライバーのビットはあるかw
でも日本語が同じ言葉より語彙を増やすことを好む言語なのはちょっと考えれば
大方同意するよね

スレ違いなのでこれで終わりで

**デフォルトの名無しさん** · 2018/08/18(土) 02:14:44.60

× 同じ言葉より語彙を増やすことを好む
〇同じ言葉を使いまわすより語彙を増やすことを好む傾向が強い

**デフォルトの名無しさん** · 2018/08/18(土) 02:58:17.88

valueをgetするメソッド名に悩んでるのですが、一般的にはどんな名前になるんですかね？

**デフォルトの名無しさん** · 2018/08/18(土) 02:59:09.12

valueGetterでいいのかな？

**デフォルトの名無しさん** · 2018/08/18(土) 04:05:49.01

>>320
いうほど使わないが。
Func<T,bool>としか書かないからな。

**デフォルトの名無しさん** · 2018/08/18(土) 05:31:12.42

>>326, >>327
変数のようにその値が意味する名称にする（例えば、string.length）、あるいはgetValueのように動詞始まりで書く
個人的には、状態を取得する関数は他の関数（手続き、メソッド）と完全に区別しているから、名詞にするよ
状態を表すbool型を返す場合は、trueを想定した命題にする特殊なルールがある（例えば、iterator.hasNext）

ValueGetterって名称の場合、関数は動詞始まりが一般的だから、(get)ValueGetterのように省略していると解釈され
意地悪を言っちゃうと、Valueを取得するGetterオブジェクトを返すって意味に取られかねない

**デフォルトの名無しさん** · 2018/08/18(土) 06:39:02.57

>329は解答として満点に近いと思うのでこれに賛成しておこう

**デフォルトの名無しさん** · 2018/08/18(土) 07:44:29.19

>>324
ありがとう把握した
個人的にはやまと言葉は1単語の広がりがとても広く
漢語はその豊富な表意文字と音素の恩恵から狭めって認識だわ
それと外来語学習者のバイアスがあって
学習者はコアとなる概念をそのまま理解できずに
母語の単語に置き換えて把握するから
例えば英語話者は日本語の核という言葉が
atomic, core, nucleus, kernelの4つに当てはまることを見て
使い回しの多い言語デスネーと感じる傾向があると思う
スレチなんで俺もこのくらいにしておきます

**デフォルトの名無しさん** · 2018/08/18(土) 07:56:57.22

>>326
言語とクラス名にも依るけど、その感じだとJavaかな
JavaならThreadLocalやOptionalのような変数のコンテナクラスにはget()というメソッド名が与えられてるから、それに倣うと自然な感じになると思う

**デフォルトの名無しさん** · 2018/08/18(土) 08:21:05.22

20年前ならともかく、
getだけでJava前提にするのは厳しいかなと思いますがｗ

**デフォルトの名無しさん** · 2018/08/18(土) 12:28:24.34

モダンな言語は大概プロパティがサポートされているから、getterメソッドを使う慣習があって、小文字で書くそこそこシェアのある言語ってことでJavaかなーと思ったんだけどな
Rubyも候補に入るのかな

**デフォルトの名無しさん** · 2018/08/18(土) 12:46:29.75

>>328
コンパイラが暗黙的にキャストしてくれるからって、それに頼り切って本来の引数型を見てみぬふりしちゃいかんだろう

**デフォルトの名無しさん** · 2018/08/18(土) 13:03:31.24

>>335
その本来がFuncだが。
https://docs.microsoft.com/en-us/dotnet/api/system.linq.enumerable.where

**デフォルトの名無しさん** · 2018/08/18(土) 13:33:47.43

>>334
プロパティあっても、アクセサ的なメソッドを作ることは珍しくないかなと

**デフォルトの名無しさん** · 2018/08/18(土) 21:18:57.24

ルッビーアックバール！

**デフォルトの名無しさん** · 2018/08/19(日) 00:30:14.49

>>334
C#でもありえーるでしょ。
リフレクション前提とか。
プロパティはメソッドと別扱いだから。

**デフォルトの名無しさん** · 2018/08/19(日) 07:29:43.11

>>339
小文字でと書いたのは、C#のようにメソッド名先頭を大文字とするのが主流の言語は
推測の第一候補にはならなかったっていう意味ね

もし>>332でJavaと推測・仮定したことがナンセンスだというツッコミを入れるなら
他の言語である可能性がゼロでないことを示しても論拠として弱い
Javaではない蓋然性の方が高いだろという主旨でないと

**デフォルトの名無しさん** · 2018/08/19(日) 12:34:21.72

１段落目だけでいいです

**デフォルトの名無しさん** · 2018/09/18(火) 13:04:45.53

今週のぱいじょ１３２話
https://paiza.jp/paijo

『大事な変数名』だってよ

**デフォルトの名無しさん** · 2018/09/19(水) 10:54:47.56

変数名は大事だな

**デフォルトの名無しさん** · 2018/09/19(水) 14:27:36.07

よーしパパ、ハンガリアンでバリバリコード書いちゃうぞ！

**デフォルトの名無しさん** · 2018/09/20(木) 20:05:21.32

ハンガリアンは大事だな

**デフォルトの名無しさん** · 2018/09/20(木) 20:50:07.90

変数名はだいじだな
ハンガリアン（に汚染されていたことの発覚）はおおごとだな

**デフォルトの名無しさん** · 2018/09/20(木) 20:51:25.89

カッコさんもこれほど存在感のない使われ方するとは思ってもみなかったやろなw

**デフォルトの名無しさん** · 2018/09/21(金) 22:58:36.14

ハンガリアン悪くない
悪いのは型名をプレフィクスに使う事

**デフォルトの名無しさん** · 2018/09/21(金) 23:17:13.00

型名が何フィクサーやったらええんや？

**デフォルトの名無しさん** · 2018/09/21(金) 23:30:33.48

NYのフィクサーならカッコいいと思います

**デフォルトの名無しさん** · 2018/09/21(金) 23:40:14.17

ハンガリアン悪くない

private変数の
m_
とか推奨

**デフォルトの名無しさん** · 2018/09/22(土) 00:07:18.77

納期

DEAD_LINE

死ぬんか

**デフォルトの名無しさん** · 2018/09/22(土) 01:02:58.20

>>352
何が言いたいのかよく分からない
英語にケチつけてるなら、それ相応の板へどうぞとしか

**デフォルトの名無しさん** · 2018/09/22(土) 09:01:46.06

訳し方ひとつじゃないだろ

プログラマーのメンタルに悪い

**デフォルトの名無しさん** · 2018/09/22(土) 09:41:14.17

こうですね、理解ります

DEAD_LINE
死の線
モノの死にやすい部分
直死の魔眼により視ることができ、切られたものは死ぬ

**デフォルトの名無しさん** · 2018/09/22(土) 10:17:47.73

>>354
一般的な日本人がそのまま読んでも意味が通じる
実に最適な選択だろ

**デフォルトの名無しさん** · 2018/09/22(土) 11:07:39.01

納期＝死線

ちがう絶対ちがう遅れたっていいんだ誰も死なないんだ

**デフォルトの名無しさん** · 2018/09/22(土) 11:23:11.52

due date使えよ

**デフォルトの名無しさん** · 2018/09/22(土) 11:26:12.67

最適解について考えるなら俺も due date を推したい
時刻もあり得る deadline と違って日付であることが明確
deadline は守るべき締め切りというニュアンスが乗りすぎてフラットでない感もある
ただアッパーケースで書いてるし、ザ・期日というべき値ならDUE_DATEよりDEAD_LINEのニュアンスが相応しい文脈なのかもと思ったり
due date という英語は難しいから避けた方がいい、なんて環境ならレベルが低すぎるからとっととおさらばしたい

**デフォルトの名無しさん** · 2018/09/22(土) 11:33:19.06

いや納期だったか
じゃあ delivery date だな

**デフォルトの名無しさん** · 2018/09/22(土) 12:34:11.88

delivery dateだと、その日だけって感じにならん？
due dateならそれより前でも可ってわかるけど

**デフォルトの名無しさん** · 2018/09/22(土) 13:49:40.09

英辞郎で「納期」で検索した感じ、ニュアンス的には納品側の用語としてはdeadline、
発注側の用語としてはdue dateが適切のように感じるね

個人的にはそこまでこだわる必要はなく、普通にdeadlineでよいと思う

**デフォルトの名無しさん** · 2018/09/22(土) 13:51:25.09

俺のメンタルに悪いっつってんだろｇじゃｋじゃあｊｓふぁ

**デフォルトの名無しさん** · 2018/09/22(土) 14:24:37.52

日本語には「～です」って言葉をよく使うんだけど
生きづらそうだね

**デフォルトの名無しさん** · 2018/09/22(土) 15:15:34.07

それは直接的な意味ではないし回避するために毎回文章を考えるのが面倒なので仕方ないdeath

**デフォルトの名無しさん** · 2018/09/27(木) 19:49:12.84

自社スタンドアロンアプリでデータをCSVにエクスポートする機能があるので、
ExportXXX()みたいな関数名が付けられていたんだけど、
この機能を使い回して自社WEBサービス版でも一部利用しようということに
なったものの、こっちで使うときもExportでいいのかどうか
くだらないことに引っかかってる次第。

スタンドアロン←→WEBの間にユーザーは一切関与せず、どちらもまとめて
一つのシステムという扱いなので、Exportでは外に出して自由に使える
イメージが強くて違和感が。

気にしすぎですかね？

**デフォルトの名無しさん** · 2018/09/27(木) 19:55:39.03

気にしすぎというか何言っとるのかわからん

**デフォルトの名無しさん** · 2018/09/27(木) 20:14:19.43

もはや気にしてもしょうがない
出来ているものの名前は変えなくていい
とはいえ違和感が強いならExportというネーミングが最初から微妙だった可能性を省みてもいいかも
システム外部へのエクスポートはCSV出力のひとつの役割で
当初はその側面しか見てなかったけど
本質を表してはいなかった可能性がある
例えば別案はWriteXXXToCSV

**デフォルトの名無しさん** · 2018/09/27(木) 20:15:54.50

Web版でExportXXXしたら何が起きるの？

**デフォルトの名無しさん** · 2018/09/27(木) 20:40:57.03

何言ってるのか分からないねw

Exportっていうのは普通に考えれば「データを他所のアプリに対してexport」ってニュアンスなので、
もしCSVをそのアプリ自身でも読むのならちょっと違うとは思う。

**デフォルトの名無しさん** · 2018/09/27(木) 21:05:18.71

>>367
スタンドアロンというのが意味が違うんですかね。
Windowsにインストールしてるソフトがあり、それのことを書いてました。
旧来のそのソフトにWEBサービス版が加わり、そっちとデータの
やりとりが必要となったという流れです。

>>368
仰るとおりです。当初は外部に出してしまって好きに使ってもらう
ことしか考えてなかったのですが、WEB版にデータを渡すのに
一々新規でそのプログラムを作らないで、Export部分を使い回した方が
工数削減出来るだろうし、その後の保守も手間を省けるというところです。
ただ、この場合システム内部で完結するのでExportとは言わないかなあと。

既に開発スタートしてて、既存のExport部とは関係ないデータを吐き出すのに
MakeXXXXCSVみたいなのを作ってから、後でExport処理も使い回す際に
ネーミングに疑問が出てきました次第で。

>>369
WEB版にはExport機能はありません。
スタンドアロン運用で不便な点のみWEB版として追加してます。

>>370
すみません。
ニュアンスとしては同感でして、そこから今回の質問の流れとなりました。

とりあえずは、やはりExportのままだと本来の意味からするとちょっと
違う感じですよね。
もうちょっと考えてみます。どうもありがとうございました。

**デフォルトの名無しさん** · 2018/09/28(金) 20:32:14.35

>>366
エクスポートは取り出した結果を外部に公開するイメージだから、スタンドアロンとかwebとかは関係ないと思う。

**デフォルトの名無しさん** · 2018/09/29(土) 01:06:55.25

おまえのイメージも関係ないと思う

**デフォルトの名無しさん** · 2018/09/29(土) 02:02:39.43

>>372
そう、関係ないですよ。一行で書けば、
既にあるExport機能を内部で完結する形で流用するので関数名がExportだと意味が違ってくるけど変えた方がいいかな考えすぎ？
という主旨です。

開発内部からみれば一応二つのシステム間でExport,Importしてるのは間違いないですが。

**デフォルトの名無しさん** · 2018/09/29(土) 12:46:33.16

最初から通信などの内部処理用として用意するならserializeとかにすると思うけど、
既存の処理を使い回すならexportでも別にいいかなあって印象

自分で自由に出来るなら、出力部分のコードをserialize側に移して
export側ではserializeを呼び出すようにしちゃってもいいんだろうけど

**デフォルトの名無しさん** · 2018/10/06(土) 01:13:06.07

「システム・ハンガリアン記法」を嫌う人がいるようだけど、個人的には実際に長年使ってみて、
コーディング効率が上がっていると感じる。

ネット上でよく見かける反論に、「システム・ハンガリアン記法は、（代入などで型が異なれば）コンパイラ
がエラーを出してくれるのだから不要」というものがある。

しかし、システム・ハンガリアン記法を使っていれば、たとえば、代入のコードをコーディングしたい最中に
周囲の変数の変数名を見て、エラーが起きない組み合わせを探すと、実は、非常にわずかな組み合わせ
しか無いことが多い。

そして、そのわずかな組み合わせの中に必ず正しいコードがあるので、人間の作業は、
そのわずかな組み合わせの中から選ぶだけでよくなるので、思考の節約になってくれる。

もし、システム・ハンガリアンを使っていなければ、この思考の節約が働かないので、
本格的に考えないといけないことがあり、余計に時間がかかってしまうことがある。

正しいコードが次のようなものだったとする：

pXxxx = pYyyy + ofsAaa;

周囲には、pXxx, pYyy, ofsAaa 位しか変数がないとすれば、頭を使わなくても、可能な組み合わせは、
上記のコードを含む少数のパターンしかないことがすぐに分かる。

そのうちから正しいコードを「選ぶ」事と、意味で考えることを二重に行うことで、早く正解のコードを
書くことが出来るようになる。

ところが、システム・ハンガリアン記法を使っていなければ、意味で考えることしか出来なくなり、
思考パターンを減らすことが出来ない。また、コンパイルしてみないと「検算」もも出来ない。

**デフォルトの名無しさん** · 2018/10/06(土) 01:42:44.00

さらに、文字列などを使っている時、

CString　　　　　strText;
const char　　　*pszText = (const char *)strText; // operator char *() 演算子による型変換
int　　　　　　　　lenText = strText.GetLength();

などと、同じ Text という名前の文字列に対して、CString 文字列や、それを高速アクセスするための
文字列へのポインタ、文字列の長さ、の各々に対する変数名を機械的に付けられるのは重宝している。

さらに、よくあるのは、メンバ変数と全く同じ意味のローカル変数や仮引数がある状況。

この場合、毎回、新しい生を考え出すのは大変なので、メンバ変数には必ず先頭に m_ を
つけていると便利。今の場合、

m_strText　　　= strText;
m_lenText　　　= lenText;

のように美しくバランスするのがとても好きだ。
これだと、エラーが正しいコードであることがとても分かりやすい。

また、「m_」の接頭辞は、次のようなコンストラクタでも重宝する：
CPerson::CPerson( const CString &strName ) {
m_strName = strName;
}
さらに、引数が同じ文字列でも、0終端文字列の場合は、
CPerson::CPerson( const char *pszName ) {
m_strName = pszName;
}
とすればよいだけなので、とても美しい。

**デフォルトの名無しさん** · 2018/10/06(土) 02:54:17.48

唐突にどうしたのw
真面目に言ってるのかネタのつもりかのか知らんけど、畢竟

「書きっぱなしで他人も自分も後でメンテしない」

コードならどんな表記法使おうが何の問題もないのよ。
ハンガリアンが批判されるのは、この条件を満たさない（世の中のコードの9割はそうだと思うけど）
場合に問題が起こるから

もちろんハンガリアンがダメって言ったって教条主義的に全部捨てる必要はない。
メンバ変数のプリフィクスなんか誰も文句言わないよ

こんな20年前に決着が付いてる話を今頃して何が楽しいの

**デフォルトの名無しさん** · 2018/10/06(土) 03:14:51.07

ワイはアプリもシステムも混在するハンガリアン
とりあえず事故は皆無

アプリケーションで使うのは、大体座標系かな
x,y,cx,cyとか、コイツらをシステムの方でやっちゃうと変数名が長くなるだけ
ならまだいいんだけど、計算がちと複雑化してくるとあああああってなる

**デフォルトの名無しさん** · 2018/10/06(土) 07:22:44.97

グローバル変数でなければハンガリアンオッケーだ。

**デフォルトの名無しさん** · 2018/10/06(土) 11:05:40.90

個人的にはこうだな
・ポインタ変数にpを接頭するのは分かりやすい
・メンバ変数にm_も悪くない
・型を接頭するのはやめて

**デフォルトの名無しさん** · 2018/10/06(土) 11:06:26.33

lenTextがintLenTextじゃないのは気になった
デフォルト扱い？

**デフォルトの名無しさん** · 2018/10/06(土) 11:10:52.47

型の接頭がいいと思うのは関数内で型変換するときくらい

**デフォルトの名無しさん** · 2018/10/06(土) 11:17:28.61

ポインタと型変換とメンバ変数に共通することを一般化して考えると、同じ情報を異なる形式で2つ持ちたいときにハンガリアンは活きる

**デフォルトの名無しさん** · 2018/10/06(土) 14:07:26.85

>>381
今時pXxxはないわ
普通にPtrToXxxかXxxPtrでいい

PtrToReadPtr
これなら何を意味してるかだいたいわかるが
ppRead
こんなのは勘弁してもらいたい

**デフォルトの名無しさん** · 2018/10/06(土) 15:03:56.04

C++相談室 part137
https://mevius.5ch.net/test/read.cgi/tech/1535353320/962

962　デフォルトの名無しさん (ﾜｯﾁｮｲ 6ee3-BkfR)　[sage]　2018/10/05(金) 18:51:17.31 ID:4ThlZrTR0 [3/7]
>>947
最初の従業員のデータについては、
EmployeeInfo

二番目の dictionary の方は、
g_dictCompanyEmploeeInfo_s

**デフォルトの名無しさん** · 2018/10/06(土) 15:21:42.95

コピペマン参上！！！まで読んだ

**デフォルトの名無しさん** · 2018/10/06(土) 16:32:09.02

pFooとbarPtr/PtrToBazの間に
そこまで大きな差があるとも思えないんだが

>>381
個人的には、メンバ変数の m_ はバッドノウハウに見える

**デフォルトの名無しさん** · 2018/10/06(土) 20:13:22.49

>>388
pは適当すぎたか
PointerToCompanyNameよりは
ptrCompanyNameのほうが好み程度のことが言いたかった

**デフォルトの名無しさん** · 2018/10/06(土) 21:13:34.32

>>389
どっちもプリフィクスなの変わらなくない？って聞きたかったんだけど

**デフォルトの名無しさん** · 2018/10/06(土) 22:43:56.02

>>390
別にサフィックスでもいいんじゃない？
そこは気にしてなかったわ

**デフォルトの名無しさん** · 2018/10/06(土) 22:52:54.09

変なプレフィックスを使うことに忌避感情はあるけどptrというやや古典的な略語を使うことについてマイナスイメージはないということか

**デフォルトの名無しさん** · 2018/10/06(土) 23:10:54.72

>>391-392
よく分からんが、pFoo を否定したのは>385だぞ

**デフォルトの名無しさん** · 2018/10/06(土) 23:46:24.65

>>393
ゴメン間違えた

**デフォルトの名無しさん** · 2018/10/07(日) 11:54:03.14

>>385
何故、ハンガリアン記法が支持され、否定されてきたか

PtrToReadやPointerToReadなんて記法は、そのオブジェクトのデザインとしての命名ではなく
ハンガリアン記法と同じくプログラマの都合のような命名でしょ
文章的にそれをやってしまうと、ハンガリアン記法よりも余計にウザったい命名規則になると思うがな
そのPointer（Ptr）って名前は、システムとしてのポインタ（型）なのか
デザインとしてのポインタ（指し示すもの）なのか、って分かりづらくなる

**デフォルトの名無しさん** · 2018/10/07(日) 12:09:03.29

>>395
何を言ってるのか意味が分からないよ
システムとかデザインとか何のこっちゃw

世の中いろんなプログラマがいるが、PtrToReadなんて命名をする奴は誰もいないだろうw

よく見てみ
ReadPtrって書いてあるでしょうw
これは例えばキューみたいなものを実装する時に次のデータの読み出し位置をポイントするポインタ（読み出しポインタ）だ
だからPtrToReadPtr は「読み出しポインタへのポインタ」だw

**デフォルトの名無しさん** · 2018/10/07(日) 13:54:56.07

>>395
だからどっちのハンガリアンだよ

**デフォルトの名無しさん** · 2018/10/07(日) 16:58:32.70

>>396
>PtrToReadなんて命名をする奴は誰もいないだろう
「普通にPtrToXxxかXxxPtrでいい」って>>385に書いてあるじゃん

>だからPtrToReadPtr は「読み出しポインタへのポインタ」だw
意気揚々と説明しなくても、そんなことは分かってるよ

>システムとかデザインとか何のこっちゃw
意味分からんか？
本来デザインとしての名称にシステムとしての名称が加味される状態だろ（strFoo、iBarなどのシステムハンガリアンみたいに）
PtrToXXXでもXXXPtrでもそれと同じな上に変に文章的な書き方をしたことでデザイン上の名称なのか区別がつき難い
fooPointerって変数があった時、それがポインタ型を表すのか、デザインとして指し示すモノって意味でつけたのか、分からないだろ
そんなのなら、まだpFooのような無機質な記号の方がまだマシだよ
こんなの、Bool型を返すプロパティを命題にするとか、プロパティ名は名詞にするとかと同じように特殊ルールなんだからさ

>>397
システムハンガリアンだよ

**デフォルトの名無しさん** · 2018/10/07(日) 17:11:57.27

>>398
よっしゃ、今日はこれぐらいにしといたるワ、まで読んだ

しかし、前置詞のtoと不定詞のtoに区別が付かないって真面目にいう人初めて見たよw

**デフォルトの名無しさん** · 2018/10/07(日) 17:17:10.53

>>399
その区別の話をしていないよ
文章の書き方が悪かったら申し訳ないけど、何でそんなふうに捉えるんだ？

**デフォルトの名無しさん** · 2018/10/07(日) 17:42:41.95

よしじゃあMemoryAddressPointerToReadにしよう

**デフォルトの名無しさん** · 2018/10/08(月) 00:52:41.08

とりあえず、生ポインタ使うのはやめようぜ

**デフォルトの名無しさん** · 2018/10/08(月) 01:47:59.04

(´∀｀)＜なまぽ

**デフォルトの名無しさん** · 2018/10/08(月) 05:15:16.84

ギュッ❤

**デフォルトの名無しさん** · 2018/11/08(木) 04:04:47.08

ドラゴンボール的なものを想像して欲しいんだけど
かめはめ波を撃つとして

(1)手首を合わせて腰の横に持っていく
(2)エネルギーを貯める「かめはめ～」
(3)手首を前に突き出す、エネルギー放出開始。「波！」
(4)敵に命中
(5)「行けぇ！！」とか「うおおおお！」とか叫びながら攻撃力アップさせる
(6)耐えきれなくなった敵が吹っ飛ぶ

というシークエンスに分割するとき、それぞれどういう単語を選んだら良いだろうか。

とりあえず
(1)PreliminaryAction (2)ChargingEnergy (3)MainAction (4)Impact (6)BlowingAway
まではそれっぽいのを探したが、(5)が全然分からん。そもそも適切な日本語も分からん。

**デフォルトの名無しさん** · 2018/11/08(木) 08:10:50.98

>>405
BoostActionとかでいいと思うけど個人的にはMainActionがイミフ

**デフォルトの名無しさん** · 2018/11/08(木) 08:21:30.16

>>406
なるほどboost。
(1)が予備動作だったので、対になる主動作かなあって

**デフォルトの名無しさん** · 2018/11/08(木) 08:23:29.59

>>405
prepare
charge
fire / discharge
hit
empower / inject power
blow away

一部微妙？

**デフォルトの名無しさん** · 2018/11/08(木) 09:29:43.84

それならfireとboostに一票
6段階あるシーケンスで主処理って命名は危うい
目的は相手にダメージを与えることだからむしろboostが主ともいえる
解釈に差が生まれる語は避けるが吉

アクションと状態が一緒くたになってるからアドバイスが名詞と動詞で割れてる
状態遷移図でいう丸印と矢印ね

**デフォルトの名無しさん** · 2018/11/08(木) 12:08:24.19

あんまりアニメみないが、あのシーンは単に揉み合ってるんじゃなくて攻撃力をアップさせてるのかw
その発想は俺にはなかった
あの世界ではそんなことが可能なのか

**デフォルトの名無しさん** · 2018/11/08(木) 15:27:58.00

>>405
(5) はreinforce とかどうか
こういうのは軍隊用語引っ張ってくるとそれっぽいのが見つかりそう
Reinforcements は「増援部隊」の意味