アカウント名:
パスワード:
第一線のエンジニアという言が真ならば、今時のプログラムなんて楽勝です。GUIだってネットワークだってLLだって、一皮向けばC言語とアセンブリの世界に突入です。ゼロから始めた初学者がJavaで「同じ単語を格納したstringの比較が真にならない」件で悩んでる間に、たぶんJavaに加えてP*言語ぐらいはマスターできてるんじゃないかな。
きちんと基礎の基礎が身についてる人っていうのは、応用習得はびっくりするぐらい早いもんです。私の実例でも、Cとアセンブリしかやってこなかった人が、わずか1週間で、経験3年の奴に勝るとも劣らないC#コードを書いていましたよ。さすがにOOな所は厳しかったけど、delegateやクロージャをばりばり使いこなしてました。
もちろん今時の、オープンフレームワークを切り貼りするプログラムについては数多のライブラリを時間をかけて1つ1つ知っていくしかないのだけど、それは必要になったときにすれば充分じゃないかと。
あ、でも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」なのは自明なので、追加情報としては役に立たない。省略が嫌な場合には「
> 「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/do [sun.com]
最初に。別に個人攻撃をしてるつもりはないです。そのように受け取られたなら申し訳ない。
> ●変数名「lhs」と「rhs」について> Javaに限っても、標準APIで特に断りなく使われています。
これは私が無知なだけでしたね。失礼しました。せっかくひとつお利口になったので、二項演算の処理を書く機会があれば使っていこうと思います。
> ●メソッド名「eq」について
うーん。どうも誤解されてるようですけど、『「equals」の略として「eq」が変だ』って言ってるわけじゃないんですよ。『同値比較メソッドの名前は「equals」のほうが一般的だ』と言っています。挙げられてる例
あなたが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)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
楽勝です (スコア:5, すばらしい洞察)
第一線のエンジニアという言が真ならば、今時のプログラムなんて楽勝です。
GUIだってネットワークだってLLだって、一皮向けばC言語とアセンブリの世界に突入です。
ゼロから始めた初学者がJavaで「同じ単語を格納したstringの比較が真にならない」件で悩んでる間に、
たぶんJavaに加えてP*言語ぐらいはマスターできてるんじゃないかな。
きちんと基礎の基礎が身についてる人っていうのは、応用習得はびっくりするぐらい早いもんです。
私の実例でも、Cとアセンブリしかやってこなかった人が、わずか1週間で、経験3年の奴に勝るとも劣らない
C#コードを書いていましたよ。さすがにOOな所は厳しかったけど、delegateやクロージャをばりばり使いこなしてました。
もちろん今時の、オープンフレームワークを切り貼りするプログラムについては
数多のライブラリを時間をかけて1つ1つ知っていくしかないのだけど、それは必要になったときにすれば充分じゃないかと。
あ、でも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」なのは自明なので、追加情報としては役に立たない。
省略が嫌な場合には「
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/do [sun.com]
Re: (スコア:0)
最初に。
別に個人攻撃をしてるつもりはないです。
そのように受け取られたなら申し訳ない。
> ●変数名「lhs」と「rhs」について
> Javaに限っても、標準APIで特に断りなく使われています。
これは私が無知なだけでしたね。失礼しました。
せっかくひとつお利口になったので、二項演算の処理を書く機会があれば使っていこうと思います。
> ●メソッド名「eq」について
うーん。どうも誤解されてるようですけど、
『「equals」の略として「eq」が変だ』って言ってるわけじゃないんですよ。
『同値比較メソッドの名前は「equals」のほうが一般的だ』と言っています。
挙げられてる例
Re: (スコア:1)
●「eq」というメソッド名について
> 挙げられてる例はどれもクエリの組み立てなんかに使うもので、
SAStrutsのeqは内容の一致を表すので、同値比較ですよ。
また、制約ソルバや抽象構文木の同値比較ノードの場合、
意味的には同じことではないでしょうか。
(操作をデータとして表しただけなので)
それとも、返値の型がbooleanでオブジェクト間の同値比較を行う
メソッド以外は全部別物扱いということでしょうか?
そうだとしたら、問題設定自体に無理があります。
2つのObjectを引数にとるstaticメソッドの同値比較は
標準APIに存在せず、個々の開発者が自作してい
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をどう解釈するかはあなたの自由です。