14/01/21 00:05:45.80
クラス名、変数名のつけ方に悩んだら書き込むスレです。
命名規則や設計の善し悪しについて議論するのは基本的に禁止。
前スレ
クラス名・変数名に迷ったら書き込むスレ。Part23
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
14/01/21 00:51:08.78
うんこ中かそうでないかを判断するための変数の名前どうしましょう？
3:デフォルトの名無しさん
14/01/21 01:01:25.96
isUnching
4:デフォルトの名無しさん
14/01/21 01:08:07.54
>>3
if(isUnching = 1){
printf("ぶりぶりぶりぶり");
}
やっとかけました！
5:デフォルトの名無しさん
14/01/21 11:33:49.32
>>4
それわざとやってる？
6:デフォルトの名無しさん
14/01/21 13:00:03.27
ここまで自演
7:デフォルトの名無しさん
14/01/22 04:42:51.63
kakko
kokka
8:デフォルトの名無しさん
14/01/23 22:03:32.97
>>5
これどう見てもわざとだろｗｗｗ
いちいい反応するとか()
9:デフォルトの名無しさん
14/01/25 03:18:44.84
>>8
顔真っ赤なの？
10:デフォルトの名無しさん
14/01/25 14:06:33.48
日本人の精神年齢は12歳と言ったアメリカ人がいたが、うんこちんこで喜べるのは
普通はせいぜい10歳まで。
webでは、（特に2chみたいな掃き溜めでは）世の中にめったにいない少数派でも
自分と同類の趣味嗜好の同士を見つけられるが、それをもって自分が普通だと勘違いすると
どこかで痛い目見るよマジで。
11:デフォルトの名無しさん
14/01/25 19:05:03.50
つまり、特亜人の精神年齢は高くても１０歳程度と
12:デフォルトの名無しさん
14/01/27 16:17:41.83
やっと次スレできたのかと思ったら文字通り糞スレだった
13:デフォルトの名無しさん
14/02/01 19:39:38.45
「＊＊を表すステートメント」というもの表す識別子をいくつも作る必要があります。
「＊＊」の部分が最も大事なのでここを名前に活かし、
かつステートメントであることもパッと見て分かるようにしたいです。
なので、ステートメントの略称を＊＊に接頭するか接尾したのですが、
略称はあるでしょうか？
stm ですか？
14:デフォルトの名無しさん
14/02/01 19:57:09.53
statusなどと被りやすいので下手に略さずにstatementでいいと思う
15:デフォルトの名無しさん
14/02/01 20:03:52.83
>>14
stm が status などと被りやすい、とは？
16:デフォルトの名無しさん
14/02/01 20:37:02.95
>>13
それ以前に、もちろん一般論ではあるが、その「＊＊を表すステートメント」であることを
本当に名前で表現する必要があるのかを再考すべきだと思うけどね。
型で表現すれば十分じゃないの？
17:デフォルトの名無しさん
14/02/01 21:25:57.91
>>16
再考した結果、このような識別子が必要だという結論に達しました。
18:デフォルトの名無しさん
14/02/01 21:40:21.25
関数名なんですけども、ゲートクラスとそれを通過する訪問者クラスがあるとします。
ゲートを訪問者が通過する時に呼ぶ関数名はどうすれば良いでしょうか？
訪問者側ならば、Visitor::Pass(Gate gate)でいいのですが、
ゲート側でPassとすると主語、目的語の順序がおかしくなるので別の名前にすべきだと考えてるのですが。。。
19:デフォルトの名無しさん
14/02/01 21:45:01.43
>>18
passed
20:デフォルトの名無しさん
14/02/01 21:46:36.24
Passにも他動詞の意味があるからおかしいと思わんけどEnterの方がしっくり来る気もする
21:デフォルトの名無しさん
14/02/01 22:33:24.89
>>18
TriggerPassedはどう？
22:デフォルトの名無しさん
14/02/01 22:51:53.21
gate.accept(visitor) とか
23:デフォルトの名無しさん
14/02/01 22:54:03.78
追記: acceptは、Visitorパターンの紹介コードでよく使われている気がする。
24:デフォルトの名無しさん
14/02/01 22:59:56.58
Gate::Pass(Visitor visitor)
25:デフォルトの名無しさん
14/02/01 23:42:54.95
>>19
それだと通過後に呼ばれる関数な感じがしませんかね？
受動態って意味で過去分詞を使うのって一般的なんでしょうか？
>>20
他動詞でも主語は人じゃないですか？
>>21,22さんのどっちかを使おうと思います。
ありがとうございました。
しかし受動態で関数名書きたいとき毎回命名で悩む気がします。
英語ネイティブの人たちは悩まないんだろうか…
26:デフォルトの名無しさん
14/02/01 23:51:43.60
>>17
>>17が使っている言語にもよるけど、
(>>16の提案した型ではなく、）名前空間で表現できないかな？
たとえばRubyだとモジュールが名前空間を提供するから、
たとえばゲーム記述言語であれば以下のようになる
module Statement
class Foward; .... end # 前進ステートメント
class Attack; .... end # 攻撃ステートメント
class Morph; .... end # 変身ステートメント
end
参照する場合には Statement::Foward と書くけど、
面倒であれば STM = Statement と省略名(シノニム)を宣言すると
STM::Foward で参照できるようになる
あるいは Statement 参照を多用する文脈であれば、
include Statement と宣言すると、直接 Foward だけで参照できるようになる
Rubyに限らず、今時の言語の多くはこういった名前空間を扱えると思うよ
27:デフォルトの名無しさん
14/02/01 23:55:04.72
どうせ大したもの作ってないからどうでもいいんじゃない。
28:デフォルトの名無しさん
14/02/02 00:03:24.15
>>13
DBとかだとStatementの略はstmtが一般的な気がする。
あとLLVMでもstmtヘッダがあったりするらしい。
URLﾘﾝｸ(clang.llvm.org)
29:デフォルトの名無しさん
14/02/02 00:23:00.48
>>26
使用言語は Haskell で、確かにモジュールに分ければ名前空間と同じ役割はできます。
> 面倒であれば STM = Statement と省略名(シノニム)を宣言すると
> STM::Foward で参照できるようになる
それは結局のところ、「ステートメントの略称を＊＊に接頭する」のと同じですよね。
その省略名(シノニム)として何がいいか、ということです。
> あるいは Statement 参照を多用する文脈であれば、
> include Statement と宣言すると、直接 Foward だけで参照できるようになる
その識別子を使用している部分でステートメントかどうかをパッと見て分かるようにしたい
というのが目的ですので、直接 Foward だけで参照すると意味がなくなります。
>>28
> DBとかだとStatementの略はstmtが一般的な気がする。
採用させていただきます。
アイデアや意見をくださった皆様、ありがとうございました。
30:デフォルトの名無しさん
14/02/02 00:38:35.04
>>25
Gateがpassやenterを主語にとっても全然おかしくないって。
日本語で言うと通過させるとか通すとか入れるとかそんな意味合い。
31:デフォルトの名無しさん
14/02/02 00:57:53.17
>>29
>それは結局のところ、「ステートメントの略称を＊＊に接頭する」のと同じですよね。
いや、接頭語(prefix)であれば名前は stmt_xxxx になるし、
修飾子(modifier)であれば Stmt.xxxx になるから、
それらの違いを意識したコーディングが望ましいと考える
（些細な事柄ではあるけど、このスレだからあえて言う）
またHaskellerならば、シノニムの持つ意味(=暗喩)の重要性は
十分に理解しているはずだと思う
個人的には、モジュールやデータ型に関してはシノニムを活用すべきだけど、
関数名や変数名については、たとえ接頭語であっても省略すべきではないと考える
もしもスコープで接頭語が明解に識別できるのならば、
(省略名 stmt_xxxx ではなく)単純に xxxx と命名すればいい
それができないのならば、コード設計のどこかを誤っている
（これも些細な事柄ではあるけど、....<以下略>）
>直接 Foward だけで参照すると意味がなくなります。
>>26で「Statement 参照を多用する文脈であれば」と前提条件を書いたように、
一般には、(Ruby では include に相当する)名前空間の無条件な取り込みは
できるだけ避けるべきだね
32:デフォルトの名無しさん
14/02/04 19:16:57.48
Windowsプログラミングで、フォルダ名を文字列型などの変数で定義する場合、
PathName
FolderName
DirName
など、Path、Folder、Dirのどれを使うかでよく迷います。
どれが主流でしょうか？
33:デフォルトの名無しさん
14/02/04 20:01:51.26
>>32
俺は DirName というと、例えば "C:\Users\tomato\dressing" というパスに対して
"C:\Users" の部分を意味すると捉えてしまうが・・・
フォルダそのものの名前ということなら、FolderName が普通だと思う。
それはそうと、余計なお世話なのは承知しているが、
主流かどうかで名前を決めるのは本末転倒だと思うぞ。
34:33
14/02/04 20:02:31.24
>>32
失礼、間違えた
俺は DirName というと、例えば "C:\Users\tomato\dressing" というパスに対して
"C:\Users\tomato" の部分を意味すると捉えてしまうが・・・
35:デフォルトの名無しさん
14/02/04 21:20:43.30
>>34
なるほど。確かにそうですね。では、DirNameは使わないようにして、
PathNameかFolderNameにします。
36:デフォルトの名無しさん
14/02/04 21:26:55.50
>>32
今時のファイルシステムの大半は階層構造になっていて、
そのオブジェクト(=構成要素)にはディレクトリとファイルがある
で、アプリケーションがファイルシステム内のオブジェクトを見つけたい時には、
根(ルート)から下方へとファイルシステムのツリーを辿ることになる
その根から目的とするオブジェクトへの道筋をパス(=経路)と呼ぶ
つまり、オブジェクトの実体そのものに付随する名前(=ラベル、タイトル)であれば
それらはディレクトリ名(DirName)またはファイル名(FileName)になるし、
それらオブジェクトを一意に識別できる情報に関する名前であれば
その名前はパス名(PathName)になる
また、ディレクトリとフォルダという名前はどちらも同じ実体を指す同義語だ
ただし、ファイルシステムに近い文脈であればディレクトリ名(DirName)、
よりユーザに近い文脈であればフォルダ名(FolderName)と使い分ける
今時のMVCアーキテクチャであれば、モデル(Model)ではディレクトリと呼び、
ビュー(View)ではフォルダと呼び、両者の仲介役であるコントローラ(Controller)では
両方の名前を文脈に応じて使い分ける、つまり混在することになるだろう
あとは、>>32が命名に迷っている対象がどれに該当するのか、自分で判断しなさい
最後に、
>主流かどうかで名前を決めるのは本末転倒だと思うぞ。
には同感
37:デフォルトの名無しさん
14/02/05 00:34:16.09
>>35
>>34の言ってることに納得するのはどうかと面うけど...
正直俺には>>34が何言ってるのか全然わからない。
個人的にはむしろDirectory(Name)こそ正解だと思う。
フォルダというのはファイルシステム上の概念というより、Windowsで言ったら
コントロールパネルのような仮想的な入れ物とファイルシステムのディレクトリを
透過的に扱うためのシェル上の概念だからFolderNameはちょっと不適切に思う。
PathNameは論外。
パスって、文字通り根っこから枝葉（ファイルやディレクトリ）までの「道筋」のことでしょ普通は。
枝葉のことを道筋と呼ぶのは変だ。
38:デフォルトの名無しさん
14/02/05 00:51:19.40
使用する言語のライブラリに合わせるというのがいいと思うが。
C#だと、FileInfoクラスのDirectoryNameとかあるな。
39:デフォルトの名無しさん
14/02/05 08:01:03.11
>>33
> 主流かどうかで名前を決めるのは本末転倒だと思うぞ。
フォルダとディレクトリみたいなほぼ意味的に変わらないようなものなら主流かどうかで決めるのもありだ思うが
40:デフォルトの名無しさん
14/02/05 08:47:51.17
DirName一択だろ
迷う意味がわからない
41:デフォルトの名無しさん
14/02/05 09:41:48.52
dir_fullpathとか
42:デフォルトの名無しさん
14/02/05 12:44:39.99
DirNameって同名の関数が >>34 のような挙動になっていることが多い
43:デフォルトの名無しさん
14/02/05 12:46:35.80
そのプロジェクトで他の用語と被りそうだからとかで選ばないこともあるな。だから一択とかはないけど。
フォルダはGUIのイメージ、
ディレクトリはノード単体を扱うときにも使うイメージ、
というわけでパスに一票。
44:デフォルトの名無しさん
14/02/05 18:55:12.13
>>32
俺ならば
例えば "C:\Users\tomato\dressing" というパスに対しては AbsolutePathName
"C:\Users\tomato" の部分を意味するものとしては ParentPath
"dressing" の部分を意味するものとしては、どこかの ParentPath からみた
相対位置という意味で OffsetPathName
45:デフォルトの名無しさん
14/02/07 19:30:14.29
gcc用のファイルとllvm用のファイルとVC用のがあるとして、それを置くディレクトリの名前はどれがいいと思う？
gcc/llvm/vc
gcc-support/llvm-support/vc-support
for-gcc/for-llvm/for-vc
on-gcc/on-llvm/on-vc
rts-gcc/rts-llvm/rts-vc
46:デフォルトの名無しさん
14/02/07 19:30:51.49
>>44
他はいいとしてOffsetはない。Relativeだろ
47:デフォルトの名無しさん
14/02/07 19:57:10.98
>>47
スマンm(_ _)m
マジで間違えてた RelativePathName が正解だな
48:デフォルトの名無しさん
14/02/07 19:59:38.51
>>45
一番上のでいいだろ
ディレクトリ名がgccであれば、その中はgccに関する何かが入っているに決まってる
for とか on とか、アホかと思うぞ
49:デフォルトの名無しさん
14/02/07 20:20:28.84
>>48
gとlとvの間に他のファイルが大量に挟まるのやだなあ
前置詞が付いてたらエクスプローラー上で並ぶなあ、と
50:デフォルトの名無しさん
14/02/07 21:42:15.45
>>49
そういう大切な「名付ける意図や求める効果」をなぜ最初に言わない？
俺の >>48 のレスが完全に的外れじゃないか。
で、本題だが
それでも俺は個人的には for_ や on_ なんて接頭辞は付けたくないな。
ディレクトリというものの役割から考えて、
あらゆるディレクトリが for_ や on_ なのは当たり前だから。
今回の場合、俺なら gcc、llvm、vc というディレクトリ共通の親ディレクトリを作る
つまり ???/gcc、???/llvm、???/vc
その親ディレクトリをどう名付けるかは、gcc や llvm などの中身による。
コンパイル結果のみ入れるのなら build、配布する最終結果のみ入れるなら dist、
ソースファイルのみ入れるのなら src・・・など。
51:デフォルトの名無しさん
14/02/07 22:29:30.57
>>50
ごめんごめん、そこまで重視することか自分でも疑問だったので、真っ白な意見を聞きたかった。
あと当然だけど、「gとlとvの間にあるその他のファイル」も同種(srcやbuildに該当する)ので
親ディレクトリを作るならcompiler-dependedとかそういう意味の単語かなあ
ありがとう
52:デフォルトの名無しさん
14/02/08 11:37:13.42
>>47
> >>47
Offset: 0 ?
53:デフォルトの名無しさん
14/02/09 10:37:37.08
Guidをランダムに生成してアプリ内で重複しなければそのまま返す
重複してるならリトライを繰り返して重複しなくなったらそれを返す
最大試行回数を超えたら例外を投げる
この例外の名前はなにがいいと思いますか？
ちなみに.NETで開発しているので標準にドンピシャな例外があればそれがベストなのですが…
54:デフォルトの名無しさん
14/02/09 11:02:28.40
DamePoNoLongerException
55:デフォルトの名無しさん
14/02/09 13:12:49.31
そもそも例外クラスの名前というのは、"***Exception" に統一すべきなんだろうか。
"***" には「～ができなかった、～に失敗した」の「～」を表す名前がいいのか、
「できなかった」「失敗した」という意味も表した方がいいのか。
例外が発生した「理由」を名前に込めるべきなのか。
なかなか迷うな。
>>53 の場合、俺なら GiveupFindingUniqueGuid あるいは CanNotFindUniqueGuid にしたいな
Exception を付けて長くなるのはあまり好きではない。
（まぁ一般的には Exception を付けるのが当たり前なんだろうなとは思うが）
56:デフォルトの名無しさん
14/02/09 13:37:14.53
>>53
全体的に何言ってるのかよく分からん。
ランダムに生成とか言ってる時点で既にそれGUIDとは違う何か別の物じゃん。
アプリ内でバッティングしない値を生成するってそんなに難しいか？
リトライが上限に達したら例外って、そもそもリトライが必要な処理と思えん。
努力する方向が根本的に間違ってないか？
57:デフォルトの名無しさん
14/02/09 13:53:43.25
>>53
FailureGenGUIDException
分かってるとは思うけど Gen は Generate の略な
>>55
UniqueGuidの Guid って確か Global Unique ID の略じゃなかったか？
もし俺が正しいのなら重複している部分を削って
> GiveupFindingGuid あるいは CanNotFindGuid
が妥当でないかい？
>>56
>命名規則や設計の善し悪しについて議論するのは基本的に禁止。
58:デフォルトの名無しさん
14/02/09 14:05:48.17
>>57
そんなものに俺は同意してないから
59:デフォルトの名無しさん
14/02/09 14:15:04.09
>>58
同意しろやボケ
60:デフォルトの名無しさん
14/02/09 14:25:13.98
>>58
嵐宣言乙
61:デフォルトの名無しさん
14/02/09 15:00:11.76
>>57
> UniqueGuidの Guid って確か Global Unique ID の略じゃなかったか？
確かに・・・
62:デフォルトの名無しさん
14/02/09 17:28:55.65
GUIDがいわゆるUUIDのMS実装のことなら、
バージョン(という名前だが生成方法)4に限れば、
乱数による生成なので、低確率で重複しうる。
バースデーパラドックスを考慮しても相当に低い確率だけど。
63:デフォルトの名無しさん
14/02/10 00:02:08.28
>>55
自分は名前空間を利用している
具体的には(Rubyで...)、トップレベルのモジュール名が M だとすれば、
その下にサブモジュール M::Exception を定義し、
このモジュールの内部で例外クラス群を定義する
例外クラスの命名は、ケースバイケースで適切だと思える具体的な名前にする
[例外クラスの例]
・M::Exception::SubclassResponsibility -- 具象クラスでメソッド未実装
・M::Exception::EmptyIdentifier -- 空の識別子
・M::Exception::CantRecognizeAsToken -- トークンとして認識できない
・M::Exception::SyntaxError -- 構文エラー
実際の参照では、EX = M::Exception とシノニム(同義語)を定義しておいて、
たとえば raise EX::SyntaxError みたいに書く
64:デフォルトの名無しさん
14/02/10 00:20:39.56
>>63
汎用的じゃない例外なんかは、普通はその例外を発生させるクラスと同じかまたは上位の
名前空間で定義したいと思うはずで、そういうのは名前空間の使い方としてどうかと思うけど。
っていうか例外クラスなんかコード中に頻出するわけじゃないんだから
名前短くしようとかケチ臭いこと考えずにベタに名前を付ければいいでしょ。
65:デフォルトの名無しさん
14/02/10 00:46:02.60
>>63
>汎用的じゃない例外なんかは、普通はその例外を発生させるクラスと同じかまたは上位の
小さなプログラムであれば、例外に関して１個の名前空間(たとえば M)ですむ
プログラムが大きくなれば、複数のサブシステムに分割して構造設計するはずだから、
各サブシステムごとに例外に関する名前空間を持てばいいだけの話
たとえば、M::Exception、N::Exception、O::Exception みたいに....
シノニムも M::EX、N::EX、O::EX と別個に定義することになる
>っていうか例外クラスなんかコード中に頻出するわけじゃないんだから
いや、実用的なプログラムを書こうとすれば、エラー検査と例外発生だらけになるよ
しかも例外の種類(例外クラス)も数多く必要になるから、クラス継承設計も大切になってくる
このあたりの感覚は、ある程度の規模(10Kstep以上)、
かつ実用的なソフトウェアの開発経験が無いと分からないかもね....
66:デフォルトの名無しさん
14/02/10 01:21:47.03
>>65
だからそういうのは名前空間の本来の使い方じゃないってば...
一般的なプログラマが名前空間に期待するものは型を意味的に分類する入れ物なんだから。
"Exception"なんてただのベースクラスの名前じゃないの。
そもそもこんな方針じゃ、プロジェクトの名前空間が階層を構成していて
各階層ごとに例外クラスを定義したいというごくありきたりのシナリオにも対応できない。
＞実用的なプログラムを書こうとすれば、エラー検査と例外発生だらけになるよ
だらけかどうかは感覚の問題だと思うが、例外だらけだったらすでにそれは例外じゃなくて「普通」になってしまう。
IOのよほど低水準のライブラリでも書いてるのなら話は別だけど、
俺の個人的感覚ではそんな例外ばっかり構ってるコードこそむしろどこか設計がおかしいんじゃないのかと。
まあ繰り返しになるけど「だらけ」かどうかは感覚の問題ではあるけどね。
67:デフォルトの名無しさん
14/02/10 05:19:06.89
シナリオから外れることが例外で頻度のことを言っているわけではない。
たまにしかないから例外とかヤバイ設計だな。
68:デフォルトの名無しさん
14/02/10 19:32:39.83
Exceptionなんてドンブリ勘定な名前空間に全部突っ込むほうがよほどヤバイって。
何を言ってるんだろうね。
ついでに言わせてもらえば、「自称プロ」ほどコードの大半は例外処理だとか嘯く。
そんな馬鹿な。本当に実用的なコード書いてるんだろうかこの人。
69:デフォルトの名無しさん
14/02/10 20:18:00.51
分野によるが、ビジネス系なので大半が例外処理だ。
入門サイトなどによく書いてあるよな。
このコードでは例外処理を省略してますって。
それをコピペしてるんだろうな。こいつは。
70:デフォルトの名無しさん
14/02/10 20:22:24.74
最後に余計な一言をいう人が多すぎる
71:デフォルトの名無しさん
14/02/10 21:10:20.30
>>66
>一般的なプログラマが名前空間に期待するものは型を意味的に分類する入れ物なんだから。
そもそもの出発点からして異なっていたみたいだね
自分は「名前空間とは型を(意味的にではなく)構造的に分類する入れ物」なんだと考える
実際、Rubyでは名前空間をモジュール(module)と呼ぶし、
MLという関数型言語にいたってはストラクチャ(structure)と。まさに構造と呼んでいる
逆に、型を意味的に分類するのは部分型、つまりオブジェクト指向におけるクラス継承になる
集合論的に言えば、型とは集合であり、型の分類とは部分集合に分けることになる
ここで、もし分けた部分集合間に交わりがあれば(クラスの)複数継承になり、
交わりが無い直和分割であれば単一継承になる
>"Exception"なんてただのベースクラスの名前じゃないの。
ここも解釈が異なっているなあ
自分は、「"Exception" とは例外という概念を表す象徴的な記号(=アイコン)」だと考える
だからクラス名になるし、名前空間(=モジュール)や変数の命名にも使われる
>各階層ごとに例外クラスを定義したいというごくありきたりのシナリオにも対応できない。
階層化した名前空間ごとに例外に関する名前空間を設ければいいだけの話だよ
たとえば名前空間 M を階層化して M::M1、M::M2 と設計したのであれば、
M::M1::Exception、M::M2::Exception になる
こんな単純な話なのに、ナゼに「対応できない」と断言できてしまうのか不思議だ....
72:デフォルトの名無しさん
14/02/10 21:41:14.24
だから、最後の一言が余計なんだってば。
君にとっては単純な話かもしれんが、別の人にとっては初めての考え方・概念かもしれん。
その人が君の披露した考え方を知らず、そのため君にとっては頓珍漢な事を言って、
しかも最後に君を馬鹿にしたような事を言ったとしても、
君まで同じように相手を小馬鹿にする必要はないだろ？
余計な一言があるせいで、変な方向にヒートアップしてしまうんだよ。
もういい加減、余計な一言の応酬は止めないか？
この議論まで止めろとは言わんから
73:デフォルトの名無しさん
14/02/10 21:46:05.07
君みたいな人が増えるといいね
74:デフォルトの名無しさん
14/02/10 21:52:23.42
>>71
自分で書いてて苦しいと思わないの？
構造的に分類ってどういう意味だよ。
じゃああなたの言うExceptionってのは「構造」をあらわしてるの？
その構造って何よ。
＞ 階層化した名前空間ごとに例外に関する名前空間を設ければいいだけの話だよ
＞ たとえば名前空間 M を階層化して M::M1、M::M2 と設計したのであれば、
＞ M::M1::Exception、M::M2::Exception になる
だから何のため？
今日日何事もただでさえ複雑なのに、何のためにそんな余計な混乱材料を持ち込むの？
たった数文字名前をケチるため？
どんな本末転倒よそれ。
言っちゃ悪いけど、プログラマ1年生にありがちな倒錯だよそれ。
75:デフォルトの名無しさん
14/02/10 22:40:03.72
>>74
>構造的に分類ってどういう意味だよ。
それは「名前空間に期待するものは型を意味的に分類する入れ物」と語った>>66が
「構造的に分類ってどういう意味だよ。」という質問にレスしてから、説明しよう
先にヒントを与えると、オブジェクト指向分析/設計の基礎概念の一つだ
>今日日何事もただでさえ複雑なのに、何のためにそんな余計な混乱材料を持ち込むの？
小さなプログラムであれば、無理に名前空間を階層化する必要は無いと思うよ
「各階層ごとに例外クラスを定義したいというごくありきたりのシナリオ」という
>>66の想定に合わせて、階層化が必要なほど大きなプログラムであれば、
こんな風に名前空間を活用すればいいんだよ、ってことを説明しているだけ
>たった数文字名前をケチるため？
はて？どこをどう読めばそんな推測に至るのか、意味不明だ....
>>63で例外クラスの命名について「適切だと思える具体的な名前にする」と
説明したのと同様に、名前空間の命名にも「(機能の)構造的な分類」に従って
適切かつ具体的な名前を選ぶべきであると考える
76:デフォルトの名無しさん
14/02/10 22:48:56.53
自己レスで>>75を訂正、肝心なとことをミスしてた....
X: 「構造的に分類ってどういう意味だよ。」という質問にレスしてから、
O: 「意味的に分類ってどういう意味だよ。」という質問にレスしてから、
77:デフォルトの名無しさん
14/02/10 22:50:29.85
>>75
結局「構造」って何のことだか分からないね。
例外だけ"Exception"なんて妙な入れ物でネストする動機もまったく説明されてない。
何が言いたいの？
っていうか、名前をケチることが動機じゃないなら>>65では>>63に何が言いたかったの？
とにかく例外だけExceptionで包んで別名付けろ？
だから何故？
以下、まあたぶん理解してもらえないと思うが一応本来どうあるべきかの追加説明。
意味っていう俺の言葉遣いが気に入らないなら問題領域と言い換えてもいい。
名前空間は問題領域をコードに写像したもの。
例えばある計測器からデータを取得してグラフ表示したりログを取ったりするアプリを
作ってるとする。
この時、モデル化した計測器に関係する型を入れる名前空間は
MyCompany.SomeVendor.DeviceXs
その計測器との通信データを処理するサブシステムに関する型を入れる名前空間は
MyCompany.SomeVendor.DeviceXs.Communication
常識的なプログラマなら名前空間はこういう感じで使う。
そして、その問題領域で発生させる例外の定義は、当然同じ名前空間で行いたいと普通は思う。
こういう別け方（入れ物）を「構造」呼ぼうが何と呼ぼうが、それは自由だけど、
通常の名前空間とは別に例外だけを入れる名前空間が必要であり、
かつそれが例外クラスの名前を短くするのが動機だなんて、
こんな方針を支持するプログラマなんてまず普通じゃないよ。
78:デフォルトの名無しさん
14/02/10 22:52:24.04
失礼、
× っていうか、名前をケチることが動機じゃないなら>>65では>>63に何が言いたかったの？
○ っていうか、名前をケチることが動機じゃないなら>>63では>>55に何が言いたかったの？
79:デフォルトの名無しさん
14/02/10 22:54:38.25
Exceptionなんて名前空間を用意するくらいなら
例外を発生させるクラス::○○Exceptionを作るかなあ俺なら
逆に、1クラスで発生する例外の種類が、わざわざ括りを入れないといけないような量なら
それは多くの場合、クラスが巨大過ぎる気がする
もちろん、Rubyで言うところのErrno::E～みたいな(例外処理ではなく一般的な意味での)例外もあるけどさ
80:デフォルトの名無しさん
14/02/11 00:20:05.04
>>77
名前空間の使い方に関しては、「機能」に着目して階層的に分割するという意味で同じだね
この「機能」という言葉を「意味」と呼ぼうが「問題領域」と言い換えてもかまわないという事にも同意する
で、
>通常の名前空間とは別に例外だけを入れる名前空間が必要であり、
>かつそれが例外クラスの名前を短くするのが動機だなんて、
どこにも必要とか ..... すべき(MUST or SHOULD)とは言っていないよ
数多くの例外クラスが必要なプログラムで、
それらを一意に識別できる適切な名前の命名に悩んでいるのならば(>>55)、
例外クラスだけで独立した名前空間で分けるという設計方法もある(MAY)と提案しているだけ(>>63)
計測器からのデータ収集という大きな「問題領域」があり、それがベンダやデバイスという
部分的な「問題領域」から構成されている時、それらに名前空間を与える設計手法を>>77は選んでいる
同様に、例外も(例外扱いせずに)部分的な「問題領域」の一種であると考えて
名前空間を与えてもいいんじゃないのかな？という発想だ
81:デフォルトの名無しさん
14/02/11 00:52:23.62
理屈ばかりでは分からないと思うので、>>63の考え方を具体的なコードで示す
URLﾘﾝｸ(www.h6.dion.ne.jp)
これは、作りかけの小さな言語処理系から、例外に関するページだけを抜き出したもの
[機能の構造に関する分類(=モジュール構造)]
・トップレベルに構文という問題領域に対応した Syntax という名前空間(=モジュール)がある
・その下に「例外」という部分的な問題領域に対応した Syntax::Exception という名前空間を設けた
・更に、「(例外に関する)抽象クラス」に対応した Syntax::Exception::Abstraction という名前空間も設けた
[型の階層に関する分類(=クラス階層)]
・例外という問題領域は、「予期した例外」と「予期しない例外」という２つの部分的な問題領域へ分割した
・「予期した例外」は、付随する情報、つまり属性によって更に細かな問題領域(=型 or クラス)へと分割される
・「予期した例外」とはいわゆる一般的なエラーであり、
これが発生した場合にはアプリケーションで捉えて適切なエラーメッセージを表示する
・「予期しない例外」とはいわゆるバグであり、これが発生した場合にはアプリケーションでは捉えず
処理系を異常終了させて、スタックダンプ等のデバッグ情報を得る
82:デフォルトの名無しさん
14/02/11 02:35:01.16
読んでないが、簡潔にまとめられない奴らが、良い名前を付けられるわけがない。
83:デフォルトの名無しさん
14/02/11 02:59:31.95
言えてる
84:デフォルトの名無しさん
14/02/11 09:04:52.22
言語処理系そのものや、独自のスクリプトを実装したいとか
例外処理機構の無い言語に例外的な機構を実装したいとかなら
Exceptionでグループをひとつ作るのもアリだと思うけど
一般的なプログラミングにはそぐわないと思うんだよなあ
85:55
14/02/11 09:22:25.06
>>82
議論してる人たちから見れば、興味がない外野は黙ってろと言いたいだろうなぁ。
>>63 の考えを簡潔にまとめたのが >>63 の「自分は名前空間を利用している」であり、
>>71 の「名前空間とは型を(意味的にではなく)構造的に分類する入れ物」で、
君が読んでいないというのは、それに例を付けて説明した部分だろうに。
で、>>64 の例外クラスの名前に関する考えの本質は >>64 にもある
「例外クラスはコード中に頻出しない --> 短くしようとせずベタに名前を付ければいい」で、
名前空間に対する考え方の本質は >>66 の「型を意味的に分類する入れ物」だろ。
あとは、これも君は読んでいないだろうが、この考え方を説明した部分だろうに。
俺は、振り返ってみると、今まで入門書や他人のソースなどを見て、
「何の考えもなしに」 >>64 のようにやってた。
あらためて考えてみると >>63 の考え方にはナルホドと思わせられるところがある。
確かに、例外や名前空間に対するそういう捉え方・考え方もできるなと思った。
俺は両者のメリット・デメリットをまだちゃんと自分で検証しないから、意見は言えない。
が、ちょうど今趣味でそこそこの規模のアプリを作ってみようとしてたところだから、
一度 >>63 の考え方でやってみようかと思う。
もしかしたら言語によってもメリット・デメリットが変わってくるかもしれん。
ただなぁ、なんでこう煽り合うんだろう。
せっかく興味深いことを議論してるのに、大変見苦しい。
86:55
14/02/11 09:24:42.25
>>85
誤解を生みかねないミスをした。
誤) 俺は両者のメリット・デメリットをまだちゃんと自分で検証しないから、意見は言えない。
正) 俺は両者のメリット・デメリットをまだちゃんと自分で検証していないから、意見は言えない。
87:デフォルトの名無しさん
14/02/11 09:25:08.66
自分のブログに書いてろ
>>1
>命名規則や設計の善し悪しについて議論するのは基本的に禁止。
88:デフォルトの名無しさん
14/02/11 09:37:34.44
設計の「善し悪し」を言い合っている部分は確かにNGだろうけど
でもこういう設計（方法）があって、その場合にはこういう構造でこう名付ける案もある、
と言っている部分はスレ的にはOKじゃね
まぁ、あくまで名前を付けることが主で、その前提となる設計が従のスレにおいて、
設計の方の話がヒートアップしてるのは、馬鹿かこいつら、って思うが
89:デフォルトの名無しさん
14/02/11 09:41:05.23
今北産業
伸びてるな
90:デフォルトの名無しさん
14/02/11 09:50:01.37
>>88
支持
名前空間を機能分けにするか役割分けにするかの「是非」はどうでもいいな
そういう多面的な観点を、根拠の一つとして提示して、こんな名前付けもできるね、っていう話なら建設的だよね
91:デフォルトの名無しさん
14/02/11 10:14:15.86
これが会話なら流動的になっても致し方無い部分もあるけれど
ワンクッション置いた文章のやり取りなのだから
簡潔に主張したいことだけ書いて相手の反論にいちいち反応するなと言いたい
議論は解決の糸口を見つける方法であって、一連のやり取りは議論じゃなく単なる主張のし合いってだけ
両者の主張に答えを出す必要性すら無い
オレならNamespaceにExceptionは使わない
Usingを使ってNamespaceと切り離して使われる場合があるから
92:デフォルトの名無しさん
14/02/11 10:18:05.47
やっと収束したな
93:デフォルトの名無しさん
14/02/11 10:36:36.84
大元の話は >>53 なんよね
GUIDの生成に失敗するのを、何度か試行して
生成不能とみなした場合の例外だから…俺なら単に
GUID::GenerateFailed
かなぁ、「何度も繰り返した部分は無視か？」と思うかも知れんが
試行回数は投げられた例外オブジェクトの属性やメッセージに書いとく
94:デフォルトの名無しさん
14/02/11 15:32:15.71
だから、>>53についてはそもそもリトライするようなコードが間違ってるわけで、
そんなものはリトライなんか必要がないアルゴリズムに置き換えるべき。
その実装が技術的に困難とかコストが掛かりすぎるとかならともかく、バッティングしない
IDを発行することのどこが難しいのか。
プログラミングは実用技術なんだから、実用上価値がない方向の工夫を重ねても何の意味もない。
95:デフォルトの名無しさん
14/02/11 15:43:44.46
>>93
命名方針はそれがよさそう
96:デフォルトの名無しさん
14/02/11 16:45:45.50
>かなぁ、「何度も繰り返した部分は無視か？」と思うかも知れんが
>試行回数は投げられた例外オブジェクトの属性やメッセージに書いとく
例外発生に関する情報をオブジェクトに持たせる、
というところは同意する
ところで>>53は逃亡したようだな
97:デフォルトの名無しさん
14/02/11 17:37:31.07
>>94
でも実装そのものを変える話になると、もうこのスレの範疇じゃないからな
98:デフォルトの名無しさん
14/02/11 17:51:04.88
>>94
> プログラミングは実用技術なんだから、実用上価値がない方向の工夫を重ねても何の意味もない。
中身のないお前のレスの方が意味ないわ (w
99:デフォルトの名無しさん
14/02/11 18:40:11.25
>>96
横道にそれてどうでもいいバトルが始まってたら、俺が53でもブラウザ閉じる
100:デフォルトの名無しさん
14/02/11 18:43:53.93
>>99
そういう言い草頭悪いと思うよ。
ウンコ蝿がウンコのまわりを周回しながら「ウンコ臭え」って文句言ってるのと同じ。
お前はウンコ周回しならが何言ってんだ。
馬鹿じゃないの。
101:デフォルトの名無しさん
14/02/11 18:56:05.07
>>99
確かに >>100 みたいなレス見たらそっ閉じするに限るな
102:スレの内容がズレてきたから修正用の ネ タ ！
14/02/11 19:21:33.63
2chのスレ追跡のプログラミングしてるんだけど、
基地外を発見したとき、そいつをマーキングして追跡したいんだけど
どういう名前にしたらいい？
103:デフォルトの名無しさん
14/02/11 19:29:38.60
unko
104:デフォルトの名無しさん
14/02/11 19:37:44.91
>>102追跡プログラム
105:デフォルトの名無しさん
14/02/11 20:03:48.82
S_Talker
106:デフォルトの名無しさん
14/02/11 20:27:42.94
>>105
それだっ
107:デフォルトの名無しさん
14/02/11 22:13:56.00
>>102
何に対する名前を訊いているのか曖昧だな
108:デフォルトの名無しさん
14/02/11 23:08:48.81
スレタイは確か：
基地外名・プログラム名に迷ったら書き込むスレ。Part24
だったはずだよな？
109:デフォルトの名無しさん
14/02/11 23:17:21.07
>>102
CrazyMarker
110:デフォルトの名無しさん
14/02/12 04:30:09.06
>>102
自警団でいいじゃん
英訳しなくていい
その方がモチベーションも維持できる
111:デフォルトの名無しさん
14/02/14 02:04:33.35
STawk
112:デフォルトの名無しさん
14/02/14 17:32:57.04
単語Offsetを3文字に短縮したい場合、
Ofs
Ost
Off
その他
どれが良いだろう？
113:デフォルトの名無しさん
14/02/14 17:49:56.41
短縮しない
それがメモリとかの相対位置を意味するものならDifference
短縮してDiffとかにする
114:デフォルトの名無しさん
14/02/14 18:29:53.28
>>112
offsetじゃなくてindexの短縮形であるiを使う
115:デフォルトの名無しさん
14/02/14 19:19:44.73
>>112
俺も基本的には短縮しないほうがいいと思うが
敢えて3文字に短縮するなら、OST だな
116:デフォルトの名無しさん
14/02/14 20:49:00.11
ofsじゃね？いや省略しなきゃいいじゃんとは思うけど。
117:デフォルトの名無しさん
14/02/14 21:12:25.62
コーディング規約で決められてるとかじゃなければ、
offsetのままがいい。
118:デフォルトの名無しさん
14/02/14 21:57:21.92
span も4文字で済むが、
offsetの方が実態を表しているならこだわったほうがいいかもよ
119:デフォルトの名無しさん
14/02/14 21:59:34.01
ハードの世界ではaddressをadrs とか
offsetをoffsとか４文字に短縮することが多い。
120:デフォルトの名無しさん
14/02/14 22:08:16.57
そういう適当なこと言わないの。
121:デフォルトの名無しさん
14/02/14 23:30:05.88
address は addr じゃないのか？
122:デフォルトの名無しさん
14/02/15 01:27:10.30
adrわ？
123:デフォルトの名無しさん
14/02/15 16:23:16.66
C#で開発していて、今まで作ってきた自分用のクラスライブラリを
整理整頓したいのですが、最上位のNamespaceは何にすべきでしょうか？
自分の名前でしょうか？良い分類方法があれば教えてほしい。
124:デフォルトの名無しさん
14/02/15 16:39:36.94
>>123
特にこだわりがないのならMSのガイドラインどおりでいいでしょ
URLﾘﾝｸ(msdn.microsoft.com)
125:デフォルトの名無しさん
14/02/15 16:49:08.41
＞addressをadrs とか
Aurex の Adres と Victor の anrs 思い出した
126:デフォルトの名無しさん
14/02/15 16:53:28.57
>>123
良い分類法と言えるか自信は無いが
”自分用のクラスライブラリの最上位のNamespace”
ならば、万が一、他のライブラリと名前が衝突してしまっても
コードの一部分をツールで書き換えてしまえばいいので適当でもいいと思う。
でも一意性の確保はやはり欲しいというなら、俺は好きなフレーズの省略したものを使っている。
例えば、"mou dame po" ならば mudmpo という感じ
一応参考に挙げとくが、JAVAでは保持しているドメイン名を逆順をしたものを推奨している。
例えば、toro.2ch.net ならば net.2ch.toro という感じ
127:デフォルトの名無しさん
14/02/15 18:09:35.64
みなさんありがとうございます。
>>124,126
MSやJAVAのガイドライン大変参考になりました。とりあえずMSの方式で
やってみます。
128:デフォルトの名無しさん
14/02/15 18:11:54.72
っていうかMSのガイドラインをこれまで目を通したことがないC#の開発者って...
129:デフォルトの名無しさん
14/02/15 18:17:05.80
>>128
ん？
呼んだ？
130:デフォルトの名無しさん
14/02/15 18:29:30.24
>>126
数字始まりだとパッケージ名に使えなくて困るよな。
131:デフォルトの名無しさん
14/02/15 18:40:03.00
なんでMSのガイドラインを見ないといけないんだ ﾌﾟﾝｽｶ 信者じゃねーんだ
132:デフォルトの名無しさん
14/02/15 18:59:13.49
>>131
従うかどうかは別にして、一度目を通すくらいはしておくことを勧める
133:デフォルトの名無しさん
14/02/16 11:02:28.44
だな
感情論的な文句を言う奴に限って不勉強だから困る
不勉強なだけならまだしも、オレオレルールの方が優れてるぜ的な主張始めるから手に負えない
134:デフォルトの名無しさん
14/02/16 14:07:55.41
>>128を書いたのは俺だが、そのよくわからん被害妄想もどうかと思うが。
個人的にはあんたみたいなタイプの方が手におえないよw
135:デフォルトの名無しさん
14/02/16 15:05:38.39
>>134以外で被害妄想に見えるレスが見当たりませんが…
136:デフォルトの名無しさん
14/02/16 19:58:14.75
>>135
わろたｗ
137:デフォルトの名無しさん
14/02/16 23:11:47.76
>>135＝池沼
138:デフォルトの名無しさん
14/02/17 18:09:33.78
>>135
見当たらんのう
139:デフォルトの名無しさん
14/02/19 01:09:25.85
よしやり直そうぜ
っていうかMSのガイドラインをこれまで目を通したことがないC#の開発者って...
140:デフォルトの名無しさん
14/02/19 18:58:57.83
ルーピーきもっ、まで読んだ。
141:デフォルトの名無しさん
14/03/01 17:48:11.51
こういうことをしたいクラスの名前、いいのありますか？
class X {
int value, goal;
X(int start, int goal) : value(start), goal(goal) {}
void update() {value += (goal - value) / 2} // 差の半分だけ近づく
int value() {return value}
}
142:デフォルトの名無しさん
14/03/01 17:56:26.63
>>141
Asymptotic
143:141
14/03/01 17:57:35.04
>>142
ハイ採用！ありがとう！
144:デフォルトの名無しさん
14/03/01 18:10:45.70
アキレスの亀（笑）とかみたいな中二病な名前の方が分かりやすいと思う。
それに漠然と漸近じゃどう漸近するのか分からん
145:デフォルトの名無しさん
14/03/01 18:13:36.35
>>144
> それに漠然と漸近じゃどう漸近するのか分からん
うん、でもこの場合偶然これでちょうど良いんよ。
>>141の近づきかたは一例で、バリエーションは派生クラス名で表現したいいと思ってたから。
でも多分これ単体で十分そう。
146:デフォルトの名無しさん
14/03/01 19:18:42.51
>>141
反復的に処理するんだよね
何それ怖い、一向にゴールに辿りつけない
夢で追い掛けられて走っても全然前に進まないみたい
147:デフォルトの名無しさん
14/03/01 19:19:52.09
>>144
アキレスの亀？
意味が分からん
アキレスの亀は一度に
148:デフォルトの名無しさん
14/03/01 19:20:51.95
>>144
途中でレスしてしまった
アキレスの亀は一度に2倍ずつ前進するわけではないと思うが
149:デフォルトの名無しさん
14/03/01 19:45:23.16
>>148
それを言うなら漸近という概念も離散的なものじゃない。
対して、亀やアキレスからはボードゲーム的な動作を想像することは比較的容易。
150:147
14/03/01 20:08:55.61
>>149
ごめん、ちゃんと真面目な理由があってのことだったのならいいんだ
謝る
151:デフォルトの名無しさん
14/03/01 20:20:41.35
自然数を要素とする有限リストに適用し、真偽値を返す関数の名前を考えています。
この関数は、適用したリストが、1番目の要素として 1 が、2番目の要素として 2 が、・・・
n 番目の要素として n が入っている状態では真を、そうでない場合は偽を返します。
（べつに 0 から始めても何も問題ありません）
整列しているというニュアンスから aligned を考えましたが、
やや抽象的といいますか、曖昧という感じがします。
なにか良い名前はないでしょうか。
152:151
14/03/01 20:29:21.62
>>151
すいません、関数の定義を訂正します。
1番目の要素として 1 が、2番目の要素として 2 が、・・・
n 番目の要素として n が入っている状態とは限りませんでした。
リストに決められた順で決められた値が入っているかどうかを真偽値として返す関数です。
（どのように決められたいるかは任意です）
153:デフォルトの名無しさん
14/03/01 20:33:49.70
意図通りに並んでいるということなら arranged とか
参照するパターンや定形名があるなら arrangedAs(xx) とか
154:デフォルトの名無しさん
14/03/01 20:39:49.18
真偽値を返す関数にはhasとかisとか三単現の同士を使うって既約はわりと一般的？
155:151
14/03/01 20:49:16.61
>>153
ありがとうございます。
名前も短く、意味も明瞭なので採用させていただきます。
156:デフォルトの名無しさん
14/03/01 20:51:29.10
>>154
使っている人は多いですね。
そういう意味では一般的だと思います。
私はあまり使いません。
使わなくても、文脈などで十分わかる場合がほとんどなので。
私がメインで使っているのは Haskell ですが、
ライブラリドキュメントから is*** という関数名を調べると結構な数がありました。
調べて初めて気づきましたが、面白いことに、そこにあるのは「is + 名詞」ばかりで、
他言語でよくある「is + 過去分詞」は一つもありません。
私の環境にインストールされているライブラリがたまたまそのようなだけかもしれませんが。
157:デフォルトの名無しさん
14/03/01 21:13:00.35
is + 動名詞 で何かの動作中ってのもあるよね。
158:デフォルトの名無しさん
14/03/02 09:38:44.49
>>141
easing.foo()とかeasing_bar()みたいな命名にして
URLﾘﾝｸ(semooh.jp)
ここから似たような挙動のやつの名前をパクってくる
159:デフォルトの名無しさん
14/03/02 11:08:33.84
>>158
easing は >>141 そのものではなく、どちらかといえば
>>141 において goal に近づく「strategy」に当てる名ではないだろうか
160:デフォルトの名無しさん
14/03/02 12:39:26.19
>>158
解決済みだよ
結構下がってきたから上げとく
161:デフォルトの名無しさん
14/03/02 14:00:46.35
>>158
時間の関数になってないんだからイージング関数としては使えない
162:デフォルトの名無しさん
14/03/02 16:56:37.19
>>156
その辺りは規約次第かな
限定的な意味になるならIS＋名詞でも差し障りないとは思う
例えば、isLimitとかなら限界に達したかどうかなんだなって思えるし
これをまともに書いたらhasReachedLimitって長くなる
ただ、これをisLimitedにしたら違う意味になるし
その辺りよく考えないとね
頭にISを付けるのってBool値を返すための接頭辞的な使い方が最初じゃなかったっけ？
163:デフォルトの名無しさん
14/03/02 17:40:47.56
識別子に ? が使える言語が羨ましい
164:デフォルトの名無しさん
14/03/02 18:29:57.31
>>160
別に解決済みでもいいっしょ。
165:デフォルトの名無しさん
14/03/03 00:51:15.82
改行したばかりで一文字も入力されていない
＝一桁目だ、ということを表す変数名はis何がいいですか？
166:デフォルトの名無しさん
14/03/03 01:08:37.21
>>165
isAtLineHeadとか
167:デフォルトの名無しさん
14/03/03 01:59:10.13
>>165
firstLetter
168:デフォルトの名無しさん
14/03/03 06:55:51.92
>>165
isEmptyLine
169:デフォルトの名無しさん
14/03/03 08:19:27.09
日本語やり直して
170:デフォルトの名無しさん
14/03/03 08:33:14.39
>>165
> 一文字も入力されていない
と
> 一桁目だ、
は、全然 = じゃないんだが、どっちよ。
171:デフォルトの名無しさん
14/03/03 12:36:09.40
>>170
一桁目というのは、たぶんカーソルが（その行の）１桁目にあるという意味だと思う。
そう捉えればイコールで結べるから
172:デフォルトの名無しさん
14/03/03 19:11:10.16
俺は>>170とは別人だが、
キャレットの後ろに文字があるケースを想像できないってどんなダメグラマだよ。
173:デフォルトの名無しさん
14/03/03 19:33:01.05
お前がな
174:デフォルトの名無しさん
14/03/03 22:17:44.91
>>165
>>167と>>168をパクって
isFirstLetterAsEmptyLine
175:デフォルトの名無しさん
14/03/05 23:56:03.70
C言語ではbFlagって書いてたけどC#になってisFlagって書くようになった不思議
176:デフォルトの名無しさん
14/03/06 01:30:18.26
users というテーブルに、指定したidが存在するかどうかを調べる関数を作っています。
英語が苦手で自信がないのですが、
$db->users->hasId( $user_id );
or
$db->users->hasUserById( $user_id );
hasId() は問題なさそうに見えるのですが、hasUserById() もどうでしょうか。
また、他に良い関数名などありますか？
177:デフォルトの名無しさん
14/03/06 01:52:03.20
contains
178:デフォルトの名無しさん
14/03/06 02:21:12.92
俺もcontainsがいいと思うが他に
searchID or searchUserID
なんかどう？
179:デフォルトの名無しさん
14/03/06 02:49:44.33
>>176
1つ目はusersリストに指定したIDがあるかどうか
2つ目はusersリストの指定したIDにユーザが登録されているかどうか
って事？
ID自体が管理する為のユーザの代替名だから
ユーザが登録済み故にIDが発行されるって設計だよね？
IDが存在するならユーザ情報も存在するって意味で
もしそうなっているなら前者で十分、後者はいらんよな
180:デフォルトの名無しさん
14/03/06 07:40:18.92
>>175
まじ？ ＜C#
181:デフォルトの名無しさん
14/03/06 07:41:43.31
>>176
リストに対してhas～ はないなー。そもそも
182:デフォルトの名無しさん
14/03/06 07:51:02.97
>>176
exist
183:デフォルトの名無しさん
14/03/06 09:25:03.79
>>176
exist
idかどうかは引数でわかるだろう。
184:デフォルトの名無しさん
14/03/06 09:25:35.99
かぶってた
185:176
14/03/06 16:31:42.92
該当のidを持つユーザがいるかどうかを調べたい感じです。
$db->users->containId( $id );
$db->users->searchId( $id );
$db->users->existId( $id );
といったところでしょうか。
メールであれば
$db->mails->existMsgno( $msgno );
のような利用で大丈夫ですか？
186:デフォルトの名無しさん
14/03/06 18:43:27.90
>>185
引数の型とか、順番で判断すればいいだろ。
複合キーだったらexistHogeAndFooAndBarとかするつもり?
187:176
14/03/06 19:59:23.51
その場合は
$query = array(
"key1" => "value1",
"key2" => "value2",
);
$db->users->search( $query );
を作っています。
使い勝手として
if ( $db->users->existId( $user_id ) ) {
}
と書けた方がいいので、作りたいと思った感じです。
hasはusersがidを持っているか、というようなニュアンスで付けました。
#間違っているかもしれないですが。。
188:デフォルトの名無しさん
14/03/06 20:14:53.27
C#ならメソッド名はFindかExistsにして、その引数にはラムダ式（デリゲート）
を取るようにするケースかね。
俺も>>176が言うとおり、引数に「ユーザー」の型を取るわけじゃなく、
「ユーザー」の属性を取るのにメソッド名にその属性の名前がないのは変だと思う。
189:デフォルトの名無しさん
14/03/06 20:45:52.18
>>187
オーバーロードなら、searchにuser_id渡せるだろ。
まあ戻り値が条件として使えるかは、言語が不明なので何とも言えないが。
まあ、昔はそういう命名が流行ってた時期もあったようだから、いいんじゃない。とりあえず全部入れとけというような名前とか見かけるし。
190:176
14/03/07 00:38:02.69
言語はphpです。
ContainsId( $user_id )
にしました。
ありがとうございました。
191:デフォルトの名無しさん
14/03/07 04:42:08.24
lookup を忘れてあげないで
192:デフォルトの名無しさん
14/03/28 06:14:01.93 dT+U4pbh
スタック式のカスタムアロケーターの名前なんだけど、名前被りにより「Stack_Allocator」が使えない
Mark_And_Release_AllocatorとRegion_Allocatorのどっちが好き？
193:デフォルトの名無しさん
14/03/28 07:48:58.33 t8r5ABN8
templateにせんのか？
194:デフォルトの名無しさん
14/03/28 08:18:39.24 dT+U4pbh
C++じゃないんで
195:デフォルトの名無しさん
14/03/28 09:16:06.59 VVPQgbpw
My_Stack_Allocator
196:デフォルトの名無しさん
14/03/29 01:59:53.96 BlQ6/Bp+
Stack_Broker
197:デフォルトの名無しさん
14/03/29 17:37:57.18 I1tU3ujG
>>194
Cなの?
198:デフォルトの名無しさん
14/04/11 16:40:34.37 5YbjDPT2
正規表現のRegex風にS式のS-Expressionのクラスの名前教えてください
199:デフォルトの名無しさん
14/04/11 18:17:32.56 F9N8K0IN
>>198
SymExp
200:デフォルトの名無しさん
14/04/14 22:42:01.64 EeY8LyqJ
int xxx(int n, int minValue, int maxValue)
{
if (n < minValue) return minValue;
if (n > maxValue) return maxValue;
return n;
}
n = xxx(n, 0, 999);
数値が、最小値、最大値からはみ出していたらその大きさに丸めて、
範囲内だったらそのまま返す関数って、どういう名前がいいですか?
201:デフォルトの名無しさん
14/04/14 22:44:40.32 Jngx582W
>>200
bound_int_value
202:デフォルトの名無しさん
14/04/15 01:06:13.82 xRl40yH0
clamp
203:デフォルトの名無しさん
14/04/15 02:32:35.48 fR6ayjsl
>>200
似たような関数作ったことある
その時はRangeってしたわ
204:デフォルトの名無しさん
14/04/15 02:50:39.53 9pVsP7Oj
>>200
InsureRange
205:デフォルトの名無しさん
14/04/15 07:34:23.85 2R2ghSam
>>200
シェーダ言語とかではよくclampって関数名で定義されてるね
206:デフォルトの名無しさん
14/04/15 08:09:11.21 D5PUC5mL
>>200
飽和演算？
207:デフォルトの名無しさん
14/04/15 13:45:53.03 xKGzsUAl
ensureRange
208:デフォルトの名無しさん
14/04/15 17:56:19.53 e83dq4jx
>>206
似てるけど、今回のはそれ自体に演算機能は持たないんじゃね？
209:デフォルトの名無しさん
14/04/15 19:15:34.41 XJQt4XYv
>>208
なるほど、そういやそうだな。
210:デフォルトの名無しさん
14/04/15 19:32:08.94 RXwoPk3P
>>200
もうこのスレでも何度も出てるお題。
clampで決まりでしょ
211:デフォルトの名無しさん
14/04/17 08:27:53.03 fUQRRpSZ
clipも似たような状況で使われるけど、微妙に違いがわからない
212:デフォルトの名無しさん
14/04/17 21:53:03.54 aSfdufW/
cropも仲間入りだ
213:デフォルトの名無しさん
14/04/17 23:57:04.46 fUQRRpSZ
cropは見たこと無いな。
どういう意味合いで使われてんのん？
214:デフォルトの名無しさん
14/04/18 00:53:41.80 UHEH0YN2
clampは弾圧し、制限する
clipは必要な部分を切り抜く
cropは不要な部分を切り落とす
clipとcropはやることは似てるけど、注目してる対象が真逆なんじゃね
215:デフォルトの名無しさん
14/04/18 01:09:26.87 Gdxkjuia
それはどうかねw
用例を見てみるとどちらも目的語に取る単語は変わらないようだが
216:デフォルトの名無しさん
14/04/18 18:52:51.47 HhTg8YpZ
clipやcropだと、指定範囲に入ってなければ削除されちゃうイメージなのか
217:デフォルトの名無しさん
14/04/18 22:04:36.18 AgX57pfJ
ImageMagickはcrop派
URLﾘﾝｸ(www.stat.ufl.edu)
218:デフォルトの名無しさん
14/04/20 00:30:26.48 v+osdnJB
clampは万力で挟み込むイメージ
219:デフォルトの名無しさん
14/04/20 03:36:43.29 lQVYmlUh
うまく説明できないんですけど、いくつかのincludeされるファイル（仮にA～K）があって、
もちろんそれらをincludeするファイル（仮にX）があるんです。この時、A～KからみたXを
なんて呼べば（なんて変数名／定数名にすれば）いいのかわからないのです。
今のところ
top
master
parent
が思い浮かんだのですが。。。
流れぶった切ってすいません。ちなみに私はclamp派です。
220:デフォルトの名無しさん
14/04/20 04:39:06.64 DYddObWG
統括することによって発現する機能は何？
221:デフォルトの名無しさん
14/04/20 05:04:36.10 lQVYmlUh
ちょっと言葉が足りませんでした。A～K、Ｘはソースコードで、A～Kはライブラリです。
現在タブ型エディタからコンパイルなどを行おうとしています。編集中のソースコードを
コンパイルする機能までは実装できたのですが、この方法だとコンパイルの際に毎回Ｘに
移動しなければならず、煩雑に思っています。ですのでコンパイルを行うファイル(Ｘ)を
Ａ～Ｋにコメントのような形で指定できれば楽かなあと考えたのですが、丁度いい名前が
うまく思い浮かばなかったのです。考えているソースのイメージはこのような感じです。
#master X
/*A～Kなど個々の処理*/
222:デフォルトの名無しさん
14/04/20 10:11:26.86 1NFV65d8
>>221
makeコマンド使えよ。設計が悪……げふんげふん
俺ならentrypointにする。
223:デフォルトの名無しさん
14/04/20 10:37:31.72 DYddObWG
IDEだと、メニューに「コンパイル」と「ビルド」の項目があったりする。
（何と何をどうビルドするかは、プロジェクトなどと呼ばれる別の部分に書いてあるわけだが）
ところでライブラリって言うからには、Xに限らずYとかZからも
同様に使われるんじゃないの?
「コンパイル」という概念だけで管理したかったら、
「Xのタブ」に"masterFile" みたいな属性つけてみれば?
＃俺はこういう方式でビルドを管理することに違和感があるけど
# (要は>>222の一行目と同意見）
224:219
14/04/20 13:08:45.17 lQVYmlUh
すいません、インタプリタ言語なのでコンパイルではなく実行でした。。。
言葉を間違えてしまってごめんなさい。自分の誤用がうんだのだと思いますが、
makeはどうやらコンパイラ型言語用っぽいので、使えなさそうです。
>>222
>>223
IDEにしてプロジェクトを作成するようにすることも考えたのですが、
なにかちょっとしたコードを書くだけですぐに実行できる手軽さが
長所なので、プロジェクトを作成・管理する方式にするのはなるべく
避けたいと思っています。
ですがIDEにしないとなると>>221のように面倒になるので、
ソースコード中にXを指定できればいいなと思ったのです。
entrypointとmasterFileですか。考えます。
225:デフォルトの名無しさん
14/04/20 14:01:51.48 QOBJ+v8C
>>224
もう使用言語書いちゃった方が早いんじゃないの？
スレ違いなら該当スレに誘導もできるし
226:デフォルトの名無しさん
14/04/20 14:22:51.42 1NFV65d8
>>224
結局、個々のファイルにプロジェクト情報を埋め込むことになってるけどな。
#entrypoint
#entry
#start
#run
227:デフォルトの名無しさん
14/04/20 15:56:19.15 FM5jWgiI
>>219の言ってることはさっぱり理解できんな。
依存される（インクルードされる）側のコードから依存する側が分かるようにしたいって
そんな情況ありえない。
依存関係は一方通行にしろって基本中の基本だろ。
228:219
14/04/20 16:59:01.63 lQVYmlUh
ああそうか、やっと>>223の言っていることが理解できた｡
他の（X以外の）ファイルからもincludeされている場合が
あるのか。だから、依存関係は一方通行にするんですね。
もともと大規模な開発には向いていないし、色々使われる
ようなファイルにはそんな頻繁に変更を加えないだろうし
大丈夫、などといった考えはさすがに甘いですかね。。。
（例えばCのstdio.cはまず編集しないだろうという考え）
複数のファイルから依存されるファイルでの指定はどんな
感じにすればいいんでしょうか。依存するファイルを全て
書いてもらい、その中で最も新しく編集・実行されたもの
にすればいいんでしょうか。
>>226
そうなっちゃいますけど、
複数ファイルを編集しての開発の数＜＜＜＜１ファイルのみの編集での開発の数
なので、今のところは仕方ないで済ませるしかないかなあと。
229:デフォルトの名無しさん
14/04/20 17:19:02.19 1NFV65d8
「必要とされている」に着目するなら
#required_by
#used_by
#prerequisite_of
「アイツにはincludeされてもいいけど、アイツにはincludeされたくない」っていうアクセスコントロールは
まあアリなんじゃねーの。新しい可能性は感じる。
その場合はサーバの設定みたく
#allow
#deny
みたいな名前を推すね。
230:デフォルトの名無しさん
14/04/20 20:39:37.72 sUEwE9Sm
SQLクエリ作って実行して結果セットを返すだけの関数がたくさんあるのだけど名前の付け方になやむ
きっちり名前つけたらめちゃ長くなるし短くしたら意味わからんくなる
ビジネスロジック次第でどんどん増えてくるし名前考えるのが間に合わないよ
231:デフォルトの名無しさん
14/04/20 20:52:45.25 G8rwm69d
ここは愚痴を言うスレじゃありませんよ
232:デフォルトの名無しさん
14/04/20 20:57:18.39 1NFV65d8
>>230
Connection.getXXX
233:デフォルトの名無しさん
14/04/20 21:09:25.05 AgU+bPCO
>>230
クラスにして、longNameやdescriptionって属性付ければいい。
234:デフォルトの名無しさん
14/04/20 22:18:11.91 k3tDznaJ
f001_0001
235:デフォルトの名無しさん
14/04/21 14:13:39.74 hwQr/gvM
あるデザパタに則ったクラスを作った時、そのクラス名にデザパタ名って入れてる？
236:デフォルトの名無しさん
14/04/21 18:17:02.65 zZ+Xq2d/
>>235
入れないかな
入れる必要性ってあるかなあ
237:デフォルトの名無しさん
14/04/21 21:03:10.78 oJpcDlRY
○○Factoryはアリだけど
××Compositeは無いわ
238:デフォルトの名無しさん
14/04/21 21:46:56.50 7G5cgUXt
Bridge Adaptor 入れるやつもけっこありそうだが
239:219
14/04/22 23:28:59.39 0+lCOfH1
皆様ありがとうございました。
とりあえず、#entrypointあたりを考えてみます。
240:デフォルトの名無しさん
14/04/24 22:39:36.55 kRu8Dwzx
ブログのエントリ作成ページを表示するメソッド名で悩んでいます。
show_entry_create_page()ではおかしいと思うので
いい名前があれば教えていただけないでしょうか
241:デフォルトの名無しさん
14/04/24 22:59:49.00 a86mk3CI
showPage2CreateEntry
「2」で分けてるところがポイント
242:デフォルトの名無しさん
14/04/24 23:01:00.54 hPYav21o
PageCreateView.show
243:デフォルトの名無しさん
14/04/24 23:26:30.99 y+/G0yAt
>>240
背景情報ゼロでそれだけ言われても何を求めてるのか誰も分からないと思うが...
ShowEntryPageStub()
ShowEntryPageSkeleton()
ShowStub(KindOfPage page)
244:デフォルトの名無しさん
14/04/25 01:21:53.23 KTr74lei
>>240ですがすみません、メソッドではなく関数でした。
投稿フォームがあるhtmlを返すだけの関数です。
245:デフォルトの名無しさん
14/04/25 06:24:47.85 Pkyhb6hg
>>244
なんでネームスペースなりモジュールを切らないのさ
246:デフォルトの名無しさん
14/04/25 07:30:18.56 KTr74lei
>>245
シンプルなブログで、使っているフレームワークも
flaskというマイクロフレームワークなので必要ないかなと思いました
247:デフォルトの名無しさん
14/04/27 11:54:30.16 ZFL5ABxC
リスト内のあるパターンにマッチする、あるいはマッチしない要素のみを集めて別のリストにする、
いわゆるフィルター関数を作っています。
マッチする、しない、どちらの処理かはこの関数の引数で指定できるようにします。
要素ひとつに対して、パターンとマッチするなら0を、しないなら-1を返す関数は予め用意されています。
あとはリストをたどってフィルターする関数を作るだけですが、
質問は上記の役割の引数の名前をどうするかです。
filter関数の定義 (List list, int <引数>) {
foreach (list の各要素 e について) {
if (match (pattern, e) == <引数>) then 別のリストに加える
}}
248:デフォルトの名無しさん
14/04/27 12:42:48.45 CYgu7nDo
>>247
filter
249:デフォルトの名無しさん
14/04/27 13:32:30.32 MXG/a/88
引数は
マッチさせたいパターンではなく
マッチしたものを集めるのか、マッチしないものを集めるか、の真偽値?
それにしては実装の条件判定が変な気が。
250:デフォルトの名無しさん
14/04/27 14:03:56.07 0q81XbwG
>>247
別関数にしろよ
251:デフォルトの名無しさん
14/04/27 14:10:36.20 GbqQrH3o
>>247
condition
pattern
isComplement (補集合が欲しい場合はtrueにする）
252:デフォルトの名無しさん
14/04/27 15:02:03.12 s0NPrJow
>>250に同意
filterMatched()
filterUnmatched()
253:デフォルトの名無しさん
14/04/27 15:24:56.79 ZFL5ABxC
ご意見ありがとうございます。
別関数にすると、真偽判定が逆なだけの、ほぼ同じ関数ができます。
filterMached (List list) {
foreach (list の各要素 e について) {
if (match (pattern, e) == 0) then 別のリストに加える
}}
filterUnmached (List list) {
foreach (list の各要素 e について) {
if (match (pattern, e) == -1) then 別のリストに加える
}}
これは、似たようなルーチンをコピペで作ることによって
バグが入り込みやすくなるのと同じ問題を抱える危険性はないでしょうか？
それとも、この程度は心配に及ばないでしょうか？
パターンをハードコードするか、引数で渡すかは、
今回の質問とは直接関係はないと判断しました。
実際は引数で渡しますが、疑似コードからは省きました。
254:デフォルトの名無しさん
14/04/27 15:33:21.21 xRItzqVi
filterUnmatchedはfilterMatchedを使って実装する
255:デフォルトの名無しさん
14/04/27 15:33:40.04 0q81XbwG
>>253
別関数にして内部で共通のprivateな関数を呼ばせればいい
256:デフォルトの名無しさん
14/04/27 16:08:17.03 GbqQrH3o
result = filter(list, MATCHED);
result = filter(list, UNMATCHED);
257:デフォルトの名無しさん
14/04/27 16:22:58.70 ZZqYBvz3
自分の場合こういうのはだいたいmodeにしてる
258:デフォルトの名無しさん
14/04/27 16:36:49.52 CYgu7nDo
複雑化の予感がするので、なるべくmodeという言葉は避けている。
259:デフォルトの名無しさん
14/04/27 16:57:01.14 6s7wVMIk
>>253
今時そういう処理は、要素を評価してboolを返す処理（いわゆる術語ってやつ）
そのものを外から引数で与えるのが普通だと思うけどね。
そうすればフィルター関数そのものは1つで済む。
List FilterList(List list, IPredicate pred){...}
260:デフォルトの名無しさん
14/04/27 18:10:18.87 0q81XbwG
>>259
predicateを渡せるようにするにしろ、selectとfilterは切り替えられた方が楽じゃない？
261:デフォルトの名無しさん
14/04/27 19:36:41.11 Rnjqi7kK
>>260
言いたいことがよく分からないけど、>>250みたいに
(1) 条件に一致するものをピックアップする関数
(2) 条件に一致しないものをピックアップする関数
の2つが必要ってこと？
だとしたらそんなの無駄だよ。
それは単にIPredicateの中のboolを返すメソッドの返り値を反転するだけで実現できるんだから。
262:デフォルトの名無しさん
14/04/27 19:52:30.82 0q81XbwG
>>261
predicateの返り値を論理反転するの面倒じゃね？
263:デフォルトの名無しさん
14/04/27 20:29:01.78 7z1LvxMJ
>>262
え？
え？
264:デフォルトの名無しさん
14/04/27 20:31:02.25 0q81XbwG
unary_negateを使いやすいと思うかどうかって話になるのかな。
俺はアレ使い辛いと思うんだが。
265:デフォルトの名無しさん
14/04/28 07:50:49.67 BPdrCHGq
match関数は0か-1しか返さず、それに基づいてフィルターすることしかやっていません。
作っているアプリ全体を通しても、今のところ、将来述語を引数で渡す需要は予定されていないのですが、
万が一のために、今のうちに述語を引数で渡すようにリファクタリングしておくべきでしょうか。
そうすれば、名前に悩む必要もなくなると？
mode は簡潔で魅力的だと思いました。
266:デフォルトの名無しさん
14/04/28 09:14:13.54 BvpC1L+S
>>265
設計の話はスレ違い
267:デフォルトの名無しさん
14/04/28 11:31:51.89 iG5L3XR9
ここまで案が出ているなら
仕様と照らし合わせながら好みの方法を取ればいいじゃない
自分なら>>259と同じ方法を取るかな
filter(List list, IPredicate pred) {
foreach (list の各要素 e について) {
if (pred(e)) then 別のリストに加える
}}
predの戻り値はbool値
match (pattern, e) == -1
や
match (pattern, e) == 0
を返す
これならフィルタリング関数を使う側がパターンを指定できるし
真偽判定を操作できる
268:デフォルトの名無しさん
14/04/28 12:49:08.74 BPdrCHGq
分かりました。
mode を採用させていただきます。
ありがとうございました。
269:デフォルトの名無しさん
14/04/29 00:48:10.95 AbmpH0cg
カリー化勉強しろ
270:デフォルトの名無しさん
14/04/30 09:21:15.70 cx3jGZZa
レス番、名前、書き込み日時、id、書き込み内容を持つResponseクラスがあったとして、
htmlからResponseオブジェクトにする関数はどんな名前がいいでしょうか？
mapじゃ変ですよね
271:デフォルトの名無しさん
14/04/30 09:24:22.38 6UO7iz+Z
Deserialize
272:デフォルトの名無しさん
14/04/30 10:05:30.07 E490Ymqi
getResponse(html)
273:デフォルトの名無しさん
14/04/30 12:01:32.55 MnAqZAza
>>270
parseにした
274:デフォルトの名無しさん
14/04/30 13:18:26.79 0MeOOKwa
まさか生のhtml解析するところから全部やるのか？w
275:デフォルトの名無しさん
14/04/30 14:41:54.36 JPnQYaUd
Parse()に一票。
入力をテキストファイルに限定しない、例えばDBからの入力なども含むなら GetResponse() でもいいかなあ。
276:デフォルトの名無しさん
14/04/30 17:45:07.90 j4BsIhks
俺もparseに一票
277:デフォルトの名無しさん
14/04/30 18:20:44.45 YL9xmsHU
生のhtmlを直接「解析」した結果が特定のデータ型ってかなり違和感あると思うんだけどね
278:デフォルトの名無しさん
14/04/30 18:26:24.21 16cTkqRc
いわゆるレス、なんだからresponseとか一般的な名前使っちゃうのは大盤振る舞いすぎると思う。
ResuでいいんだよResuで。
List reslist = Resu.createResuList(html)
Resu r270 = reslist.get(270 - 1)
こんな感じにとどめとくのが一番素直じゃね？
279:デフォルトの名無しさん
14/04/30 19:40:03.20 hD0MhTgo
>>270
> Responseオブジェクトにする
Response のコンストラクタじゃダメなの？
280:デフォルトの名無しさん
14/04/30 20:04:11.60 6UO7iz+Z
いまどき言語ならリフレクションが使えるからそもそも車輪の再発明かもしれんし
どういう目的でhtmlなんて解析したいのかによるな
281:デフォルトの名無しさん
14/04/30 21:43:20.88 qHgsSpiC
>>274
html(文字列？)を入力にして、それぞれの要素を取り出して返すならそうなるだろ
アホか
282:デフォルトの名無しさん
14/05/01 13:08:02.88 sff33EKO
>>280
>>270を素直に読めば、掲示板のブラウザを開発していると想定するのが、
自然な解釈ではないかと思う
つまり、
「2ch.netなどの掲示板サイトからHTTPなどの手段で
あるスレッドのHTML形式(文字列型)データがすでに取得されている」
ここまでが質問(>>270)の想定になる
283:デフォルトの名無しさん
14/05/01 14:42:17.70 uU7/MEkt
結局 tmp
284:デフォルトの名無しさん
14/05/01 17:31:51.38 qBGbIEYq
>>281
お前の使ってる言語に、HTMLパーサはないのか？
285:デフォルトの名無しさん
14/05/01 18:51:05.30 QfqMeChr
>>283
まあな
286:デフォルトの名無しさん
14/05/01 19:07:57.44 sff33EKO
>>282の想定が正しいと仮定し、さらに
>>270の質問を要求仕様としてじっくり検討してみると
仕様そのものに曖昧さ/矛盾がみえてくる
具体的には、>>270には「htmlからResponseオブジェクトにする関数」と
あるけれど、>>282で書いたように取得したHTMLデータとはスレを表す
そしてスレは複数のレスの反復から構成されるわけだから、
論理的にHTMLからレスへの関数は存在しえない
この矛盾は>>270が作ろうとする仕様に応じて、以下のいずれかになるだろう
(1) 実は「HTMLからスレを得る関数」が欲しかった
(2) 実は「HTMLからレスの集合オブジェクトを得る関数」が欲しかった
(3) その他
これらのどれが正しいかは>>270本人しか分からないわけで、
それが決まらなければ適切な命名はできない
287:デフォルトの名無しさん
14/05/02 00:11:37.40 9qUJMVyr
>>286
「複数のレス」なんて拡大解釈もいいとこだろ
288:デフォルトの名無しさん
14/05/02 00:21:33.07 TboE210z
>>286
気持ち悪…
289:デフォルトの名無しさん
14/05/02 01:46:28.84 OgCqwCcb
ついでに、専ブラのスレ一覧で１日とか1時間あたりのレス数を表示するものありますよね。勢いとか呼ばれたり。この英語名をお願いします
290:デフォルトの名無しさん
14/05/02 01:52:37.23 jIwzpAmb
ikioi
わりとマジ
291:デフォルトの名無しさん
14/05/02 08:25:06.54 H6Oph/1V
PPD、PostsPerDay
292:デフォルトの名無しさん
14/05/02 17:37:17.12 BQe7Xuso
trend
momentum
293:デフォルトの名無しさん
14/05/04 13:34:36.36 Qr2Jhwpy
JavaScriptで矩形を扱ってます
左上、右上
左下、右下
に対応する変数名なんですが、慣例みたいなものがあれば教えてほしいです
294:デフォルトの名無しさん
14/05/04 13:56:37.66 Zzf9bUfD
>>293
慣例かどうか知らんけど、単純に
topLeft、topRight
bottomLeft, bottomRight
で良いと思うがなあ
295:デフォルトの名無しさん
14/05/04 15:38:30.98 Fi2TCAxj
上下は top/bottom のかわりに upper/lower を使うのも見たことある。
296:デフォルトの名無しさん
14/05/04 15:46:40.57 n8bRVLF6
方角使ったの見たことあるな。
左上はnwとか、右下がseとか。
ただ、評判は悪い方が多かったな。
297:デフォルトの名無しさん
14/05/04 15:58:45.46 M/fXRR5a
まあ、左上、右下とかで十分なところに、北西とか南東とか言っても分かりやすくはならないからなぁ
298:デフォルトの名無しさん
14/05/04 16:14:17.24 /8HFkyur
タブレットみたいに画面が回転するデバイスであれば、
絶対的な東西南北と相対的な上下左右という
二種類の命名を意識して使い分ける必要があると思う
ただし、一般的なJSプログラミングであれば>>294で十分
299:293
14/05/04 18:18:25.80 Qr2Jhwpy
みなさんありがとう
半径rみたいに決まった文字とかあるかと思ったんですが、特に無さそうなんで>>294使わせてもらいます
300:デフォルトの名無しさん
14/05/04 20:06:37.81 CnsXC7Sg
十分に狭い範囲でなら、t/b/l/rくらいだと説明なしに出てくるかもなー
301:デフォルトの名無しさん
14/05/05 11:53:12.10 Mu2ScZdD
ビットマップの中の1の数を数えるメソッド、0を数えるそれを教えてください。
302:デフォルトの名無しさん
14/05/05 14:36:02.42 vEoyNxMN
count_ones
count_zeros
303:デフォルトの名無しさん
14/05/06 23:57:11.60 sL8fKPSd
関数での計算結果はcomputationって単語使うのが適切ですか？
もっと適切な名前はありますか
304:デフォルトの名無しさん
14/05/07 00:03:15.59 GRjLr4h4
>>303
とりあえずvalue
何の計算結果か特定できるなら、それとわかる名前がいい。
305:デフォルトの名無しさん
14/05/07 00:05:11.61 bFoGw102
result
306:デフォルトの名無しさん
14/05/07 00:10:53.69 9YkH6KpU
var result = ...;
return result;ってやりがちな俺
307:デフォルトの名無しさん
14/05/07 00:13:08.76 bcucIi7c
result 最終状態。～その結果として。結果が…となる。
>>305 適切っぽい。ありがとう
308:デフォルトの名無しさん
14/05/07 00:46:45.31 ww08WxpS
>>307
で、数か月後に自分のコード見て「結果って何の結果だよ（ﾑｷｰ」ってなるの巻。
>>304の言うとおり、戻り値を受ける側の変数の名前であれば戻り値の意味の名前をつける方が
適切だと思うけど。
値を返す側で戻り値を入れる変数の名前であればretとかで十分。
309:デフォルトの名無しさん
14/05/07 00:50:13.42 n0BPcJ7e
>>306
>>308
その用途ならrvをよく使うわ。retってのはどうもこそばゆい
Return Value の略なのか Value of Result なのか知らんけど
int rv = ...;
return rv;
310:デフォルトの名無しさん
14/05/07 05:03:21.93 nyTYPDB6
>>308
これから戻す値にresultを使うのはDelphi流じゃね？
あの言語はresultに代入した値が返される仕様だし
311:デフォルトの名無しさん
14/05/07 06:19:35.17 2wVYcLHM
>>303
関数名と同じか似たもの。
312:デフォルトの名無しさん
14/05/07 06:44:31.76 aKLx6ZH2
関数内の戻り値ならResult
単純な同じ種類の数値の合計とかならSumとかTotalとか
関数から受け取る値ならその値の意味する名前
313:デフォルトの名無しさん
14/05/07 06:57:33.46 sWKK4Euk
>>308
ならんだろ、なんの結果かわからんようになりそうなら関数仕様なりコメントなり入れるし
314:デフォルトの名無しさん
14/05/07 07:01:01.27 bcucIi7c
>>311
天才
315:デフォルトの名無しさん
14/05/07 07:19:32.82 bcucIi7c
ついでなんでコストの日本語教えてくれー
意味的には「いちいちかかる費用」みたいな感じ
316:デフォルトの名無しさん
14/05/07 07:51:58.45 VjouCf5b
overhead か
cost
317:デフォルトの名無しさん
14/05/07 08:39:55.89 FZZA6k3k
RunningCost
318:デフォルトの名無しさん
14/05/07 08:49:54.47 lc26ma19
日本語か…
もちょっと文脈が欲しい
319:デフォルトの名無しさん
14/05/07 08:54:52.28 9YkH6KpU
>>309
それいただき
320:デフォルトの名無しさん
14/05/07 09:23:30.02 aFwzCm3Y
うろ覚えだけど、リーダブルコード的には、retだのretvalだのは避けろって書いてなかったっけ?
321:デフォルトの名無しさん
14/05/07 10:23:40.79 edkmu5YG
関数名と同じでint mainを作ったらwarning: 'main' is usually a function [-Wmain]だって。
322:デフォルトの名無しさん
14/05/07 10:33:28.39 2wVYcLHM
>>321
mainの戻り値で計算結果返すなよ。
323:デフォルトの名無しさん
14/05/07 11:47:36.32 edkmu5YG
え？
シェルスクリプト向けなどで結果は返すぞ？ｗ
324:デフォルトの名無しさん
14/05/07 14:49:20.58 2wVYcLHM
正常終了かエラーコードでなくて計算結果を?
それを置いてもmainとかで計算を行わずに、別関数にすべきだと思うが。
もっとも最初から、言語依存の予約語や制約、名前空間、コーディング規約を考慮して、"同じか似たもの"と書いてあるけどな。アンダースコアでもつけとけよ。
ちなみに自分では適切な名前毎回考えてる。VBみたいでイヤだから。
325:デフォルトの名無しさん
14/05/07 15:24:31.43 n0BPcJ7e
>>320
関数名から返却値の性質は自明なんだけど、スコープ終端に資源解放があって結果を保留しておかなきゃいけない場合に使う
RAIIが徹底してる言語であれば任意にreturnできるからあまりこういう変数いらないんだけどな
326:デフォルトの名無しさん
14/05/07 16:40:16.47 NpxBbooR
resultに統一だな。関数名に引きずられる名前は文脈で意味が変わって読み辛いよ
mainに限ればexitcodeでもいいが
327:デフォルトの名無しさん
14/05/07 17:19:05.56 v8XT9GT6
>>320
リーダブルコードの例で出てくるダメなresultは、
最後が return Math.sqrt(result); になっている特殊なケース。
これは変数resultが関数の結果ではないから混乱する。
こういうケースでないならresult使ってもいいと思う。
328:デフォルトの名無しさん
14/05/07 17:49:15.46 mpbwymho
呼び出す関数の戻り値ではなく、
自分を含むブロックを関数としたとき、その戻り値ってことなのね
329:デフォルトの名無しさん
14/05/07 23:26:12.35 f43fXs2r
booleanの変数名や関数名の接頭語にisを付ける風潮あるじゃん。
インスタンスフィールドやインスタンスメソッドになら良いと思うのだけど、
ローカル変数やstaticメンバーにまでis付いてるの見かけてキモい。
主語の無いis…
330:デフォルトの名無しさん
14/05/07 23:48:28.93 9YkH6KpU
JSなら全部thisだから問題ないな！
331:デフォルトの名無しさん
14/05/07 23:54:50.52 n0BPcJ7e
>>329
booleanは'f'接頭辞で統一してるな。'b'でもいいけどさ
システムハンガリアンなんて糞くらえだが能動態で表現しないとどうにもならないフラグって結構あるから
is~の命名にいちいち頭悩ますのはいやだ
332:デフォルトの名無しさん
14/05/07 23:59:06.89 9YkH6KpU
has使ってもいいのよ
333:デフォルトの名無しさん
14/05/07 23:59:11.54 cMom8c9/
>>315
ああ、日本語か...
連続的にかかるなら運用費用 とかかな。
スポット保守費みたいな奴なら 都度費用 とかぐらいしか思い付かん。
334:デフォルトの名無しさん
14/05/08 00:04:51.42 od3Ldiu5
>>332
これから～するぞ、っていうフラグはどういう名前つけるの？
335:デフォルトの名無しさん
14/05/08 00:11:32.59 TVCEdFQe
can～
336:デフォルトの名無しさん
14/05/08 00:19:41.04 3uesuF+X
>>327
今思い返してみたら結構そのパターンやってるわ…
337:デフォルトの名無しさん
14/05/08 00:39:06.13 MYrg8Jhx
>>329
その場合、第一引数が主語と考えれば良いんじゃね
338:デフォルトの名無しさん
14/05/08 01:22:59.85 gVOrgIvu
>>337
そういう読む側が歩み寄らなきゃいけない名前は嫌だなー
何にでもis付けて、結局型を表してるだけのものになってしまったら、
実質システムハンガリアンみたいになってくるってのもきもいし。
isの意味はどこに行ったんだーってね
339:デフォルトの名無しさん
14/05/08 02:54:45.19 iYzmgXRT
>>333
運用費か。
冷蔵庫を買うとする。寿命は10年なので、120ヶ月持つ。
原価がかかって電気代もかかってメンテナンス代もかかるとする。
全部合計して、120で割ると一ヶ月分のコストが出てくる。
これが3000円だとする。
この3000円に日本語の名前をつけないとならない。
340:デフォルトの名無しさん
14/05/08 03:40:09.39 oGu9Ywqg
>>334
set～State
>>329
排他などでHoge.is～State?
341:デフォルトの名無しさん
14/05/08 03:55:22.70 od3Ldiu5
>>335
bool addsMargin;
みたいに3単現のsつけるっていう流儀もあって結局悩むことになるんだよなあ
342:デフォルトの名無しさん
14/05/08 04:55:47.42 TVCEdFQe
あー、～ableってのは使うかも
343:デフォルトの名無しさん
14/05/08 07:06:53.63 kvSwmeeY
>>339
冷蔵庫代まで含むなら、経費かな
344:デフォルトの名無しさん
14/05/08 08:52:29.14 X5dRpFAy
>>339
ランニングコストとか維持費で良いんじゃないの？
345:デフォルトの名無しさん
14/05/08 09:16:24.48 Yajv3evl
月あたりコスト コスト毎月 コスト（月額）
例：20km/h -> 20km毎時
346:デフォルトの名無しさん
14/05/08 12:05:27.10 OHs+q7mk
色々な金を合計してるなら、費用としか言いようがないんじゃないか？
347:デフォルトの名無しさん
14/05/17 13:16:26.52 18igEiY0
htmlのtitleタグの中身を取得する関数名で悩んでます。
getTitle(html), extractTitle(html) とか考えたんですがしっくりきません。
いい名前はないでしょうか
348:デフォルトの名無しさん
14/05/17 13:37:38.30 xUIr72T7
html.head.title();
349:デフォルトの名無しさん
14/05/17 14:09:28.32 g/LugQB1
gettle
350:デフォルトの名無しさん
14/05/17 14:35:46.06 /wPndJU8
pick up
retrieve
find
351:デフォルトの名無しさん
14/05/18 05:58:07.12 UqGH8+5G
search
lookup
352:デフォルトの名無しさん
14/05/18 06:32:49.10 ZUzVYIGO
new Document(html).getTitle()
関数ではないか。
353:デフォルトの名無しさん
14/05/18 09:13:36.01 xPqPYAXW
メソッドを実装するクラスの役回りによって名づけ方が変わると思うんだな。
354:デフォルトの名無しさん
14/05/18 15:19:36.46 sw3cv+Zt
>>353
俺も思った
HTML 系のクラスじゃなかったら、getTitle だと何のタイトルを取るのか分かんないから getHtmlTitle とか
355:デフォルトの名無しさん
14/05/18 16:46:37.79 ZUzVYIGO
Documentのtitleだろう。
クラスを"関数を行う機械"みたいに考えてるとそうなっちゃうのかもだけど。それはそこの文化次第か。
356:デフォルトの名無しさん
14/05/19 20:50:20.38 xlvr7GFL
ドキュメントに決まったタイトルがあるならTitleプロパティだよぬ
プロパティのない言語ならgetとかつけるんだろうけど
357:デフォルトの名無しさん
14/05/20 09:55:56.84 FWxzHtTB
数値が指定した最小値、最大値の範囲に収まるかを調べるメソッド名は何がいいですか？
358:デフォルトの名無しさん
14/05/20 12:01:55.30 94D84veD
そんなメソッドいるのか？
359:デフォルトの名無しさん
14/05/20 13:23:52.03 V4tAqkoY
欲しいと思う時はあるな
[x, y]にするか[x, y)か(x, y)かで悩み、
結局直接書いて終わる
360:デフォルトの名無しさん
14/05/20 14:00:18.56 8WR+pTUq
アルファベットって64文字くらいあれば単語とか短くなってすげぇ便利だったのにね
どうでもいいけど、最近自分専用のスクリプトだと漢字を使うことがある
ここ数年UTF脳になってきたのか気にならなくなってきたと言うか、漢字が美しいと思うようになってきた
プログラムでも(簡単に出来る場合は)わざわざデータ名を漢字で扱えるように工夫してみたり。
10年前なら批判の雨嵐で、20年前なら「？？？」みたいな反応されて、
今なら、やや変な目で見られるくらい
361:デフォルトの名無しさん
14/05/20 14:17:57.85 EzdvYWDi
>>359
閉区間限定なら、ContainsとかClampといったメソッドを持つClosedIntervalみたいなクラスを
作るのも場合によっては有用かも、というか昔やったことがある。
362:デフォルトの名無しさん
14/05/20 15:30:04.48 FqGwI+0M
MIN <= x <= MAX
363:デフォルトの名無しさん
14/05/20 15:33:48.41 94D84veD
MIN <= x && x <= MAX を
x >= MIN && x <= MAX て書く人キライ
364:デフォルトの名無しさん
14/05/20 17:35:33.05 7I4ys7NV
>>360
アルファベットも昔に比べて増えてるんじゃないの。これから増えるかもよ。ASCIIコードでは増えないだろうけど。
>>362
pythonか。
365:デフォルトの名無しさん
14/05/20 20:03:27.94 JHroLS6/
>>357
IsBetween
366:デフォルトの名無しさん
14/05/20 20:33:22.94 8WR+pTUq
いやA-Zまでしかないからｗ
変数や関数にも漢字使うって意味だぜ
ASCIIじゃなくていいならアラビア文字でも漢字でも象形文字でも・・・
ただしローマ字、お前だけは認めん。ASCIIでも認めん。
367:デフォルトの名無しさん
14/05/20 22:34:38.53 6ibk+cUe
>>357
within だったと思う。
in_range() もよいよね
368:デフォルトの名無しさん
14/05/20 23:54:27.03 /zZE4L8n
>>365
I prefer "InBetween"
369:デフォルトの名無しさん
14/05/21 01:49:29.39 W2g5L2xs
>>357
In( )
370:デフォルトの名無しさん
14/05/21 02:00:50.12 zRWlqSPr
IsIn
371:デフォルトの名無しさん
14/05/21 21:59:00.59 By3uWb7U
>>368
なんだその重箱は
372:デフォルトの名無しさん
14/05/21 22:08:10.70 lAoDIlqk
>>371
"is in between" （ダブルクォート付き）でググれ
373:デフォルトの名無しさん
14/05/21 22:30:49.66 By3uWb7U
>>372
だいぶ真ん中のことを指すみたいだけど
374:デフォルトの名無しさん
14/05/21 22:42:45.77 2m6TKtRx
betweenはニュアンスが違うんじゃね？
Rubyだと
Range#include?
Range#cover?
p (0.1 .. 0.2).member?(0.15) # => true
375:デフォルトの名無しさん
14/05/22 08:16:33.07 ap8tg97M
やっぱRuby は汚いな。記号系言語なくなって欲しいわ
376:デフォルトの名無しさん
14/05/22 12:24:27.70 TFAWZMIx
記号系？
377:デフォルトの名無しさん
14/05/22 15:26:41.78 /fnIWJ4j
数字があれば数字を表示したボタンを表示、0ならボタン自体表示しない、
という処理はなんという関数名がいいでしょうか？
viewHogeやshowHogeだと、0なら表示しないというニュアンスがないので間違えやすいです
378:デフォルトの名無しさん
14/05/22 15:52:34.70 W7u09vVN
>>366
昔はJとかUとかなかったって話。
379:デフォルトの名無しさん
14/05/22 18:33:47.14 ifR7mYv4
>>377
まず何言ってるのか人に伝わるような質問文を書かないと誰も回答しようがないと思うよ。
率直に言って何言ってるのかさっぱりわからん。
380:デフォルトの名無しさん
14/05/22 20:30:47.52 f9nw6pOH
ShowHogeUnlessZero
381:デフォルトの名無しさん
14/05/22 23:42:29.53 cb5GmodY
honeNonzeroButton
382:デフォルトの名無しさん
14/05/23 00:34:41.72 MmgPEE2U
>>377
Button表示とその判定を分けたらいいんでない？
ShowNumberedButtonとCanShowNumberedButton
383:デフォルトの名無しさん
14/05/23 00:41:26.11 gA8NAXmG
>>377
そんな特殊な処理に名前つけても一年もたたないうちになんだこれ？ってなると思うよ。
素直にドキュメントなりコメントちゃんと書いとけ
384:デフォルトの名無しさん
14/05/23 00:59:58.27 fx7mUsAj
>>377
showAvailableButton
385:デフォルトの名無しさん
14/05/27 00:43:40.99 +73eA8YR
自分自身の実行ファイルの情報を読み取るモジュールの名前、何がいいですか？
Windowsのwinternl.hやLinuxのlink.hをラップするやつ
386:デフォルトの名無しさん
14/05/27 01:23:52.49 8crr5LnX
ApplicationInfo
WhoAmI
387:デフォルトの名無しさん
14/05/27 11:01:18.91 MG+zHjTE
ReadMe
388:デフォルトの名無しさん
14/05/28 19:19:35.40 wWBPFMBN
>>385
Spy++
389:デフォルトの名無しさん
14/05/30 10:39:37.09 5UIEmL2b
変数名でペアで用いるもの、例えば
start/end
begin/end
width/height
top/bottom
up/down
left/right
first/last
など使うことが有りますが、単語の文字数が違うとエディタの画面で文字がずれて見づらいですよね。
なので、私は
sta/end
width/heigh
lef/rig
などと略す事が多いのですが、これは邪道ですか？