長い関数名、変数名、どこまで許せる? 226
ストーリー by headless
動詞は1つだけにしてください 部門より
動詞は1つだけにしてください 部門より
insiderman 曰く、
最近久しぶりにWindows関連の案件に関わったのだが、ここ数年UNIX/Linuxばかりを触っていたので結構な違和感があった。特に気になったのが、関数名や変数名などの識別子が長くなる傾向がある点だ。たとえば「GetApplicationConfigurationString」とか、「SaveAllChangeSetToDatabase」とか、確かに分かりやすいのだがタイピングするのに指が絡まるわ!と思う識別子名が多々あった。
そもそもWindows APIには長い関数名、変数名が多く、IDEの補完機能によって長い識別子も入力しやすくなっている、という背景もあるのだろう。しかし、長い識別子名が多いと1行は78文字以内というポリシーを守るのがかなりきつい。長い識別子を許した方が分かりやすいかもしれないが、それでコードが見づらくなるのは個人的にはちょっと避けたいところである。
/.J読者でプログラミングに関わっている人は多いかと思うが、実際設計段階で識別子の長さについて意識している人はどのくらいいるのだろうか。そして、どのくらいの長さまでは許せるだろうか。
開発環境が優秀なので (スコア:5, 興味深い)
30文字ぐらいは全然きになりませんな
変に省略されて意味わからないよりは全然マシ
1行78文字ポリシーを辞めたほうがいいんじゃないですかね
今時固定幅画面でもないでしょうし
Re:開発環境が優秀なので (スコア:5, 興味深い)
名前を省略させないことを優先させて1行78文字ポリシーを捨てたクチです。
しばらくは両立させようとしていましたが、「変数名1->メンバ名 = 変数名2->メソッド(引数1, 引数2);」としただけで78文字を超えたのを見て、78文字ルールは守り切れないと悟りました。
同一関数内でstという省略がstaticとstatisticとstatusの3種類を表している(*)のを見て頭を抱えた経験もあり、ローカル変数なども極力省略は控えるようにしたり、それを布教したりしています。
(*)それぞれ別人が異なる時期にメンテした結果そうなったらしい。
ただ、際限なく長くしても見辛いので、78文字に代わる新たな目安をどうするかに悩んでいます。
今は気分次第で適当に。
巧妙に潜伏したバグは心霊現象と区別が付かない。
Re:開発環境が優秀なので (スコア:3, 興味深い)
自分は最近は 120文字の118文字折り返し(縦は45行)でやっています。
1024x768 なモニタで Teraterm 利用時に 11pt 表示でも 1画面内に収まるというのが理由です。
ノートでのソースの編集は最小限しかしないけど、俯瞰時に折り返しが発生して欲しくないので、
デスクトップよりはノートの現状の制限に合わせています。
Re:開発環境が優秀なので (スコア:2)
それって、後から変更した人が、 st がコード内で既に別の意味で使われていることに気付いていなかったってことだよね。
その状況を改善するのに、略語を避けるのは多少有効かもしれないけれど、本質的な解決方法は「保守するコードは書き換える前にちゃんと読む」って以外ないんじゃなかろうか。略語を避けても「こっちの行で status と呼んでいるものとこっちの行で status と呼んでいるものは全然意味が違う」というような同種の現象は起こりうるわけで。
べつに static 等の英単語を st と略すのが良いとは思わないけど、なんか略語が悪の根源みたいに言われると、それは違うんじゃね、と思った。
Re:開発環境が優秀なので (スコア:5, 参考になる)
EclipseやVisual Studioなんかだと、キャメルケースで補完できますからね。
GetApplicationConfigurationString→SACS
SaveAllChangeSetToDatabase→SACSTD
見たいな感じで。
意外と知らない人もいるみたいですが、タイピングのリズムもいいし、好きな機能です。
Re:開発環境が優秀なので (スコア:3, 参考になる)
> 大文字で打ったらそうなるんですか?
Eclipseではキャメルケースマッチングとか言われてる機能です。
単語の区切りの先頭文字から補完してくれます。
[N]→[P]→[E]→[Ctrl]+[Space]
↓
NullPointerException
エディタだけでなく、型検索のダイアログとかでも使えるので便利です。
Visual Studioでは確か2010でEclipseからパクってきてます。
Re:開発環境が優秀なので (スコア:3, 興味深い)
Re:開発環境が優秀なので (スコア:2)
80カラム制限を疑うほうが先 (スコア:1)
きわめて同感。
APIが出てくるところはそもそも多いとは言えないし、関数名短くするためにどのように省略するかとか規則を決めたりとかのほうがイライラするんじゃないかと思う。
いまどき80カラムである必然性は少ない様に思う。C++とかだとAPI関係なく80なんてきつすぎだと思う。
結局のところ自分が慣れたやり方が一番で、違うものと接すると自己防衛が働いて排斥したくなるってことじゃないのかな。
Re:開発環境が優秀なので (スコア:2)
統合開発環境というのをほとんど使わないのは同じくなんですが、天下のMS様がショートカットキーを用意していないとは思えないんですが…ないんですかね…
(78文字制限は今時時代遅れだとは思うけど。Xでも80文字幅でわざわざtty開いたりしてないし)
Re:開発環境が優秀なので (スコア:1)
VisualStudioならかなりの部分をカスタマイズできるよ。
emacs風なら結構簡単にできたと思う。
最近使ってないけど、C-x C-fとか2段階はできたはず。
C-x r cみたいなのはどうだったかな。俺は窓使いの憂鬱と組み合わせてやってた様な気がする。
Re:開発環境が優秀なので (スコア:1)
そもそも標準でemacsキーバインドのせっていができます(2008まで)
2010でもキー設定ファイルが開発ブログで配布されていたかと。
eclipseのemacsバインドなんかよりよほどできがいいです。
Re:MS環境のカスタマイズ(オフトピ) (スコア:2)
VSは知らないですがMS-IMEなら、私はレジストリの設定をコピーして
あちこちの端末で共有してますよ。
HKEY_CURRENT_USER\Software\Microsoft\IMEJP\10.0\ 以下に
設定とか全部入っていたと思います。(10.0の部分はMS-IMEのバージョンによって異なります)
素人厳禁なレジストリの直接操作ですから方法は敢えて書きませんが、ここの住人なら不用ですよね?
Re:開発環境が優秀なので (スコア:2)
Re:開発環境が優秀なので (スコア:2)
Vimプラグインで解決です。
私はVimプラグインとHHKのお陰でコーディングが3倍速くなり,プログラミングを楽しんでいます。
# 個人の感想です。 :-p
Re:開発環境が優秀なので (スコア:2)
Re:開発環境が優秀なので (スコア:1)
おいおい……。
ちゃんと使ってたら、Visual Studio編集中にマウスを操作しなきゃならないことなんてありゃしませんがな。
(Xcodeだと、マウスorタッチパッドなしじゃにっちもさっちも行かないことはありますが)
自分がまともに使いこなせていないのを棚に上げて、そりゃないですぜ。
# Visual Studioの問題点は、むしろバージョン違いによる操作方法の差異。
# そういう意味でも、「ガラパゴスな進化(笑)」は的外れ。VS1.0→VS2010には連続性がないから。
Re:開発環境が優秀なので (スコア:1)
マウス操作は不要だけど、ホームポジションから手を離さないとダメだとかじゃね?
たとえばカーソルキーが必用というだけで、面倒だよね。
Re:開発環境が優秀なので (スコア:2)
c% (メソッド呼び出し(対応する括弧まで)を削除して変更) とか dap (メソッド定義(空行で挟まれたブロック)を削除) みたいなごく基本的な操作のために10ストロークも打鍵しなきゃいけないエディタでは、開発なんてやってられないわけですよ!
Re:開発環境が優秀なので (スコア:1)
どっちかというとあなたの方がガラパゴスな進化をしているんじゃないですかね。
開発環境が整備され誰でも簡単に開発者になれる現在ではキーボードに最適化した開発者の方がガラパゴスですね。
Re:開発環境が優秀なので (スコア:1)
VisVimは個人的にあまり使い勝手が良くなかったので、
ViEmu http://www.viemu.com/ [viemu.com]
使ってます。有料($99)ですけど。
Re:開発環境が優秀なので (スコア:1)
Javaのコーディング規約に"変数名等の各単語は省略するな"ってのがあった気がする
Re:開発環境が優秀なので (スコア:2)
しかし…何でもかんでもつなげるのは疲れるわけで
public String convertToStringByHogeAndFugaAndFooAndBarAndFizzAndBuzzAndKouAndOtsuAndHei(Object hoge, Object fuga, Object foo, Object bar, Object fizz, Object buzz, Object kou, Object otsu, Object hei)
...
}
みたいなコードに出くわした時には、ほんとどうしようかと思いました…。
せめて標準にそって、引数の名前だけは省略してくれと。
そもそも、引数が多すぎという問題はダイブあるのですが…しかし、それにしても…。
無理せず日本語使えよ (スコア:2, すばらしい洞察)
VisualStudioなら、関数名なんてIntelliSenseで選択するだけなんだから素直に日本語で書いたらいいんじゃないの。
ローカル変数まで日本語使われるとウザいけど、大半は[.]押してから選択するだけだし。
特にテストコードやENUMなんて遠慮せず日本語で書いていけば良いと思う。
> しかし、長い識別子名が多いと1行は78文字以内というポリシーを守るのがかなりきつい。
だいたいこれもおかしいだろ。昨今フルHDの液晶が手頃かつ入手性も最強な上、
VisualStudioもマルチモニタ最適化が進んでいるというのに、ゴミPC制約に合わせる必要なんぞどこにあるんだ。
Re:無理せず日本語使えよ (スコア:2)
日本語を使うと、FEPとエディタのショートカットが微妙に絡まって、困るんですよね。
漢字orローマ字? (スコア:2)
ここでの日本語って、漢字かな交じり? それともローマ字?
ローマ字で書かれるくらいなら、一般的な英単語で書いてくれた方が読みやすいよ。
一般的なというのは、実際にプログラミングでよく使われるテクニカルタームと中学英単語+αくらいの範囲で。
予約語は英単語とその略なんで、ローマ字が混ざると読みづらいよ。
ぴゅう太なら予約語もひらがなだっけ。ひらがなLogoとかいうのもあったかな。
どちらにしても、かな入力やローマ字入力は勘弁して欲しいな。
ちなみに、省略形は一般的な範囲なら気にならない。
ConfigurationをConfig/Conf/Cfgとかさ。
ただ、省略の程度がバラバラだと紛らわしいけど。
内容をよく表す名前を使う (スコア:2, 興味深い)
『Clean Code アジャイルソフトウェア達人の技 [amazon.co.jp]』 P70「内容をよく表す名前を使う」より。
英語圏の話なので、日本語だと必ずしもメソッド名だけで意味が通じるかと言うと微妙な部分はありますが、基本的にIDEが主流になった昨今、下手に短い意味の判らないメソッド名にするよりはっきり意味の判る長いメソッド名の方がよいでしょう。モニターも横長のものが増えていますし、数十文字程度なら全然OKです。
# 1行80文字とかコーディング規約が厳しい場合は・・・ご愁傷様で、、、
Re:内容をよく表す名前を使う (スコア:1)
BOOL ::IsAllYourBaseAreBelongToUs()
#26文字余裕でした。
昔は短く、今は長く (スコア:2)
APIは長いのばっかなので、次第になれるものね。
特にオブジェクト指向だと、関数や変数が「掴めないと」致命的にやばいことも多いよね。
昔はそこらは考えなくてもよくって、フローがつかみやすいことが第一と。
まあ、
補完や長名ではまることもある (スコア:2)
補完機能が普及して、長い関数名でスペルミスを含んだものが広まったりしがち。
んで、あとからスペルあってりゃ同名になるはずの似た名の関数追加されて、無事にビルド通っちゃって、関数呼ぶほうのコード書いたとき補完機能で意図せぬほう選んではまる。Un-とか使って反対の機能の関数名を付けるときにUnPackみたいに単語の頭じゃなくなったとこを大文字にしたりしなかったり人によって違うとかも困る(このあたりは英語力に依存するか・・・)。
表意文字が母語のものとしては、長くてもいいけどぱっと見で差異わかる程度にしてほしいかな。
新しい関数名を決めるときにありものの関数に安易になんかつけ足して済ませるのはキライ。
むしろ省略するほうが許せない (スコア:1, すばらしい洞察)
言語の文化みたいなのは当然あるとは思いますが、
JavaなのにgetAplCfgStrとかなってるほうがよっぽどイヤです。許せない。
CとUNIXの呪い (スコア:1)
といいますか、あんな原型不明まで切り詰めた略記に違和感を感じないのは、UNIXとCの呪いです。
UNIXとC界隈のほうがイレギュラーなんですよ。
他でもLisp系の言語を書いているはずなのに、何故か途中からC関数のmanを引いている…って事態ありますし。
Cを知らないなら、strftimeとかsscanfとかあんな命名しませんよ。
学校の一年生でいきなりC言語を教えるから、切り詰めすぎた命名法が身についてしまうのかなぁ。
最初はJavaかLispを教えた方がいいと思う。
Unix and C are the ultimate computer viruses.(CとUNIXは最悪のコンピュータウイルス)
http://www.jwz.org/doc/worse-is-better.html [jwz.org]
Re:CとUNIXの呪い (スコア:2)
ただし、名前を短くするのが古い言語は多くがそう。1行が80文字以上にのばせない(パンチカード)とか、リンカの外部シンボル識別文字数に6文字とか8文字とかの制限があったりした。Cはイレギュラーじゃない。長生きして世の中の体勢が変わってしまってイレギュラーにおもえるようになっちゃっただけ。
教育現場の手抜きが問題 (スコア:1)
ぶっちゃけ、UnixやC標準ライブラリなんて、内輪向けの機能で、素人に使わせることなんて想定してない。
本気で教育用に使うなら、まともなコマンドとライブラリを用意して、生のコマンドやライブラリを使わずに済ませるべきなんだよね。
ま、当然、そのままじゃ学外じゃ即戦力にはならないけど、実習で使ったライブラリしか知らないような人間は、そもそも即戦力足り得ないから問題無い。
その辺を理解せずに、即戦力風味な新人出荷したんじゃ、教育の意味が無い。
これは、教える側の手抜きが酷すぎると考えるべきかと。
それに、「プログラミング教育」で要求されるのは、中途半端な小技じゃなく、きちんと物を組み上げる能力の筈。
ローカルなライブラリしか使えなくても、それが只の便利ツールじゃなく、自力での「組み立て」を要求するプリミティブな物なら、その技術はすぐに別環境でも応用出来るし、そう云う人材の方が使える場合が多いと思う。
「半端に知ってる奴」が一番手に負えないのは、皆分かってると思うから、「生のUnixコマンドやC標準ライブラリは、初心者には教えない」って云う気風が望ましいかと。
-- Buy It When You Found It --
UNIX系のコマンド名 (スコア:1)
mvとかcpとかで通じる世界に慣れているから
ついついhoge.Mvみたいなメソッド名にしがち。
で、叱られると。
つーかStringはStr、IntegerはIntで十分じゃね?さすがに。
Z80ですらcdで通じるのに(意味ちゃうがな…)、ChangeDirectoryとかもどうなのよと。
最初大文字にするのしないのの兼ね合いで
無理矢理長くしてるように思えなくもない。
Re:UNIX系のコマンド名 (スコア:3)
私もそう思っていたのですが、若者のプログラムを見て考えを改めました。
たとえば、Strは、String, Structure, Startの略語で見たことがあります。
Intは、Integer, Interruput, Interpretの略語で見たことがあります。
こういう紛らわしいのを見てしまうと、省略しない方がマシだと思うようになりました。
後生畏るべし (オフトピ: -1) (スコア:1)
…そっか。ギリギリ20代でSmalltalk-80に触れる機会があった人間から見ればそんな手合いは若造以外の何者でもないとはいえ、もっともっともっと若年の人にとってはオッサンなんだなあ。。。
Re:変に略されるよりマシ (スコア:4, おもしろおかしい)
>変に略される
creat() の悪口はそこまでだ!
#変に略す、じゃなく、変な略し方、だけど。
記事
>確かに分かりやすいのだがタイピングするのに指が絡まるわ!
長い関数だけでなく、それなりの長さの変数、マクロはコピペが基本。
くだらない打ち間違えでコンパイルエラーを大量に吐くよりましですしね。
#未だにCのセミコロンを忘れるのはどうしようもないけどorz
Re:長すぎるのは同意 (スコア:1)
その関数・変数をユニークに指し示すものが名前でしょうから、扱うシステムが
大きくなると“くどく”なるのはしょうがないでしょうが、最終的に人間が扱うもの
だから、人間が認識しやすいものが一番で、むやみに長い名前は逆に扱いにくい
点もあると思いますね。(じゅげむ.*長助)
人間同士でのコミュニケーションでも「あれ」「それ」で十分に対象を特定できる
ことが多いように、外堀を固めてある程度短く表現するのはありだと思います。
例えば、ある一連の関数に関してアレといえばアレのことであると認識できれば
省略しても問題ないわけです。
(元々関数名だって、ん十、ん百行の処理を圧縮したものですし)
頭にカテゴリーをあらわす数文字の接頭語をつけて認識を助けたりしますよね。
ただ問題は、この接頭語の読み下し方やシステムにおける位置づけがなかなか
わからないことが多いのです。ぜひ最寄にコメントしておいてください。
それよりキャメルケース表記だと単語の切れ目を探すだけで疲れてしまうのですが、
そんなことないですか? 字数がもったいなくてもアンダースコアでつないでほしい・・・。
Re:長すぎるのは同意 (スコア:2)
同意。
入力の手間は補完で補えますが、読解の手間は、長すぎても短すぎても効率が悪くなる。
省略付加を守るがゆえに、やたら長い共通の接頭辞がつく変数群や関数群が出来たとき、視認性が悪くなって、ロジックを追いにくい。
いずれにしても原理主義に固まると、だいたい使いにくいものができる。うまくバランスをとることがセンスだし、人間様の最後の砦。
Re:プログラマの経験が無いので分からないのですが (スコア:1)
重要性に応じて長さを変えるのが普通です
APIの名前の話がもともと (スコア:1)
そうしたローカル変数に対応するような変数は簡単な単語や1文字英字とかが多い。
APIはグローバルに使われる名前で機能がわかるようにつけるからトピックのような話になる。
Re:IDEで開発するならハンガリアン記法捨てようぜ (スコア:2)
同意。
今時まだシステムハンガリアン使ってるヤツってそういう言い訳するし
変数名が適当過ぎますね。
そこまではギリギリ譲歩できるけど、
システムハンガリアンを強要したり、使ってないとわかりにくいとかわけわからんこと言ってくるのはほんと勘弁して欲しい。
Re:IDEで開発するならハンガリアン記法捨てようぜ (スコア:1)
ハンガリアン記法は強力だ。使いどころを間違えなければ。
間違ったコードは間違って見えるようにする - The Joel on Software Translation Project [joelonsoftware.com]
結局のところ、言いたいことは分からないでもないが書き方に問題がある。
鈍感に「ハンガリアン記法」とだけ書くから反感を買う。
Re:部門名で良いんじゃ (スコア:2)
「あまりに長いメソッド名を持っているときはそのクラスが多くの機能を持ちすぎているサインだから、分ける事を検討しなさい。」というようなのもをどっかでよみました。
本質はわかりやすくすることであって、省略しないことではない。
わかりやすいかが基準であって何文字だからだめだとかそういう話ではないよね。(長すぎるとわかりにくいことがあるのは認めますが)
# VB.NETだと許されるけど個人的にはメソッドに括弧ついてないほうが気になります。
# yes, fly. no, fry.
Re:なんでここで略すなが主流なんだ? (スコア:2)
「前」ってのがいつの話か知らないけど、べつに「コードを書くときに意味のわかりやすい変数名・関数名を使え」と「コードを読むときに変数名・関数名を信用するな」とは、同じ人が言ったとしても矛盾しないよ。
Re:なんでここで略すなが主流なんだ? (スコア:2)
そりゃわかりやすい変数名・関数名の方が間違えにくいからでしょ。何言ってんの?
で、それとは全然別の話として、「既存のコードが規則なり常識なりを守って書かれていると盲信するな」ってのは、少なくともデバッグのためにコードを読むなら当たり前だと思う。デバッグ以外の目的で読むときにどうするべきかは僕は知らない。
Re:外部名は6文字以上禁止 (スコア:2)
C89 でも 31 文字まで保証されていたよ。
Re:外部名は6文字以上禁止 (スコア:2)
今までずっと勘違いしてた…。ご指摘ありがとうございます。
ええー、じゃあ C89 って、ユーザーが例えば strtoui という名前の関数を定義したら、標準関数の strtoul と名前が衝突する可能性があるのか。標準関数の長さの分くらいは区別することが義務付けられているはずと勝手に思い込んでいました。
Re:まあ長すぎるのもどうかと (スコア:2)
日本語で考えるんだ!
縦書きにおける「行」は縦方向でしょ。