※この記事は2013年に書いたものです。すこし変化した私の考え方を以下に書いてみました。
あるプロジェクトのソースコードがすべて、ハンガリアン記法で記述されていました。
私はハンガリアン記法が気持ち悪くて、気持ち悪くてしょうが無いです。
ハンガリアン記法とは
ハンガリアン記法とは主に、変数名などの先頭に、その変数の方を示す接頭語をつけるソースコードの記述スタイルです。
例えば、以下の様にintとunsigned intの変数があったら、iCountとしたり、uiNumberとしたりすることです。
int iCount; unsigned int uiNumber;
変数がどこに記述されていても、宣言部まで遡らずに方がわかるため、明示的でわかりやすいです。
ただ、ほんとにそんな情報必要でしょうか？？？
単純に宣言部まで遡ってこの変数はこういう方なんだと覚えてから、トレースなりするのは大した労力ではないと思います。
しかし、このように方を明示的に変数名に記載することで、変数の型を変更する必要が出た際に、変数名まで修正しなければならないし、そちらの方が修正インパクトもあり大変な労力だと思います。
また、私はとにかく冗長なコードが嫌いです。
宣言部でこの変数はこの型です。と記述したのですから、それ以上にその情報を出す必要はないとおもいます。
そこで、これよりはマシでよく見かけるのはスネーク記法です。
スネーク記法とは
単語の区切りを「_」アンダーバーでつなげて変数名などを記載する記法です。
int client_num; unsigned int server_num;
これはこれでよいのですが、私は「_」が邪魔でしょうがないです。
そこで私はキャメル記法で書くようにしています。
キャメル記法
複数単語が連なる変数名の場合、ラクダのコブの様に単語の先頭を大文字にすることで、意味の分割を図ることです。
int numOfClient; unsigned int CountOfServer;
先頭の文字も大文字にするケースを「アッパーキャメルケース」、小文字にする場合を「ローワーキャメルケース」というようです。
詳しくはWikiをご参考までに「キャメルケース」。
私は「ローワーキャメルケース」が好きです。
みなさん、それぞれ独断と偏見によりソースコードの記述スタイルはそれぞれあると思います。
私のモットーは「記載する文字数を少しでも少なく、かつ後で読んだ時に意味がわかること」としています。
私のベストなスタイル例
私が理想のコードは以下のような形です。
int main(int argc, char **argv) {
int numOfClient;
char stringOfClient[100][10];
memset(stringOfClient, 0, sizeof(stringOfClient));
for (numOfClient = 0; numOfClient < 100; numOfClient++) {
sprintf(stringOfClient[numOfClient], "client:%d¥0",numOfClient);
}
return 0;
}
簡単に説明しますと、変数宣言は「ローワーキャメルケース」になっています。
また、変数宣言時には変数を初期化していません。
numOfClientについては、for文の初期化時に初期化しますし、stringOfClientについては変数宣言時ではなく使用直前に初期化することがベストだと考えました。
あまり、お決まりのように変数初期化し過ぎるとバグを解析するための情報が消えてしまったりすることもあるため、１ステップ１ステップ必然的に必要なコードを書くように心掛けています。
みなさんのお好みはどのようなコードでしょうか？
JSerです
関数名：ローワーキャメルケース
クラス（コンストラクタ）名：アッパーキャメルケース
定値：大文字スネークケース
変数名：出来る限り小文字１単語
重要なオブジェクトなどならローワーキャメルケース
そうでないのなら小文字スネークケース
またJSは型が緩く、正確にはクラスもないので、逆に
型やクラスを意識した時システムハンガリアンで書かれることもしばしばあります
コメント頂きありがとうございます。
WEB、アプリ系開発者の方の事情が聞けて、大変参考になります。
組み込み系ではサイズがシビアなため、値範囲が足りる場合はshortやcharで変数定義するプログラマがおります。しかし、コンパイラの最適化によって32bit CPUであれば4byteになるようにパディングされてしまいます。
メモリは4byte使ってるのに変数名がsHogeとか泣けてきます。。
そもそも、shortの必要性が感じられない。。
WEB系ではハンガリアンによる問題ってなにかあるのでしょうか？
> テキストエディタ１画面で宣言部が見えるようなソースコードであれば変数名に型情報を載せる必要は無いのではないでしょうか？
その条件でしたら必要ではないと言われれば否定はできないでしょうね。あって便利だとは思いますが。
関数が長くなった例といえば、最近ではVMのプログラムでインストラクションを処理するときのswitch文が長めになったり。
こういうコードを見たとき違和感を感じるか否かなど、個人的な美学が大きいと思います。
HogeStruct HogeA, *HogeB;
HogeA.marge(HogeB);
HogeB->marge(&HogeA);
HogeAとHogeBは別物なのに名前が差別化されていないのは気持ち悪いとするか、
宣言や演算子を見れば一目瞭然なものに接頭辞を加えるのは気持ち悪いとするかですね。
改めて考えるとポインタ自体が煩わしい概念で、参照型オンリーだったらこういう問題も起こらなかったのでしょう。
> 実は英単語の省略形って英語圏ではすでに確立されていて、日本人だけ悩んでいるのでは。。。
日本よりは発達している可能性が高いですが細かい統一は難しそうです。
elemで検索するとWebの辞書にelementの略だと載っていて、
実際にJSだと取得したelementにelemなんたらと名付けることは多いですが、
それすら煩わしくなってelmとかelとか書いてる人は英語圏でも見かけます。
SQLiteの作者であるD. Richard Hippさんが書いたLemonパーサーのソースコードが
手元にあったので読んでみましたが、いかにもC言語的な略語が多いですね。atoiみたいな。
コメントありがとうございます。
> こういうコードを見たとき違和感を感じるか否かなど、個人的な美学が大きいと思います。
結局のところ、こういうことですよね。
師匠が誰かとかによるのかと思います。
> それすら煩わしくなってelmとかelとか書いてる人は英語圏でも見かけます。
これは、すばらしい情報をありがとうございます。
安心しました。。
> 手元にあったので読んでみましたが、いかにもC言語的な略語が多いですね。atoiみたいな。
システムコールがatoiなので、自分で実装した類似関数についてはあえてa2iなんてするひともいますね。
あえて、言葉をずらすのもそれはそれで意味がある場合もありますので、なんとも言えないですね。。
システムコールやライブラリに合わせるのがいいのか、あえて異なる命名規則にしておいたほうがいいのか。。
問題は特に無いかと
私から見てですが、
アプリケーションハンガリアンについては推奨されているというか
極当たり前のように使われていて、誰も疑問は持ってないかと
システムハンガリアンについても、JSのような動的型付け言語では
型がなく、どんな型同士の演算も、暗黙的に型変換されてほとんど成功してしまいます
また宣言もいつでもどこでもでき、名前から正確な型と役割を察せられなければ困るので
比較的許容されると思います
実際接頭、接尾ともに、無意識でしょうがけっこうよく使われています
もっと言えば、型が薄い言語だと、型とクラスの境界が曖昧です
特にJSはプリミティブ型の多くが、暗黙的にラッパーオブジェクトに型変換されるので
数値はNumberクラスのインスタンスオブジェクト、
文字列はStringクラスのインスタンスオブジェクトとしても見れます
また、JSの少々ニッチな話ですが
今までJSの数値は全て64bit浮動小数点型だったのですが
近頃沢山の型付配列が導入されて、
実質(unsigned )charからlongまで考えられるようになりました
また、MapやSetの導入など今までになかった概念が取り入れられつつあります
これらは一応はオブジェクトですが、JSや柔軟なオブジェクト指向型言語にとっては
型に近い存在です
それから将来的にはプリミティブ型に
64bit整数型やbignum型の導入が予定されており
さらにsymbol型という面白いものもあります
そういう扱う型が増えていく状況の中で、むしろシステムハンガリアンは
JSではこれから重要になっていくのではないかと思います
ただし、何にでもつけるというのは良くないかと
効果的に使っていくのがいいと思います
大変、参考/勉強になる情報を頂きありがとうございます。
C言語などの静的型付けである言語においては、コンパイル時に型の不整合は警告としてプログラマに通知されます。
この機能があるため、システムハンガリアンで変数名に型情報を載せるのは冗長であるし無意味であると私は考えています。
当然、状況によって意図的に型が違う変数の代入をしたい状況もありますが、それはプログラマが意図的にキャストをしますので、ソースコードとしても特別な意味を持つステップになります。
仕様を理解して、変数名に仕様にあった適切な名前をつければ型は必然的に決まるものだと考えています。
アプリケーションハンガリアンにおいても、私は不要だと考えていて、中途半端な接頭辞、接尾辞をつけるならば、長くなっても適切な「単語」を使用した方が良いと考えています。
私が最終的に目指しているものはコメントが無いソースコードです。
コメントはコンパイルされないのに記述する必要がある文字列です。
コメントが減ると保守性も落ちていきます。
WEB系の方は工数算出などを画面数などで出すかと思いますが、組み込み系ではソースコードのステップ数で工数算出します。
その際にコメントは省かれます。
書かなければいけないコメントが工数に含まれていないなんて、最初っから時間が足りるわけ無いです。
（そもそもこんなレガシーな工数算出方法自体を見直すことも必要ですが）
ソースコード自体が人間語になっていれば工数と実作業が１：１になると考えているのです。
まあ、極論に近いとは自分でも思っています。。。あくまで理想ですね。。
動的型付けである言語に馴染みが無い私ですが、JSではそれだけ複雑な型があるならば、よりいっそうハンガリアンではなく「単語」を使用する必要があると思ってしまいました。
省略語はプログラママターであるので癖が出やすいです。
(receiveをrecvとする人もいればrcvとする人もrxとも。。)
ソースコードにおいても上位ドキュメントで整理された言葉を使用することが基本的にはベストだと考えていますので、ソースコードで突然、省略やプログラマの言葉になるのは保守性にかけると思いました。
＞ハンガリアンではなく「単語」を使用する必要があると思ってしまいました。
うーん、どうなんでしょうか
JSではreceiveをrcvやrxとする人はあまりみないような気がします
先の話ではrecv程度の省略や、receiveとそのまま単語を書く場合のイメージで書いてしまいました
確かに、１、２文字程の接頭文字、接尾文字を付けることを強制するのは、
私も意味が無いと思いますし、sHogeみたいなことは絶対にやりませんし、
あまりに省略された記法は嫌われると思います
ただし全く省略されないのも好かれなくて、
読める程度に省略するのがスマートとされていると思います
多分「recv」が一番好まれ、使われていそうです
＞ソースコードで突然、省略やプログラマの言葉になるのは保守性にかける
ここの当たりは私もいつも強く感じているのですが、
どうするのがベストかまだJSの世界では確立されてないと思います
そもそもJS自体、１つの事を様々に書ける言語で、
オブジェクト指向も、イベント指向も、関数型も、メタプロもなんでもできる、
自由が売りのスクリプト言語で、規則とか慣習とかは合わない性質だと思います
多くの人がサイト制作など手軽な目的のために独学で覚えたというのもあって
コーディングスタイルは混沌としています
それでも今までは、一人が少量書くことが多かったのであまり問題になりませんでしたが
近頃大規模に使われる事が増えてきて、悪い記法を正そうと言われるようになってきました
ですがそれは、ここ５年くらいの話で、
入門書や、解説サイトはまだ独特で自由な書き方をしてるとこも多いです
キャメルケースについては（記法に興味ある人達の中では）
かなり確立したと思っていますが、それ以上は全然かと
というか、これ以上JS言語として縛ることは無理なのかもしれません
近頃は、TypeScriptといったJSに変換可能なより厳しい言語を使って
開発することが増えているようです
あと、ハンガリアンを使ってしまうのは
JSerが型に慣れてない（見慣れない）からかもしれません
例えば型付配列はサンプルでint32～などとなってることも多くて、
私も初期はそんな感じで書いていたと思います
しかし、最近書いたコードを見なおしてみると、
全く自然に用途に合った名前を付けていました
逆に、最近導入されたシンボル型を実験的に使っているのですが
それには無意識にsymを付けたりしてしまいます
しかし、symbolはもちろん、型付配列に馴染みのある人もそれほど多くないと思うので、
大規模開発において、変数名をどうしたらいいのかはわかりません
やはり単語をそのまま書くのが、一番行儀の良いことなのでしょうね
私もこれから気をつけます
コメントありがとうございます。
> しかし、最近書いたコードを見なおしてみると、全く自然に用途に合った名前を付けていました
これには強く同意致します。
> 逆に、最近導入されたシンボル型を実験的に使っているのですがそれには無意識にsymを付けたりしてしまいます
やはり、どんな言語であれ、使い方を理解していれば保守性に優れた名称を使用して実装ができるということなのだと思います。
趣味でも好きで扱う言語であれば、どんどん知識が深まり、言語仕様ではなく機能仕様に目を向けられると思いますが、仕事上不慣れな言語を触らなければいけない状況というのはあると思います。
そんなときには、言語仕様を理解しきれずに、本来目を向けなければいけない機能仕様/要求仕様に手が回らず、言語仕様に対して意識が集中してしまう。
そこで、知らず知らずにシステムハンガリアンでコーディングしてしまっている。。
その後はレガシーソースがシステムハンガリアンなので、別担当者もシステムハンガリアンで実装していく。。
ある日、言語に対する有識者が見た時に機能仕様に特化した実装になっていないため、システムハンガリアンに対して不満を感じていく。。。
私の場合、組み込み系に偏っていますので偏った考えになってはいますが、C言語の言語仕様自体は理解しているつもりです。
その為、言語仕様ではなく機能仕様により目を向けられるので、ハンガリアンを嫌うのかなと思いました。
> やはり単語をそのまま書くのが、一番行儀の良いことなのでしょうね
> 私もこれから気をつけます
私事ですが、今後WEB系案件への配属がありそうで、コーディングの認識に不安を感じています。
Javaになりそうなのですが、ハンガリアンなどは、オブジェクト指向云々に比べたら細かい話ですが、言語仕様の理解不足がこのような細かい話から派生して自分のクビをしめることになるのは、容易に想像できてしまいます。
今今はハンガリアンは不要だと私は思っていますが、新しい言語を触ることになった時に本当に不要か判断して行きたいです。
C++，PHP，JSなどを使います。
ローワーキャメルケースからスネークケースに乗り換えた人間ですが、
名前がアンダースコア一本分長くなるものの、小文字だけの平坦な識別名は私にとって大変読みやすいです。
乗り換えた理由はキャメルケースで大文字の略語を含む変数名のデリミタに困ったからですね。
クラス名がブサイクに見えるのは今でも変わりませんが。
ハンガリアン記法については、多くの動的型付け言語については否定的ですが、
共通認識がありながら最短で意味付けできる性質は、
静的型付け言語でのポインタの明示など用途次第では現役で有利だと思います。
少ない文字数で意味が明快というコンセプトにも合致するかも。
ハンガリアン記法が有効になるのは、対象の情報が大まかには分かってはいるものの、
その中でいくつかの種別がありそれによって処理方法が異なる状況でしょうね。
例えばtextという変数があれば、それが文字列型であることは容易に推測できます。
ゆえにJSやPHPのような言語ではここにsという型名を入れるのは蛇足といえます。
しかしながら、C++においては文字列を管理するデータ型は複数あります。
単純なchar型の配列とSTL::basic_stringのようなテンプレートクラスなどです。釈迦に説法ですが。
この場合、ゼロ終端文字列はszText，テンプレートクラスなどはsTextのように表記できます。
こういう事体は基本型と複合型が混ざり合う状況で起こりやすいといえます。
ポインタ型の存在する言語でも同様のことが言えるでしょう。
Windows SDKではハンガリアン記法を使うという人は多いと思います。
なにしろ公式が採用していますからね。hWndなどは私にとっては英単語の一つです。
一方でスネークケースはハンガリアン記法とすこぶる相性が悪いので今でも悩みますね。
結局、ハンガリアン記法が無くてもコメントが無くても読めるコードは書けると思いますが、
いずれも有効に活用できたソースの方が、インテリセンスから型を参照する手間，コードを読み解く手間が省けることも事実でしょうから、そのように書き手が掛けた手間が読み手に余すことなく還元されるコードがいいコードだと思います。
工数と読みやすさはトレードオフになりやすいので、
変数iが添え字用の一時変数と事実上の標準になっているように、
汎用性の高い簡略化された識別名が浸透していけばいいなあと思います。
ついては影響力のある団体がプログラマ専用の人工単語を規格化してくれないかなあ…とか。
コメントありがとうございます！
様々な言語を扱っている方にご意見頂けるのは大変嬉しいです！
> 乗り換えた理由はキャメルケースで大文字の略語を含む変数名のデリミタに困ったからですね。
笑ってしまいましたが、確かにこれに悩む場合がありますね。
私は思い切ってキャメルケースを貫いちゃいます（SNMPのリクエストパケット用の変数だったらSnmpRequestなんていう風にしちゃいます）。
> 静的型付け言語でのポインタの明示など用途次第では現役で有利だと思います。
これは、最近ようやく気づきましたが、C言語においての話に特化してしまいますが、バグとしてキャストさえしなければコンパイラが防いでくれるため、私は変数名をpHogeとかにするのはやめました。
それから、そもそも、どうしてもその変数の型が知りたければ宣言部をみれば良いと思っています。
C言語では例外処理などで関数をコンパクトにしづらいため、一関数がダラダラと長い場合が多くありますが、このしがらみから脱却しようと私は考えています。
一関数がテキストエディタ上の一画面で見えれば、システムハンガリアンなんて不要で目の届く範囲に型名が記載されているはずなのです。
> 少ない文字数で意味が明快というコンセプトにも合致するかも。
大昔のコンパイラは変数名の長さにも制限があったと、年配のプログラマから聞いたことがあります。
ハンガリアンはそのような古い文化の名残のような気もしてきます。。
> しかしながら、C++においては文字列を管理するデータ型は複数あります。
大変、勉強になりました。
その場合、ハンガリアンが必要なのかと思えてきますが、やはりテキストエディタ１画面で宣言部が見えるようなソースコードであれば変数名に型情報を載せる必要は無いのではないでしょうか？
（理解しきれずに書いているので、それだけでは済まないシチュエーションがあるならば、ご指摘頂けると幸いです。）
> なにしろ公式が採用していますからね。hWndなどは私にとっては英単語の一つです。
これはちょっと衝撃的でした。。
Windows系の開発をしたことが無いため、全く知りませんでした。
私の経験上、Linux/Unixまた、その他の組み込みOSではシステムハンガリアンをあまり見受けません。
> いずれも有効に活用できたソースの方が、インテリセンスから型を参照する手間，コードを読み解く手間が省けることも事実でしょうから、そのように書き手が掛けた手間が読み手に余すことなく還元されるコードがいいコードだと思います。
はい、おっしゃるとおりだと思います。
> 変数iが添え字用の一時変数と事実上の標準になっているように、
これについては私もそう思っておりますが、別業界の管理者からの転職でこの業界にきたマネージャーにコードインスペクションして頂いた際に「iってなんだよ、意味がわかるように書け」と言われました。
ちょっと特殊な経歴の方からの指摘ですが、これはショックでした。。
> ついては影響力のある団体がプログラマ専用の人工単語を規格化してくれないかなあ…とか。
ホントにそう思います。
でも、意外とこういうのって英語が公用語の国では国語レベルで省略語ってありますよね。
日本人てprivateはprivってよく書いているのを見かけますが、外国の方はpvtって書いてたり、priorityはprioだったり。。
実は英単語の省略形って英語圏ではすでに確立されていて、日本人だけ悩んでいるのでは。。。
誰か否定して。。。
> テキストエディタ１画面で宣言部が見えるようなソースコードであれば変数名に型情報を載せる必要は無いのではないでしょうか？
その条件でしたら必要ではないと言われれば否定はできないでしょうね。あって便利だとは思いますが。
関数が長くなった例といえば、最近ではVMのプログラムでインストラクションを処理するときのswitch文が長めになったり。
こういうコードを見たとき違和感を感じるか否かなど、個人的な美学が大きいと思います。
HogeStruct HogeA, *HogeB;
HogeA.marge(HogeB);
HogeB->marge(&HogeA);
HogeAとHogeBは別物なのに名前が差別化されていないのは気持ち悪いとするか、
宣言や演算子を見れば一目瞭然なものに接頭辞を加えるのは気持ち悪いとするかですね。
改めて考えるとポインタ自体が煩わしい概念で、参照型オンリーだったらこういう問題も起こらなかったのでしょう。
> 実は英単語の省略形って英語圏ではすでに確立されていて、日本人だけ悩んでいるのでは。。。
日本よりは発達している可能性が高いですが細かい統一は難しそうです。
elemで検索するとWebの辞書にelementの略だと載っていて、
実際にJSだと取得したelementにelemなんたらと名付けることは多いですが、
それすら煩わしくなってelmとかelとか書いてる人は英語圏でも見かけます。
SQLiteの作者であるD. Richard Hippさんが書いたLemonパーサーのソースコードが
手元にあったので読んでみましたが、いかにもC言語的な略語が多いですね。atoiみたいな。
コメントありがとうございます。
> こういうコードを見たとき違和感を感じるか否かなど、個人的な美学が大きいと思います。
結局のところ、こういうことですよね。
師匠が誰かとかによるのかと思います。
> それすら煩わしくなってelmとかelとか書いてる人は英語圏でも見かけます。
これは、すばらしい情報をありがとうございます。
安心しました。。
> 手元にあったので読んでみましたが、いかにもC言語的な略語が多いですね。atoiみたいな。
システムコールがatoiなので、自分で実装した類似関数についてはあえてa2iなんてするひともいますね。
あえて、言葉をずらすのもそれはそれで意味がある場合もありますので、なんとも言えないですね。。
システムコールやライブラリに合わせるのがいいのか、あえて異なる命名規則にしておいたほうがいいのか。。
C++，PHP，JSなどを使います。
ローワーキャメルケースからスネークケースに乗り換えた人間ですが、
名前がアンダースコア一本分長くなるものの、小文字だけの平坦な識別名は私にとって大変読みやすいです。
乗り換えた理由はキャメルケースで大文字の略語を含む変数名のデリミタに困ったからですね。
クラス名がブサイクに見えるのは今でも変わりませんが。
ハンガリアン記法については、多くの動的型付け言語については否定的ですが、
共通認識がありながら最短で意味付けできる性質は、
静的型付け言語でのポインタの明示など用途次第では現役で有利だと思います。
少ない文字数で意味が明快というコンセプトにも合致するかも。
ハンガリアン記法が有効になるのは、対象の情報が大まかには分かってはいるものの、
その中でいくつかの種別がありそれによって処理方法が異なる状況でしょうね。
例えばtextという変数があれば、それが文字列型であることは容易に推測できます。
ゆえにJSやPHPのような言語ではここにsという型名を入れるのは蛇足といえます。
しかしながら、C++においては文字列を管理するデータ型は複数あります。
単純なchar型の配列とSTL::basic_stringのようなテンプレートクラスなどです。釈迦に説法ですが。
この場合、ゼロ終端文字列はszText，テンプレートクラスなどはsTextのように表記できます。
こういう事体は基本型と複合型が混ざり合う状況で起こりやすいといえます。
ポインタ型の存在する言語でも同様のことが言えるでしょう。
Windows SDKではハンガリアン記法を使うという人は多いと思います。
なにしろ公式が採用していますからね。hWndなどは私にとっては英単語の一つです。
一方でスネークケースはハンガリアン記法とすこぶる相性が悪いので今でも悩みますね。
結局、ハンガリアン記法が無くてもコメントが無くても読めるコードは書けると思いますが、
いずれも有効に活用できたソースの方が、インテリセンスから型を参照する手間，コードを読み解く手間が省けることも事実でしょうから、そのように書き手が掛けた手間が読み手に余すことなく還元されるコードがいいコードだと思います。
工数と読みやすさはトレードオフになりやすいので、
変数iが添え字用の一時変数と事実上の標準になっているように、
汎用性の高い簡略化された識別名が浸透していけばいいなあと思います。
ついては影響力のある団体がプログラマ専用の人工単語を規格化してくれないかなあ…とか。
多分JSだとelmが多いです
elは見ますが、elemは見た覚えがありません
JSでeと言えば
errorかelementかeventくらいしかないので
この３つは３字でや２字の略語でも十分JSerに伝わると思います
狭い範囲で使う変数など、場合によってはe１字でもいいと思われます
コメントありがとうございます。
確かにロジックから必然的にある単語しか、連想しないであろう時は私も最短一文字まで省略してしまう場合もありますね。
むやみやたらに単語にしてもコード量が増えますから、ロジックも含めた時に断定できればいかもしれません。
ちょっと、話は違いますが、皆さんは関数名や変数名に接続詞/前置詞はつけますか？
ofとかfor、per、withなどです。
例えばAリストの情報取得関数の名前はgetInfoOfAlistにするか、ofはつけないかということです。
多分JSだとelmが多いです
elは見ますが、elemは見た覚えがありません
JSでeと言えば
errorかelementかeventくらいしかないので
この３つは３字でや２字の略語でも十分JSerに伝わると思います
狭い範囲で使う変数など、場合によってはe１字でもいいと思われます
コメントありがとうございます。
確かにロジックから必然的にある単語しか、連想しないであろう時は私も最短一文字まで省略してしまう場合もありますね。
むやみやたらに単語にしてもコード量が増えますから、ロジックも含めた時に断定できればいかもしれません。
ちょっと、話は違いますが、皆さんは関数名や変数名に接続詞/前置詞はつけますか？
ofとかfor、per、withなどです。
例えばAリストの情報取得関数の名前はgetInfoOfAlistにするか、ofはつけないかということです。
個人的にトップレベルの関数では付けないことが多いですが、
例えばDOM操作の標準メソッドはしっかり付いてるタイプですし、
DOM操作の関数作る時は付けたくなりますね。
扱う付近のAPIの雰囲気に合わせると思います。
個人的にトップレベルの関数では付けないことが多いですが、
例えばDOM操作の標準メソッドはしっかり付いてるタイプですし、
DOM操作の関数作る時は付けたくなりますね。
扱う付近のAPIの雰囲気に合わせると思います。
elemという接頭辞はjQueryが採用していますよ。
elはprototype.jsだったっけ…こちらはよく覚えていません。
私も前置詞を用いるよりはgetAlistInfoのように複合名詞として名付けるケースが多いですが、
for, byのように名詞だけでは間に合わないニュアンスを持つ場合には前置詞を付けるかもしれません。
できればAlistを抜いてメンバ関数にしたいですね。
ネイティブ関数の拡張的な用途になるときはやはりそれらの関数名にあやかって名付けますね。
JSだと今でこそほとんどのブラウザが実装していますが、getElementsByClassNameの自作が代表的ですかね。
>>ht.askさん
ああすみません。
確かに接頭語としては短いと分かりにくいのでelemくらいが使われるでしょうね。
変数の話のつもりで書いてしまいました。
みなさん、コメント頂きありがとうございます。
やはり、使うフレームワークやライブラリなどに合わせたり、細かなニュアンスを伝える為に工夫したりして、すべてを単一のポリシーで統一するのは難しいですよね。
私の目指すところはイレギュラーな命名規則がないように完全に統一するところですが（ある機能を実現することよりもその先の保守性、可読性を最優先したい）、そもそも人間語を制さなければ（特に英語）プログラム言語も効率的で可読性のあるソースコード作成は難しいと感じました。
elemという接頭辞はjQueryが採用していますよ。
elはprototype.jsだったっけ…こちらはよく覚えていません。
私も前置詞を用いるよりはgetAlistInfoのように複合名詞として名付けるケースが多いですが、
for, byのように名詞だけでは間に合わないニュアンスを持つ場合には前置詞を付けるかもしれません。
できればAlistを抜いてメンバ関数にしたいですね。
ネイティブ関数の拡張的な用途になるときはやはりそれらの関数名にあやかって名付けますね。
JSだと今でこそほとんどのブラウザが実装していますが、getElementsByClassNameの自作が代表的ですかね。
>>ht.askさん
ああすみません。
確かに接頭語としては短いと分かりにくいのでelemくらいが使われるでしょうね。
変数の話のつもりで書いてしまいました。
みなさん、コメント頂きありがとうございます。
やはり、使うフレームワークやライブラリなどに合わせたり、細かなニュアンスを伝える為に工夫したりして、すべてを単一のポリシーで統一するのは難しいですよね。
私の目指すところはイレギュラーな命名規則がないように完全に統一するところですが（ある機能を実現することよりもその先の保守性、可読性を最優先したい）、そもそも人間語を制さなければ（特に英語）プログラム言語も効率的で可読性のあるソースコード作成は難しいと感じました。
もう二年以上前の記事にコメントをつけるのも何なのですが、検索上位記事なので失礼させてください。
Rubyistです。C/C++/JSの勉強も経ています。
Rubyではアプリケーションハンガリアンは利用される傾向にあります。上で出ていたJSと同じく、動的型付けのスクリプト言語なので、似たような傾向と言えます。しかしどちらかというとtetoatomさんが書かれているような
> アプリケーションハンガリアンにおいても、私は不要だと考えていて、中途半端な接頭辞、接尾辞をつけるならば、長くなっても適切な「単語」を使用した方が良いと考えています。
フルレングスの単語を利用することのほうが好まれているようです。変数名がそこそこ長くなっても許容されることからも見られますが、Rubyでは構文そのものを英語としてなるべく読めるようにすることが多いです。例えば、
students = [“Taro”, “Jiro”, “Emi”]
3.times do |index|
print students[index]
end
この場合もっといい書き方はありますが…
一方で、RubyはJSよりもさらに方に囚われない言語で、メタプログラミングやダック・タイピング、モンキーパッチを好んで行う傾向があります。条件分岐によって一つの変数に違うデータ型が入ることもあります。例：
case should_be_array # boolean
when true
then data = [“hoge”, “hoge”] # Array
when false
then data = {one:”hoge”, two;”hoge”} # Hash
end
return data.first # firstメソッドはArrayにもHashにも使える
なので、システムハンガリアンは好まれない変数名の定め方です。
また、ここで出てきましたが、標準的な規約(公式には規約がない)では、Rubyの変数にはスネークケースを用います。これは先頭が大文字な変数名をインタープリタが定数と扱うからです。とだけ聞くと(ローワー)キャメルケースでもいいと思うかもしれませんが、これはクラス名との混同の恐れがあるため避けられます。軽くまとめると次のとおりです：
CONSTANT_VALUE # 定数
ClassOrModuleName # クラス名・モジュール名
local_variable # 変数
the-name-of-the-file.rb # Rubyファイル名
まとめると、変数(オブジェクト)名や関数名にフルレングスの単語を用い、データ型や用途を見ただけでわかるようにし、「イレギュラーな命名規則がないように完全に統一する」ことで間違いを間違いだとわかりやすくしている……はずなのですが、それでもまだコメントは全然減りませんね。
古い記事にも関わらず、ご覧いただき、また、コメントまで頂きありがとうございます。
私は業務においてRubyを扱ったことはないため、大変、参考になる情報です。
最近では、このような習慣が比較的、浸透しているのか私好みなソースコードを多々見受けます。
そこで、周知の単語については思い切った省略をするようにしています。
よくある例ですと、ループカウンタとして「index」という変数を使用する場合は「i」としてしまいます。
リストはなるべく単語の複数系を使用し、foreachなどで要素を格納する変数はその単語の頭文字ひとつとします。
for (ENTITY e : entities) {
e.value = value;
}
「いちいち書かなくてもわかるだろ」ということまで書く必要はないというのが前提なのですが、難しい判断でもあります。
「わかる人にはわかる」から省略するというのは避けるようにしています。
要するに自分がいなくなっても、そのコードがメンテできることを常に考えなければなりません。
コメントは減らないし、コメントを頼りにするシチュエーションは多々あるのですが、経験の浅いプログラマはソースコードのメンテだけで、コメントのメンテをしない場合が腹立たしいです。。
あるタイミングに入った修正によって、コメントと処理が全く異なる場合など、よくあります。。
もう二年以上前の記事にコメントをつけるのも何なのですが、検索上位記事なので失礼させてください。
Rubyistです。C/C++/JSの勉強も経ています。
Rubyではアプリケーションハンガリアンは利用される傾向にあります。上で出ていたJSと同じく、動的型付けのスクリプト言語なので、似たような傾向と言えます。しかしどちらかというとtetoatomさんが書かれているような
> アプリケーションハンガリアンにおいても、私は不要だと考えていて、中途半端な接頭辞、接尾辞をつけるならば、長くなっても適切な「単語」を使用した方が良いと考えています。
フルレングスの単語を利用することのほうが好まれているようです。変数名がそこそこ長くなっても許容されることからも見られますが、Rubyでは構文そのものを英語としてなるべく読めるようにすることが多いです。例えば、
students = [“Taro”, “Jiro”, “Emi”]
3.times do |index|
print students[index]
end
この場合もっといい書き方はありますが…
一方で、RubyはJSよりもさらに方に囚われない言語で、メタプログラミングやダック・タイピング、モンキーパッチを好んで行う傾向があります。条件分岐によって一つの変数に違うデータ型が入ることもあります。例：
case should_be_array # boolean
when true
then data = [“hoge”, “hoge”] # Array
when false
then data = {one:”hoge”, two;”hoge”} # Hash
end
return data.first # firstメソッドはArrayにもHashにも使える
なので、システムハンガリアンは好まれない変数名の定め方です。
また、ここで出てきましたが、標準的な規約(公式には規約がない)では、Rubyの変数にはスネークケースを用います。これは先頭が大文字な変数名をインタープリタが定数と扱うからです。とだけ聞くと(ローワー)キャメルケースでもいいと思うかもしれませんが、これはクラス名との混同の恐れがあるため避けられます。軽くまとめると次のとおりです：
CONSTANT_VALUE # 定数
ClassOrModuleName # クラス名・モジュール名
local_variable # 変数
the-name-of-the-file.rb # Rubyファイル名
まとめると、変数(オブジェクト)名や関数名にフルレングスの単語を用い、データ型や用途を見ただけでわかるようにし、「イレギュラーな命名規則がないように完全に統一する」ことで間違いを間違いだとわかりやすくしている……はずなのですが、それでもまだコメントは全然減りませんね。
古い記事にも関わらず、ご覧いただき、また、コメントまで頂きありがとうございます。
私は業務においてRubyを扱ったことはないため、大変、参考になる情報です。
最近では、このような習慣が比較的、浸透しているのか私好みなソースコードを多々見受けます。
そこで、周知の単語については思い切った省略をするようにしています。
よくある例ですと、ループカウンタとして「index」という変数を使用する場合は「i」としてしまいます。
リストはなるべく単語の複数系を使用し、foreachなどで要素を格納する変数はその単語の頭文字ひとつとします。
for (ENTITY e : entities) {
e.value = value;
}
「いちいち書かなくてもわかるだろ」ということまで書く必要はないというのが前提なのですが、難しい判断でもあります。
「わかる人にはわかる」から省略するというのは避けるようにしています。
要するに自分がいなくなっても、そのコードがメンテできることを常に考えなければなりません。
コメントは減らないし、コメントを頼りにするシチュエーションは多々あるのですが、経験の浅いプログラマはソースコードのメンテだけで、コメントのメンテをしない場合が腹立たしいです。。
あるタイミングに入った修正によって、コメントと処理が全く異なる場合など、よくあります。。
新人のころ（15年前くらい）の組込み系の仕事をしていたときは、
コンパイラが、大文字と小文字の区別ができなくて、スネーク記法でした。
一番最初に、これで慣れてしまったので、スネーク記法で書くことが多いです。
新人のころ（15年前くらい）の組込み系の仕事をしていたときは、
コンパイラが、大文字と小文字の区別ができなくて、スネーク記法でした。
一番最初に、これで慣れてしまったので、スネーク記法で書くことが多いです。
一人で書いているなら、自分の好みで書けばいいと思います。
ですが困るのは、チームで仕事するときも自分の好みの記法で書く人です。
それをされると、複数の記法が混じったカオス状態になってしまいます。どの記法を選ぶよりも、そのカオス状態こそが当然、最悪です。
しかし「どの記法がいい」という主張を始める人は、
このカオス状態を作り出すことが多いように思います。
既存のソースやチームの慣習より、
自分の「理論」の方が優先になっているのでは。
しかも自分の見識が高いと思ってるから、なかなか折れてくれないし。
本当に困るんですよね。
どの記法がベストか、なんていう理論より、
合わせるとか、統一するとか。
そういう気持ちを優先する方が大事じゃないですかね。
>一人で書いているなら、自分の好みで書けばいいと思います。
>しかし「どの記法がいい」という主張を始める人は、
>このカオス状態を作り出すことが多いように思います。
>既存のソースやチームの慣習より、
>自分の「理論」の方が優先になっているのでは。
>しかも自分の見識が高いと思ってるから、なかなか折れてくれないし。
>本当に困るんですよね。
全くその通りだと思います。
プログラマーの悪い癖だと思います。
私もかつてプログラマーでしたので共感できます。
プログラマーはPCの中では全知全能の神のような感覚になりやすく、PCという狭い世界の中で自分の思い通りにプログラムを組めるため自分の思考が「絶対的」という人間が多いような気がします。
キャメルが／スネーク／ハンガリアン等の好みは、人それぞれで感じ方や読みやすさ／読みにくさが個人差があるように、「自分がこう思うから他の人もこうしてほしい」というのはただの自分本位に事を進めたいだけの思考やエゴそのものだと思います。
何故なら、ソースコードは最終的にコンパイラを通ってしまえば、人間の記述法の好みなど関係ないからです。
記述法をどうしても「こうしてほしい」のであれば、会社に「こうした方がより良くできると思います」と掛け合い記述法を変更してもらうか、それが無理であれば我慢するか自分で会社を興すのが一番でしょう。
どの職種／職業でもそうですが、会社にはそれまで培ってきた歴史や経験があり、「郷に入れば郷に従え」というのはあるいみ理にかなっていると思います。が、そういう意味では「プログラマー」という職業の人は「個」が強い人間が多いように感じます。誤解がないように書きますが、「個」が悪いという意味ではありません。
私も会社で決められた記述法に気持ち悪さを感じましたが、それがその会社の「ルール」であるため、その会社に所属している自分は会社のルールに従うだけです。
>どの記法がベストか、なんていう理論より、
>合わせるとか、統一するとか。
>そういう気持ちを優先する方が大事じゃないですかね。
その通りだと思います。
それでも「いや、それじゃダメだ。絶対これが良いだろう」と主張してくる人には、
「人は十人十色、人は精密な機械ではなく細胞の集まりである生物で、価値観も考え方も感じ方も皆違う。物事に絶対は無い」ということを感じてほしいです。
長文になってしまいましたが以上で終わりです。
失礼いたしました。
私のプロジェクトでは変数はハンガリアン＋スネーク
その他はロワーキャメルで統一してます。
慣れや練度によりますが、新米ＰＧ抱えると変数の型が一目でわからないと
後々のデバッグや仕変でエラい事になるのを経験的に学びました。
自分のソースならいいのですが、いくら変数や関数の仕様を取り決めても
こちらの意図とは違う記述やコーディングされるので
結果的にそのコード、関数を見ただけで最低限変数の型は分かるくらいに
しておかないと型チェックの時間ばかりが膨大になります。
ＰＧには、とにかく命名規約だけは絶対に守れと常日頃から言い聞かせています。
同じですね！ ハンガリアン記法は必要です。数万ステップのソースを扱うときは無いとレビューに時間がかかります。型変換による名称変更は置換機能でやるので簡単です。検索範囲もモジュール内、プロジェクト内などと絞って検索置換処理できるので不便とは思いません。グローバル変数は極力使いたくありませんが、MSバグ対策として使う場合が多いです。グローバル変数はスネーク記法＋ハンガリアン記法にしてます。g_lnSumとか。
プライベート関数とMSライブラリ関数を区別するためにプライベート関数名はローワーキャメルを使って他人が一目でわかるようにしてます。
一番気持ち悪くなるのはいずれの記法も使っていないソースです。結構、unix系のソースで見かけます。オレオレソースコードですね。チームで取り組むソースコードではありませんね！
この記事を書いた私自身、ハンガリアン記法への抵抗が薄れつつあります。
確かに、グローバル変数にそれだとわかる変数名をつけるのは非常に効果的ですよね。
Javaなどではメンバ変数をわかりやすい名称（例えば先頭文字はアンダーバーなど：String _hogeHuga）にしておくこともあります。
＞オレオレソースコードですね。
私自身、Unix系システムでC言語による開発をしていた時代、半端なオブジェクト指向の知識で迷走していたことがあります…（構造体をクラス的に使おうとしたり）
おっしゃる通り、まずは記法云々ではなく、チームとして取り組んでいる意識が重要であると感じています。