[Java]
内部的にunicodeだから日本語つかえるけど・・・いくら英語苦手だからって・・・
投稿者からのアピールポイント
これを書いた先輩に「英語で書きましょうよ！」と言ったら、「頭が固い」と一蹴された。そういうことじゃない。 ちなみに先輩はこれをコードアシストの無いただのテキストエディタで、日本語入力を巧みにon/offしてコーディングしているから、ある意味すごい。
class 会員 {
private int 会員番号;
private String 名前;
public int get会員番号 () {
return this.会員番号;
}
public String get名前() {
return this.名前;
}
public void 入会する() {
....
}
public boolean 会員状態をチェックする() {
....
}
....
}
使い方ヒント: 「これは臭う」という行を見付けたら、各行の
をクリックしてマーキングしておきましょう(要Twitter OAuth認証)
コメント(82)
別に悪いと思わない。:-P
日本語使ってもいいと思うけど、その時はパスカル／キャメルに関する標準的な命名規約を適用できないんで、ガラパゴス規約をさらに重ねないと不便かも。プライベートメンバにはアンスコつけるとか、そういうたぐいの。
英語だかローマ字だかわからんクソみたいな変数名付けられるよりマシだからコード中に日本語使える言語だとむしろ推奨してるな。 あと「会員状態をチェックする」みたいにちゃんと「てにをは」をつけてるのは素晴らしい。漢字の羅列で呪文みたいになってるのはクソ。
あえてヘンだとは思わないし、動作メソッドなどは可読性もいいが、なぜそんなにゲッターセッターわざわざ作って、頑に get/set つけたがるのか。目的を考えよう。
予約後にも非ASCII文字が使えないものか、と、lambdaという予約後を持つ言語を使うたびに思う
予約後にも非ASCII文字が使えないものか、と、lambdaという予約後を持つ言語を使うたびに思う
get/set はJavaBean の規約で、無いとリフレクションが辛くなるので、つけているのかな。 あえて突っ込むとしたら、会員状態ってなんだってのと、会員状態である() ってほうが個人的にはしっくりくる、というかそれならis会員状態とかになるのか、とか想像が止まらない。
boolean なんだから、どっちであるかをはっきりさせないと。会員番号持ってたりするし、状態ではなく「isプレミアム会員」あたりじゃないの？
いっそすがすがしいけど、get会員番号 ()はなあ… アクセッサにはgetつけないと社内規約なり開発環境の支援機能の都合なりでなんかマズイことが起こるんだろうけど。アクセッサ関数名には頭に「get/set」をつけるか、もしくは末尾に「取得/設定」をつける、とか規約変えてからやればいいんじゃない？
いっそすがすがしいけど、get会員番号 ()はなあ… アクセッサにはgetつけないと社内規約なり開発環境の支援機能の都合なりでなんかマズイことが起こるんだろうけど。アクセッサ関数名には頭に「get/set」をつけるか、もしくは末尾に「取得/設定」をつける、とか規約変えてからやればいいんじゃない？
「あり」って意見が意外と多いのに驚く。 信じられない。 開発現場の違いなのかなぁ・・・。
メソッドやフィールドに非ASCII名は場合によってはあり。が，パッケージ名やクラス名はASCII限定にするべき。Javaの仕様では，これらはディレクトリ名やファイル名と密接に結びついている。異なるOS・ファイルシステム間で非ASCIIファイル名を交換するのはトラブルのもと。
某社のフレームワークだとDB定義書から勝手に日本語変数とか生成してくれたりするんだよなぁ・・・・（遠い目）
全角スペースとか長音と全角ハイフンとかちゃんと区別する、間違えない、を克服できればアリ。たいてい克服できないけど。非ASCIIと言う点ではFORTH系がフリーダム。
こういうのアリって言う人、動けばいいって考え方なのかな。
ないわー。
これ、ファイルとしては 会員.java で、コンパイルすると 会員.class ができるのか。そう思うとスゴイな。Windows - Linux間で移行したときにファイル名が化けて爆死しそうである。
(:])『 文字化けよりもファイルサイズの無駄な増大が問題だね～
日本語Classとか使うと、ビルド環境と実行環境が別OSの場合、ビルドは通るがClassNotFoundExceptionになったりするから、迂闊に使うと痛い目に合う。
テストコードなら普通だけど
全角文字をシンボル名には使わないとしてるけど、動作に影響が無ければアリ。
アリ。識別子が英語でなければならない絶対的な理由はない。国内限定なら、日本語（漢字）の方が可読性は高い。変換がメンドウという意見はあるだろうけど、書くときの苦労よりも、後で読むときの苦労を減らした方が幸せ。
日本語プログラミング言語を使おう!
日本語で問題がないことが充分に検証されているならあり。でも、何も自分が人柱になることはないと思う。 インテリセンスとか働かなくて結局イライラしそうだし、ファイル名はアスキーじゃないと危険。命名規則も先人にならうことが出来なくなる。 予約語は混じるわスペース区切りは日本語に合わないわで、結局可読性が本当にあがるとはちょっと思えない。
臭うコメントにもを付けられないと片手落ちだな。
なにが臭うかって「プログラマーのくせに考えずに良し悪しを論じていること」 不都合があるなら何がまずいのかくらい考えないと。 「文字に統一感がなくなる」と言いつつ統一感のないカラフルな文字でコード書いてたり。
昔の「1つの関数は1画面32行まで」みたいな作法。 今だけしか通用しない小手先ルールを後に残るコードに使わないでね。
現状”なし”だけど、理想的なんじゃ？開発メンバーが日本人だけなら。
これ単品だけ出されても「動くからいいんじゃね ?」って言う人続出しそうだな。これがたとえば Bean とかで、Web アプリケーションで使うことを想定してるなら getter/setter が正しく動作する保証はどこにある ? その意味でも変数名・メソッド名にマルチバイト文字を使うことがいかに危険かわかると思うんだが。
そんなに日本語でプログラミングしたいなら「ひまわり」か「なでしこ」でも使ってろってこった。
DBだけど某所でアンケートしたら、日本語のカラム名使うって人多かったよ。 更に対応するクラスのプロパティ名も同じく日本語使うって人多かったよ。 これは.NET界隈の話だけど。Javaならなしだよね。
実行時のファイルにマルチバイトが残っちゃうから、マルチバイト非対応のOSで動かない可能性があるのは javaとしては排除したい案件かも。
DB 側ならば日本語テーブル名や日本語カラム名はあってもいいのかもしれない。CakePHP とか RoR とかじゃないんなら動かせるし、顧客がそれを望むならそうするべきだと思う。ただソース側で変数名やメソッド名に日本語はやはりやっちゃいかんと思う。
ああ、仮にウチの部署がどんだけブラックであっても、マルチバイトを成果物に入れるのに躊躇いを感じないような メンバーで構成されていない事は、不幸中の幸いだ。
メンバーが居たら、ウチの部署はきっと、闇より暗かったさ。
ケーキが食べれないならコメントやドキュメントからも日本語排除しちゃえばいいじゃない。
ぴゅう太を彷彿とさせるね
これはJava言語の正しい使い方。これが動かないウェブアプリのフレームワークなり周辺ツールがあれば、それはそれらのバグ。 論理的に考えるならば、Javaの言語仕様がマルチバイト文字の名前を認めている以上、getter/setterが正しく動く保証とはJavaの言語仕様に他ならず、ウンコなのは動かないフレームワークやツールの方。
あまり真面目に検証したことないので推論だけれど、上の諸氏は、Javaネイティブのクラスローダが、クラス名のプラットフォーム依存に対応してない、と言ってるんじゃないの。
あと、これはこちらのミスリーだったら申し訳ないんだけど、「出来ること」と「やってよいこと」と「すべきこと」を繋げて議論するのはあまり好きくない。全部違う話題なので。
Java言語でマルチバイト文字を名前に使って、どんな実害があるの？ファイルシステムがマルチバイト文字を通さない場合だけのはず。 で、あなたがたのプログラムは本当にそんなプラットフォームで動かさないといけないの？動かすことがあるの？ これは、「出来ること」で「やってもよいこと」。プロジェクトの規約で決めればいいだけ。 さらにテーブル名やカラム名が日本語で設計されていて、Beanのgetter/setterまで自動生成するとかフィールド名とカラム名を一致させるという設計方針ならば、むしろ「すべき」でさえある。 なにがなんでもマルチバイト文字は成果物にいれちゃだめなんてのは、今時あまりに盲目的。どうせコメントや文字列には日本語書くんでしょ？
おや、長文ありがとう。こんなところで真面目な議論に花を咲かせる気はないから答えないけど、こちらの言葉のニュアンスが期待通り伝わってないんだなぁ、という点がちょっと残念。まぁ、自分の文章力の問題なんだろうね。うん、そうなんだろう。
「貴方が踏むまで」はなかなか気づかれないもんだが、ウンコってのは道端のあちこちに落ちてるもんだ。解釈はご自由に。
ぼくの言いたいのは、「なんで、どういう場合にマルチバイト文字の名前がいけないのか」ほんとにちゃんと考えてる？調べてる？理解してる？ってことなんだけどね。こういう思考停止は「定数に切り出せ」と言われて「ONE=1」ってやるのと同レベル。そういう意味ではよりウンコを踏みそうなのはあなたの方かもね。クラスローダの挙動を詳しく調べれば、ぼくが前のコメントで言っていた意味がわかると思うよ。
あと、「これで動かなかったらフレームワークやツールの方がウンコ」って言ってるけど、じゃあ例えばこれが Struts で動かなかったらあなたは Apache に「このウンコが !」って言うわけですね ?
まぁ、この程度の話題でいがみ合っても仕方ない。世の中いろんな価値観の人がいるよね、ってことでいいんでないの。
Ukai_Hさんって若い人なんだろうなぁ、と勝手に想像してしまった。学生の頃の自分の発想とそっくりなんだもの。
そう考えると、自分も場数を踏んで、だいぶん濁ってしまったなぁ、と思う。いい意味でも、悪い意味でも。
コードを海外に出す可能性がある場合を除けば、筋論としてはこれを否定するのはやはり思考停止だな。実用的にはライブラリやツールのバグを踏むリスクとのトレードオフ。
日本国内で使用する。エディタ側で色分けされている。という条件が付けばアリだと思うけど、これがもしアラビア語とか中国語、韓国語とかで書かれていたらと思うと死ぬ。そーいうのはコメントだけにしといてお願い。
get/setはbean仕様に沿ったものだろう。使えるなら使えばいいと思うが入会する()と会員状態をチェックする()は名前がアレだと思う。
Javaがコンパイルエラーにしないのが悪いの？
悪いのは、マルチバイト変数名なんてコーティング習慣が世間一般では少数派だって事だね。ウンコが考を労しようが、その点から保守性の低さが指摘されて、それを覆せない妥当な理由を見つけられない。生産性と保守性を落とすコードはどんな理由があろうと、ウンコに変わりないんだからね。
統計学とかのよくわからない専門用語の英語とかが出てくるならアリだと思う。 あとリフレクションを使ってExcelみたいにユーザーが入力したマクロをコンパイルしてメソッドを呼び出す機能を実装するとかならこれでいいと思う。 （自分はこのモジュール使いたくないけど）
単純に読み難いし、ファイル名が 会員.java となると扱いづらいな。 (あと、入会する() はこのクラスにはいらない)
徹底できるのなら有り
ロジック側で日本語は絶対に使わないけどテストケースのメソッド名は日本語にするかなー 「AのBがCの時Dであることを確認する」とかいちいち英語にすんの面倒くさいから
ひどいとは思うけれど英語名を付けずにローマ字名をつけるよりはこっちの方が潔くて好きだわ。
一部誤解してる人がいるようだけどJavaは識別子にUnicode文字を使っていいと仕様書に明記してあるから識別子に漢字を使うのは言語仕様上何ら問題ない。 よくある「仕様外だけど処理系の動作上たまたま日本語が通っちゃう」という話とは分けて考えたほうがいい。
入会する（）で吹いたわｗｗｗｗ
動くか動かないかどうかよりも、日本語はコメントで書けばいいと思う。
実用上ではエディタの補完機能が使いにくくなるというのと（get会員番号じゃなくてgetIDならエディタによってはgidなどと入力すれば補完できる）、 日本語の識別子のための規約や慣習なんてものが殆ど無いから識別子の恣意性が増す（「に」と「へ」や「が」と「は」の使い分けを一々規約で定めるのか？）というのも一応あるよなあ。
こういうのが鬼のようにあるので英語にされるとコメントだらけになってしまう。 public flort 低温割れ防止限界予熱温度(flort 溶着金属拡散性水素量 ...
SQLかと思った
Java 1.0.2 のころの Symantec VisualCafe のサンプルコードにこんなのあったよ。 ちなみに当時のSunのJavacではエラーとなった。
程度問題だけどさー。上で 低温割れ防止限界予熱温度 とか書いてる人もいるけど
- 可能かどうか(問題なく動作するか)
2012年当時でも.NET環境は問題なく、Javaは問題ある可能性があった…？ - やってよいか(規約適合・当然の推論として)
国際化前提ならNG、規約違反はNG。
平易自明な英単語(上例なら会員はMemberとか)はNG。入力切替の手間や一般慣習に反する。 - すべきか
平易自明な英単語が無いことが自明な場合、その表現と頻度によってはすべき。
てかドメドメなSIなんて仕事の８割そうなんじゃ…。
例えば警察用の日報アプリを仕事で作ってるときに
職務質問のclassなりが必要なときにQuestionとかInterrogationとかはまだ頑張れる。
でも道交法適合とか酒酔いと酒気帯び、飲酒検知拒否とかの定訳も無いものを個別に訳していくか？費用対効果は？その訳は正しいのか？訳の正しさもプログラマが保証するのか？
とかとか考えたら、 1, 2 の条件さえパスして必要性があるなら、日本語使うこと自体を拒否する理由無いとは思うよ。2012年当時はまだマルチバイト処理が適当で実行環境によってエラーになった頃の名残が強かったけど。
コメント投稿には、twitter認証が必要です。
Twitter認証
和英混在入力モード(ローマ字入力中かなに変換せず変換キーで一気に変換)にしておくとこういうのは比較的らくに打てるよ