日本語の識別子を使うと馬鹿にされる風潮

変数名やルーチン名で、全角を使ってると無条件に馬鹿にされる世の中っておかしいよな。

怪しい英語や、暗号みたいな略号、読みにくいローマ字を使うくらいなら、
潔く漢字やひらがなをつかったほうがよっぽど読みやすくなるよ。

全角を使わない理由で「トラブルがおきる」以上の説明をしてるやつなんて見たことない。
本当は素人っぽく見られるのを心配してるだけなのにな。

全角は入力が遅くなる。

文字コードが乱立している日本語でソースコードを書く人間は愚か者としか言い様が無いが、
>>1 はこれ→ http://fortress.sunsource.net/ を使ったら良いんじゃないか。

そもそもまだまだ使えないことも多い。
Visual C++でもようやく2005から使えるようになった。

>>3
日本語でコメント書いてて、文字化けに困ることなんてめったにありません。

>>4
VBは大昔から使えるけど、なぜか普及しなかったね。
.net系や、rubyでも使える。

>>1
> 怪しい英語や、暗号みたいな略号、読みにくいローマ字を使うくらいなら、
ここまで比較対象のレベルを下げないと大手を振れないモノだ、ってことはわかってるんだな。

「怪しくない英語」「暗号のようでない略号」「読みやすいローマ字」で命名できないのなら
馬鹿にされて当然。

>>7
業務固有の用語なんか、そうとう英語力ないと、うまく英訳できない。

つか、日本語で命名するのって、逆に難しくね？
うちの会社はクラス管理簿にクラスの日本語名を登録しなきゃいけないんだけど、
いつも英単語をそのままカタカナ読みした名前になっちまう。XXマネージャとかXXファクトリとか

怪しい日本語、仮名漢字を使った暗号みたいな略号も有り得るだろうから、これは日本語にしようという理由としては少々弱いと思う。
仮名漢字を使えば怪しくない日本語、暗号みたいでなくなるなんてのは幻想だよ。
駄目な奴はどんな文字でも同じように駄目。

日本語で命名されたソースは、書くときも読むときも
精神が「そこで一端引っかかる」んだよなー。踏み切り前の一時停止みたいに。

>>10
まあ、もともと業務で「怪しい日本語、暗号みたいな略号」みたいな用語が
大量にあるけど、それを怪しい英語にするってステップがなくなるだけでもだいぶましになるとは思う。

全角とかいってるあたりで駄目っぽい人に見える。

関係ないが、どの板に行っても見事なまでに
「全角英数字」を使って書かれたレスの内容って厨率高いよな。
不思議なくらい、板に依らず成立してる。

>>9
この場合は日本語命名が云々よりも管理規約がおかしい。
クラス管理簿なんて作っても何の役にも立たん。

エクセルVBAの時は日本語で命名する。下請けルーチンは英語だけど。
送り仮名とか、日本語の表記ゆれのほうが、英語の表記ゆれよりもイライラしそうだから、あまり日本語で命名しないほうがいいと思う。

日本語は同じ同義同音のものに対してすら
複数の記述の仕方がある可能性が頻繁にあるからなあ。

たとえばこんな項目の変数がいるときはみんなどうしてるん
今はしょうがないからローマ字表記で書いてるんだけど…

固定資産税率
固定資産税額
小規模住宅用地
一般住宅用地
耐火構造
納税時期

>>13
あまりそこらへんは深く考えないようにしてる。
「漢字や平仮名や片仮名」とかだったら冗長だし「日本語」だとローマ字表記も
日本語だってツッコミ入れられるし、コードの名前で云々だと、unicodeとかsjisとか
コードによらずに、アルファベット以外の文字のことを言うのって、いい言い方を
思いつかないし。
(「asciiに入ってる文字以外」とかってのもなんだし)

2バイト文字でいんじゃないの

>>20
unicodeだと、3バイトだったり4バイトだったりの可能性も。

という以前に「nバイト文字」なんて長くていちいち打ちたくないよ。
日下部陽一みたいなキチガイ以外には通じるだろう、全角で。

>>22
void にだって通じる。
ただ、この業界にいてそういう表記するのは
あまり頭がよくない、と思われる事があるだけ。

奴には通じない。

プログラムは、わかりやすく・・・

$ cat ほげ.java
public class ほげ {
　public static void main(String[] 引数) {
　　for (int 整数 = 0; 整数 < 引数.length; ++整数)
　　　System.out.println(整数 + ": " + 引数[整数]);
　}
}
$ javac ほげ.java
$ java ほげ ふが もが
0: ふが
1: もが
$

ついうっかり紙を剥がし忘れたカステラを口に入れたみたいな異物感・・・

>>25
IMEの切り替えがめんどい

メイン -> main
システム -> System
...
とかで、辞書に登録しておくとか。

>>18
taxRateFixed
taxAmonuntFixed
miniHomeGround
generalHomeGround
stopFireStruct
seasonPayTax

なでしこでも使えば？

>>29
ここまで酷いのは見たことない

>>18
俺がコボラーだった頃の会社のコーディング規約だと
およそこんな感じだな。
ktsszr
ktsszg
skztyt
ipztyt
tkkozo
nzziki

こんなの読めねーよ。

俺は、ｃ＃野郎だから、識別氏は全て日本語で書いている。
だが、日本語で書くと、基本的に文字がでかいので、識別子が長くなると言う欠点がある。
そこで、半角カタカナを混ぜると、短くなって、全体的に見やすくなる。

使ったことないけど、
そろそろ使った方がいいじゃないかと思い始めますた

書く時に毎回辞書サイト見て考える時間を考えると、
一人なら日本語でサクサクでいいかもしれない

>>5
滅多にないということは、希にある、ということだね。

>>25
わかりにくいな。

なんだよ、その「整数」ってのは。
int int1 ;
みたいな変数宣言と同じくらい恥ずかしいぞ。

>>34
> 書く時に毎回辞書サイト見て考える時間を考えると、
会社の金で勉強できるなら、いいことじゃない。
そのうち英語の資料や論文も読まなきゃいけなくなるんだし。

1.ローマ字で入力
2.ショートカットキー押す
3.ローマ字→ひらがな変換をしてIMEをON
4.候補表示・選択
5.入力確定，IMEOFF

ここまで自動でやってくれるエディタがあればいいのにな。

慣れだろうと思う。

昔は俺もデータベースのカラム名を英語表記してたけど、
(日本語で書くと問題が色々あったからな。)
最近は日本語そのままで書くようになった。

まじめな話し、やはり理解しやすい。英語ネイティブな
奴らは、やっぱり有利だよなぁ...、と思ったよ。

でも、そんな俺でもまだ識別子に日本語を使うのはちょっ
と躊躇してるんだが、入力がもう少し楽になればいいのか
も知れない。

>>37
入力されたローマ字ごと覚えておいて、インテリセンスで
選択肢を表示してくれればいいと思うよ。

IME は、学習によっていちいち違う候補が表示されそうで、
いらいらする元となると思う。

やっぱネックは変換だよな。
特殊なインテリセンスのサポートがないと、面倒いし typo しやすい。

表記はローマ字で，表示は日本語でってのはどうだろう。

migemoというライブラリがあってだな

日本人にしか読めないソースコードを書くのは、どうかと思う。

ソースコードのコメントがアラビア文字で書かれていたら、おまえらどう思うよ。

オープンソースプロダクトじゃなければ別にいいんでね？

日本人しか読まないソースのコメントを英語で書くのってどうなの？

英語を上達させる手段だと思うしかないなw

>>35
その、まれさかげんと、日本語識別子の読みやすさをどう評価するかって問題だよね。

>>42
すでにコメントは日本語だし。

２バイト文字使いたい奴は勝手に使えよ。














ただお前のオナグラミングのときだけにしろよ。

>>43
日本語が読める人間が保守するとは限らないよ。
アホな上層部が、せっせとソースコードを中国に送ってるからなぁ・・・orz

>>44
コメントは日本語で書けばいいと思うよ。
機械翻訳しても、誰かに翻訳させても、なんとかなるから。
日本語の識別子を後から英語に翻訳させるのは、ちょっと怖いよ。

>>45
和製インチキ英語が身につくだけです。

中国で保守させるとしたら、なんちゃって英語と日本語とどちらがいいのだろうか。。。

>>49
> 日本語が読める人間が保守するとは限らないよ。

そもそも仕様書とかのドキュメントはどうなってるんだ？

仕様書等も外国語で書かれてるなら、コメントもそれに合わせるべきだろうな。

> 日本語の識別子を後から英語に翻訳させるのは、ちょっと怖いよ。

なんで？ 一意に対応してれば別に問題ないし、そもそも変な英語でソース書い
てる奴がいっぱいいる現状と同じことだろ。

>>50
その保守させるところの質に依存する。

(技術系の言葉に限るのかもしれないけど) 日本語としてちゃんと通じる言葉を
読み書きできる中国人はいっぱいいるよ。

日本語のコメントの語尾をアルにしておけば何とかなる

>>51
> そもそも仕様書とかのドキュメントはどうなってるんだ？

ドキュメントも、どこかで翻訳しているらしい。

> なんで？ 一意に対応してれば別に問題ない

そりゃそうなんだけどね。

＞　　for (int 整数 = 0; 整数 < 引数.length; ++整数)
＞俺は、ｃ＃野郎だから、識別氏は全て日本語で書いている。
＞そろそろ使った方がいいじゃないかと思い始めますた
＞まじめな話し、やはり理解しやすい。英語ネイティブな
＞その、まれさかげんと、日本語識別子の読みやすさをどう評価するかって問題だよね。

斯くの如く、日本語識別子推奨派はお郷が知れている。
#ネタもありそうだが。

今回も、日本語識別子否定派の合理的で説得力のある理由はでないで終わるのであった。

そして明日からもやっぱり日本語識別子肯定派は
馬鹿の烙印を押されながら生きるのであります。
不器用を越えて間抜け極まりない人生、乙であります。

昔のvi対emacsみたいなもんか

どっかのブログで、アルゴリズムを説明するのに、Rubyを使って、シンボルとか一部の識別子を
漢字にして、擬似言語っぽく書いてたのを見たことあるな。

最初はああいう使い方をすれば、そんなに抵抗ないかも。

日本語識別子は検索が面倒なのがなんともねえ。

>>59
インクリメンタルサーチとかで?

>>60
とかで。ていうかその時だけなんだけど、
コード書くリズムが崩れちまう。修業が足りないのかも。

インテリセンスがIMEと連動して、変換中でも、候補をバンバン表示してくれればいいけど、
ローカルな要求だから、そこまでは無理か。

Excel のオートコンプリートは変換前に候補を出すんだから、ヘルプでもやってくれていいと思うんだけどねえ

IMEの変換候補とインテリセンスの補完候補がいっぺんに出ると操作しづらいんじゃないか？

日本語に特化した何か新しいUIを考え出す必要があると思う。

>>42
そういう考え方も一理ある場合もあるな。そういう時は当然、
ソース以外のドキュメント等でも日本語禁止になるけど。

なんかどうでもいいことで体裁だけを気にする奴ばかりだな、業界の体質なのか？
他業種の俺から見ると異常だわ・・・。

単に、何がどうでもよくて何が実はどうでもよくないのか、
他業種だから判断がつかないんだろう。

「体裁だけ」とか言ってる時点で、煽り心みえみえ。スルーよろ。

思考が中断されるのがもうダメなんだよなあ。＞日本語識別子
>>25のコード打つのに、何回日本語入力をトグルして、
何回変換候補を回すんだろう。
怪しげな英語でもローマ字でもいいんだが、
それに比べて圧倒的に入力が遅い。

T-CODE みたいな直接入力が出来る人がウラヤマシイ。

>>69
読むのが楽だから、保守でおつりがくるかもよ(こないかもしれんけど)

うーん、読むの楽かなぁ・・・

for(int 整数 = 0;

とかいう変数名をつけることの出来る時点で狂ってる。

for(整数 番号 = 0;

とかならまだしも。



でも、意味的にとんちんかんだったり、
理解するのに変なイディオムの知識が必要な英語を使われるよりはまだ良い。

型なしのアプリケーションスクリプトでなら日本語識別子も悪くないよ。
C++で使う気にはならない。

どうせ本格的にソースを読まなきゃならないなら置換すればいい分だけ「変な英語」の方がマシな希ガス。
#漢字一文字の変数だらけだったら置換もままならない……

つ正規表現

旧字を使って困らせる年輩社員

for (int い = 0;
    for (int ろ = 0;
        for (int は = 0;

ソース読む作業は検索する時間が多数。
検索語句入力する時、ASCIIと日本語じゃすごい差よ。

ダブルクリック+Ctrl-Fだろ普通

>>72
そういうのは
for (int i
とかでいいだろうけど、

int 標準価格;
int 値引き後価格;

とか、使いたくね?

>>79
右クリックして、定義位置とか参照位置とかにジャンプできる環境もあるしな。

標準ライブラリの関数やクラス、予約語も日本語になってるCやJavaがあったと思うのだが、どうなったかは知らん

変数宣言の横にコメント書けばいいじゃん。

>>60
漢字を読み仮名でインクリメンタルサーチできるようにすれば、使い物になりそうね。

秀丸でコードを書く人が、いまだに、いるのですが。
勘弁して欲しい。

やっぱ vi だよな

ed だろ

cat > hogehoge.c

時代はパンチカード

コメント内に絵を描きたい
さらにはhtmlを記述したい

VS2005で普通にIDEから、コントロールをダブルクリックで日本語名のメソッドが作られるなｗ

>>91
余計なお世話な日本語化ってやつだなぁ。

>>90
まったく、いつまでプレーンテキストなんだよ、進化ないなぁと思う。
紙に赤ペンで書き込むかのように、自在にコードにコメントを書き込みたい時もある。
とはいえ、互換性とか考えると、しかたないのかな。

コメントが便利になるってのは、進む方向が間違ってる。

>>92
Doxygenならhtmlも書ける。

HTMLで書きたいわけじゃあないんだ。

ソースコードをプリントアウトした紙に赤ペンで書き込むような感じでコメントを入れたいんだ。

ソースコード＋メタデータなエディタを作ればいいじゃない
ペンタブで書き込めるようにしてくれると嬉しいな

コメントにhtmlを書きたいってのは、おそらく、htmlのソースを書きたいってことじゃなくて、
レンダリング後のhtmlのような表現とか機能とかをちょくせつソースに書きたいってことなんじゃないの?
そういうのは方向性としてちがってると思うけど。

つまり、そういうエディタを作ればいいと言う話だな。
>>92
がんばれ。

> とはいえ、互換性とか考えると、しかたないのかな。
> とはいえ、互換性とか考えると、しかたないのかな。
> とはいえ、互換性とか考えると、しかたないのかな。


まぁ、そもそもソースコードの原本がプレーンテキストである必要はないわな。
コンパイラに渡す部分だけプレーンテキストにすればいいんだから。

でもやはり、互換性の問題は残るね。
バージョン管理システムにどうやって突っ込むか、
独自のエディタではないものを使う人への対応や、
独自のエディタを使うのをやめた場合の後片づけなど。

ソースコードが、その独自のエディタと心中するようなのはダメだからね。

純ソース部分を引っぺがしやすいようにpdfみたいなフォーマットか
OpenDocumentみたいに純テキストのソースと別にファイルを持ってそれらをアーカイブするかってところかな。

各言語の文法に沿ったコメントとして、データを埋め込むのはどうか。

原本がプレーンテキストであるがゆえの欠点、
そのままコンパイルできなくてはいけないという制約から生じる欠点
というのは、そのまま残るけどさ。

base64とかishみたいにすれば良いのか

コードだけ修正して、
コメントを修正せず、
コードとコメントの対応が崩れる
ということになりかねないな。

そんなの今でもあるけどね。心がけ次第じゃね？

おまえらWEbとかKnuthとか知ってるの？

TeXとかいう糞言語開発したやつのこと？

accessで造ったちっさい社内アプリでやったな>>日本語テーブル名＆カラム名＆クエリ名

なんだ禁じ手だったのか。

日本人ならやっぱ縦書きだろ

>>108が良いこと言った！
誰か縦書きの日本語プログラミング言語作れよ。

>109
縦書きエディタ使って、なでしこで組めば良いんじゃね？

今時、日本人でもポエムと漫画ぐらいしか縦書きじゃないゾナ

小説と新聞と雑誌も

>>108-110
後の「縦の会」である

＞今時、日本人でもポエムと漫画ぐらいしか縦書きじゃないゾナ

小説、雑誌、新聞等を一切読まない人ってホントにいたんだ。
ゾナとか言ってるし・・・

>>104
コメントに埋め込まれた何かに対応していない、
一般のテキストエディタでコードを編集したら、
心がけとか、それ以前に、対応が崩れますが。

>>107
むしろ、名前だと明らかになって、SQLが読みやすいよ。
予約語とのバッティングも気にしなくてよくなるしね。

Oracleだと避ける傾向が強いけど、
HiRDBとかだと当たり前のように日本語使ってるな。

>>117
>Oracleだと避ける傾向が強いけど、
そら、動く保証ないからね。
(10g 以降はどうだか知らんが)

日本語が通るようにUnicodeにしよう → レコードが倍の長さになるからダメ

というのが辛い。

身内でつかうちょっとしたツールをC#で作るんで、ためしに変数を漢字で書いてみた。
最初は変数名を考える必要がないんで超楽だと思ったけど、すぐに入力がめんどくさくなってムカついてきたよ。

普段は全角ひらがなにして、半角英字の時はＦ１１を押す

そしてスペース押した時にF11押し忘れて、
なんか分からないけどコンパイル通らねえクソー
とか言うわけだ。

>>1
2バイト文字のプログラムを開発したらいいんじゃない？

ひまわり
なでしこ

>>119
> 日本語が通るようにUnicodeにしよう → レコードが倍の長さになるからダメ

何を言ってるんだろうか...。

>>122
IME の設定を「スペースは常に半角」に設定しとけはいいじゃん。

○○丸出しのｽﾚはここです。

ω丸出しのスレはここです。

記述性を取るか、
見易さを取るか、
だな。

記述性と解読性と書いた方が良いかな？

読解性と書いても良いか？

>>115
今でもコメントに何か埋めることはあるだろ？
doxygen だのなんだので。

>>1は桐でも使ってろよ。一生。

>>122
C#は全角スペースでも通るね

>>130
doxygenのコメントは人間にも読み書きできるものでしょ。

図表のデータをエンコードしたものは、人間には読めないよ。

>>133
だから何なんだよ。
みんなそんなことはわかった上で話してるだろ？

確かに図表だろうがなんだろうが、そこに符号化されて
置かれていることさえ理解することができれば
それを避けて編集すればいいだけだからな。 // P3 3 3 1 0 0 0 0 1 1 0 0 0 0 1 1 0 1 1 0 1 1 0 0 0 0 1 1 0 0 0
例えば前の行に符号化された画像を貼ってみたが、
別段困ることは何もないな。
#ちなみに↑は所謂ppm形式なので正しくフィルタリングすればちゃんと画像になる。

>>135
そういう話じゃない。

図の内容を更新せずにコードだけを修正したら、
わけわかんなくなるよ、という話よ。

だからそんなことはみんな当たり前だと思って話してる。

doxygen なんかは、ソースもコメントもテキストだから、
テキストエディタで両方修正できるだけのこと。

かたっぽが図表なんかでも一緒に編集したかったら、そうい
うエディタを作れば済むだけのこと。

どっちにせよ、現状ではソースとコメントは心がけが悪いと
対応がすぐ崩れてしまうと言うのが >>103-104 の話。

HTML みたいに読める形ならいいわけだろ？
というか、HTML 埋め込んだらいいんじゃね？

>>90 あたりから読み返しておかないとまたループするぞ

だから、専用のエディタを通してみれば
HTML エディタみたいに絵がソース内に貼り付いてるように見えて、
普通のエディタから見ればタグになってるってだけの話なのだが。

うわっ、またレベルの低い奴がきたもんだ。(w

専用エディタは受け入れられにくいような気がする。
固定ピッチフォントを前提として、AAで図を書くための支援ツールが
あればいいのではないだろうか。

ファイルフォーマットの説明等ちょっとした図を書くのに便利そうだし。

Prologに識別子ってないね。

：＝！．（）

それなんて顔文字？

>145
>144 は Prolog で使う記号を書いたんだと思う
ただしそれ以外にも使うハズだが…

最近のコンパイラって、全角スペースを空白と判断してくれる？

>>147
それなんて文字?
なコンパイラが圧倒的ではないかと。

JavaなんかisWhitespaceはtrueを返すんだけどコンパイラは駄目だな。
JavaっつーかUnicodeの仕様かもしれんが

>>142
#region とかおもっくそ専用エディタ用のものだよな？

専用も広まればほぼ標準

>>143 ここでいう識別子にあたるのは述語(名)や関数(名)ですね。Prologの場合はちょっと特殊で、引数側に主語があるわけです。述語はその言語系に準じますから、引数がすなわちデータ側に日本語がある場合は必然的に識別子は日本語になります。

>>152 識別子というのは　**仕様書を作成する各段階で
責任あるプログラマが決めていくもの。これを省略して
いきなりコーディングにはいることもありますが。
Prologの述語は論理的主張そのものですから、
プログラマが恣意的に決められるようなものではありません。
したがって、述語(名)は識別子ではありません。

しいてき0 【▼恣意的】

(形動)
その時々の思いつきで物事を判断するさま。

・―な解釈

[ 大辞林　提供：三省堂 ]

なるほど。恣意的という表現は適切でないか。ありがとう。
何といえばいいんだろう。
思いつきで、と言っては言い過ぎになるし、
その時々の個人的な判断で、は重たいし、
何か言い換えてください。

識別子は言語的に提供される以外のもの、
つまり、ユーザ、あるいは処理系提供のライブラリ等により定義されるものを指す用語では？

識別子って字句解析の要素のことかと思ってたよ

それはトークンでは。

要素 (=トークン) の一つだろ。

字句解析のレベルだと。

予約語とかも含まれる (構文解析で区別する) かどうかは、実装による。

Prologでは仕様が
「義朝は頼朝の父である」なら 父(義朝,頼朝).
になり、
「義朝と頼朝はparent関係にある」なら parent(義朝,頼朝).
となる。"父"、"parent"は他のプログラミング言語の
クラス名とかプログラム名に相当するが、名付けると
いうニュアンス、余地はない。

parent は名付けてるように見えるが。
is_parent でも 父 でもいいのに parent にしてるわけだし。

Prologのプログラミング作法は仕様、文書、表などを受取り、
それを出来るだけ忠実に論理式に変換することです。
>>160 は「義朝と頼朝はparent関係にある」という仕様を
プログラマが不自然と感じたとしても、そのまま
書き下ろすべきだということを示す例として書きました。
>>152 のような見解はもっともですが、そうでないことも
あるよという例でもあります。

>>161 で述べられている判断、決定は、仕様を決めていく中で
必ずありますね。プログラマと同一人の私がこの段階から関わる
ことが多いわけですから、おっしゃられる通りです。しかし、
案件を頭の中で「アレがドウだ」と文章を作りあげて、それを
述語に落としていくわけですから、
「日本語の識別子を使うと馬鹿に」されるかどうかなどということへの
配慮が入り込むことはあり得ません。

append([], x, x).
append([a|x], y, [a|z]) :- append(x, y, z).
において、a, x, y, z という識別子にコーディング時点での任意性が無いというのは
あまり同意できない。

>>164 論理変数に関しては、
これが識別子かどうかの議論になりますね。識別子であることを
否定したものが論理変数であるということでしょう。論理変数は
同一の変数があるかだけが焦点になるのですが、それでも、
_氏名 Name Shimei のように表記することによってそのクラスを
暗示することは可能です。この場合は確かに識別子的な性質も
併せ持っているかもしれません。コメントの意味もあります。
私は、読ませることを重視しているため、 _氏名 のような
表記を好みますが、少数派というよりケレンと見なされるようです。
どこに変数がありどの変数と同一であるかをできるだけはっきり
させる、そういう、論理変数の表記をすべきだというのが多数派の
見解のようです。

私は可能限り暗示した方が、

すみません。最後の一行はゴミです。枠の下に隠れていて気がつきませんでした。

名前に意味があるか否かはコンピュータの認知するところではないし識別子であるか否かを左右するようなものでもないだろう。

このスレタイで使われている「識別子」という言葉は、
メモリー領域、構造体、型、クラス、モジュール、手続き名、変数などに
付けられるラベルのことですね。
ラベルの名付けルールがテーマになっています。
>>153->>165で私が書いたことは、ラベルの名付けの由来に
関してのPrologの特異性についてです。そして、Prologで現れる
このラベルもまた、最終的にはコンパイラによってアドレス解決
されるべき対象であることは確かで、他の言語のそれと違いは
ありません。

指定された文字数だけハイフンで埋める関数を作成しろって研修中に言われて

わかりやすい関数名を考えて、umeru_hyphenっていう関数名にしたら笑われたけど、
その上司の作った関数名の方がおいらにとっては、わけわからん。

umeru_hyphen() はダメだろ、笑われてもしょうがない。

fill_hyphen() か、umeru_haihun() の方がマシだ。

もっとも ハイフンで埋める(int 文字数) が一番いいけど。(w

全角で埋めそうな名前だなｗ

問題文に「全角じゃ駄目」って書いてなかったらそれでもいいんじゃね？

全角がマルチバイトって呼ばれるようになる日は恐らく来ないんだろうな。

そりゃ「全角==マルチバイト」じゃないから、来ないだろうね。

それもそうだな。

日本語の識別子なんざ使わないし使おうとも思わない。
馬鹿にするつもりは全く無いけど、
そのようなコードを保守する羽目にならないことを祈るのみ。

送りがなで間違い連発。
縦書きで書く奴。
bidiで右から左で書いてくる奴。
�鰍ｪ"(","株",")"とパースされないのはおかしいとか言い出すやつまで。
読み方が難しいから変数名にルビ振ろうということになってエディタは
結局MS Wordに。
正規表現エンジンにあいまい検索オプション追加。

またループさせたいの？

>>177
ルビを振るなら Word より Excel だろ。

マルチバイトか。そういえばバイトの単位はビット数固定じゃないんだよな。
32ビットで1バイトのマシンがあったら Unicode は全部1バイトで表現可能だ。

正確にいうならオクテットか。
これなら間違いはないな。
うぅ、それでもLSBから送るかMSBから送るかで変わってきちゃう。

BOM

Bill Of Material

０から設計するなら日本語やローマ字読み識別子は使わないけど、
システム案件とかの場合は使われている社内用語にあわせた
ローマ字識別子を使うようにしてる。

変に翻訳というか、どれだけ上手く翻訳したところで、人間同士が
意思疎通する際の用語と異なる識別子を利用していると、似ているが
違う概念の識別が困難になって、特に後日の修正でバグが入り込みやすい。

・顧客
・カスタマ
・契約者
・契約課金対象
・申込者
・管理者
・契約管理者

とかずらずらと並んでて、最初は用語<->型・変数名マッピングを用意して
補助資料にしようかと考えたが、そもそも誰の目から見ても用語に
一致する名称にしていれば問題ない。英語に翻訳すると他の人には
対応関係が不明瞭だし、コード化しても同様。

>>1
そんな風潮ないよ。

「見たことがない」というならまぁあり得る。
「ない」というのは単に「僕の見てきたものが世界のすべて」と思い込んでるアフォ。
この二つは結構違う。

>>186
統計学的に十分なサンプル数見聞してるから「ない」よ

そりゃぁないだろう。馬鹿にされる以前にそんな香具師殆どいないんだから。

するってーとなんだ、>187は統計学的に充分なだけ日本語の識別子を使っても馬鹿にされない状況を見ているのか。
#桑原桑原w

なあ、COBOLって、たしか、ちゃんとしたソースコードであれば、英語として読めるんじゃなかったけか?
その為にわざと冗長な記法をさせたんじゃないのか?

日本のプロジェクトで日本語を使わないってのは、英語のプロジェクトで英語を使わないぐらい可笑しな事だと思わないか?

まあ、コンパイラ依存って問題があるから、なかなか難しいとは思うが

>>190
例えばHyperTalkも、
put 単価 * 個数 into card field "小計"
みたいに書くのか?
英語を理解する脳の部位と日本語を理解する脳の部位が違うのか、なんだか脳が捩れる気分だ。

なでしこが流行らない理由を考えた方がいい。

>>184
業務系のヘルプに入ったときに不思議だったのが何でもコードで管理することだったな。
例えば、画面もsty-003とかだったし。
この例だと、「プロセスstyの画面sty-1003を実装してください」って言われると
自動的に画面リソースの名前とソースコードの名前がsty-1003で作ることになっていた。
それに対するドキュメントは、sty.docに目次があるからそれを使って、sty-1000.doc内の該当ページを見る、
なんて要領だし。
一件判りやすそうなんだが、「mtyは完成しているので、mty-1005を参考にしてください」なんて言われたら
同じ要領で探さないといけない。
挙句、参照するデータベースの名前とは関連性が無いからもうね。

今考えてみたら、1003だとか1005だとかじゃなくて機能に基づいたローマ字名前でもついてれば楽だったかもね。
#こちとら業務系の知識は無いから英語にされたらお手上げだったし。

>>191を見てて気持ちがいいと思ったおれはバカなのだろうか?

>>192日本語の揺れが問題だったりしてな...

↓今、こっちのスレで日本語の識別子が評価されてますよ！

【汚物】痛い変数名・関数名【破廉恥】
http://pc11.2ch.net/test/read.cgi/tech/1077137948/

>>191
なるほど、コードを読む時完全に脳が英語モードになる人にとっては
読みづらく感じる訳か。なんかわかった気がする。
ちなみに俺は英会話力ゼロだから、たとえば"The port of RS-232C"は
「ざ、ポート、オブ、アールエス、*にーさんにー*しー」と黙読するくらいなので
>>191はなんの違和感もない。
そうか、識別子の日本語を馬鹿にするのはつまり、
「お前は英語が話せないんだな、バーカバーカ」と言いたいのか。そうに違いない。
だったら仰るとおりです。
SQLも英語を意識してると思うけど、"SELECT 商品ID, 単価 FROM 商品"とか
へっちゃらというか、かえって読みやすいと感じる。あくまで俺はね。

>>196
まぁ、そーゆーのは慣れの問題だと思うよ。

>>196
日常生活で日本語を使っている普通の日本人なら大抵あなたと同じだと思う。

>>192
文系の学者は、コンピューターが嫌いとか...
なでしこの文法が正しい日本語ではないとか...
そう言うつまらん問題だろうことは火を見るより明らか

>>193
誰の気にも障らない名前を追求すると無味乾燥なコードに
なってしまうんだよね。まるでRDBのOIDのような。昔は
長いシンボルが使えなかったというのも影響しているのかも。

でも問題は、識別子はRDBのクエリエンジンではなくて人間が
意思疎通で使う名前ってこと。別紙資料を引かないといけない
構成にすると、あらゆるところで資料にまで戻る必要があるので
キャッシュのないPentiumみたいなスピードダウンになる。
脳内キャッシュや脳内連想配列へのヒット率を高めるようにする上で
ネーミング重要。