アカウント名:
パスワード:
第一線のエンジニアという言が真ならば、今時のプログラムなんて楽勝です。GUIだってネットワークだってLLだって、一皮向けばC言語とアセンブリの世界に突入です。ゼロから始めた初学者がJavaで「同じ単語を格納したstringの比較が真にならない」件で悩んでる間に、たぶんJavaに加えてP*言語ぐらいはマスターできてるんじゃないかな。
きちんと基礎の基礎が身についてる人っていうのは、応用習得はびっくりするぐらい早いもんです。私の実例でも、Cとアセンブリしかやってこなかった人が、わずか１週間で、経験３年の奴に勝るとも劣らないC#コードを書いていましたよ。さすがにOOな所は厳しかったけど、delegateやクロージャをばりばり使いこなしてました。
もちろん今時の、オープンフレームワークを切り貼りするプログラムについては数多のライブラリを時間をかけて１つ１つ知っていくしかないのだけど、それは必要になったときにすれば充分じゃないかと。
あ、でもC++には近づかない方がいい。あれを真に使いこなすには少なくとも10年かかる。
Javaで「同じ単語を格納したstringの比較が真にならない」件
たまに真になるんですよね。余計なおせっかいというか何と言うか。
オブジェクト型の比較演算子(==)では内容比較ではなくポインタ比較を行っているためです。String a = "H";String b = new String("H");if (a == b) {...} // ←aとbは同じ内容でも別アドレスの文字列なのでここの条件節は偽になります
それだけだとaがnullの場合にNullPointerExceptionを投げるので、以下のようにする場合もあります。
if((a == null) ? (b == null) : a.equals(b)) {...}
あるいは、こういうのを定義しておいて、public static boolean eq(Object lhs, Object rhs) { return (lhs == null) ? (rhs == null) : lhs.equals(rhs);}
こうするとか。if(eq(a, b)) {...}
「参考になる」じゃねーよ。メソッド名も仮引数名もまるでなってない。典型的にダメなパターン。まるでダメの見本ですね。privateならともかく、publicなメンバの名前にはもっと責任を持って頂きたい。
変に単語を省略しないように。eqは恐らくequalを省略したものだろうけど、あえて省略する意味がありません。仮引数名は省略形が使われることもあるが、lhsって何?全く分かりません。
参考までに、Apache Commons Langの同様のメソッドは、equals(String str1, String str2)です。
# 似たようなコードを書く「ベテランプログラマー」が近くにいるので思わず熱くなってしまった。# ホント、地味に迷惑なんですよ。こういう基本的な部分の非常識さ。いちいち指摘しづらいし。# ちなみに私なら、equals(String value1, String value2)にするかな。
> 仮引数名は省略形が使われることもあるが、lhsって何?全く分かりません。
lhs/rhsは、left hand side、right hand side の略です。C++などで演算子オーバーロードで2つのオペランドをlhs/rhsと表現するのはよくみかける表現です。Boost なんかでも普通に使われてるし。
==の場合は可換だから value1、value2 でもいいかもしれませんが、とかの可換でない演算子の場合、1,2という命名の方が混乱の元になります。
まあ、演算子オーバーロードの無いJavaでは見慣れない表現かもしれませんが、最初に一度説明すれば終わる話だし、そこまで否定するほどの命名規則とは思えないですね。
引数名については#1806916 [srad.jp]でご指摘いただいた通りです。また「str1」だと「str」なのは型を見れば分かりますし、「value」なのは自明なので、追加情報としては役に立たない。省略が嫌な場合には「left」と「right」などいかがでしょう。
ところで「eq」という名前も慣習で色々と使われていまして、ちょっと調べてみました。(「Java以外の慣習を持ち込むな」と言われればそれまでですが)一覧 (もちろん不完全) を貼っておきます。
実際の開発で使用する関数を書く場合には他の言語の慣習を持ち込むのと「オレ省略」の境目は難しいですが、チーム内で了解が得られていれば問題無いかと。
========== 一覧ここから ==========
SAStruts (検索条件) http://www19.atpages.jp/~taipeimaomao/pukiwikiplus/inde [atpages.jp]
# まとめてお返事にて失礼します。
lhs/rhsは、left hand side、right hand side の略です。C++などで演算子オーバーロードで2つのオペランドをlhs/rhsと表現するのはよくみかける表現です。
Javaの話をしているつもりでしたが。そういえば、私の近所の「ベテランプログラマー」もすぐに「C++では」などとのたまうのですが、Javaのコーディングスタイル(しかも命名規約)の話題で、他の言語を持ち出されてもって感じです。「全てのJavaプログラマーはC++の知識が必要」って主張でもないでしょうに。
可換でない演算子の場合、1,2という命名の方が混乱の元になります
その場合は1,2という命名をしないというのは言うまでもないですよね。
そこまで否定するほどの命名規則とは思えないですね。
メソッド名「eq」についてもでしょうか?であれば、初心に帰って勉強しなおすか、潔くプログラマーを引退したほうがよろしいかと。
「value」なのは自明なので、追加情報としては役に立たない。省略が嫌な場合には「left」と「right」などいかがでしょう。
今回の例でいうと、「equals」で十分用途が伝わるので「追加情報は必要ない」という判断です。仮引数名に関して言えば、省略が嫌なのではなく、C++を知らないと分からない命名が嫌なのです。個人的には「s1, s2」でも良い位ですが、その辺は好みの話にしかならないのでこの辺で。
「Java以外の慣習を持ち込むな」と言われればそれまでですが
というか、私が言いたいのは一点、それのみです。「Java以外の慣習を持ち込むな」Javaの標準APIや、まともなフレームワークのAPIは、Javaのスタイルで命名されています。正当な理由なしに他の言語の慣習を持ち込むことがNGです。
チーム内で了解が得られていれば問題無い
そのコードに関わる全ての人の了解が得られていれば問題ないでしょう。今回は、了解が得られていないコードをサンプルとして挙げられていたので、異を唱えたまでです。
まあ、私のようなどこの馬の骨とも分からないようなACに言われても聞く耳持たないでしょうから、以下のリンクを貼っておきますね。訛りのない Java 言語を話す [ibm.com]Effective Java 第2版 [pej-hed.jp] (項目56 一般的に受け入れられている命名規約を守る)
# こういう細かいやり取りも含めて、「ベテランプログラマー」に基本的なことを指摘するのがホント面倒。## もともとはモデレータに「参考になる」じゃねーよって突っ込みたかっただけなんだけど。
> 「Java以外の慣習を持ち込むな」ではJavaに絞って、現状を書いてみますね。(URLを減らせと叱られたので減らしました)
●変数名「lhs」と「rhs」について
まずlhsやrhsという表現は、C++など特定の言語によらず、二項演算子のオペランドを表すために使われる、プログラミング一般の略語です。Javaに限っても、標準APIで特に断りなく使われています。
一例 (変数名は英語版も同じ)http://java.sun.com/javase/ja/6/docs/ja/api/java/awt/font/FontRenderCo... [sun.com]http://java.sun.com/javase/ja/6/docs/ja/api/java/awt/font/TransformAtt... [sun.com]http://java.sun.com/javase/ja/6/docs/ja/api/java/awt/font/class-use/Im... [sun.com]http://java.sun.com/javase/ja/6/docs/ja/api/java/awt/geom/Area.html [sun.com]http://java.sun.com/javase/ja/6/docs/ja/api/java/lang/class-use/Object.html [sun.com]http://java.sun.com/javase/ja/6/docs/ja/api/javax/xml/datatype/Duration.html [sun.com]
●メソッド名「eq」について
こちらは「lhs」と「rhs」ほど一般的では無いですが、標準APIだと「javax.management.Query」で使用されています。
http://java.sun.com/javase/ja/6/docs/ja/api/javax/management/Query.html [sun.com]
また、Java EEでも以下のように使用されています。(こちらは定数名で大文字)
http://download.oracle.com/javaee/5/api/javax/mail/search/ComparisonTe... [oracle.com]http://download.oracle.com/javaee/5/api/javax/mail/search/ReceivedDate... [oracle.com]http://download.oracle.com/javaee/5/api/javax/mail/search/IntegerCompa... [oracle.com]
また、#1807054 [srad.jp]の一番上で挙げたSAStrutsは、Javaの代表的なフレームワークの一つです。
他には、Seasarでも。http://s2container.seasar.org/2.4/s2-tiger/ja/apidocs/org/seasar/exten... [seasar.org]
「eq」「ne」「gt」「ge」「lt」「le」の6つは様々な言語やライブラリで使われてきた経緯から、「==」「!=」「>」「>=」「<」「<=」の代わりとして様々な言語やライブラリで使用されています。(おそらく今後開発されるものでも)こちらも特定の言語に限らない慣習なので、覚えておいて損は無いでしょう。
●「参考になる」モデについて
元がオブジェクトの同一性と同値性のトピックだったので、#1806790 [srad.jp]に対するモデはNullPointerExceptionの防ぎ方に対してでしょう。(命名規則に対してではない)
●その他
> Javaの標準APIや、まともなフレームワークのAPIは、Javaのスタイルで命名されています。ということであれば、lhsもrhsもeqも、Javaのスタイルということになりますね。
> Effective Java 第2版 (項目56 一般的に受け入れられている命名規約を守る)また、この項の最後には「『長く維持されてきた慣用的な用法が別に規定している場合、これらの規約に盲目的に従うべきではない。』ということです。常識を働かせてください。」とも書いてあります。
> どこの馬の骨とも分からないようなACACだと他の投稿を読めないのが残念ですね。これだけコードにこだわりがあれば、面白いものを読めそうですが。
以下は老婆心ですが。JavaのAPIも含め技術というのは広いもので、プログラマー一人の経験はそのごく一部です。自身の狭い経験に含まれないものは一般的では無いと決めつけ、調べもせずに批判、それも個人攻撃をしていては、知識を広げる機会を失います。引退すべき「ベテランプログラマー」はそうして誕生するのではないでしょうか。
既にオフトピ気味ですが、まだまだ引退する気は無いのでID。
私も良く命名規則とか拘る方なんですが、傍から見てるとキモいですね。 org.apache.commons.lang.builder.* [apache.org]あたりにもあなたの嫌いな例がゴロゴロあるようですよ。よかったですね
ここで言うのも何ですが、 訛りのない Java 言語を話す [ibm.com] の著者は C++ の知識が不十分な気がします。
C++ では、同じクラスのオブジェクトは互いの private メンバー変数を見られないということです。
ダウト
あと、普通の C++ プログラマなら RAII
最初に。別に個人攻撃をしてるつもりはないです。そのように受け取られたなら申し訳ない。
> ●変数名「lhs」と「rhs」について> Javaに限っても、標準APIで特に断りなく使われています。
これは私が無知なだけでしたね。失礼しました。せっかくひとつお利口になったので、二項演算の処理を書く機会があれば使っていこうと思います。
> ●メソッド名「eq」について
うーん。どうも誤解されてるようですけど、『「equals」の略として「eq」が変だ』って言ってるわけじゃないんですよ。『同値比較メソッドの名前は「equals」のほうが一般的だ』と言っています。挙げられてる例
「Javaのメソッド名はフルスペルの英語表記とするのが一般的である。○か×か?」単純な話です。
あなたは「自分のコードがおかしくない」ことを主張しようとするあまり、話が飛躍しすぎています。あのコードを読んだ全ての人があなたの様に深い知識や経験、調査能力や洞察力、応用力や柔軟性等々を持っているわけではないのです。
あのコードはJava初心者向けのサンプルとしては不適切です。
> 件のコードのメソッド名はもう少しで「hoge」になるところでしたサンプルであることが明らかな分、そのほうが100倍マシです。
あなたがSAStrutsを使ったことがないのは分かりましたから、SAStrutsを変な命名をしている仲間みたいに言わないでください。迷惑です。# 挙げられてるリンクはS2Tigerだし。あ、S2Tigerもあなたの仲間じゃないですよ。自分に都合のいい部分だけ取り出して自分に都合のいいように解釈しないで。
# バックファイアー [srad.jp]に巻き込まれてはかなわん。
SAStrutsもS2Tigerも、Javaの一般的な命名規則にしたがっています。Operations#eqは特殊な例ですが、敢えて省略形にしている明確な理由があります。(Operationsの他のメソッドや使用方法を考えればなぜ省略形にしているかは明らかです)
なぜ省略形にしているのかという理由は無視し、特殊な例のみを都合よく取り上げて、「SAStrutsでも使ってる。だから、自分のコードは間違ってない」という主張はどうなんだということ。まるでSAStrutsが一般的な命名規則を無視して省略形を使いまくってるみたいじゃないですか。
つーか、『長く維持されてきた慣用的な用法が別に規定している場合』をここまで曲解するならなんでもありじゃね?
#1809055 [srad.jp]だけ読むと「メソッド名を理由なく省略するのは間違い」という話に見えてしまうので、 #1806894 [srad.jp]からの流れを読んでみてください。「単に省略したわけではなく、こういう慣習があるんだよ」という話です。(省略の是非はそもそも議論していない)
> つーか、『長く維持されてきた慣用的な用法が別に規定している場合』を> ここまで曲解するならなんでもありじゃね?
「eq」の是非で平行線を辿っている原因は、「長く維持されてきた慣用的な用法」にJava以外の出身も含めるか、というスタンスの違いでしょう。
「eq」や「gt」などの名前は最古の高水準言語と言われるFORTRANや、シェル
論点がずれてます。仮にSAStrutsに同値比較のメソッドがあったら、equalsと名付けられるでしょう。そういう意味で、「仲間ではない」といっています。
個人的には、cosの例を挙げて、件のコードが正しいとするのはどうかと思います(得られるメリットがないので)が、あなたがどう考えるかやEffective Javaをどう解釈するかはあなたの自由です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
楽勝です (スコア:5, すばらしい洞察)
第一線のエンジニアという言が真ならば、今時のプログラムなんて楽勝です。
GUIだってネットワークだってLLだって、一皮向けばC言語とアセンブリの世界に突入です。
ゼロから始めた初学者がJavaで「同じ単語を格納したstringの比較が真にならない」件で悩んでる間に、
たぶんJavaに加えてP*言語ぐらいはマスターできてるんじゃないかな。
きちんと基礎の基礎が身についてる人っていうのは、応用習得はびっくりするぐらい早いもんです。
私の実例でも、Cとアセンブリしかやってこなかった人が、わずか１週間で、経験３年の奴に勝るとも劣らない
C#コードを書いていましたよ。さすがにOOな所は厳しかったけど、delegateやクロージャをばりばり使いこなしてました。
もちろん今時の、オープンフレームワークを切り貼りするプログラムについては
数多のライブラリを時間をかけて１つ１つ知っていくしかないのだけど、それは必要になったときにすれば充分じゃないかと。
あ、でもC++には近づかない方がいい。あれを真に使いこなすには少なくとも10年かかる。
Re: (スコア:0)
たまに真になるんですよね。余計なおせっかいというか何と言うか。
Re: (スコア:0)
Re: (スコア:0)
オブジェクト型の比較演算子(==)では内容比較ではなくポインタ比較を行っているためです。
String a = "H";
String b = new String("H");
if (a == b) {...} // ←aとbは同じ内容でも別アドレスの文字列なのでここの条件節は偽になります
Re: (スコア:1)
Re: (スコア:2, 参考になる)
それだけだとaがnullの場合にNullPointerExceptionを投げるので、
以下のようにする場合もあります。
if((a == null) ? (b == null) : a.equals(b)) {...}
あるいは、こういうのを定義しておいて、
public static boolean eq(Object lhs, Object rhs) {
return (lhs == null) ? (rhs == null) : lhs.equals(rhs);
}
こうするとか。
if(eq(a, b)) {...}
Re: (スコア:0)
「参考になる」じゃねーよ。
メソッド名も仮引数名もまるでなってない。典型的にダメなパターン。まるでダメの見本ですね。
privateならともかく、publicなメンバの名前にはもっと責任を持って頂きたい。
変に単語を省略しないように。
eqは恐らくequalを省略したものだろうけど、あえて省略する意味がありません。
仮引数名は省略形が使われることもあるが、lhsって何?全く分かりません。
参考までに、
Apache Commons Langの同様のメソッドは、equals(String str1, String str2)です。
# 似たようなコードを書く「ベテランプログラマー」が近くにいるので思わず熱くなってしまった。
# ホント、地味に迷惑なんですよ。こういう基本的な部分の非常識さ。いちいち指摘しづらいし。
# ちなみに私なら、equals(String value1, String value2)にするかな。
Re: (スコア:1)
> 仮引数名は省略形が使われることもあるが、lhsって何?全く分かりません。
lhs/rhsは、left hand side、right hand side の略です。
C++などで演算子オーバーロードで2つのオペランドをlhs/rhsと表現するのはよくみかける表現です。
Boost なんかでも普通に使われてるし。
==の場合は可換だから value1、value2 でもいいかもしれませんが、
とかの可換でない演算子の場合、1,2という命名の方が混乱の元になります。
まあ、演算子オーバーロードの無いJavaでは見慣れない表現かもしれませんが、
最初に一度説明すれば終わる話だし、そこまで否定するほどの命名規則とは思えないですね。
Re: (スコア:1)
引数名については#1806916 [srad.jp]でご指摘いただいた通りです。
また「str1」だと「str」なのは型を見れば分かりますし、
「value」なのは自明なので、追加情報としては役に立たない。
省略が嫌な場合には「left」と「right」などいかがでしょう。
ところで「eq」という名前も慣習で色々と使われていまして、
ちょっと調べてみました。
(「Java以外の慣習を持ち込むな」と言われればそれまでですが)
一覧 (もちろん不完全) を貼っておきます。
実際の開発で使用する関数を書く場合には
他の言語の慣習を持ち込むのと「オレ省略」の境目は難しいですが、
チーム内で了解が得られていれば問題無いかと。
========== 一覧ここから ==========
SAStruts (検索条件)
http://www19.atpages.jp/~taipeimaomao/pukiwikiplus/inde [atpages.jp]
Re:楽勝です (スコア:0)
# まとめてお返事にて失礼します。
lhs/rhsは、left hand side、right hand side の略です。
C++などで演算子オーバーロードで2つのオペランドをlhs/rhsと表現するのはよくみかける表現です。
Javaの話をしているつもりでしたが。
そういえば、私の近所の「ベテランプログラマー」もすぐに「C++では」などとのたまうのですが、
Javaのコーディングスタイル(しかも命名規約)の話題で、他の言語を持ち出されてもって感じです。
「全てのJavaプログラマーはC++の知識が必要」って主張でもないでしょうに。
可換でない演算子の場合、1,2という命名の方が混乱の元になります
その場合は1,2という命名をしないというのは言うまでもないですよね。
そこまで否定するほどの命名規則とは思えないですね。
メソッド名「eq」についてもでしょうか?
であれば、初心に帰って勉強しなおすか、潔くプログラマーを引退したほうがよろしいかと。
「value」なのは自明なので、追加情報としては役に立たない。
省略が嫌な場合には「left」と「right」などいかがでしょう。
今回の例でいうと、「equals」で十分用途が伝わるので「追加情報は必要ない」という判断です。
仮引数名に関して言えば、省略が嫌なのではなく、C++を知らないと分からない命名が嫌なのです。
個人的には「s1, s2」でも良い位ですが、その辺は好みの話にしかならないのでこの辺で。
「Java以外の慣習を持ち込むな」と言われればそれまでですが
というか、私が言いたいのは一点、それのみです。
「Java以外の慣習を持ち込むな」
Javaの標準APIや、まともなフレームワークのAPIは、Javaのスタイルで命名されています。
正当な理由なしに他の言語の慣習を持ち込むことがNGです。
チーム内で了解が得られていれば問題無い
そのコードに関わる全ての人の了解が得られていれば問題ないでしょう。
今回は、了解が得られていないコードをサンプルとして挙げられていたので、異を唱えたまでです。
まあ、私のようなどこの馬の骨とも分からないようなACに言われても聞く耳持たないでしょうから、以下のリンクを貼っておきますね。
訛りのない Java 言語を話す [ibm.com]
Effective Java 第2版 [pej-hed.jp] (項目56 一般的に受け入れられている命名規約を守る)
# こういう細かいやり取りも含めて、「ベテランプログラマー」に基本的なことを指摘するのがホント面倒。
## もともとはモデレータに「参考になる」じゃねーよって突っ込みたかっただけなんだけど。
Re:楽勝です (スコア:1)
> 「Java以外の慣習を持ち込むな」
ではJavaに絞って、現状を書いてみますね。
(URLを減らせと叱られたので減らしました)
●変数名「lhs」と「rhs」について
まずlhsやrhsという表現は、C++など特定の言語によらず、
二項演算子のオペランドを表すために使われる、
プログラミング一般の略語です。
Javaに限っても、標準APIで特に断りなく使われています。
一例 (変数名は英語版も同じ)
http://java.sun.com/javase/ja/6/docs/ja/api/java/awt/font/FontRenderCo... [sun.com]
http://java.sun.com/javase/ja/6/docs/ja/api/java/awt/font/TransformAtt... [sun.com]
http://java.sun.com/javase/ja/6/docs/ja/api/java/awt/font/class-use/Im... [sun.com]
http://java.sun.com/javase/ja/6/docs/ja/api/java/awt/geom/Area.html [sun.com]
http://java.sun.com/javase/ja/6/docs/ja/api/java/lang/class-use/Object.html [sun.com]
http://java.sun.com/javase/ja/6/docs/ja/api/javax/xml/datatype/Duration.html [sun.com]
●メソッド名「eq」について
こちらは「lhs」と「rhs」ほど一般的では無いですが、
標準APIだと「javax.management.Query」で使用されています。
http://java.sun.com/javase/ja/6/docs/ja/api/javax/management/Query.html [sun.com]
また、Java EEでも以下のように使用されています。
(こちらは定数名で大文字)
http://download.oracle.com/javaee/5/api/javax/mail/search/ComparisonTe... [oracle.com]
http://download.oracle.com/javaee/5/api/javax/mail/search/ReceivedDate... [oracle.com]
http://download.oracle.com/javaee/5/api/javax/mail/search/IntegerCompa... [oracle.com]
また、#1807054 [srad.jp]の一番上で挙げた
SAStrutsは、Javaの代表的なフレームワークの一つです。
他には、Seasarでも。
http://s2container.seasar.org/2.4/s2-tiger/ja/apidocs/org/seasar/exten... [seasar.org]
「eq」「ne」「gt」「ge」「lt」「le」の6つは様々な言語やライブラリで使われてきた経緯から、
「==」「!=」「>」「>=」「<」「<=」の代わりとして様々な言語やライブラリで使用されています。
(おそらく今後開発されるものでも)
こちらも特定の言語に限らない慣習なので、覚えておいて損は無いでしょう。
●「参考になる」モデについて
元がオブジェクトの同一性と同値性のトピックだったので、
#1806790 [srad.jp]に対するモデはNullPointerExceptionの防ぎ方に対してでしょう。
(命名規則に対してではない)
●その他
> Javaの標準APIや、まともなフレームワークのAPIは、Javaのスタイルで命名されています。
ということであれば、lhsもrhsもeqも、Javaのスタイルということになりますね。
> Effective Java 第2版 (項目56 一般的に受け入れられている命名規約を守る)
また、この項の最後には「『長く維持されてきた慣用的な用法が別に規定している場合、
これらの規約に盲目的に従うべきではない。』ということです。常識を働かせてください。」
とも書いてあります。
> どこの馬の骨とも分からないようなAC
ACだと他の投稿を読めないのが残念ですね。
これだけコードにこだわりがあれば、面白いものを読めそうですが。
以下は老婆心ですが。
JavaのAPIも含め技術というのは広いもので、プログラマー一人の経験はそのごく一部です。
自身の狭い経験に含まれないものは一般的では無いと決めつけ、
調べもせずに批判、それも個人攻撃をしていては、知識を広げる機会を失います。
引退すべき「ベテランプログラマー」はそうして誕生するのではないでしょうか。
既にオフトピ気味ですが、まだまだ引退する気は無いのでID。
Re: (スコア:0)
私も良く命名規則とか拘る方なんですが、傍から見てるとキモいですね。
org.apache.commons.lang.builder.* [apache.org]あたりにもあなたの嫌いな例がゴロゴロあるようですよ。よかったですね
ここで言うのも何ですが、 訛りのない Java 言語を話す [ibm.com] の著者は C++ の知識が不十分な気がします。
ダウト
あと、普通の C++ プログラマなら RAII
Re: (スコア:0)
最初に。
別に個人攻撃をしてるつもりはないです。
そのように受け取られたなら申し訳ない。
> ●変数名「lhs」と「rhs」について
> Javaに限っても、標準APIで特に断りなく使われています。
これは私が無知なだけでしたね。失礼しました。
せっかくひとつお利口になったので、二項演算の処理を書く機会があれば使っていこうと思います。
> ●メソッド名「eq」について
うーん。どうも誤解されてるようですけど、
『「equals」の略として「eq」が変だ』って言ってるわけじゃないんですよ。
『同値比較メソッドの名前は「equals」のほうが一般的だ』と言っています。
挙げられてる例
Re:楽勝です (スコア:1)
●「eq」というメソッド名について
> 挙げられてる例はどれもクエリの組み立てなんかに使うもので、
SAStrutsのeqは内容の一致を表すので、同値比較ですよ。
また、制約ソルバや抽象構文木の同値比較ノードの場合、
意味的には同じことではないでしょうか。
(操作をデータとして表しただけなので)
それとも、返値の型がbooleanでオブジェクト間の同値比較を行う
メソッド以外は全部別物扱いということでしょうか?
そうだとしたら、問題設定自体に無理があります。
2つのObjectを引数にとるstaticメソッドの同値比較は
標準APIに存在せず、個々の開発者が自作しているはずです。
(つまり、どの慣習のことも支持しない)
また、rhsだけを取るインスタンスメソッドが「equals」なのは
慣習ではなく仕様なので、慣習が使われる余地はありません。
仕様で決まっていないメソッド名を、どの慣習に従って付けるか、
という話ですよね?
> 同値比較メソッドの名前が「eq」と「equals」のどちらが一般的ってのは、
どちらがより一般的かを決める必要は無いんですよ。
二つの慣習が併存する場合もありますので。
(一つのソースコードツリー内では統一すべきですが)
別の言い方をすると、ある慣習を使うか使わないかは、
どの慣習の使用数が一位かを決めるという話ではないのです。
> 繰り返しにしかなりませんが、
> 同値比較メソッドの名前をeqとする慣習はありません。
上で書いたように、前回挙げた例が慣習の例になっていると思います。
●なぜ「eq」のような慣習がJavaにも入ってきているのか
以下は私の個人的な意見ですが。
Javaが作られた時代は、意味不明な省略形が横行していた暗黒時代でした。
Javaの長く説明的な名前はそれを解消し、名前付けの重要性を示しました。
一方で、Javaも既に15年近く経過し、コード量の多さを批判されるように
なりました。
(Web開発ではしばらく前に、大真面目にRubyと比較されていました)
いくつか根拠が挙げられていますが、その一つが説明的なメソッド名です。
通常のメソッドには説明的な名前が必要ですが、極めて高頻度に使用され、
かつ一般的なメソッドだけは、短くすべきではないか、と考える人がいる
ということだと思います。
(どうせ暗記して使うので)
例えば「int」が「integer」ではないからといって、分かりにくいと思う
人はいないでしょう。
慣習というのは、良いと思う人は使い、使う人が増えれば一般的になります。
新しく、生産性を上げようとするフレームワークで「eq」のような名前が
採用されているということは、その慣習がJavaの文化にも入ってきている
最中なのでしょう。
さらに多くのフレームワークやライブラリで採用され、
より一般的になれば、いずれ違和感は感じなくなると思います。
他の言語の文化から慣習が入ってくるのを「今までのJavaと違う」
というだけで拒否し続けると、改善が見込めなくなるのではないでしょうか。
# 昔のJava文化なら「ge」は「isGreaterThanOrEquals」としたでしょう。
●なぜ「くだらない」と言われるのかについて
私が思うに、命名規則の話をするのがくだらないと言われている
わけではないと思います。
> 特に違和感はないです。
結局のところ、これに尽きるのではないでしょうか。
自分自身が見慣れているか否かという話になっている点です。
他の方々は、色々経験すれば変わると思い、経験の代わりに
各自のC++などでの経験談を伝えてくれているのだと思います。
●その他
> ましてや、あんな基礎的なNullPointerExceptionの防ぎ方を「参考になる」とするような
> 初心者に提示するサンプルコードとしては不適切としかいいようがない。
最初からプログラマ向けのスレッドなので、
皆さんプログラミング自体の初心者ではないでしょう。
(スラドには猛者も多いです)
おそらく「Javaでは」どうなのかが参考になったのでは。
(件のコードのメソッド名はもう少しで「hoge」になるところでした)
Re: (スコア:0)
「Javaのメソッド名はフルスペルの英語表記とするのが一般的である。○か×か?」
単純な話です。
あなたは「自分のコードがおかしくない」ことを主張しようとするあまり、話が飛躍しすぎています。
あのコードを読んだ全ての人があなたの様に深い知識や経験、調査能力や洞察力、応用力や柔軟性等々を持っているわけではないのです。
あのコードはJava初心者向けのサンプルとしては不適切です。
> 件のコードのメソッド名はもう少しで「hoge」になるところでした
サンプルであることが明らかな分、そのほうが100倍マシです。
Re: (スコア:0)
あなたがSAStrutsを使ったことがないのは分かりましたから、
SAStrutsを変な命名をしている仲間みたいに言わないでください。迷惑です。
# 挙げられてるリンクはS2Tigerだし。あ、S2Tigerもあなたの仲間じゃないですよ。
自分に都合のいい部分だけ取り出して自分に都合のいいように解釈しないで。
# バックファイアー [srad.jp]に巻き込まれてはかなわん。
Re: (スコア:0)
S2Tigerの「eq」は、SQLの検索条件で特定のフィールドが
指定した値と同値だという意味ですよね?
だとしたら、SAStrutsじゃないのはともかく、
> eqは内容の一致を表すので、同値比較ですよ。
の内容自体は間違っていないのでは。
というわけで、レッテル貼りは性急かと。
#1808909は以下の部分だけで充分だと思う。
#1809055への答えにもなっているし。
最後だから色々書いたんだろうけど。
> どちらがより一般的かを決める必要は無いんですよ。
> 二つの慣習が併存する場合もありますので。
> (一つのソースコードツリー内では統一すべきですが)
>
> 別の言い方をすると、ある慣習を使うか使わないかは、
> どの慣習の使用数が一位かを決めるという話ではないのです。
Re: (スコア:0)
SAStrutsもS2Tigerも、Javaの一般的な命名規則にしたがっています。
Operations#eqは特殊な例ですが、敢えて省略形にしている明確な理由があります。
(Operationsの他のメソッドや使用方法を考えればなぜ省略形にしているかは明らかです)
なぜ省略形にしているのかという理由は無視し、特殊な例のみを都合よく取り上げて、
「SAStrutsでも使ってる。だから、自分のコードは間違ってない」という主張はどうなんだということ。
まるでSAStrutsが一般的な命名規則を無視して省略形を使いまくってるみたいじゃないですか。
つーか、『長く維持されてきた慣用的な用法が別に規定している場合』をここまで曲解するならなんでもありじゃね?
Re: (スコア:0)
#1809055 [srad.jp]だけ読むと「メソッド名を理由なく省略するのは間違い」という
話に見えてしまうので、
#1806894 [srad.jp]からの流れを読んでみてください。
「単に省略したわけではなく、こういう慣習があるんだよ」という話です。
(省略の是非はそもそも議論していない)
> つーか、『長く維持されてきた慣用的な用法が別に規定している場合』を
> ここまで曲解するならなんでもありじゃね?
「eq」の是非で平行線を辿っている原因は、
「長く維持されてきた慣用的な用法」にJava以外の出身も含めるか、
というスタンスの違いでしょう。
「eq」や「gt」などの名前は最古の高水準言語と言われるFORTRANや、
シェル
Re: (スコア:0)
論点がずれてます。
仮にSAStrutsに同値比較のメソッドがあったら、equalsと名付けられるでしょう。
そういう意味で、「仲間ではない」といっています。
個人的には、cosの例を挙げて、件のコードが正しいとするのはどうかと思います(得られるメリットがないので)が、
あなたがどう考えるかやEffective Javaをどう解釈するかはあなたの自由です。