クラス名・変数名に迷ったら書き込むスレ。Part24
うんこ中かそうでないかを判断するための変数の名前どうしましょう?
isUnching
>>3 if(isUnching = 1){
printf("ぶりぶりぶりぶり");
}
やっとかけました!
5 :
デフォルトの名無しさん:2014/01/21(火) 11:33:49.32
ここまで自演
kakko
kokka
>>5 これどう見てもわざとだろwww
いちいい反応するとか()
日本人の精神年齢は12歳と言ったアメリカ人がいたが、うんこちんこで喜べるのは
普通はせいぜい10歳まで。
webでは、(特に2chみたいな掃き溜めでは)世の中にめったにいない少数派でも
自分と同類の趣味嗜好の同士を見つけられるが、それをもって自分が普通だと勘違いすると
どこかで痛い目見るよマジで。
つまり、特亜人の精神年齢は高くても10歳程度と
やっと次スレできたのかと思ったら文字通り糞スレだった
「**を表すステートメント」というもの表す識別子をいくつも作る必要があります。
「**」の部分が最も大事なのでここを名前に活かし、
かつステートメントであることもパッと見て分かるようにしたいです。
なので、ステートメントの略称を**に接頭するか接尾したのですが、
略称はあるでしょうか?
stm ですか?
statusなどと被りやすいので下手に略さずにstatementでいいと思う
>>14 stm が status などと被りやすい、とは?
>>13 それ以前に、もちろん一般論ではあるが、その「**を表すステートメント」であることを
本当に名前で表現する必要があるのかを再考すべきだと思うけどね。
型で表現すれば十分じゃないの?
>>16 再考した結果、このような識別子が必要だという結論に達しました。
関数名なんですけども、ゲートクラスとそれを通過する訪問者クラスがあるとします。
ゲートを訪問者が通過する時に呼ぶ関数名はどうすれば良いでしょうか?
訪問者側ならば、Visitor::Pass(Gate gate)でいいのですが、
ゲート側でPassとすると主語、目的語の順序がおかしくなるので別の名前にすべきだと考えてるのですが。。。
Passにも他動詞の意味があるからおかしいと思わんけどEnterの方がしっくり来る気もする
21 :
デフォルトの名無しさん:2014/02/01(土) 22:33:24.89
22 :
デフォルトの名無しさん:2014/02/01(土) 22:51:53.21
gate.accept(visitor) とか
23 :
デフォルトの名無しさん:2014/02/01(土) 22:54:03.78
追記: acceptは、Visitorパターンの紹介コードでよく使われている気がする。
Gate::Pass(Visitor visitor)
>>19 それだと通過後に呼ばれる関数な感じがしませんかね?
受動態って意味で過去分詞を使うのって一般的なんでしょうか?
>>20 他動詞でも主語は人じゃないですか?
>>21,22さんのどっちかを使おうと思います。
ありがとうございました。
しかし受動態で関数名書きたいとき毎回命名で悩む気がします。
英語ネイティブの人たちは悩まないんだろうか…
>>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に限らず、今時の言語の多くはこういった名前空間を扱えると思うよ
どうせ大したもの作ってないからどうでもいいんじゃない。
>>26 使用言語は Haskell で、確かにモジュールに分ければ名前空間と同じ役割はできます。
> 面倒であれば STM = Statement と省略名(シノニム)を宣言すると
> STM::Foward で参照できるようになる
それは結局のところ、「ステートメントの略称を**に接頭する」のと同じですよね。
その省略名(シノニム)として何がいいか、ということです。
> あるいは Statement 参照を多用する文脈であれば、
> include Statement と宣言すると、直接 Foward だけで参照できるようになる
その識別子を使用している部分でステートメントかどうかをパッと見て分かるようにしたい
というのが目的ですので、直接 Foward だけで参照すると意味がなくなります。
>>28 > DBとかだとStatementの略はstmtが一般的な気がする。
採用させていただきます。
アイデアや意見をくださった皆様、ありがとうございました。
>>25 Gateがpassやenterを主語にとっても全然おかしくないって。
日本語で言うと通過させるとか通すとか入れるとかそんな意味合い。
>>29 >それは結局のところ、「ステートメントの略称を**に接頭する」のと同じですよね。
いや、接頭語(prefix)であれば名前は stmt_xxxx になるし、
修飾子(modifier)であれば Stmt.xxxx になるから、
それらの違いを意識したコーディングが望ましいと考える
(些細な事柄ではあるけど、このスレだからあえて言う)
またHaskellerならば、シノニムの持つ意味(=暗喩)の重要性は
十分に理解しているはずだと思う
個人的には、モジュールやデータ型に関してはシノニムを活用すべきだけど、
関数名や変数名については、たとえ接頭語であっても省略すべきではないと考える
もしもスコープで接頭語が明解に識別できるのならば、
(省略名 stmt_xxxx ではなく)単純に xxxx と命名すればいい
それができないのならば、コード設計のどこかを誤っている
(これも些細な事柄ではあるけど、....<以下略>)
>直接 Foward だけで参照すると意味がなくなります。
>>26で「Statement 参照を多用する文脈であれば」と前提条件を書いたように、
一般には、(Ruby では include に相当する)名前空間の無条件な取り込みは
できるだけ避けるべきだね
Windowsプログラミングで、フォルダ名を文字列型などの変数で定義する場合、
PathName
FolderName
DirName
など、Path、Folder、Dirのどれを使うかでよく迷います。
どれが主流でしょうか?
>>32 俺は DirName というと、例えば "C:\Users\tomato\dressing" というパスに対して
"C:\Users" の部分を意味すると捉えてしまうが・・・
フォルダそのものの名前ということなら、FolderName が普通だと思う。
それはそうと、余計なお世話なのは承知しているが、
主流かどうかで名前を決めるのは本末転倒だと思うぞ。
34 :
33:2014/02/04(火) 20:02:31.24
>>32 失礼、間違えた
俺は DirName というと、例えば "C:\Users\tomato\dressing" というパスに対して
"C:\Users\tomato" の部分を意味すると捉えてしまうが・・・
>>34 なるほど。確かにそうですね。では、DirNameは使わないようにして、
PathNameかFolderNameにします。
>>32 今時のファイルシステムの大半は階層構造になっていて、
そのオブジェクト(=構成要素)にはディレクトリとファイルがある
で、アプリケーションがファイルシステム内のオブジェクトを見つけたい時には、
根(ルート)から下方へとファイルシステムのツリーを辿ることになる
その根から目的とするオブジェクトへの道筋をパス(=経路)と呼ぶ
つまり、オブジェクトの実体そのものに付随する名前(=ラベル、タイトル)であれば
それらはディレクトリ名(DirName)またはファイル名(FileName)になるし、
それらオブジェクトを一意に識別できる情報に関する名前であれば
その名前はパス名(PathName)になる
また、ディレクトリとフォルダという名前はどちらも同じ実体を指す同義語だ
ただし、ファイルシステムに近い文脈であればディレクトリ名(DirName)、
よりユーザに近い文脈であればフォルダ名(FolderName)と使い分ける
今時のMVCアーキテクチャであれば、モデル(Model)ではディレクトリと呼び、
ビュー(View)ではフォルダと呼び、両者の仲介役であるコントローラ(Controller)では
両方の名前を文脈に応じて使い分ける、つまり混在することになるだろう
あとは、
>>32が命名に迷っている対象がどれに該当するのか、自分で判断しなさい
最後に、
>主流かどうかで名前を決めるのは本末転倒だと思うぞ。
には同感
>>35 >>34の言ってることに納得するのはどうかと面うけど...
正直俺には
>>34が何言ってるのか全然わからない。
個人的にはむしろDirectory(Name)こそ正解だと思う。
フォルダというのはファイルシステム上の概念というより、Windowsで言ったら
コントロールパネルのような仮想的な入れ物とファイルシステムのディレクトリを
透過的に扱うためのシェル上の概念だからFolderNameはちょっと不適切に思う。
PathNameは論外。
パスって、文字通り根っこから枝葉(ファイルやディレクトリ)までの「道筋」のことでしょ普通は。
枝葉のことを道筋と呼ぶのは変だ。
使用する言語のライブラリに合わせるというのがいいと思うが。
C#だと、FileInfoクラスのDirectoryNameとかあるな。
>>33 > 主流かどうかで名前を決めるのは本末転倒だと思うぞ。
フォルダとディレクトリみたいなほぼ意味的に変わらないようなものなら主流かどうかで決めるのもありだ思うが
DirName一択だろ
迷う意味がわからない
dir_fullpathとか
DirNameって同名の関数が
>>34 のような挙動になっていることが多い
そのプロジェクトで他の用語と被りそうだからとかで選ばないこともあるな。だから一択とかはないけど。
フォルダはGUIのイメージ、
ディレクトリはノード単体を扱うときにも使うイメージ、
というわけでパスに一票。
>>32 俺ならば
例えば "C:\Users\tomato\dressing" というパスに対しては AbsolutePathName
"C:\Users\tomato" の部分を意味するものとしては ParentPath
"dressing" の部分を意味するものとしては、どこかの ParentPath からみた
相対位置という意味で OffsetPathName
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
>>44 他はいいとしてOffsetはない。Relativeだろ
>>47 スマンm(_ _)m
マジで間違えてた RelativePathName が正解だな
>>45 一番上のでいいだろ
ディレクトリ名がgccであれば、その中はgccに関する何かが入っているに決まってる
for とか on とか、アホかと思うぞ
>>48 gとlとvの間に他のファイルが大量に挟まるのやだなあ
前置詞が付いてたらエクスプローラー上で並ぶなあ、と
>>49 そういう大切な「名付ける意図や求める効果」をなぜ最初に言わない?
俺の
>>48 のレスが完全に的外れじゃないか。
で、本題だが
それでも俺は個人的には for_ や on_ なんて接頭辞は付けたくないな。
ディレクトリというものの役割から考えて、
あらゆるディレクトリが for_ や on_ なのは当たり前だから。
今回の場合、俺なら gcc、llvm、vc というディレクトリ共通の親ディレクトリを作る
つまり ???/gcc、???/llvm、???/vc
その親ディレクトリをどう名付けるかは、gcc や llvm などの中身による。
コンパイル結果のみ入れるのなら build、配布する最終結果のみ入れるなら dist、
ソースファイルのみ入れるのなら src・・・など。
>>50 ごめんごめん、そこまで重視することか自分でも疑問だったので、真っ白な意見を聞きたかった。
あと当然だけど、「gとlとvの間にあるその他のファイル」も同種(srcやbuildに該当する)ので
親ディレクトリを作るならcompiler-dependedとかそういう意味の単語かなあ
ありがとう
Guidをランダムに生成してアプリ内で重複しなければそのまま返す
重複してるならリトライを繰り返して重複しなくなったらそれを返す
最大試行回数を超えたら例外を投げる
この例外の名前はなにがいいと思いますか?
ちなみに.NETで開発しているので標準にドンピシャな例外があればそれがベストなのですが…
DamePoNoLongerException
そもそも例外クラスの名前というのは、"***Exception" に統一すべきなんだろうか。
"***" には「〜ができなかった、〜に失敗した」の「〜」を表す名前がいいのか、
「できなかった」「失敗した」という意味も表した方がいいのか。
例外が発生した「理由」を名前に込めるべきなのか。
なかなか迷うな。
>>53 の場合、俺なら GiveupFindingUniqueGuid あるいは CanNotFindUniqueGuid にしたいな
Exception を付けて長くなるのはあまり好きではない。
(まぁ一般的には Exception を付けるのが当たり前なんだろうなとは思うが)
>>53 全体的に何言ってるのかよく分からん。
ランダムに生成とか言ってる時点で既にそれGUIDとは違う何か別の物じゃん。
アプリ内でバッティングしない値を生成するってそんなに難しいか?
リトライが上限に達したら例外って、そもそもリトライが必要な処理と思えん。
努力する方向が根本的に間違ってないか?
>>53 FailureGenGUIDException
分かってるとは思うけど Gen は Generate の略な
>>55 UniqueGuidの Guid って確か Global Unique ID の略じゃなかったか?
もし俺が正しいのなら重複している部分を削って
> GiveupFindingGuid あるいは CanNotFindGuid
が妥当でないかい?
>>56 >命名規則や設計の善し悪しについて議論するのは基本的に禁止。
>>57 > UniqueGuidの Guid って確か Global Unique ID の略じゃなかったか?
確かに・・・
62 :
デフォルトの名無しさん:2014/02/09(日) 17:28:55.65
GUIDがいわゆるUUIDのMS実装のことなら、
バージョン(という名前だが生成方法)4に限れば、
乱数による生成なので、低確率で重複しうる。
バースデーパラドックスを考慮しても相当に低い確率だけど。
>>55 自分は名前空間を利用している
具体的には(Rubyで...)、トップレベルのモジュール名が M だとすれば、
その下にサブモジュール M::Exception を定義し、
このモジュールの内部で例外クラス群を定義する
例外クラスの命名は、ケースバイケースで適切だと思える具体的な名前にする
[例外クラスの例]
・M::Exception::SubclassResponsibility -- 具象クラスでメソッド未実装
・M::Exception::EmptyIdentifier -- 空の識別子
・M::Exception::CantRecognizeAsToken -- トークンとして認識できない
・M::Exception::SyntaxError -- 構文エラー
実際の参照では、EX = M::Exception とシノニム(同義語)を定義しておいて、
たとえば raise EX::SyntaxError みたいに書く
>>63 汎用的じゃない例外なんかは、普通はその例外を発生させるクラスと同じかまたは上位の
名前空間で定義したいと思うはずで、そういうのは名前空間の使い方としてどうかと思うけど。
っていうか例外クラスなんかコード中に頻出するわけじゃないんだから
名前短くしようとかケチ臭いこと考えずにベタに名前を付ければいいでしょ。
>>63 >汎用的じゃない例外なんかは、普通はその例外を発生させるクラスと同じかまたは上位の
小さなプログラムであれば、例外に関して1個の名前空間(たとえば M)ですむ
プログラムが大きくなれば、複数のサブシステムに分割して構造設計するはずだから、
各サブシステムごとに例外に関する名前空間を持てばいいだけの話
たとえば、M::Exception、N::Exception、O::Exception みたいに....
シノニムも M::EX、N::EX、O::EX と別個に定義することになる
>っていうか例外クラスなんかコード中に頻出するわけじゃないんだから
いや、実用的なプログラムを書こうとすれば、エラー検査と例外発生だらけになるよ
しかも例外の種類(例外クラス)も数多く必要になるから、クラス継承設計も大切になってくる
このあたりの感覚は、ある程度の規模(10Kstep以上)、
かつ実用的なソフトウェアの開発経験が無いと分からないかもね....
>>65 だからそういうのは名前空間の本来の使い方じゃないってば...
一般的なプログラマが名前空間に期待するものは型を意味的に分類する入れ物なんだから。
"Exception"なんてただのベースクラスの名前じゃないの。
そもそもこんな方針じゃ、プロジェクトの名前空間が階層を構成していて
各階層ごとに例外クラスを定義したいというごくありきたりのシナリオにも対応できない。
>実用的なプログラムを書こうとすれば、エラー検査と例外発生だらけになるよ
だらけかどうかは感覚の問題だと思うが、例外だらけだったらすでにそれは例外じゃなくて「普通」になってしまう。
IOのよほど低水準のライブラリでも書いてるのなら話は別だけど、
俺の個人的感覚ではそんな例外ばっかり構ってるコードこそむしろどこか設計がおかしいんじゃないのかと。
まあ繰り返しになるけど「だらけ」かどうかは感覚の問題ではあるけどね。
シナリオから外れることが例外で頻度のことを言っているわけではない。
たまにしかないから例外とかヤバイ設計だな。
Exceptionなんてドンブリ勘定な名前空間に全部突っ込むほうがよほどヤバイって。
何を言ってるんだろうね。
ついでに言わせてもらえば、「自称プロ」ほどコードの大半は例外処理だとか嘯く。
そんな馬鹿な。本当に実用的なコード書いてるんだろうかこの人。
分野によるが、ビジネス系なので大半が例外処理だ。
入門サイトなどによく書いてあるよな。
このコードでは例外処理を省略してますって。
それをコピペしてるんだろうな。こいつは。
最後に余計な一言をいう人が多すぎる
>>66 >一般的なプログラマが名前空間に期待するものは型を意味的に分類する入れ物なんだから。
そもそもの出発点からして異なっていたみたいだね
自分は「名前空間とは型を(意味的にではなく)構造的に分類する入れ物」なんだと考える
実際、Rubyでは名前空間をモジュール(module)と呼ぶし、
MLという関数型言語にいたってはストラクチャ(structure)と。まさに構造と呼んでいる
逆に、型を意味的に分類するのは部分型、つまりオブジェクト指向におけるクラス継承になる
集合論的に言えば、型とは集合であり、型の分類とは部分集合に分けることになる
ここで、もし分けた部分集合間に交わりがあれば(クラスの)複数継承になり、
交わりが無い直和分割であれば単一継承になる
>"Exception"なんてただのベースクラスの名前じゃないの。
ここも解釈が異なっているなあ
自分は、「"Exception" とは例外という概念を表す象徴的な記号(=アイコン)」だと考える
だからクラス名になるし、名前空間(=モジュール)や変数の命名にも使われる
>各階層ごとに例外クラスを定義したいというごくありきたりのシナリオにも対応できない。
階層化した名前空間ごとに例外に関する名前空間を設ければいいだけの話だよ
たとえば名前空間 M を階層化して M::M1、M::M2 と設計したのであれば、
M::M1::Exception、M::M2::Exception になる
こんな単純な話なのに、ナゼに「対応できない」と断言できてしまうのか不思議だ....
だから、最後の一言が余計なんだってば。
君にとっては単純な話かもしれんが、別の人にとっては初めての考え方・概念かもしれん。
その人が君の披露した考え方を知らず、そのため君にとっては頓珍漢な事を言って、
しかも最後に君を馬鹿にしたような事を言ったとしても、
君まで同じように相手を小馬鹿にする必要はないだろ?
余計な一言があるせいで、変な方向にヒートアップしてしまうんだよ。
もういい加減、余計な一言の応酬は止めないか?
この議論まで止めろとは言わんから
73 :
デフォルトの名無しさん:2014/02/10(月) 21:46:05.07
君みたいな人が増えるといいね
>>71 自分で書いてて苦しいと思わないの?
構造的に分類ってどういう意味だよ。
じゃああなたの言うExceptionってのは「構造」をあらわしてるの?
その構造って何よ。
> 階層化した名前空間ごとに例外に関する名前空間を設ければいいだけの話だよ
> たとえば名前空間 M を階層化して M::M1、M::M2 と設計したのであれば、
> M::M1::Exception、M::M2::Exception になる
だから何のため?
今日日何事もただでさえ複雑なのに、何のためにそんな余計な混乱材料を持ち込むの?
たった数文字名前をケチるため?
どんな本末転倒よそれ。
言っちゃ悪いけど、プログラマ1年生にありがちな倒錯だよそれ。
>>74 >構造的に分類ってどういう意味だよ。
それは「名前空間に期待するものは型を意味的に分類する入れ物」と語った
>>66が
「構造的に分類ってどういう意味だよ。」という質問にレスしてから、説明しよう
先にヒントを与えると、オブジェクト指向分析/設計の基礎概念の一つだ
>今日日何事もただでさえ複雑なのに、何のためにそんな余計な混乱材料を持ち込むの?
小さなプログラムであれば、無理に名前空間を階層化する必要は無いと思うよ
「各階層ごとに例外クラスを定義したいというごくありきたりのシナリオ」という
>>66の想定に合わせて、階層化が必要なほど大きなプログラムであれば、
こんな風に名前空間を活用すればいいんだよ、ってことを説明しているだけ
>たった数文字名前をケチるため?
はて?どこをどう読めばそんな推測に至るのか、意味不明だ....
>>63で例外クラスの命名について「適切だと思える具体的な名前にする」と
説明したのと同様に、名前空間の命名にも「(機能の)構造的な分類」に従って
適切かつ具体的な名前を選ぶべきであると考える
自己レスで
>>75を訂正、肝心なとことをミスしてた....
X: 「構造的に分類ってどういう意味だよ。」という質問にレスしてから、
O: 「意味的に分類ってどういう意味だよ。」という質問にレスしてから、
>>75 結局「構造」って何のことだか分からないね。
例外だけ"Exception"なんて妙な入れ物でネストする動機もまったく説明されてない。
何が言いたいの?
っていうか、名前をケチることが動機じゃないなら
>>65では
>>63に何が言いたかったの?
とにかく例外だけExceptionで包んで別名付けろ?
だから何故?
以下、まあたぶん理解してもらえないと思うが一応本来どうあるべきかの追加説明。
意味っていう俺の言葉遣いが気に入らないなら問題領域と言い換えてもいい。
名前空間は問題領域をコードに写像したもの。
例えばある計測器からデータを取得してグラフ表示したりログを取ったりするアプリを
作ってるとする。
この時、モデル化した計測器に関係する型を入れる名前空間は
MyCompany.SomeVendor.DeviceXs
その計測器との通信データを処理するサブシステムに関する型を入れる名前空間は
MyCompany.SomeVendor.DeviceXs.Communication
常識的なプログラマなら名前空間はこういう感じで使う。
そして、その問題領域で発生させる例外の定義は、当然同じ名前空間で行いたいと普通は思う。
こういう別け方(入れ物)を「構造」呼ぼうが何と呼ぼうが、それは自由だけど、
通常の名前空間とは別に例外だけを入れる名前空間が必要であり、
かつそれが例外クラスの名前を短くするのが動機だなんて、
こんな方針を支持するプログラマなんてまず普通じゃないよ。
失礼、
× っていうか、名前をケチることが動機じゃないなら
>>65では
>>63に何が言いたかったの?
○ っていうか、名前をケチることが動機じゃないなら
>>63では
>>55に何が言いたかったの?
Exceptionなんて名前空間を用意するくらいなら
例外を発生させるクラス::○○Exceptionを作るかなあ俺なら
逆に、1クラスで発生する例外の種類が、わざわざ括りを入れないといけないような量なら
それは多くの場合、クラスが巨大過ぎる気がする
もちろん、Rubyで言うところのErrno::E〜みたいな(例外処理ではなく一般的な意味での)例外もあるけどさ
>>77 名前空間の使い方に関しては、「機能」に着目して階層的に分割するという意味で同じだね
この「機能」という言葉を「意味」と呼ぼうが「問題領域」と言い換えてもかまわないという事にも同意する
で、
>通常の名前空間とは別に例外だけを入れる名前空間が必要であり、
>かつそれが例外クラスの名前を短くするのが動機だなんて、
どこにも必要とか ..... すべき(MUST or SHOULD)とは言っていないよ
数多くの例外クラスが必要なプログラムで、
それらを一意に識別できる適切な名前の命名に悩んでいるのならば(
>>55)、
例外クラスだけで独立した名前空間で分けるという設計方法もある(MAY)と提案しているだけ(
>>63)
計測器からのデータ収集という大きな「問題領域」があり、それがベンダやデバイスという
部分的な「問題領域」から構成されている時、それらに名前空間を与える設計手法を
>>77は選んでいる
同様に、例外も(例外扱いせずに)部分的な「問題領域」の一種であると考えて
名前空間を与えてもいいんじゃないのかな?という発想だ
理屈ばかりでは分からないと思うので、
>>63の考え方を具体的なコードで示す
http://www.h6.dion.ne.jp/~machan/misc/exception.html これは、作りかけの小さな言語処理系から、例外に関するページだけを抜き出したもの
[機能の構造に関する分類(=モジュール構造)]
・トップレベルに構文という問題領域に対応した Syntax という名前空間(=モジュール)がある
・その下に「例外」という部分的な問題領域に対応した Syntax::Exception という名前空間を設けた
・更に、「(例外に関する)抽象クラス」に対応した Syntax::Exception::Abstraction という名前空間も設けた
[型の階層に関する分類(=クラス階層)]
・例外という問題領域は、「予期した例外」と「予期しない例外」という2つの部分的な問題領域へ分割した
・「予期した例外」は、付随する情報、つまり属性によって更に細かな問題領域(=型 or クラス)へと分割される
・「予期した例外」とはいわゆる一般的なエラーであり、
これが発生した場合にはアプリケーションで捉えて適切なエラーメッセージを表示する
・「予期しない例外」とはいわゆるバグであり、これが発生した場合にはアプリケーションでは捉えず
処理系を異常終了させて、スタックダンプ等のデバッグ情報を得る
読んでないが、簡潔にまとめられない奴らが、良い名前を付けられるわけがない。
言えてる
言語処理系そのものや、独自のスクリプトを実装したいとか
例外処理機構の無い言語に例外的な機構を実装したいとかなら
Exceptionでグループをひとつ作るのもアリだと思うけど
一般的なプログラミングにはそぐわないと思うんだよなあ
85 :
55:2014/02/11(火) 09:22:25.06
>>82 議論してる人たちから見れば、興味がない外野は黙ってろと言いたいだろうなぁ。
>>63 の考えを簡潔にまとめたのが
>>63 の「自分は名前空間を利用している」であり、
>>71 の「名前空間とは型を(意味的にではなく)構造的に分類する入れ物」で、
君が読んでいないというのは、それに例を付けて説明した部分だろうに。
で、
>>64 の例外クラスの名前に関する考えの本質は
>>64 にもある
「例外クラスはコード中に頻出しない --> 短くしようとせずベタに名前を付ければいい」で、
名前空間に対する考え方の本質は
>>66 の「型を意味的に分類する入れ物」だろ。
あとは、これも君は読んでいないだろうが、この考え方を説明した部分だろうに。
俺は、振り返ってみると、今まで入門書や他人のソースなどを見て、
「何の考えもなしに」
>>64 のようにやってた。
あらためて考えてみると
>>63 の考え方にはナルホドと思わせられるところがある。
確かに、例外や名前空間に対するそういう捉え方・考え方もできるなと思った。
俺は両者のメリット・デメリットをまだちゃんと自分で検証しないから、意見は言えない。
が、ちょうど今趣味でそこそこの規模のアプリを作ってみようとしてたところだから、
一度
>>63 の考え方でやってみようかと思う。
もしかしたら言語によってもメリット・デメリットが変わってくるかもしれん。
ただなぁ、なんでこう煽り合うんだろう。
せっかく興味深いことを議論してるのに、大変見苦しい。
86 :
55:2014/02/11(火) 09:24:42.25
>>85 誤解を生みかねないミスをした。
誤) 俺は両者のメリット・デメリットをまだちゃんと自分で検証しないから、意見は言えない。
正) 俺は両者のメリット・デメリットをまだちゃんと自分で検証していないから、意見は言えない。
自分のブログに書いてろ
>>1 >命名規則や設計の善し悪しについて議論するのは基本的に禁止。
設計の「善し悪し」を言い合っている部分は確かにNGだろうけど
でもこういう設計(方法)があって、その場合にはこういう構造でこう名付ける案もある、
と言っている部分はスレ的にはOKじゃね
まぁ、あくまで名前を付けることが主で、その前提となる設計が従のスレにおいて、
設計の方の話がヒートアップしてるのは、馬鹿かこいつら、って思うが
今北産業
伸びてるな
>>88 支持
名前空間を機能分けにするか役割分けにするかの「是非」はどうでもいいな
そういう多面的な観点を、根拠の一つとして提示して、こんな名前付けもできるね、っていう話なら建設的だよね
これが会話なら流動的になっても致し方無い部分もあるけれど
ワンクッション置いた文章のやり取りなのだから
簡潔に主張したいことだけ書いて相手の反論にいちいち反応するなと言いたい
議論は解決の糸口を見つける方法であって、一連のやり取りは議論じゃなく単なる主張のし合いってだけ
両者の主張に答えを出す必要性すら無い
オレならNamespaceにExceptionは使わない
Usingを使ってNamespaceと切り離して使われる場合があるから
やっと収束したな
大元の話は
>>53 なんよね
GUIDの生成に失敗するのを、何度か試行して
生成不能とみなした場合の例外だから…俺なら単に
GUID::GenerateFailed
かなぁ、「何度も繰り返した部分は無視か?」と思うかも知れんが
試行回数は投げられた例外オブジェクトの属性やメッセージに書いとく
だから、
>>53についてはそもそもリトライするようなコードが間違ってるわけで、
そんなものはリトライなんか必要がないアルゴリズムに置き換えるべき。
その実装が技術的に困難とかコストが掛かりすぎるとかならともかく、バッティングしない
IDを発行することのどこが難しいのか。
プログラミングは実用技術なんだから、実用上価値がない方向の工夫を重ねても何の意味もない。
96 :
デフォルトの名無しさん:2014/02/11(火) 16:45:45.50
>かなぁ、「何度も繰り返した部分は無視か?」と思うかも知れんが
>試行回数は投げられた例外オブジェクトの属性やメッセージに書いとく
例外発生に関する情報をオブジェクトに持たせる、
というところは同意する
ところで
>>53は逃亡したようだな
>>94 でも実装そのものを変える話になると、もうこのスレの範疇じゃないからな
>>94 > プログラミングは実用技術なんだから、実用上価値がない方向の工夫を重ねても何の意味もない。
中身のないお前のレスの方が意味ないわ (w
>>96 横道にそれてどうでもいいバトルが始まってたら、俺が53でもブラウザ閉じる
>>99 そういう言い草頭悪いと思うよ。
ウンコ蝿がウンコのまわりを周回しながら「ウンコ臭え」って文句言ってるのと同じ。
お前はウンコ周回しならが何言ってんだ。
馬鹿じゃないの。
2chのスレ追跡のプログラミングしてるんだけど、
基地外を発見したとき、そいつをマーキングして追跡したいんだけど
どういう名前にしたらいい?
103 :
デフォルトの名無しさん:2014/02/11(火) 19:29:38.60
unko
104 :
デフォルトの名無しさん:2014/02/11(火) 19:37:44.91
S_Talker
>>102 何に対する名前を訊いているのか曖昧だな
スレタイは確か:
基地外名・プログラム名に迷ったら書き込むスレ。Part24
だったはずだよな?
>>102 自警団でいいじゃん
英訳しなくていい
その方がモチベーションも維持できる
STawk
単語Offsetを3文字に短縮したい場合、
Ofs
Ost
Off
その他
どれが良いだろう?
短縮しない
それがメモリとかの相対位置を意味するものならDifference
短縮してDiffとかにする
>>112 offsetじゃなくてindexの短縮形であるiを使う
>>112 俺も基本的には短縮しないほうがいいと思うが
敢えて3文字に短縮するなら、OST だな
ofsじゃね?いや省略しなきゃいいじゃんとは思うけど。
コーディング規約で決められてるとかじゃなければ、
offsetのままがいい。
span も4文字で済むが、
offsetの方が実態を表しているならこだわったほうがいいかもよ
ハードの世界ではaddressをadrs とか
offsetをoffsとか4文字に短縮することが多い。
そういう適当なこと言わないの。
address は addr じゃないのか?
adrわ?
C#で開発していて、今まで作ってきた自分用のクラスライブラリを
整理整頓したいのですが、最上位のNamespaceは何にすべきでしょうか?
自分の名前でしょうか?良い分類方法があれば教えてほしい。
>addressをadrs とか
Aurex の Adres と Victor の anrs 思い出した
>>123 良い分類法と言えるか自信は無いが
”自分用のクラスライブラリの最上位のNamespace”
ならば、万が一、他のライブラリと名前が衝突してしまっても
コードの一部分をツールで書き換えてしまえばいいので適当でもいいと思う。
でも一意性の確保はやはり欲しいというなら、俺は好きなフレーズの省略したものを使っている。
例えば、"mou dame po" ならば mudmpo という感じ
一応参考に挙げとくが、JAVAでは保持しているドメイン名を逆順をしたものを推奨している。
例えば、toro.2ch.net ならば net.2ch.toro という感じ
みなさんありがとうございます。
>>124,126
MSやJAVAのガイドライン大変参考になりました。とりあえずMSの方式で
やってみます。
っていうかMSのガイドラインをこれまで目を通したことがないC#の開発者って...
>>126 数字始まりだとパッケージ名に使えなくて困るよな。
なんでMSのガイドラインを見ないといけないんだ プンスカ 信者じゃねーんだ
>>131 従うかどうかは別にして、一度目を通すくらいはしておくことを勧める
だな
感情論的な文句を言う奴に限って不勉強だから困る
不勉強なだけならまだしも、オレオレルールの方が優れてるぜ的な主張始めるから手に負えない
>>128を書いたのは俺だが、そのよくわからん被害妄想もどうかと思うが。
個人的にはあんたみたいなタイプの方が手におえないよw
>>134以外で被害妄想に見えるレスが見当たりませんが…
よしやり直そうぜ
っていうかMSのガイドラインをこれまで目を通したことがないC#の開発者って...
ルーピーきもっ、まで読んだ。
こういうことをしたいクラスの名前、いいのありますか?
class X {
int value, goal;
X(int start, int goal) : value(start), goal(goal) {}
void update() {value += (goal - value) / 2} // 差の半分だけ近づく
int value() {return value}
}
143 :
141:2014/03/01(土) 17:57:35.04
アキレスの亀(笑)とかみたいな中二病な名前の方が分かりやすいと思う。
それに漠然と漸近じゃどう漸近するのか分からん
>>144 > それに漠然と漸近じゃどう漸近するのか分からん
うん、でもこの場合偶然これでちょうど良いんよ。
>>141の近づきかたは一例で、バリエーションは派生クラス名で表現したいいと思ってたから。
でも多分これ単体で十分そう。
>>141 反復的に処理するんだよね
何それ怖い、一向にゴールに辿りつけない
夢で追い掛けられて走っても全然前に進まないみたい
>>144 アキレスの亀?
意味が分からん
アキレスの亀は一度に
>>144 途中でレスしてしまった
アキレスの亀は一度に2倍ずつ前進するわけではないと思うが
>>148 それを言うなら漸近という概念も離散的なものじゃない。
対して、亀やアキレスからはボードゲーム的な動作を想像することは比較的容易。
150 :
147:2014/03/01(土) 20:08:55.61
>>149 ごめん、ちゃんと真面目な理由があってのことだったのならいいんだ
謝る
自然数を要素とする有限リストに適用し、真偽値を返す関数の名前を考えています。
この関数は、適用したリストが、1番目の要素として 1 が、2番目の要素として 2 が、・・・
n 番目の要素として n が入っている状態では真を、そうでない場合は偽を返します。
(べつに 0 から始めても何も問題ありません)
整列しているというニュアンスから aligned を考えましたが、
やや抽象的といいますか、曖昧という感じがします。
なにか良い名前はないでしょうか。
152 :
151:2014/03/01(土) 20:29:21.62
>>151 すいません、関数の定義を訂正します。
1番目の要素として 1 が、2番目の要素として 2 が、・・・
n 番目の要素として n が入っている状態とは限りませんでした。
リストに決められた順で決められた値が入っているかどうかを真偽値として返す関数です。
(どのように決められたいるかは任意です)
意図通りに並んでいるということなら arranged とか
参照するパターンや定形名があるなら arrangedAs(xx) とか
真偽値を返す関数にはhasとかisとか三単現の同士を使うって既約はわりと一般的?
155 :
151:2014/03/01(土) 20:49:16.61
>>153 ありがとうございます。
名前も短く、意味も明瞭なので採用させていただきます。
>>154 使っている人は多いですね。
そういう意味では一般的だと思います。
私はあまり使いません。
使わなくても、文脈などで十分わかる場合がほとんどなので。
私がメインで使っているのは Haskell ですが、
ライブラリドキュメントから is*** という関数名を調べると結構な数がありました。
調べて初めて気づきましたが、面白いことに、そこにあるのは「is + 名詞」ばかりで、
他言語でよくある「is + 過去分詞」は一つもありません。
私の環境にインストールされているライブラリがたまたまそのようなだけかもしれませんが。
is + 動名詞 で何かの動作中ってのもあるよね。
>>158 easing は
>>141 そのものではなく、どちらかといえば
>>141 において goal に近づく「strategy」に当てる名ではないだろうか
160 :
デフォルトの名無しさん:2014/03/02(日) 12:39:26.19
>>158 解決済みだよ
結構下がってきたから上げとく
>>158 時間の関数になってないんだからイージング関数としては使えない
>>156 その辺りは規約次第かな
限定的な意味になるならIS+名詞でも差し障りないとは思う
例えば、isLimitとかなら限界に達したかどうかなんだなって思えるし
これをまともに書いたらhasReachedLimitって長くなる
ただ、これをisLimitedにしたら違う意味になるし
その辺りよく考えないとね
頭にISを付けるのってBool値を返すための接頭辞的な使い方が最初じゃなかったっけ?
識別子に ? が使える言語が羨ましい
改行したばかりで一文字も入力されていない
=一桁目だ、ということを表す変数名はis何がいいですか?
日本語やり直して
>>165 > 一文字も入力されていない
と
> 一桁目だ、
は、全然 = じゃないんだが、どっちよ。
>>170 一桁目というのは、たぶんカーソルが(その行の)1桁目にあるという意味だと思う。
そう捉えればイコールで結べるから
俺は
>>170とは別人だが、
キャレットの後ろに文字があるケースを想像できないってどんなダメグラマだよ。
173 :
デフォルトの名無しさん:2014/03/03(月) 19:33:01.05
お前がな
C言語ではbFlagって書いてたけどC#になってisFlagって書くようになった不思議
176 :
デフォルトの名無しさん:2014/03/06(木) 01:30:18.26
users というテーブルに、指定したidが存在するかどうかを調べる関数を作っています。
英語が苦手で自信がないのですが、
$db->users->hasId( $user_id );
or
$db->users->hasUserById( $user_id );
hasId() は問題なさそうに見えるのですが、hasUserById() もどうでしょうか。
また、他に良い関数名などありますか?
contains
俺もcontainsがいいと思うが他に
searchID or searchUserID
なんかどう?
>>176 1つ目はusersリストに指定したIDがあるかどうか
2つ目はusersリストの指定したIDにユーザが登録されているかどうか
って事?
ID自体が管理する為のユーザの代替名だから
ユーザが登録済み故にIDが発行されるって設計だよね?
IDが存在するならユーザ情報も存在するって意味で
もしそうなっているなら前者で十分、後者はいらんよな
>>176 リストに対してhas〜 はないなー。そもそも
>>176 exist
idかどうかは引数でわかるだろう。
かぶってた
185 :
176:2014/03/06(木) 16:31:42.92
該当のidを持つユーザがいるかどうかを調べたい感じです。
$db->users->containId( $id );
$db->users->searchId( $id );
$db->users->existId( $id );
といったところでしょうか。
メールであれば
$db->mails->existMsgno( $msgno );
のような利用で大丈夫ですか?
>>185 引数の型とか、順番で判断すればいいだろ。
複合キーだったらexistHogeAndFooAndBarとかするつもり?
187 :
176:2014/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を持っているか、というようなニュアンスで付けました。
#間違っているかもしれないですが。。
C#ならメソッド名はFindかExistsにして、その引数にはラムダ式(デリゲート)
を取るようにするケースかね。
俺も
>>176が言うとおり、引数に「ユーザー」の型を取るわけじゃなく、
「ユーザー」の属性を取るのにメソッド名にその属性の名前がないのは変だと思う。
>>187 オーバーロードなら、searchにuser_id渡せるだろ。
まあ戻り値が条件として使えるかは、言語が不明なので何とも言えないが。
まあ、昔はそういう命名が流行ってた時期もあったようだから、いいんじゃない。とりあえず全部入れとけというような名前とか見かけるし。
190 :
176:2014/03/07(金) 00:38:02.69
言語はphpです。
ContainsId( $user_id )
にしました。
ありがとうございました。
lookup を忘れてあげないで
スタック式のカスタムアロケーターの名前なんだけど、名前被りにより「Stack_Allocator」が使えない
Mark_And_Release_AllocatorとRegion_Allocatorのどっちが好き?
templateにせんのか?
C++じゃないんで
My_Stack_Allocator
Stack_Broker
正規表現のRegex風にS式のS-Expressionのクラスの名前教えてください
200 :
デフォルトの名無しさん:2014/04/14(月) 22:42:01.64 ID: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);
数値が、最小値、最大値からはみ出していたらその大きさに丸めて、
範囲内だったらそのまま返す関数って、どういう名前がいいですか?
clamp
>>200 似たような関数作ったことある
その時はRangeってしたわ
>>200 シェーダ言語とかではよくclampって関数名で定義されてるね
ensureRange
>>206 似てるけど、今回のはそれ自体に演算機能は持たないんじゃね?
>>200 もうこのスレでも何度も出てるお題。
clampで決まりでしょ
clipも似たような状況で使われるけど、微妙に違いがわからない
cropも仲間入りだ
cropは見たこと無いな。
どういう意味合いで使われてんのん?
clampは弾圧し、制限する
clipは必要な部分を切り抜く
cropは不要な部分を切り落とす
clipとcropはやることは似てるけど、注目してる対象が真逆なんじゃね
それはどうかねw
用例を見てみるとどちらも目的語に取る単語は変わらないようだが
clipやcropだと、指定範囲に入ってなければ削除されちゃうイメージなのか
clampは万力で挟み込むイメージ
うまく説明できないんですけど、いくつかのincludeされるファイル(仮にA〜K)があって、
もちろんそれらをincludeするファイル(仮にX)があるんです。この時、A〜KからみたXを
なんて呼べば(なんて変数名/定数名にすれば)いいのかわからないのです。
今のところ
top
master
parent
が思い浮かんだのですが。。。
流れぶった切ってすいません。ちなみに私はclamp派です。
統括することによって発現する機能は何?
ちょっと言葉が足りませんでした。A〜K、Xはソースコードで、A〜Kはライブラリです。
現在タブ型エディタからコンパイルなどを行おうとしています。編集中のソースコードを
コンパイルする機能までは実装できたのですが、この方法だとコンパイルの際に毎回Xに
移動しなければならず、煩雑に思っています。ですのでコンパイルを行うファイル(X)を
A〜Kにコメントのような形で指定できれば楽かなあと考えたのですが、丁度いい名前が
うまく思い浮かばなかったのです。考えているソースのイメージはこのような感じです。
#master X
/*A〜Kなど個々の処理*/
>>221 makeコマンド使えよ。設計が悪……げふんげふん
俺ならentrypointにする。
IDEだと、メニューに「コンパイル」と「ビルド」の項目があったりする。
(何と何をどうビルドするかは、プロジェクトなどと呼ばれる別の部分に書いてあるわけだが)
ところでライブラリって言うからには、Xに限らずYとかZからも
同様に使われるんじゃないの?
「コンパイル」という概念だけで管理したかったら、
「Xのタブ」に"masterFile" みたいな属性つけてみれば?
#俺はこういう方式でビルドを管理することに違和感があるけど
# (要は
>>222の一行目と同意見)
224 :
219:2014/04/20(日) 13:08:45.17 ID:lQVYmlUh
すいません、インタプリタ言語なのでコンパイルではなく実行でした。。。
言葉を間違えてしまってごめんなさい。自分の誤用がうんだのだと思いますが、
makeはどうやらコンパイラ型言語用っぽいので、使えなさそうです。
>>222 >>223 IDEにしてプロジェクトを作成するようにすることも考えたのですが、
なにかちょっとしたコードを書くだけですぐに実行できる手軽さが
長所なので、プロジェクトを作成・管理する方式にするのはなるべく
避けたいと思っています。
ですがIDEにしないとなると
>>221のように面倒になるので、
ソースコード中にXを指定できればいいなと思ったのです。
entrypointとmasterFileですか。考えます。
>>224 もう使用言語書いちゃった方が早いんじゃないの?
スレ違いなら該当スレに誘導もできるし
>>224 結局、個々のファイルにプロジェクト情報を埋め込むことになってるけどな。
#entrypoint
#entry
#start
#run
>>219の言ってることはさっぱり理解できんな。
依存される(インクルードされる)側のコードから依存する側が分かるようにしたいって
そんな情況ありえない。
依存関係は一方通行にしろって基本中の基本だろ。
228 :
219:2014/04/20(日) 16:59:01.63 ID:lQVYmlUh
ああそうか、やっと
>>223の言っていることが理解できた。
他の(X以外の)ファイルからもincludeされている場合が
あるのか。だから、依存関係は一方通行にするんですね。
もともと大規模な開発には向いていないし、色々使われる
ようなファイルにはそんな頻繁に変更を加えないだろうし
大丈夫、などといった考えはさすがに甘いですかね。。。
(例えばCのstdio.cはまず編集しないだろうという考え)
複数のファイルから依存されるファイルでの指定はどんな
感じにすればいいんでしょうか。依存するファイルを全て
書いてもらい、その中で最も新しく編集・実行されたもの
にすればいいんでしょうか。
>>226 そうなっちゃいますけど、
複数ファイルを編集しての開発の数<<<<1ファイルのみの編集での開発の数
なので、今のところは仕方ないで済ませるしかないかなあと。
「必要とされている」に着目するなら
#required_by
#used_by
#prerequisite_of
「アイツにはincludeされてもいいけど、アイツにはincludeされたくない」っていうアクセスコントロールは
まあアリなんじゃねーの。新しい可能性は感じる。
その場合はサーバの設定みたく
#allow
#deny
みたいな名前を推すね。
SQLクエリ作って実行して結果セットを返すだけの関数がたくさんあるのだけど名前の付け方になやむ
きっちり名前つけたらめちゃ長くなるし短くしたら意味わからんくなる
ビジネスロジック次第でどんどん増えてくるし名前考えるのが間に合わないよ
ここは愚痴を言うスレじゃありませんよ
>>230 クラスにして、longNameやdescriptionって属性付ければいい。
f001_0001
あるデザパタに則ったクラスを作った時、そのクラス名にデザパタ名って入れてる?
>>235 入れないかな
入れる必要性ってあるかなあ
○○Factoryはアリだけど
××Compositeは無いわ
Bridge Adaptor 入れるやつもけっこありそうだが
239 :
219:2014/04/22(火) 23:28:59.39 ID:0+lCOfH1
皆様ありがとうございました。
とりあえず、#entrypointあたりを考えてみます。
240 :
デフォルトの名無しさん:2014/04/24(木) 22:39:36.55 ID:kRu8Dwzx
ブログのエントリ作成ページを表示するメソッド名で悩んでいます。
show_entry_create_page()ではおかしいと思うので
いい名前があれば教えていただけないでしょうか
showPage2CreateEntry
「2」で分けてるところがポイント
PageCreateView.show
>>240 背景情報ゼロでそれだけ言われても何を求めてるのか誰も分からないと思うが...
ShowEntryPageStub()
ShowEntryPageSkeleton()
ShowStub(KindOfPage page)
>>240ですがすみません、メソッドではなく関数でした。
投稿フォームがあるhtmlを返すだけの関数です。
>>244 なんでネームスペースなりモジュールを切らないのさ
>>245 シンプルなブログで、使っているフレームワークも
flaskというマイクロフレームワークなので必要ないかなと思いました
リスト内のあるパターンにマッチする、あるいはマッチしない要素のみを集めて別のリストにする、
いわゆるフィルター関数を作っています。
マッチする、しない、どちらの処理かはこの関数の引数で指定できるようにします。
要素ひとつに対して、パターンとマッチするなら0を、しないなら-1を返す関数は予め用意されています。
あとはリストをたどってフィルターする関数を作るだけですが、
質問は上記の役割の引数の名前をどうするかです。
filter関数の定義 (List list, int <引数>) {
foreach (list の各要素 e について) {
if (match (pattern, e) == <引数>) then 別のリストに加える
}}
249 :
デフォルトの名無しさん:2014/04/27(日) 13:32:30.32 ID:MXG/a/88
引数は
マッチさせたいパターンではなく
マッチしたものを集めるのか、マッチしないものを集めるか、の真偽値?
それにしては実装の条件判定が変な気が。
>>247 condition
pattern
isComplement (補集合が欲しい場合はtrueにする)
>>250に同意
filterMatched()
filterUnmatched()
ご意見ありがとうございます。
別関数にすると、真偽判定が逆なだけの、ほぼ同じ関数ができます。
filterMached (List list) {
foreach (list の各要素 e について) {
if (match (pattern, e) == 0) then 別のリストに加える
}}
filterUnmached (List list) {
foreach (list の各要素 e について) {
if (match (pattern, e) == -1) then 別のリストに加える
}}
これは、似たようなルーチンをコピペで作ることによって
バグが入り込みやすくなるのと同じ問題を抱える危険性はないでしょうか?
それとも、この程度は心配に及ばないでしょうか?
パターンをハードコードするか、引数で渡すかは、
今回の質問とは直接関係はないと判断しました。
実際は引数で渡しますが、疑似コードからは省きました。
filterUnmatchedはfilterMatchedを使って実装する
>>253 別関数にして内部で共通のprivateな関数を呼ばせればいい
result = filter(list, MATCHED);
result = filter(list, UNMATCHED);
自分の場合こういうのはだいたいmodeにしてる
複雑化の予感がするので、なるべくmodeという言葉は避けている。
>>253 今時そういう処理は、要素を評価してboolを返す処理(いわゆる術語ってやつ)
そのものを外から引数で与えるのが普通だと思うけどね。
そうすればフィルター関数そのものは1つで済む。
List FilterList(List list, IPredicate pred){...}
>>259 predicateを渡せるようにするにしろ、selectとfilterは切り替えられた方が楽じゃない?
>>260 言いたいことがよく分からないけど、
>>250みたいに
(1) 条件に一致するものをピックアップする関数
(2) 条件に一致しないものをピックアップする関数
の2つが必要ってこと?
だとしたらそんなの無駄だよ。
それは単にIPredicateの中のboolを返すメソッドの返り値を反転するだけで実現できるんだから。
>>261 predicateの返り値を論理反転するの面倒じゃね?
unary_negateを使いやすいと思うかどうかって話になるのかな。
俺はアレ使い辛いと思うんだが。
match関数は0か-1しか返さず、それに基づいてフィルターすることしかやっていません。
作っているアプリ全体を通しても、今のところ、将来述語を引数で渡す需要は予定されていないのですが、
万が一のために、今のうちに述語を引数で渡すようにリファクタリングしておくべきでしょうか。
そうすれば、名前に悩む必要もなくなると?
mode は簡潔で魅力的だと思いました。
ここまで案が出ているなら
仕様と照らし合わせながら好みの方法を取ればいいじゃない
自分なら
>>259と同じ方法を取るかな
filter(List list, IPredicate pred) {
foreach (list の各要素 e について) {
if (pred(e)) then 別のリストに加える
}}
predの戻り値はbool値
match (pattern, e) == -1
や
match (pattern, e) == 0
を返す
これならフィルタリング関数を使う側がパターンを指定できるし
真偽判定を操作できる
分かりました。
mode を採用させていただきます。
ありがとうございました。
カリー化勉強しろ
レス番、名前、書き込み日時、id、書き込み内容を持つResponseクラスがあったとして、
htmlからResponseオブジェクトにする関数はどんな名前がいいでしょうか?
mapじゃ変ですよね
Deserialize
getResponse(html)
まさか生のhtml解析するところから全部やるのか?w
Parse()に一票。
入力をテキストファイルに限定しない、例えばDBからの入力なども含むなら GetResponse() でもいいかなあ。
俺もparseに一票
生のhtmlを直接「解析」した結果が特定のデータ型ってかなり違和感あると思うんだけどね
いわゆるレス、なんだからresponseとか一般的な名前使っちゃうのは大盤振る舞いすぎると思う。
ResuでいいんだよResuで。
List reslist = Resu.createResuList(html)
Resu r270 = reslist.get(270 - 1)
こんな感じにとどめとくのが一番素直じゃね?
>>270 > Responseオブジェクトにする
Response のコンストラクタじゃダメなの?
いまどき言語ならリフレクションが使えるからそもそも車輪の再発明かもしれんし
どういう目的でhtmlなんて解析したいのかによるな
>>274 html(文字列?)を入力にして、それぞれの要素を取り出して返すならそうなるだろ
アホか
>>280 >>270を素直に読めば、掲示板のブラウザを開発していると想定するのが、
自然な解釈ではないかと思う
つまり、
「2ch.netなどの掲示板サイトからHTTPなどの手段で
あるスレッドのHTML形式(文字列型)データがすでに取得されている」
ここまでが質問(
>>270)の想定になる
283 :
デフォルトの名無しさん:2014/05/01(木) 14:42:17.70 ID:uU7/MEkt
結局 tmp
>>281 お前の使ってる言語に、HTMLパーサはないのか?
>>282の想定が正しいと仮定し、さらに
>>270の質問を要求仕様としてじっくり検討してみると
仕様そのものに曖昧さ/矛盾がみえてくる
具体的には、
>>270には「htmlからResponseオブジェクトにする関数」と
あるけれど、
>>282で書いたように取得したHTMLデータとはスレを表す
そしてスレは複数のレスの反復から構成されるわけだから、
論理的にHTMLからレスへの関数は存在しえない
この矛盾は
>>270が作ろうとする仕様に応じて、以下のいずれかになるだろう
(1) 実は「HTMLからスレを得る関数」が欲しかった
(2) 実は「HTMLからレスの集合オブジェクトを得る関数」が欲しかった
(3) その他
これらのどれが正しいかは
>>270本人しか分からないわけで、
それが決まらなければ適切な命名はできない
>>286 「複数のレス」なんて拡大解釈もいいとこだろ
ついでに、専ブラのスレ一覧で1日とか1時間あたりのレス数を表示するものありますよね。勢いとか呼ばれたり。この英語名をお願いします
ikioi
わりとマジ
PPD、PostsPerDay
trend
momentum
JavaScriptで矩形を扱ってます
左上、右上
左下、右下
に対応する変数名なんですが、慣例みたいなものがあれば教えてほしいです
>>293 慣例かどうか知らんけど、単純に
topLeft、topRight
bottomLeft, bottomRight
で良いと思うがなあ
295 :
デフォルトの名無しさん:2014/05/04(日) 15:38:30.98 ID:Fi2TCAxj
上下は top/bottom のかわりに upper/lower を使うのも見たことある。
方角使ったの見たことあるな。
左上はnwとか、右下がseとか。
ただ、評判は悪い方が多かったな。
まあ、左上、右下とかで十分なところに、北西とか南東とか言っても分かりやすくはならないからなぁ
タブレットみたいに画面が回転するデバイスであれば、
絶対的な東西南北と相対的な上下左右という
二種類の命名を意識して使い分ける必要があると思う
ただし、一般的なJSプログラミングであれば
>>294で十分
299 :
293:2014/05/04(日) 18:18:25.80 ID:Qr2Jhwpy
みなさんありがとう
半径rみたいに決まった文字とかあるかと思ったんですが、特に無さそうなんで
>>294使わせてもらいます
十分に狭い範囲でなら、t/b/l/rくらいだと説明なしに出てくるかもなー
ビットマップの中の1の数を数えるメソッド、0を数えるそれを教えてください。
count_ones
count_zeros
関数での計算結果はcomputationって単語使うのが適切ですか?
もっと適切な名前はありますか
>>303 とりあえずvalue
何の計算結果か特定できるなら、それとわかる名前がいい。
result
var result = ...;
return result;ってやりがちな俺
result 最終状態。〜その結果として。結果が…となる。
>>305 適切っぽい。ありがとう
308 :
デフォルトの名無しさん:2014/05/07(水) 00:46:45.31 ID:ww08WxpS
>>307 で、数か月後に自分のコード見て「結果って何の結果だよ(ムキー」ってなるの巻。
>>304の言うとおり、戻り値を受ける側の変数の名前であれば戻り値の意味の名前をつける方が
適切だと思うけど。
値を返す側で戻り値を入れる変数の名前であればretとかで十分。
>>306 >>308 その用途ならrvをよく使うわ。retってのはどうもこそばゆい
Return Value の略なのか Value of Result なのか知らんけど
int rv = ...;
return rv;
>>308 これから戻す値にresultを使うのはDelphi流じゃね?
あの言語はresultに代入した値が返される仕様だし
関数内の戻り値ならResult
単純な同じ種類の数値の合計とかならSumとかTotalとか
関数から受け取る値ならその値の意味する名前
>>308 ならんだろ、なんの結果かわからんようになりそうなら関数仕様なりコメントなり入れるし
ついでなんでコストの日本語教えてくれー
意味的には「いちいちかかる費用」みたいな感じ
overhead か
cost
RunningCost
318 :
デフォルトの名無しさん:2014/05/07(水) 08:49:54.47 ID:lc26ma19
日本語か…
もちょっと文脈が欲しい
うろ覚えだけど、リーダブルコード的には、retだのretvalだのは避けろって書いてなかったっけ?
関数名と同じでint mainを作ったらwarning: 'main' is usually a function [-Wmain]だって。
え?
シェルスクリプト向けなどで結果は返すぞ?w
正常終了かエラーコードでなくて計算結果を?
それを置いてもmainとかで計算を行わずに、別関数にすべきだと思うが。
もっとも最初から、言語依存の予約語や制約、名前空間、コーディング規約を考慮して、"同じか似たもの"と書いてあるけどな。アンダースコアでもつけとけよ。
ちなみに自分では適切な名前毎回考えてる。VBみたいでイヤだから。
>>320 関数名から返却値の性質は自明なんだけど、スコープ終端に資源解放があって結果を保留しておかなきゃいけない場合に使う
RAIIが徹底してる言語であれば任意にreturnできるからあまりこういう変数いらないんだけどな
resultに統一だな。関数名に引きずられる名前は文脈で意味が変わって読み辛いよ
mainに限ればexitcodeでもいいが
327 :
デフォルトの名無しさん:2014/05/07(水) 17:19:05.56 ID:v8XT9GT6
>>320 リーダブルコードの例で出てくるダメなresultは、
最後が return Math.sqrt(result); になっている特殊なケース。
これは変数resultが関数の結果ではないから混乱する。
こういうケースでないならresult使ってもいいと思う。
呼び出す関数の戻り値ではなく、
自分を含むブロックを関数としたとき、その戻り値ってことなのね
booleanの変数名や関数名の接頭語にisを付ける風潮あるじゃん。
インスタンスフィールドやインスタンスメソッドになら良いと思うのだけど、
ローカル変数やstaticメンバーにまでis付いてるの見かけてキモい。
主語の無いis…
JSなら全部thisだから問題ないな!
>>329 booleanは'f'接頭辞で統一してるな。'b'でもいいけどさ
システムハンガリアンなんて糞くらえだが能動態で表現しないとどうにもならないフラグって結構あるから
is~の命名にいちいち頭悩ますのはいやだ
has使ってもいいのよ
>>315 ああ、日本語か...
連続的にかかるなら運用費用 とかかな。
スポット保守費みたいな奴なら 都度費用 とかぐらいしか思い付かん。
>>332 これから〜するぞ、っていうフラグはどういう名前つけるの?
can〜
>>327 今思い返してみたら結構そのパターンやってるわ…
>>329 その場合、第一引数が主語と考えれば良いんじゃね
>>337 そういう読む側が歩み寄らなきゃいけない名前は嫌だなー
何にでもis付けて、結局型を表してるだけのものになってしまったら、
実質システムハンガリアンみたいになってくるってのもきもいし。
isの意味はどこに行ったんだーってね
>>333 運用費か。
冷蔵庫を買うとする。寿命は10年なので、120ヶ月持つ。
原価がかかって電気代もかかってメンテナンス代もかかるとする。
全部合計して、120で割ると一ヶ月分のコストが出てくる。
これが3000円だとする。
この3000円に日本語の名前をつけないとならない。
>>335 bool addsMargin;
みたいに3単現のsつけるっていう流儀もあって結局悩むことになるんだよなあ
あー、〜ableってのは使うかも
>>339 ランニングコストとか維持費で良いんじゃないの?
月あたりコスト コスト毎月 コスト(月額)
例:20km/h -> 20km毎時
色々な金を合計してるなら、費用としか言いようがないんじゃないか?
htmlのtitleタグの中身を取得する関数名で悩んでます。
getTitle(html), extractTitle(html) とか考えたんですがしっくりきません。
いい名前はないでしょうか
html.head.title();
gettle
pick up
retrieve
find
search
lookup
new Document(html).getTitle()
関数ではないか。
メソッドを実装するクラスの役回りによって名づけ方が変わると思うんだな。
>>353 俺も思った
HTML 系のクラスじゃなかったら、getTitle だと何のタイトルを取るのか分かんないから getHtmlTitle とか
Documentのtitleだろう。
クラスを"関数を行う機械"みたいに考えてるとそうなっちゃうのかもだけど。それはそこの文化次第か。
ドキュメントに決まったタイトルがあるならTitleプロパティだよぬ
プロパティのない言語ならgetとかつけるんだろうけど
数値が指定した最小値、最大値の範囲に収まるかを調べるメソッド名は何がいいですか?
そんなメソッドいるのか?
欲しいと思う時はあるな
[x, y]にするか[x, y)か(x, y)かで悩み、
結局直接書いて終わる
アルファベットって64文字くらいあれば単語とか短くなってすげぇ便利だったのにね
どうでもいいけど、最近自分専用のスクリプトだと漢字を使うことがある
ここ数年UTF脳になってきたのか気にならなくなってきたと言うか、漢字が美しいと思うようになってきた
プログラムでも(簡単に出来る場合は)わざわざデータ名を漢字で扱えるように工夫してみたり。
10年前なら批判の雨嵐で、20年前なら「???」みたいな反応されて、
今なら、やや変な目で見られるくらい
>>359 閉区間限定なら、ContainsとかClampといったメソッドを持つClosedIntervalみたいなクラスを
作るのも場合によっては有用かも、というか昔やったことがある。
MIN <= x <= MAX
MIN <= x && x <= MAX を
x >= MIN && x <= MAX て書く人キライ
>>360 アルファベットも昔に比べて増えてるんじゃないの。これから増えるかもよ。ASCIIコードでは増えないだろうけど。
>>362 pythonか。
365 :
デフォルトの名無しさん:2014/05/20(火) 20:03:27.94 ID:JHroLS6/
いやA-Zまでしかないからw
変数や関数にも漢字使うって意味だぜ
ASCIIじゃなくていいならアラビア文字でも漢字でも象形文字でも・・・
ただしローマ字、お前だけは認めん。ASCIIでも認めん。
>>357 within だったと思う。
in_range() もよいよね
>>365 I prefer "InBetween"
IsIn
>>371 "is in between" (ダブルクォート付き)でググれ
betweenはニュアンスが違うんじゃね?
Rubyだと
Range#include?
Range#cover?
p (0.1 .. 0.2).member?(0.15) # => true
やっぱRuby は汚いな。記号系言語なくなって欲しいわ
記号系?
数字があれば数字を表示したボタンを表示、0ならボタン自体表示しない、
という処理はなんという関数名がいいでしょうか?
viewHogeやshowHogeだと、0なら表示しないというニュアンスがないので間違えやすいです
>>377 まず何言ってるのか人に伝わるような質問文を書かないと誰も回答しようがないと思うよ。
率直に言って何言ってるのかさっぱりわからん。
ShowHogeUnlessZero
honeNonzeroButton
>>377 Button表示とその判定を分けたらいいんでない?
ShowNumberedButtonとCanShowNumberedButton
>>377 そんな特殊な処理に名前つけても一年もたたないうちになんだこれ?ってなると思うよ。
素直にドキュメントなりコメントちゃんと書いとけ
>>377 showAvailableButton
自分自身の実行ファイルの情報を読み取るモジュールの名前、何がいいですか?
Windowsのwinternl.hやLinuxのlink.hをラップするやつ
ApplicationInfo
WhoAmI
ReadMe
変数名でペアで用いるもの、例えば
start/end
begin/end
width/height
top/bottom
up/down
left/right
first/last
など使うことが有りますが、単語の文字数が違うとエディタの画面で文字がずれて見づらいですよね。
なので、私は
sta/end
width/heigh
lef/rig
などと略す事が多いのですが、これは邪道ですか?
邪道というより愚か
それは変だ。
次ぎにくる演算子のインデントを合わせた方がきれい。
字数を合わせるより単語を省略しないでいてくれたほうが遥かに読みやすいだろ
あと、可変幅フォントの時代になにやってんだという感も
いや俺もコーディングは流石に固定幅でやるけど
関数内のローカル変数をhogehogeとfoo_____みたいに、削るんではなく付け足す方向で文字数調整したことはある
>>389 英語を見づらいと思うなら
日本語表記にした方が100倍マシ
C#なんかで最近見るけど、日本語変数名は和語と漢語があるあたり混沌とする
うまく使い分ければ読みやすくなりそうだけど
>>389 マジでありえん
lefとrigをLeftとRightと直ぐに理解できると思えん
揃えたい人はExcelでコーディングしてればいいよ。
クソみたいな略し方されるなら
クソ長い関数名つけてくれる方が幾分ましだ
yyyy/MM/dd HH:mm:ss
形式と
MM/dd HH:mm
形式の、それぞれの名前は何がいいでしょうか?
上はdatetimeでいいかと思うのですが下は何でしょう?
>>399 毎度のことだけど背景情報が分からないと名前なんか付けられんよ。
そもそも選択肢がそれほどにも多いから、書式を文字列で指定するんでしょ違うの?
選択肢がその2つのみならDetail/Simpleとかでいいと思うけど。
>>399 むしろ上のにdatetimeなんてメジャーな名前与えちゃうのが問題かとw
ふつうは
>>400さんみたいに、使われ方で名前つけときゃ普通は十分っしょ。
YaMaDa HaMuS 山田ハムス
MeDe HiMe めで姫
>>402 グイと言われて何だろうと悩むくらいに暗号だな。
404 :
デフォルトの名無しさん:2014/05/31(土) 20:40:58.66 ID:9VlbAaXB
>>399 FMT_yyyyMMdd_HHmmss
FMT_MMdd_HHmm
yymmddだから山田とか一番やっちゃいけないやつじゃん
>>399 フォーマットに名前ってピンと来ないけど
アメリカ表記、イギリス表記、日本表記とかあるから
それに加えて、Normal、Simpleってな感じでいいんじゃないかな?
EnglishNormalFormat
標準フォーマットとかショートフォーマットとか名前をつけとかないと、ここはこういうフォーマットでとか、なんでこことここのフォーマットは違うのとか、カオス状態になる。
まあ画面しか見ず注文つけてくるようなステークスホルダーがいるとどっちみちカオスだが。
enum FolderOrFile
{
FOLDER,
FILE,
}
ファイルやフォルダを操作するアプリで、処理の対象が今どちらか
を示す場合、どんな名前が良いでしょうか?
とりあえず考えたFolderOrFileではちょっと変だから、もう少しカッチョイイの
ありませんか?
OperationTarget なんかどうだ。
UNIX的にはこれ
enum FileType
{
DIRECTORY,
REGULARFILE,
}
>>410のいう環境に限定すれば、こうかな
enum OperationType
{
FOLDER_OPERATION,
FILE_OPERATION,
}
>>410 > 処理の対象
TargetType かな
ファイルかフォルダーの2択なら IsFolder とかにして boolean でもいいかも
この手の二択は、そのうちシンボリックリンク対応等が増えると相場が決まってるのでboolはやめとけ
増えた時に対応すればいいだけ
みなさんありがとうございました。
412さん方式で行こうかなと思います。
紙にかかれた漢字をカメラで読み取って部分ごとに分ける処理をしています。
たとえば「暗」という漢字であれば、日+立+日に分かれます。
それぞれの部分をImageにしてクラス化して動かせるようにしたいと思ってます。
クラス名と、これらの漢字を乗せるレイヤー名、この2つで悩んでます。
みなさんならどう名付けますか?
2値画像のつながった領域ごとに番号をつける処理っていうのは
古くからconnected-component labelingって呼ばれてるんだよね
ってわけで、KanjiComponent
レイヤー名ってのは意味わからんけど
英語にしたいんだろうBushuじゃださいかw
Part、Piece、Shardの語句辺りが分かりやすいんじゃないかな
レイヤー名ってのが意味分からんが
描写関連は別クラスで汎用的に実装した方がいいんじゃない?
>>422 説明抜けてました・・
iOSのアプリケーションをObjective-Cで実装しています。
Objective-Cにはレイヤの概念があって、層を積み重ねてアプリケーション画面を作っていく感じです。
今回の場合は多くの漢字オブジェクトを1枚の層の上に配置していきます。
その層の名前で悩んでいます。
それはそのアプリの用途とか、そのレイヤーが表示されるコンテキストとかにもよるでしょ。
設計にもよるし。それを知らない他人が名付けられるだろうか。
Wikipediaの合字の項から適当な用語を借用して使うとか。
合字 = ligature、合字を構成する要素は書記素 = graphemeというらしい。
漢字の概念を表現するのにわざわざ英単語もってくんなよ
まあ確かに。
Kanji, Bushuでいいような気もする。
>>419の言う「部分」が正確に部首と一致する(一致させられる)かどうかは別にして。
>>423 各部首のレイヤーを重ねるその一番下の層ってな感じ?
漢字→習字→半紙って事でWritingPaperとか?
>>428さん
WritingPaperにさせていただきます。
>>420さんや
>>422さんを参考にして
PieceOfKanjiや、ComponentOfKanjiがよいと思いました。
そこで重ねて質問なんですが、
自分は変数名やメソッドにやたらof,with,to等をつけてしまいます。
はじめて覚えた言語がObjective-Cだったので、前置詞を多く含むという特徴を真似してしまっているのかもしれません。
この癖なおしたほうがいいんですかね・・・
みなさんからみて、ComponentOfKanjiとKanjiComponentだったらどっちがわかりやすいですか?
>>429 適切に使われているなら前置詞込みでもいいんじゃないかな
ofと「の」は同じではない
hoge_123のような文字列から
末尾の数字を取り出す関数の名前は何がいいでしょうか?
suffixNumberFromString()
numberAtTheEndOfString()
>>432 だから、そんな関数は汎用的に使うライブラリの関数のわけがないんだから、
そういう関数に名前を付ける時には、数字を取り出す元の文字列がその問題領域で
何と呼ばれているかとか、末尾の数字は何を意味しているのかとか、
そういうことをベースに名前を付けるんだよ。
catchTheTailNumberIfYouCan()
>>435 横レスだけど、そのアプリケーション内で文字列がHogeName、数字がHogeIdを意味するなら
ExtractIdFromHogeNameみたいにしろってことでしょ
クラスの内部の配列のn番目にaの値を入れるメソッドの名前教えてください。
setValue: atIndex:
>>439 すみません、コロンの意味が分かりません。
どちらかの名前を使えという意味ですか?
いえ、そういう言語があるんですよw
setValueForArray(Var value, Var index)
こっちの方がいいか
setValueAtIndex(Var value, Var index)
javax.swing.table.TableModel
getValueAt(int rowIndex, int columnIndex)
setValueAt(Object aValue, int rowIndex, int columnIndex)
動作じゃなくて役目で名前付けた方がいいと思うぞ。
ではn番目の素数にaという値を与えるという役目なら
どうなりますか?
>>444 その哲学を教えてくれ。
俺の場合大体動詞になる。add〜, remove〜, close〜, update〜,,,
>>445 setPrimeAtIndex(a, n)
>>446 いや、素数はセットしないです。
セットするのは値です。
>>446 いや、動詞なのは同じだけど、何のためにクラスの内部の配列のn番目にaの値を入れるのかってこと。
って、ユーティリティやフレームワークの場合はそれ自体が役割だったりするか。
>>438 だから、そういうのはそのクラスが1次元配列をラップした単純なコレクション的な物か否かで
話がまったく違ってくる。
前者なら単純にsetAtで何を意味するか十分に分かるはず。
後者ならset○○Atとか(setKeyAtとかsetValueAtとか)でいいんじゃないか。
>>451 じゃあ、○○が1から0の間の値ならどうなりますか?
>>452 だから、名前を付ける時に一般的に重要なのは、それがどういう機能を果たすか
(1から0の間の値をとる)じゃなくて、それが何を意味しているかだってば。
生徒の成績を処理するプログラムを作ってるとして、生徒の点数を入れる変数の名前を、
あんたはそれが0から100の値をとるという機能面に注目して付けるのかよ。
普通はそんなことしないでしょ。
点数は素直に点数(score)にするのがいいに決まってる。
では点数の計算方法が
a[0]*2+a[1]*3+a[2]*5+a[3]*7・・・・
という計算式だとしましょう。
このときa[0]に0から1の値を入れる関数名をよろしくお願いします。
まともに相手して損した。
逃げるんですか?
卑怯者ですね。
こういう手合いからは逃げたほうが賢明w
それを計算してなにがしたいのかを書けよ
聞くだけ無駄だと思う
>>454 sineKitigaiMajide
俺ならこうするね
なんかワロタw
463 :
デフォルトの名無しさん:2014/06/10(火) 21:51:58.71 ID:fz5L4EFg
サーバーにJSON で↓こういうデータを送って、
"key" : [ {"tag":"aaa", "xxx":"2014-06-10 00:00:00"},
{"tag":"bbb", "xxx":"2014-06-11 12:00:00"} ]
タグが"aaa"で、作成時刻が"2014-06-10 00:00:00" 以降のデータと
タグが"bbb"で、作成時刻が"2014-06-11 12:00:00" 以降のデータを返してもらうみたいなことを
やろうと思ってるけど、更新時刻のところはどうすればいいですか?
last-update とかでおかしくないですかね。
>>464 時分秒を含んでるんだから
modified-Timeのほうが良くね?
>>463 last-modifiedか、たんにmodified
>>465 どうだろう
日付がメインだと思ったからdateにしたんだけどね
純粋に
>>466の案でいいかもね
468 :
463:2014/06/10(火) 23:37:26.03 ID:fz5L4EFg
これは一つのリソースを更新するイメージじゃなくて、どんどんデータがたまっていく
感じだから、updateとかmodifiedはちょっとニュアンスが違うかなって気がしてきた。
指定した日時以降に作成されたデータを欲しいって意味だから、afterなんとか みたいな感じかな。
単純にAfterじゃおかしいかな。
laterとかじゃね?
>>468 それなら単純にrecorded-dateとか
もっと単純にdateでいいんじゃないかな
afterでいいんじゃない?いやならlater-than
全体的によく理解できないから意図を誤解してる可能性があるが、
time index
reference time
marker time
こんなところ?
>>468 ならば
ObtainedTime
は、どうよ?
FromDateTime ではどうか
find(1)の-mtimeに合わせてmodified time。
英語を省略形にする法則ありますか?
>>476 ない。慣習がすべて。
勝手に省略したら何だこれってなるだけ。
i18nみたいな省略形すき
データを
・書き込み済
・未書き込み
の2値を表すenum名とメンバー名を考えてくれ
writing state
saving state
recording state
done
undone
complete
incomplete
>>480 data_state_t
data_written_t
WRITTEN, UNWRITTEN
「どこに」書き込むのかで別の候補もあるかも
なぜboolで済むものをわざわざenumにする。
将来2値でなくなりそうなものや意味がとりづらいものはenumで読みやすいようにするって流派がある
>>484 引数に使うときにTRUEとかFALSEじゃリーダブルじゃない
aを継承したのを
baあるいはa2
caあるいはa3
baを継承したのを
cbaあるいはb2a
dbaあるいはb3a
cbaを継承したのを
ecbaあるいはc2baあるいはc2b2a
fcbaあるいはc3baあるいはc3b2a
のように名前を付けていってるんですけどだんだん複雑になって
わけがわからなくなります。
どうしたらいいですか?
継承機能を使いすぎ
基本的に、継承を使うよりも複数のオブジェクトを組み合わる方がよい
本当にその階層が適切ならガンガンやったらいい、適切ならな
GUIなんかどんなに削っても(適切な分割のほうを優先するなら)10段ぐらいになりかねないし
で、c3b2aなんて連番な名前にせずに、そのものが表している対象の名前をズバリ付ければいいんじゃないでしょうかねえ…
どっかの国では、自分の名前に父親の系譜の名前が
5世代分くらいくっついてるんだとか。
Modelクラスを継承したクラスで
Modelクラスのsaveメソッドを持たない(例外を投げるようにオーバーライドした)クラスのいい名前ないでしょうか
>>494 UnsaveableModel
SaveNotImplementedModel
っていうか、普通名前を付ける時に重要な情報は、saveメソッドを未実装にする動機。
名前を付ける時に、普通は「○○が未実装にしました」なんてところに着目しません。
>>496 隠蔽されてるなら有りだと思う。
Model b = Models.temporary(a)
>>494 俺なら
>>496の SaveNotImplementedModel を採用するけど。
他に挙げるとすれば NotAbleToSaveModel とか、これを省略して NatsModel とか
普通は派生先でsaveを禁止するのではなくて、
saveメソッドを持たないModelが親クラス、saveメソッドを持つSavableModel(仮)が派生クラスになるのではなかろうか
>>501 どっちが普通かと言えば、そりゃその通り
メソッド持たないと言っても持っちゃってるから、実行時にエラーにするしかないし
今回のはできあいのクラスを利用したいとかのケースでしょ
503 :
デフォルトの名無しさん:2014/06/25(水) 01:11:41.87 ID:VDYG/4RF
ReadOnlyModel とかそういう話じゃなくて?
504 :
デフォルトの名無しさん:2014/06/26(木) 23:19:52.41 ID:QSlPFfCE
メモリにのみ存在しうるということなら ephemeral とか transient という形容になるのかも。
Inpersistent
volatile
うーん、イマイチ
ちょっと意味が変わってしまうけど
impermanentModelとか
状態をスイッチしてするような関数名は
enable何々
disable何々
でいいですか?
してするような→して状態を変えるような
状態の種類によるでしょ。
Start/Stop、Activate/Deactivate、Show/Hide、その他いろいろありうる。
いいですか?に対して
yesかnoか、その後豆知識的な感じで答えて欲しいんですけど…
だから良いかどうかはケースバイケースだろう、と書いてるんだけど。
日本語不自由なら最初からそう自己紹介してくれ。
yenos
>>511 ケースを書けば教えてくれるんですか?
教えてくれるというのなら書きますがどうします?
十秒後に隕石が降って来て回答できないかもしれないが、
それでもいいなら書けよ
ダメもとで書きますね。
あるものがアップデートされたか調べるメドッソがクラスにあって
あるメソッドを呼び出す前にそのメソッドを実行してから呼び出すか
呼びなさないかを決めるフラグを1にする関数と0にする関数。
enable update check
517 :
デフォルトの名無しさん:2014/06/28(土) 14:56:48.72 ID:VmKo75W/
なんかそれ、レースコンディション疑うわ。
フラグを外に見せずに、TryUpdateとかにして更新の必要ありならそのまま更新、更新不要ならfalseを返すみたいにするかなあ……
たとえば、配列の中身を連続して読みたい時
更新されてないのは分かってるわけだから
チェックを外して読み込んでチェックを戻す的なじゃね?
>>519 そういうのは更新フラグではなくLock/Unlockみたいな名前にならね?
rwlock的にBeginReading/EndReadingとBeginWriting/EndWritingを分けてもいいし
書き換え後何らかの全体をなめる処理が必要ならEndWritingでやればいいし
>>515 アップデートされたかどうか調べるメソッド、仮にIsUpdated()
あるメソッド、内部データに読み取りアクセスするメソッド、仮にRead()
あるメソッド、内部データに書き込みアクセスするメソッド、仮にWrite()
IsUpdated()をRead()メソッドが呼び出すかどうか決めるメソッド、←この名称
って感じかな?
Read()メソッドが絶えずIsUpdated()メソッドを呼び出し、内部データ1つに読み取りアクセスするとすると
更新されていないならIsUpdated()メソッド呼び出しの部分によりオーバヘッドが大きくなるってことだよね?
それなら一度だけIsUpdated()メソッドを呼び出し
連続した内部データを一度に読み出すReadAll()メソッドを設けるだけでいいんじゃないの
PlaylistクラスのListを格納しておくクラス名ってどう付けるのがいいのだろうか
PlayList自体にListが付いてるから付けづらい
>>523 何のためにPlaylistのlistが必要か、で決めればいいんじゃね?
例えば複数のPlaylistをまとめてCDに焼く機能ならCDImageのメンバーとしてPlayListのlistがある、みたいな
思いつかないならPlayListListでも特に変とは思わないけど
ListOfPlaylist
526 :
デフォルトの名無しさん:2014/06/29(日) 09:33:57.98 ID:N/G7sXy0
PlayLists
PlaylistCollection
PLayListStock
>>523 外に晒すものじゃないはずだから汎用的なListで十分のはずのように思うけど。
もちろん普通のListでは必要な機能に過不足があるのかもしれないが、
だったらそのクラスの名前は施されたカスタマイズに基づいて命名されるべき。
最近こんな質問ばっかりだけど、ひょっとして誰かわざとやってんのかこれ。
>>524-529 ツリー表示した時に
-PlayLists
-PlayList
だと見づらいし
PlayListListだと違和感があったから聞いてみた
PlayListCollectionがしっくり来たからこれにするよ
ありがとう
FuckPlayList
並べ替えした順番を格納して次回も同じ順番で表示させるために使用する変数名というかDBのフィールド名でいいものありませんか?
orderとかnumberだと依頼内容や番号を格納するフィールドとかぶってしまうので使い勝手が悪くて困ってます
>>532 sortorder, sortingorder
DisplayOrder
DBなんかまったく素人だけど、どう考えてもViewでしか使わない値をデータ本体に
持たせるって最悪のド素人設計じゃないのか。
>>534 ユーザごとのプリファレンスとして、最近どうソートしたかってのは覚えておくといいこともあるよね
社員とか支店の並びは微妙な力関係があるから単純に並び方決められないのよ
住所コード別の並びとかにすると「うちの支店が○○支店より下なのはどうなんでしょうか」とか言われたりする
結果としてなんの法則性もない昔からの並び順に合わせないといけない
>>536 それは分かるけど、表示の並び順の順位の情報は別のテーブルに持たせるべき情報じゃないのかと。
まあDB素人だからよく分からんけど。
広告の表示順番とか大事だよね
こっちの広告の表示優先順位上げてこっちは下げるみたいなことするから
そういう情報を保存することってわりとあると思うんだけど
正規化の話かw
表示順位って基本1:1の関係だから別に正規化しなくてもいいと思う
脱線して悪いから自分もDisplayOrderに1票
>>537 わざわざ別のテーブルにする意図がわからん
特定の人にとってはすごく重要な情報だし
馬鹿な企業だとステークスホルダーごとに違う順番を要求してきそうだから、案外別テーブルはいいかもしれない。
>>541 少なくとも普通のプログラミングでは、特定のViewに依存させるような馬鹿な設計はしない。
>>543 要求があればそれを実現するのが設計者と言うもの
複数の順序が要求された時に別テーブルで持つのか、順序フィールドを複数持つかは実装次第だけど、
>>543 みたいに馬鹿な設計と言うだけでなにもできないやつは不要だよ
>>544 馬鹿な上に無礼と来てるんだから救いようがないな。
まあ馬鹿ってだいたいそうだけど。
> 馬鹿と言うだけでなにもできないやつは不要だよ
>>544 あるべき論で言うなら、
要求すべきは問題の解決であり、見た目ではない。
見た目を要求するなら、依存度など副次的な問題に対する解決方法も全て提供すべき。
これだけで多くのプロジェクトが低コストで成功するのになー。
>>547 > 要求すべきは問題の解決であり、見た目ではない。
今頃何を言ってるんだよ...
>>536 すら理解してないアホは要らんよ
>>548 あるべき論の話してるのに、元の話をもってくるとか、こういう奴がいるからブラックが増えるんだな。
問題は当人が自覚してないケース。
>>549 ぼくのかんがえたさいきょうのあるべきろん w
要らんわ
お前もな〜 w
UXとしてレコードの表示順序を永続化して再現したいのなら、
レコードに表示順をフィールドとして持たせりゃいいだろう。
ユーザーが並べ替えた順序・位置を記憶しとくのは普通にありだろ。
なにを揉めてんのかw
別に揉めてないよ、ぼくのかんがえたさいきょうの設計でないとやだって、
>>543 が駄々こねてるだけ
似たような種類の変数名の付け方ってどうすればいいの?
アクションゲームとかで、
1. ステージ左上を(0,0)としたブロック単位のキャラの位置
2. ステージ左上を(0,0)としたピクセル単位のキャラの位置
3. 画面左上を(0,0)としたピクセル単位のキャラの位置
は、それぞれどんなふうにつけると良いですか?