クラス名・変数名に迷ったら書き込むスレ。Part28 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
クラス名、変数名のつけ方に悩んだら書き込むスレです。
命名規則や設計の善し悪しについて議論するのは基本的に禁止。
前スレ
クラス名・変数名に迷ったら書き込むスレ。Part27
http://echo.2ch.net/test/read.cgi/tech/1476572490/ そもそも質問者がC#を使ってるのに、そのC#で多用するPredicateを別の意味で再定義しようとしてる時点でアホやろ
そんなアホ新人がいたら試用期間で切るわ predicateの名詞用法のうち最も代表的なものは「述語」だから広義に用いても間違いという訳ではないんだけど、英英辞典を引くと動詞の「断定する」や「命題の述部」というニュアンスも色濃く現れてきて無視できない
https://www.dictionary.com/browse/predicate
語源としてもその辺から由来し、広義の述語へと転じた経緯がある模様
特にプログラミングや論理学の分野でどう用いられているかを見れば答えは自ずと決まる C#(特にLINQ)を触り始めたばかりの初心者だとPredicateとラムダ式を混同してることが多いからその類じゃないかね?
Predicateを引数にとる各種メソッド群も、一定の規則を守ったラムダ式ならコンパイラが自動的に解釈・変換してくれるもんだから勘違いしがち >>294
何を言いたいのかよくわからん
この際、おまえがしてた、若しくは現在進行形でしている勘違いを
洗いざらい吐き出しちまえよ >>295
「FuncにもActionにも何でもかんでもPredicateと名付けてしまうのはこれら全てがラムダ式と同一のものだと勘違いしてるんじゃないの?」ってこと
俺じゃなくて今春の新米PGにいたんだわ >>296
ラムダ式と同一のものというのがよく分からんが
ラムダ式ならLambdaでええやん
それがなぜPredicateになるんや? >>297
同じ意味をもつ別名ぐらいに考えてたらしい
そこで謎の選択をした理由はそんなの本人にしかわからんがな
カッコいいとでも思ったんじゃね? この人はPredicateとDelegateを混同してるのではないだろうか >>266が発狂してスレ伸ばしてるのこれ?
>>300
かもねえ >>300
最後の3文字しかあってないじゃないかwww
そんなバカがいるわけが…いや、そんな、まさか、ねえ? >>300
いいだしっぺ本人だが、混同はしていないつもり。
C#ではdelegateは言語機能だけど、あくまでpredicateは一般名詞。数理論理なんかを記述してるわけではないし。
lambdaは抽象的な機能とか無名関数とかをあらわす印象。
>>293
英語は同じ単語を別の用途に使い回すことはよくあるからね。
あんまり気にしない。w >>303
このスレでも何度も書いたことだが、
英語という言語は日本語のように新しい概念に対して語彙を増やして対応する言語じゃない。
同じ言葉を文脈によってまったく別の意味に使い分ける傾向が強い言語だ。
だから、
>あくまでpredicateは一般名詞
これナンセンス。
だから何度も言ってるだろう。
プログラミングの分野では(数学と同じく)boolで評価する関数のことをpredicateを言うの。
いい加減恥を知った方がいいよ。 >>303
言語機能か一般名詞かの違いしかないと思ってるんならそれは混同してるってことだよ だいたいコードの中の普通の日本語でいう述語なんか出てこないだろうってw
お前はコードの中に、
(空は)青い
(地球ま)回る
とか書くのかとw
ダイクストラ先生の時代からコードってのはデータと手続きで出来てるんだよw
それは宣言型の言語だろうが同じこと なんやまたどえらいアホが現れたなあw結構結構wwww >>303
キミ、「述語」って言葉の意味すらよく分かってないんじゃない? 混同というのはID:nnyWdGJKに対して言ったんだけどな
余計な飛び火をさせてしまった >>305
英語にも外来語は多いよね
新しい概念に対して語彙を増やさないというのが何を指してるのか詳しく知りたい
漢字がない分、同音異義語が多いという話なら分かる >>308
if (sky is blue) earth.evolute()
プログラミングで述語は書くと思うよ あらゆるメソッド名、クラス名にSentenceと名付けてしまうかのような暴挙 あらゆるメソッド名、クラス名にSentenceと名付けたらコンパイル通らんやんwwww
アホしかおらんのかここはwwww その理屈で言えば>>266もコンパイル通らんやろ… >>316
スコープ内で一意なら普通にコンパイル通るわw
おまえプログラミングしたことあるんかwwwww >>317
その理屈で言えばSentenceも通るやろ
マジレスするとプレフィックスないしサフィックスの話やろ >>318
どの理屈やねんwwww
言い訳すんなアホw つーか何度も言ってるが、C#で多用されるLINQの引数型としてPredicateはあちらこちらで使われるんだから
それに別の意味を持たせて再定義してる時点で脳味噌スッカスカだろと >>319
スコープ内でSentenceが一意ならコンパイルが通ることも知らんのかいな(呆れ)
プログラミングしたことあるか? delegate(委任、委譲)とpredicate(断定)の区別すら出来ない子がいるとは…一般名詞とか言語仕様以前の問題だろう
中学生ぐらいで英語力が止まってるのか? >>312
何を指すも英語はそんな文脈に依存して意味が変わる単語だらけ
atomic, bit, function
日本語は英語より文脈に依存する表現を好まない傾向が強い
分割不可能性みたいに明示的な漢語を作り出すか、ビットのようにカタカナ表記にするか
(日本語でビットといえば普通文脈に関係なくそのビットしかない)関数のように音訳する 電動ドライバーのビットはあるかw
でも日本語が同じ言葉より語彙を増やすことを好む言語なのはちょっと考えれば
大方同意するよね
スレ違いなのでこれで終わりで × 同じ言葉より語彙を増やすことを好む
〇 同じ言葉を使いまわすより語彙を増やすことを好む傾向が強い valueをgetするメソッド名に悩んでるのですが、一般的にはどんな名前になるんですかね? >>320
いうほど使わないが。
Func<T,bool>としか書かないからな。 >>326, >>327
変数のようにその値が意味する名称にする(例えば、string.length)、あるいはgetValueのように動詞始まりで書く
個人的には、状態を取得する関数は他の関数(手続き、メソッド)と完全に区別しているから、名詞にするよ
状態を表すbool型を返す場合は、trueを想定した命題にする特殊なルールがある(例えば、iterator.hasNext)
ValueGetterって名称の場合、関数は動詞始まりが一般的だから、(get)ValueGetterのように省略していると解釈され
意地悪を言っちゃうと、Valueを取得するGetterオブジェクトを返すって意味に取られかねない >329は解答として満点に近いと思うのでこれに賛成しておこう >>324
ありがとう把握した
個人的にはやまと言葉は1単語の広がりがとても広く
漢語はその豊富な表意文字と音素の恩恵から狭めって認識だわ
それと外来語学習者のバイアスがあって
学習者はコアとなる概念をそのまま理解できずに
母語の単語に置き換えて把握するから
例えば英語話者は日本語の核という言葉が
atomic, core, nucleus, kernelの4つに当てはまることを見て
使い回しの多い言語デスネーと感じる傾向があると思う
スレチなんで俺もこのくらいにしておきます >>326
言語とクラス名にも依るけど、その感じだとJavaかな
JavaならThreadLocalやOptionalのような変数のコンテナクラスにはget()というメソッド名が与えられてるから、それに倣うと自然な感じになると思う 20年前ならともかく、
getだけでJava前提にするのは厳しいかなと思いますがw モダンな言語は大概プロパティがサポートされているから、getterメソッドを使う慣習があって、小文字で書くそこそこシェアのある言語ってことでJavaかなーと思ったんだけどな
Rubyも候補に入るのかな >>328
コンパイラが暗黙的にキャストしてくれるからって、それに頼り切って本来の引数型を見てみぬふりしちゃいかんだろう >>334
プロパティあっても、アクセサ的なメソッドを作ることは珍しくないかなと >>334
C#でもありえーるでしょ。
リフレクション前提とか。
プロパティはメソッドと別扱いだから。 >>339
小文字でと書いたのは、C#のようにメソッド名先頭を大文字とするのが主流の言語は
推測の第一候補にはならなかったっていう意味ね
もし>>332でJavaと推測・仮定したことがナンセンスだというツッコミを入れるなら
他の言語である可能性がゼロでないことを示しても論拠として弱い
Javaではない蓋然性の方が高いだろという主旨でないと 今週のぱいじょ132話
https://paiza.jp/paijo
『大事な変数名』だってよ よーしパパ、ハンガリアンでバリバリコード書いちゃうぞ! 変数名はだいじだな
ハンガリアン(に汚染されていたことの発覚)はおおごとだな カッコさんもこれほど存在感のない使われ方するとは思ってもみなかったやろなw ハンガリアン悪くない
悪いのは型名をプレフィクスに使う事 ハンガリアン悪くない
private変数の
m_
とか推奨 >>352
何が言いたいのかよく分からない
英語にケチつけてるなら、それ相応の板へどうぞとしか 訳し方ひとつじゃないだろ
プログラマーのメンタルに悪い こうですね、理解ります
DEAD_LINE
死の線
モノの死にやすい部分
直死の魔眼により視ることができ、切られたものは死ぬ >>354
一般的な日本人がそのまま読んでも意味が通じる
実に最適な選択だろ 納期=死線
ちがう絶対ちがう遅れたっていいんだ誰も死なないんだ 最適解について考えるなら俺も due date を推したい
時刻もあり得る deadline と違って日付であることが明確
deadline は守るべき締め切りというニュアンスが乗りすぎてフラットでない感もある
ただアッパーケースで書いてるし、ザ・期日というべき値ならDUE_DATEよりDEAD_LINEのニュアンスが相応しい文脈なのかもと思ったり
due date という英語は難しいから避けた方がいい、なんて環境ならレベルが低すぎるからとっととおさらばしたい いや納期だったか
じゃあ delivery date だな delivery dateだと、その日だけって感じにならん?
due dateならそれより前でも可ってわかるけど 英辞郎で「納期」で検索した感じ、ニュアンス的には納品側の用語としてはdeadline、
発注側の用語としてはdue dateが適切のように感じるね
個人的にはそこまでこだわる必要はなく、普通にdeadlineでよいと思う 俺のメンタルに悪いっつってんだろgじゃkじゃあjsふぁ 日本語には「〜です」って言葉をよく使うんだけど
生きづらそうだね それは直接的な意味ではないし回避するために毎回文章を考えるのが面倒なので仕方ないdeath 自社スタンドアロンアプリでデータをCSVにエクスポートする機能があるので、
ExportXXX()みたいな関数名が付けられていたんだけど、
この機能を使い回して自社WEBサービス版でも一部利用しようということに
なったものの、こっちで使うときもExportでいいのかどうか
くだらないことに引っかかってる次第。
スタンドアロン←→WEBの間にユーザーは一切関与せず、どちらもまとめて
一つのシステムという扱いなので、Exportでは外に出して自由に使える
イメージが強くて違和感が。
気にしすぎですかね? もはや気にしてもしょうがない
出来ているものの名前は変えなくていい
とはいえ違和感が強いならExportというネーミングが最初から微妙だった可能性を省みてもいいかも
システム外部へのエクスポートはCSV出力のひとつの役割で
当初はその側面しか見てなかったけど
本質を表してはいなかった可能性がある
例えば別案はWriteXXXToCSV 何言ってるのか分からないねw
Exportっていうのは普通に考えれば「データを他所のアプリに対してexport」ってニュアンスなので、
もしCSVをそのアプリ自身でも読むのならちょっと違うとは思う。 >>367
スタンドアロンというのが意味が違うんですかね。
Windowsにインストールしてるソフトがあり、それのことを書いてました。
旧来のそのソフトにWEBサービス版が加わり、そっちとデータの
やりとりが必要となったという流れです。
>>368
仰るとおりです。当初は外部に出してしまって好きに使ってもらう
ことしか考えてなかったのですが、WEB版にデータを渡すのに
一々新規でそのプログラムを作らないで、Export部分を使い回した方が
工数削減出来るだろうし、その後の保守も手間を省けるというところです。
ただ、この場合システム内部で完結するのでExportとは言わないかなあと。
既に開発スタートしてて、既存のExport部とは関係ないデータを吐き出すのに
MakeXXXXCSVみたいなのを作ってから、後でExport処理も使い回す際に
ネーミングに疑問が出てきました次第で。
>>369
WEB版にはExport機能はありません。
スタンドアロン運用で不便な点のみWEB版として追加してます。
>>370
すみません。
ニュアンスとしては同感でして、そこから今回の質問の流れとなりました。
とりあえずは、やはりExportのままだと本来の意味からするとちょっと
違う感じですよね。
もうちょっと考えてみます。どうもありがとうございました。 >>366
エクスポートは取り出した結果を外部に公開するイメージだから、スタンドアロンとかwebとかは関係ないと思う。 >>372
そう、関係ないですよ。一行で書けば、
既にあるExport機能を内部で完結する形で流用するので関数名がExportだと意味が違ってくるけど変えた方がいいかな考えすぎ?
という主旨です。
開発内部からみれば一応二つのシステム間でExport,Importしてるのは間違いないですが。 最初から通信などの内部処理用として用意するならserializeとかにすると思うけど、
既存の処理を使い回すならexportでも別にいいかなあって印象
自分で自由に出来るなら、出力部分のコードをserialize側に移して
export側ではserializeを呼び出すようにしちゃってもいいんだろうけど 「システム・ハンガリアン記法」を嫌う人がいるようだけど、個人的には実際に長年使ってみて、
コーディング効率が上がっていると感じる。
ネット上でよく見かける反論に、「システム・ハンガリアン記法は、(代入などで型が異なれば)コンパイラ
がエラーを出してくれるのだから不要」というものがある。
しかし、システム・ハンガリアン記法を使っていれば、たとえば、代入のコードをコーディングしたい最中に
周囲の変数の変数名を見て、エラーが起きない組み合わせを探すと、実は、非常にわずかな組み合わせ
しか無いことが多い。
そして、そのわずかな組み合わせの中に必ず正しいコードがあるので、人間の作業は、
そのわずかな組み合わせの中から選ぶだけでよくなるので、思考の節約になってくれる。
もし、システム・ハンガリアンを使っていなければ、この思考の節約が働かないので、
本格的に考えないといけないことがあり、余計に時間がかかってしまうことがある。
正しいコードが次のようなものだったとする:
pXxxx = pYyyy + ofsAaa;
周囲には、pXxx, pYyy, ofsAaa 位しか変数がないとすれば、頭を使わなくても、可能な組み合わせは、
上記のコードを含む少数のパターンしかないことがすぐに分かる。
そのうちから正しいコードを「選ぶ」事と、意味で考えることを二重に行うことで、早く正解のコードを
書くことが出来るようになる。
ところが、システム・ハンガリアン記法を使っていなければ、意味で考えることしか出来なくなり、
思考パターンを減らすことが出来ない。また、コンパイルしてみないと「検算」もも出来ない。 さらに、文字列などを使っている時、
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;
}
とすればよいだけなので、とても美しい。 唐突にどうしたのw
真面目に言ってるのかネタのつもりかのか知らんけど、畢竟
「書きっぱなしで他人も自分も後でメンテしない」
コードならどんな表記法使おうが何の問題もないのよ。
ハンガリアンが批判されるのは、この条件を満たさない(世の中のコードの9割はそうだと思うけど)
場合に問題が起こるから
もちろんハンガリアンがダメって言ったって教条主義的に全部捨てる必要はない。
メンバ変数のプリフィクスなんか誰も文句言わないよ
こんな20年前に決着が付いてる話を今頃して何が楽しいの ワイはアプリもシステムも混在するハンガリアン
とりあえず事故は皆無
アプリケーションで使うのは、大体座標系かな
x,y,cx,cyとか、コイツらをシステムの方でやっちゃうと変数名が長くなるだけ
ならまだいいんだけど、計算がちと複雑化してくるとあああああってなる 個人的にはこうだな
・ポインタ変数にpを接頭するのは分かりやすい
・メンバ変数にm_も悪くない
・型を接頭するのはやめて lenTextがintLenTextじゃないのは気になった
デフォルト扱い? 型の接頭がいいと思うのは関数内で型変換するときくらい ポインタと型変換とメンバ変数に共通することを一般化して考えると、同じ情報を異なる形式で2つ持ちたいときにハンガリアンは活きる >>381
今時pXxxはないわ
普通にPtrToXxxかXxxPtrでいい
PtrToReadPtr
これなら何を意味してるかだいたいわかるが
ppRead
こんなのは勘弁してもらいたい 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 pFooとbarPtr/PtrToBazの間に
そこまで大きな差があるとも思えないんだが
>>381
個人的には、メンバ変数の m_ はバッドノウハウに見える >>388
pは適当すぎたか
PointerToCompanyNameよりは
ptrCompanyNameのほうが好み程度のことが言いたかった >>389
どっちもプリフィクスなの変わらなくない?って聞きたかったんだけど ■ このスレッドは過去ログ倉庫に格納されています