クラス名・変数名に迷ったら書き込むスレ。Part11

(つ∀-)酔ってるからよくわかんやいや

NumericId
DigitalId

open() の wrapper で、指定のファイル名が既に存在していたら、
ファイル名に [0], [1], ... と付けて open したファイルハンドルを返す関数、
どうしましょう？

-->954
openEx

>>954
その抽象化（機能のくくりだし方）は分かりにくい。だから名前がつけられないんだよ。
まずファイル名だけを求める関数を考えるべき。
ひょっとするとマルチスレッド環境のこととか考えてのことかもしれんが、
そういうのは関数の直感性を犠牲にしてやるべきものじゃなくて別の方法を考えるべき。

でGetFreeFileNameBySuffixNumberとか

>>956言ってることは正しいがGetFreeは無いお。
openWithUniqueSuffix

>>957
確かにすまん。。

OpenFileOrAlternativeFile

なんか関数名にOrが入ってるとはっきりしろよって感じだけど
実装を表したいんならそんなんでいいのかもしれん。
けど、したい事は常にユニークなファイルを開くopenな訳で
いっそopenUniqueとかでいいのかもしれん。
はっきりしろよって感じだけど。

つーか失敗しない限り必ずファイル作るんだからCreateUniqueFileで。

既存ファイルもCreateFile関数で開かせるWinAPIを見習って、
CreateUniqueFileで良いんじゃないだろうか。

>>961
髪が肩まで伸びたら結婚しようか？

>>962
…うん。

決定だろw

C++で、色んな型の値を複数保存できるListというクラスを作りました。
JavaのArrayList<classname>みたいな感じです。

１．これの発展系で、解放されたとき、
保持している全てのポインタを同時に解放するListクラスと、

２．各要素に対応した文字列を持たせて、
その文字列をキーにして、要素を取得できるクラスを作りたいのですが、
名前を何にするか悩んでいます。

ちょっと考えたのはこんな感じ。
１．PointerList, SolidList, DeletableList
２．MappedList, IndexedList

>>966
1. smartlist
2. map

前者は要素の型がポインタである場合に対してデストラクタを特殊化、
後者は要素をstd::pairにして[]演算子をオーバーロードすれば良いと思うよ！

1.だけ。SmartPtrList。

>>968
作り方は聞いてない。再発明だとは思うが。

ポインタである場合でも、
List解放時に解放してしまうと不味いこともあるので、
使い分けたいのです。

標準ライブラリstdというのを全く知らないのですが、
話を聞くと、似たようなクラスが既にあるっぽい。
でも、もう作っちゃったから、どうせならstd無い環境でも使えるように、
自分で一から作ろうと思った次第です。

>>969
別のクラスを作る必要ないよって言いたかったんだよ。
どっちの場合も要素の方に機能をもたせればそのままListに放り込むだけなんだから

>>971
前者はそうかもしれないけど、後者は無理だろ。
operator[]はList側に付けないと。

operator[]を引数側でオーバーロードできたら面白いな。
効率悪そうだが…

スレチ

>>961-964
こんなスレで 4秒差か。 末永くお幸せに！

ああ、そういやこういう関数で作ったことあるな。
GetInexistentFileNumber()

>>961-964
なんというワロタｗ

なんか
・無駄に冗長で説明的な名前
・ネイティブな人の書くソースコードではまず見かけないような単語を含む名前
・英語の文法にばかり気を使って可読性を考えてない名前
ばっかり出てくるね、このスレ

そもそもプログラムの識別子にネイティブも何も関係ないのでは。
俺は法則性をつけて区別しやすければいいと思っているのだが

設計を直せば名前もまともになるのに、そこ指摘しないスレのルールがあるので
仕方なく、というのはあるな。

>>979同感。
名前付けが変になるときは、大抵設計が間違ってるのが原因なんだけどな。

設計がちゃんとできないレベルのプログラマなんてたくさんいるんだし、いちいち設計を指摘してたらきりがないと思うぜ。
それに設計の話をするならUMLでも書いてもらわないと、まともな議論ができないと思うが。

俺がスノッブなだけかもしれんがやっぱりengrishは避けたい。
**_checkとか、したいことは分かるんだが

だからopenExってオレがいったのに。おまえら無駄に>>977のように
変な名前つけるから。

>>982
英語と考えないほうがいい

>>967
レス遅れましたが１．はSmartListにしました。
スマートで分かりやすい素敵な名前だと思います。
ありがとうございます。
子供が生まれたら名前は素魔斗栗鼠人にしようと思いました。

>>983
CreateUniqueFileはいい名前と思う。設計は置いといて
>>984
配布用のクラスライブラリの場合はどこに出しても恥ずかしくない名前を吟味するが
アプリケーションの場合はちょっと崩れてたほうが分かりやすいこともある
まあnamespaceをつければいいんだけど。

>>977
それはむしろ君自身の「ダメプログラマ」ぶりを語ってるんだと思うよマジで。
うん分かるよ、君は「とにかく短いのが可読的だ」と思ってるんでしょ。
実際いるいるそういう奴。

酷い勘違いだと思うけどね俺は。

たとえばopenExってw

ネタで言ってるのか真面目にいってるのか判断に苦しむが、
>>954のような要求にたいしてそんなの絶対にあり得ない。

>>977
具体的にどのレス？

>>988
openEx自体は悪い名前じゃないよね。簡潔だし。
唯その場合はExに意味がある事が条件。
Open a file using Extended/Extra何々って感じで

もう一個作りたくなった時に困らない?
パラメータがいろいろ設定できていろんな動作をさせられて
それ以上関数のバリエーションを増やす必要がないんだったらopenExでいいんじゃないの

少なくともWindows環境ではOpenExは失格だろ。
通常Openの挙動を更に広範かつ詳細に指定する為にOpenExが用意される。
挙動を特殊化する為というのはありえない。
オプションのひとつとしてUNIQUEを指定できるならありはありだが。
まあ単に設計ミスで挙動を変える為だけに用意されることもあるけどな。

OpenEx2でおｋ

じゃあExいらなくね?
open1, open2, open3, ...

>>990
絶対ダメとは言わんが。。
少なくとも積極的に使いたい命名法というより、修正したくても事情があって
修正できない場合とか、多重定義が使えない環境で仕方なく使うものじゃないの？

っていうか
＞Open a file using Extended/Extra何々って感じで
そういう場合はその'Extended'の中身を名前に盛り込んでくれよw
そんなのその中身の表現を考える手間を手抜きしてるだけだろ

>>987
こうやってすぐ極論に飛ぶのが駄目なプログラマ

駄目なプログラマかどうかまでは分からんが
> 命名規則や設計の善し悪しについて議論するのは基本的に禁止。
誰か次スレよろ

ダメかどうかは別にしてExを認めたらこのスレの存在意義が問われるw

Dxでおｋ

可能な限り英文法的に正しいネーミングにしたいし
一般的な日本人には見慣れない英単語で構成されても読めないことがあるし、
名付け方にしても他と統一できていたほうがいいわけで

そこをどう妥協するかが、このスレの意義じゃないのかな

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。