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

専用も広まればほぼ標準

>>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みたいなスピードダウンになる。
脳内キャッシュや脳内連想配列へのヒット率を高めるようにする上で
ネーミング重要。