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

**デフォルトの名無しさん** · 2025/08/01(金) 07:22:13.80

うん。
やりたい事は大体ぼんやり頭に浮かぶのだけど、言語化の過程で命名が大変だよね。
むかーし『データ構造＋アルゴリズム』って勉強したけど、それを組み立てるのに良い命名が必要で。
しかも背伸びして辞書引いて馴染みない単語を使うと、後になって意味が分からないとか。
#命名なんてaaaとかで十分ってのもまた真実なんだけど、ね。

**デフォルトの名無しさん** · 2025/08/07(木) 13:13:17.48

begin/end,start/end,start/stop,push/pop,get/set,peek/poke,put/take,put/remove
さらには、remove/delete/erase/moveなど。
対象によって微妙に異なったり、プログラミングの歴史的用法があったり、
toか2かとか、forか4かとか、
to,of,in,on,at,by,whithout,except,but,not,none,nothing,null,nil,inter,inner,middle,head,tail,is,has,-ing,-s,-es
認知科学の書籍まで総動員して名前をつける。
対象との関係は認知科学だね。
たまに、フランス語系の単語が入ってくると女性・男性・中性まで考える。
可算・不可算もあるし、扱い方によって変えたり、
block,chunk,lump,cluster,blob
場合によってはクトゥルフ神話の英語版も参照して...

**デフォルトの名無しさん** · 2025/08/07(木) 13:27:55.66

ものによっては、アメリカ俗語辞典も()
ドラクエやポケモンの英語版解説書も欲しいなぁ。
業界用語もたいへんで、地域によって意味が逆だったり、現場によって異なったり。
だいたい、法令の用語に従うと現場では逆の意味で使われていたりして混乱。

**デフォルトの名無しさん** · 2025/08/14(木) 08:36:33.30

売/買を含む単語でバイと読む場合、baiとすると区別がつかない。
買が入っていても売りのことだったりする。おそらく賈と間違えたのかもしれないが、
もともと「買」で売り買いの意味で区別せずに使われていたらしい。
区別できないので賈という字が作られ、売という字になった。
baiとすべきか、読みを無視してuri/kaiにするか。読みだとしても正式な読み方と現場では違ったりする。
英語にしちゃうと理解できないやつが出てくるし。

**デフォルトの名無しさん** · 2025/08/14(木) 08:55:20.10

全部英語か、フランス語やラテン語交じりぐらいでなんとかしたいのだが、
たいていのプロジェクトではローマ字で、プロジェクトによっては訓令式だったりヘボン式だったり。
訓令式はプログラム言語と相性が悪く、ソースみても分かりにくく単純なバグをうみやすい。ヘボンのほうがマシ。
osakaかoosakaかohsakaか。地名はJRや地図などを...参照しても悩む。
calendarがcalenderになっているのはよく見かける。nagokaがnyagoyaになっているとほっこりする。

**デフォルトの名無しさん** · 2025/08/15(金) 23:27:14.33

nagoyaとnagano同じでない。名古屋と長野は同じでないから

**デフォルトの名無しさん** · 2025/08/15(金) 23:33:31.79

ヒストリカルな配列の変数名で格納するのは
CANVASという変数名のだけど、
配列は、HistCan にしようかな　それとも　CanAryかな
それとも、複数形ぽくして　HistCans にしようかな
てか複数形ぽく最後にsつけたら配列ってわかるし
CANVASの配列ならヒストリカルって憶測つくし
Cansにしよぅかな。

**デフォルトの名無しさん** · 2025/08/16(土) 13:24:25.55

nagoka -> nagoya
typoにいまごろ気づく。
直せずにそのままになっているプロジェクトも多いよねぇ。
canvas だったら canvasesでしょう。

**デフォルトの名無しさん** · 2025/08/16(土) 13:27:33.26

historyならhistriesOfCanvasかなぁ。

**デフォルトの名無しさん** · 2025/08/16(土) 13:28:59.14

histries -> histories
oが抜けた。
canvasHistsもありかな？

**デフォルトの名無しさん** · 2025/08/16(土) 13:33:16.60

ともかく、統一する。historiesOf～か、～Historiesまたは～Histsで統一だな、おれの場合は。

**デフォルトの名無しさん** · 2025/08/16(土) 16:21:32.35

whatだけじゃなくwhyからも考えたほうがいいかもしれない
例えばcanvasに対する変更をundoできるように変更履歴を配列に入れてるということならundoStack/redoStackとか

historyをhistと略したりcanvasをcanと略するのはよほどその略語が浸透してるか文字数が著しく制限されている状況以外では避けたほうがいいと思う

それとcanvas1つの履歴データということなら意味的にはcanvasHistoryのように単数形が普通じゃないだろうか？

**デフォルトの名無しさん** · 2025/08/17(日) 07:40:05.60

ああそうだね、単一の履歴配列だったらhistoryだね。ついうっかりhistoryの配列だと思ってしまった。
単なる静的データであれば、historyで複数。
単一でない一連の操作のまとまりのようなデータの集まりであればhistories。
操作の履歴か、開始から確定までの履歴かの違い。後者は確定前と確定直後のundoの動作の粒度？が異なる。
datum(単数) -> data(複数) -> datas(dataを塊としたものが複数、業界での用法)

**デフォルトの名無しさん** · 2025/08/17(日) 08:04:22.87

undo/redoは難しく、エディタで入力文字やバックスペースなどをちまちまundoされるとかったるい。
編集点が確定できれば意味のまとまりに変換できる。作業履歴はすべて残すべきか、無駄か。AIが必要なのか？

**デフォルトの名無しさん** · 2025/11/13(木) 20:45:05.79

英語の語順で決めた方がいい

**デフォルトの名無しさん** · 2025/11/13(木) 23:40:52.57

historyやundo/redoは目的でStackはそれを実現するための構造
>>166みたいなundoStack/redoStackが目的と構造を示しててわかりやすいと思う
CANVASをどうしてもつけたいならofCanvasを後置するのが英語っぽい
配列（Array)や複数形(s)はそぐわない
historyの複数形ってさらに解釈がややこしくなる