トップページ⇒tech
166コメント57KB

ローマ字で関数名を付けるんじゃねぇ

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
いっつも思うぜ、何で関数名をローマ字で書くんだよ。
分かりやすいかも知れないけど、最近はインドとか韓国からとか外人も
こっち来て開発してんじゃん。
和英辞書ぐらい片手に、英語表記してくれい。何か恥ずかしい。


ガイシュツ失敬。
0002デフォルトの名無しさんNGNG
tokuisakiCode
0003デフォルトの名無しさんNGNG
日本語使える言語に乗り換えて漢字表記使おうぜ。
(MINDとはいわないが)
0004デフォルトの名無しさんNGNG
中文的表記。中文多人数使用。……(絶対間違。無関係。藁。

>>1
和英辞書じゃ分かりにくい時もあるしねぇ……。
>>3
それはいやん。変換も漢直も手間が掛かり過ぎる。
0005デフォルトの名無しさんNGNG
英/ローマ字混合で、
tokuisakiCode
よかは、
得意先コード
とした方が良いに決まってる。
そもそもVisualC++で漢字表記できないのが間違ってる。
なんとかしろ。
0006デフォルトの名無しさんNGNG
昔のx68kのgccは出来たぞ。>5
今のgccはどうなっとるんだ?
0007デフォルトの名無しさんNGNG
ローマ字いいじゃないですか、まだしも。
関数名を全部「通し番号」にする(つーか、させられる>N社詩ね)よりは
ずっとマシ。

>>6
それってもしかして、超僻地(=日本)的パッチなのでわ?
0008デフォルトの名無しさんNGNG
>>7
それN○T関連ですね。
私も派遣でいってて愕然とした記憶あり。
あれ考えた奴はさっさとクビになってほしい。
0009デフォルトの名無しさんNGNG
ローマ字、いいと思うけど。
ここは日本だし、漏れは日本で生まれ育った、日本語ネイティブな日本人なんだから。

それよりも、わけのわからん英語や typo の単語をつけるのはやめてくれ。
そっちの方がずっと恥ずかしい。氏ねって感じ。
0010凸NGNG
関数名を英語化→特殊な専門用語の英訳にハマる→類似単語頻出→
原因究明→そもそも仕様がおかしい→つーか客の業務体制がおかしい→
上の問題に発展→ゴタゴタ→英名やめて通し番号にしろとのお達し→死
0011デフォルトの名無しさんNGNG
>>9
ローマ字で書いてあると、馬鹿に見える。
0012デフォルトの名無しさんNGNG
>>10
>特殊な専門用語の英訳にハマる→類似単語頻出

変数や関数が皆グローバルなのですか?
0013デフォルトの名無しさんNGNG
>>1
そもそも和英辞典を引かないと出てこない英単語というのは、暗号そのもの
だと思うけど。
基本的には中学レベルで理解できない英語は、連番と大差ないのでは?

>>11
綴りや用法を間違った英語で書いてあると阿呆に見える。
0014デフォルトの名無しさんNGNG
プロジェクト内で命名規則、辞書作成とかしないの?
海外に発注した時困らない?
0015デフォルトの名無しさんNGNG
>>11 >>13
両方とも低能に見える。
0016デフォルトの名無しさんNGNG
>>14
海外になんか発注しない。
001714NGNG
こんな感じですか?

long GenzaiZandaka;
long GetZandaka();
void KurikoshiSyori();

一般的な会計ならまだしも専門用語の多い業務だと
辞書があってもつらいかもねえ。
(とりあえず俺のCDトレイには英和・和英辞書の電子Bookがいつも載ってるけど)
0018デフォルトの名無しさんNGNG
>>10
最後から2番目の段階で急に現実感がなくなるんですけど。
001914NGNG
管理番号+ローマ字併用方式

FUNC001_Kurikoshi
GBL002_Znakin
PROC008_SimeSyori

ありそうだ…
0020デフォルトの名無しさんNGNG
>ローマ字で書いてあると、馬鹿に見える。

一方で、英語で書いてあると馬鹿を隠すという危険性が有るな。
しかもつづり間違いや単語間違い(誤英訳)だったら
馬鹿さと被害が二倍二倍。

ただ、ローマ字自体が間抜けなのは、
日本語みたいに同音異義語多すぎな言語を
表音文字で表そうってのが、無理有るんだよな。
「日本語」で書くなら、(可能ならば)ローマ字より
漢字かな混じりのほうが、有利なのは確か。

ところで、戦後直後のどこぞのドキュ学者みたいに
フランス語で書け!とかいう人って居ないのか?

というか、全世界30億人(?)の非英語圏の連中は
どんなソースを書いているんだろう?
中文なソースとか、イタリアーーーンなソースとか…?
#中華とかイタリアンとか…ウマそう… :-D~~
0021デフォルトの名無しさんNGNG
フランス語やロシア語は特殊記号多いから駄目。ASCIIコードのみで
かきませう。
0022デフォルトの名無しさんNGNG
昔、講義で聞いた話だが、
10数年前のプログラマ不足危機って言われた時代のこと
COBOL ではコーディングスタイルとして、
当時の通産省自身が
「変数名はローマ字にしろ。ゴラァ」
って推奨(?)していたことがあった。ら・し・い。
理由は
o COBOL は予約語が多い。変数のつもりが命令(キーワード)になるバグ回避対策
o そもそも日本人は英語が苦手
なんてことらしい。
# 最近、シグ○での規約だったという話も聞いたが真偽はしらん。。。
0023デフォルトの名無しさんNGNG
昔、アメリカから来たエンジニアがソース見て驚いてたな。
「なんで英語で書いてんの?」
日本語版のソースは日本語で書くものと思っていたらしい。

びゅう太を教えようかと思ったがやめた。
0024デフォルトの名無しさんNGNG
>>14
一々辞書を引かないと意味が理解できない命名法に疑問を持たない?
そんなのは連番に対応表をつけるのと何ら変わらないと思うけど。
0025デフォルトの名無しさんNGNG
>>20
同音異義語が多いから漢字かなまじりの方が便利なのは確かだけど、分かち
書きをするだけでかなりましになると思うけど。
昔のファミコンの表示はほとんどそうだったけど、理解できないメッセージ
なんてなかったと思うけど。

ローマ字を使う上で最も間抜けなのは綴り法を混在させているやつ。
せめて標準式に統一して欲しいなあ。
0026デフォルトの名無しさんNGNG
>一方で、英語で書いてあると馬鹿を隠すという危険性が有るな。
>しかもつづり間違いや単語間違い(誤英訳)だったら
>馬鹿さと被害が二倍二倍。

こういうののことでしょうな。
int DANJYON(void);

dungeonだっちゅーの!
0027デフォルトの名無しさんNGNG
そんな事を気にしている暇があったら
とっととプログラムを作って早く家に帰りなさい
0028デフォルトの名無しさんNGNG
>>26
後世にソースを見る人の為のジョークです。
0029デフォルトの名無しさんNGNG
識別子をローマ字書いてるプログラムを
GPLで公開しようと思ってたのですが
やめたほうがいいですか?
0030デフォルトの名無しさんNGNG
>>29
全く問題ない
003129NGNG
>>30
問題ないと言っても馬鹿にされたりしませんかね?
全部英語に直したほうがいいですかね?
0032デフォルトの名無しさんNGNG
COBOLの害は大きい
0033デフォルトの名無しさんNGNG
>>26
>こういうののことでしょうな。
>int DANJYON(void);

これはローマ字ですらないね。ローマ字ならDANJONかDANZYONだ。
0034デフォルトの名無しさんNGNG
>>24
同意。
テーブル名はともかくフィールド名だと FLD010,FLD020...とやりたくなる事もある。
今は漢字フィールド名を使っているが。
(これやるとOracle系原理主義者が五月蝿いけど)
0035デフォルトの名無しさんNGNG
void CNichannel::KansuItteyosi(bool HikisuOmaemona);
0036デフォルトの名無しさんNGNG
KOUDOはかなり氏ねた…
0037デフォルトの名無しさんNGNG
>>29
糞コードだからって公開する権利が無くなったり
することは絶対にない。安心していい。

ただし、それと、糞コードを世間の笑い者に
されない権利(?)とは全然一緒じゃないので、心配していい。

>>35
関数とか引数とかの枕詞までローマ字書きされてるのが
ポイント高い。
0038デフォルトの名無しさんNGNG
なんでローマ字で書こうとする?
ローマ字使うぐらいなら日本語で書け。

typedef struct int 整数型;
#define 終了(戻値) exit(戻値)
#define 酒処理 main
#define 書式出力 printf

整数型 酒処理 {
 書式出力("逝って良し!\n");
 終了(0);
}
0039デフォルトの名無しさんNGNG
やっぱ漢字がイイヨ。
長ったらしい英語でも、漢字で書くと数文字で表現できる。
抽象とか継承とか代理とか委譲とか・・
0040デフォルトの名無しさんNGNG
モシ ナラバ ニイケ
0041デフォルトの名無しさんNGNG
(define 継承 call-with-current-continuation)
(define λ lambda)
(define 適用 apply)
(define 評価 eval)
0042デフォルトの名無しさんNGNG
継続だった鬱
0043デフォルトの名無しさんNGNG
型定義 列挙型 {
フタナリ
,男
,女
} 性別;
0044デフォルトの名無しさんNGNG
今疑問に思ったんですが、フタナリって漢字で書くとなんなんですか?
0045デフォルトの名無しさんNGNG
腐多那痢
0046デフォルトの名無しさんNGNG
世路刺久
0047デフォルトの名無しさんNGNG
紅夜叉
0048デフォルトの名無しさんNGNG
双哉
0049デフォルトの名無しさんNGNG
磨羅
0050デフォルトの名無しさんNGNG
編集機 compiler
翻訳機 translater
解釈機 interpreter
0051あぼ〜んNGNG
inisyaraizu();
toranzakusyon();
fainaraizu();
abo_to();
余談だけどATOK14ってカタカナ英語を英単語に変換できるんだね。
ちょっと感激…しても実は余り意味がなかったりする(藁
0052デフォルトの名無しさんNGNG
珍宝
0053名無しさんNGNG
age
0054名無しさんNGNG
age
0055名無しさんNGNG
age
0056名無しさんNGNG
age
0057名無しさんNGNG
age
0058lambdaさんNGNG
Javaは識別子がUnicodeだから日本語でもタイ語でもOKということだが。
実際のところどうなの?
0059デフォルトの名無しさんNGNG
勘定科目とか原価償却とか金がらみの仕事してると
いちいち辞書なんか引いてられないよ。
0060デフォルトの名無しさんNGNG
”静的せん断弾性係数”って、英語では何というのだ?
00611NGNG
ローマ字表記は確かに分かりやすい。でもよ、結局は慣れじゃん?

>>19 の例にあるように、一見して記号の羅列でも、プロジェクトの終盤には
絶対慣れるしな。
ま、COBOLの影響大というのは非常によく分かった。っていうか、実感してる。

>>23
ぴゅう太ワラタ そのジンガイに教えれ(W
0062デフォルトの名無しさんNGNG
だからローマ字は読みにくいってばよ!>1
漢字書けや。
漢字書けねえ言語なんざ、捨てちまえ!
0063デフォルトの名無しさんNGNG
>>52
同意。
0064デフォルトの名無しさんNGNG
英語、ローマ字混在の名前にするぐらいなら、
ドキュメントと同じ日本語にしてくれ。
(日本語使えないならプリプロセッサを通せ)
変数名のハンガリアン記法も禁止。pszhogeはやたら激しくキモイ。
凝るんなら型名に凝れ。
先頭大文字表記はウザイ。書くなら'-'または'_'区切りで全部小文字で書け。
全部大文字は論外。書き直せ。
0065デフォルトの名無しさんNGNG
>>64
海栗っくすやさん?
0066デフォルトの名無しさんNGNG
>>58 Javaはパッケージ名とクラス名が
それぞれディレクトリ名とクラスファイル名と同じでないといけない仕組みだから、
これらに英数字以外は使えないな。変数名やメソッド名はOKだけど。
0067デフォルトの名無しさんNGNG
1.GetData
2.get_data
3.getData
4.その他具体的に
お勧めは?
0068無責任な名無しさんNGNG
>>67
言語依存
0069デフォルトの名無しさんNGNG
プログラマ専用英和/和英辞典ってどこかにないかな。
処理内容から名づけた日本語の関数名を機械的に
そこそこ自然な英単語の組み合わせに変換できるようなやつ。
0070デフォルトの名無しさんNGNG
>>64
ハンガリアン記法。

Win32 だと API で使う構造体のフィールド名なんかが、そもそもハンガリアン記法に
なってるので、合わせて使ってるよ。あと C++ でプログラミングしてる分には、変数名
に型情報を反映させるのは冗長だと思うが、VBScript みたいな

- 型なし
- 構造体が使えん

言語だと、変数名にでも型情報を埋め込まないと、ソースコードの可読性が低すぎ。
0071デフォルトの名無しさんNGNG
型なし でなくて variant型では
0072デフォルトの名無しさんNGNG
>>69
カーソル位置の単語を抜き出して、和訳をポップアップ表示するソフトは作れそうな
気がする。需要あるかな?
0073デフォルトの名無しさんNGNG
>67
5.get-data
'-'が演算子に分断される言語とかでは使えないけど、
使えるなら'_'で区切るよりも見心地が良い。
0074デフォルトの名無しさんNGNG
>72
そういうソフトは既に存在します。
0075デフォルトの名無しさんNGNG
>>68
言語依存とした場合に困るのが、
いろんな言語で同一(またはAPI互換)のライブラリを使うとき。
言語によって色んな書き方で移植されると
それはそれでウザイですぞ。
0076デフォルトの名無しさんNGNG
>>70
dw -> double word
c -> const? char?
lp -> long pointer
lpsz -> char FAR *の'\0'で終る文字列
b -> bool? byte? bit?
読んでると頭痛くなるよ、ほんと。

例)lpszclientname //顧客名
もうわけわからん
0077デフォルトの名無しさんNGNG
グローバル変数はg_を、メンバ変数はm_を頭につける。(これもハンガリアンていうの?)
それ以外はやらない。
0078デフォルトの名無しさんNGNG
>>76
賛成。ハンガリアンは全然いけてない書き方だと思う。

ちなみに、OOPみたいに型の名がどんどんどんどん増える世界では
ハンガリアンって無力なんだよな。
object型であることを示すためだけにoなんて接頭文字をつけても
あほくさいだけだし。

型なし言語スレのほうで有ったけど、
型だけ押えてもあんまり嬉しくないと思う。
型が無いってことは、型と型以外の色んなものを
「同じくらいの重要度で」チェックしないとならない、
ということなんだから、型名を頭につけただけでは
安心度は殆ど替わらないと思われ。
どっちかってーと同じ型のxとyのどっちをzに代入するか?を
間違えないことのほうが、重要に思える。なにせそっちのほうが
「なまじ型があってるので」エラー(型なしならランタイムエラー)に
なる可能性が低いんで、恐い。


っていうかコンパイラが刎ねてくれるんだから、
少なくとも強型言語であるCやCを前提としたAPIで
そういうものを使うのは、変。
まぁC文化ならでわの馬鹿キャストされるのを
見越したフールプルーフなのだろうとは思うけど、
それにしてもダサ。馬鹿のほうを退場させるべき。
0079デフォルトの名無しさんNGNG
>>60
そういう専門用語(材料&機械畑だな)こそ
然るべき教科書見れば一発で答えが書いてあって
対処が簡単な好例だろう?
そんな単語を必要とする人ならば
教科書も持っていないドキュということは無かろう。

英訳どころか日本語レベルですら困るのが、
ある企業の内輪の用語とか、な。
意味が判りにくいどころか、当事者に質問しても
まともな答えが返ってこなくてノリで理解してるだけ
という奴が、しばしば困る。どう困るかってーと、
その用語を仕様に組みこむときに、どう位置付けていいのかが
よく判らなくて、仕様変更のときに思いがけない話(笑)をされる可能性が
ぐんと上がるので。「(誰にでも)判りやすい言葉」はやっぱり重要だよ…
0080デフォルトの名無しさんNGNG
>>77
発想は同じだからハンガリアンなんじゃないの?
g_ global? generic?
m_ member? method? macro?
これもキモイよ。
公開インターフェースの部分でこういうのがあると萎える。
m_が便利なのってxが外部の変数の時の演算とかで同名が被らない様にする、
m_x = x;
こういう時ぐらい。これだったら。
x = tmpx;とでもした方がマシ。
0081デフォルトの名無しさんNGNG
ハンガリアンってなにかと思ったぞ。
昔はハンガリー記法の方がメジャーだった。時代も変わったものよのぉ。
http://www.arcpit.co.jp/winapi/api_01/ap010203.htm
http://software.nikkeibp.co.jp/software/yougo/yougo4.html

MSが推奨してた。馬鹿なことを.....と思ったものだ。
関数が多きすぎるから変数宣言が見えないのだよ。
だから変数名に型情報まで入れたのだろう。

ハンガリー記法ってのはプログラム改造でintをlongすると
どうやるのだ?
変数名は全部かえるのか?いや、ごりっぱ。
0082デフォルトの名無しさんNGNG
ジャンガリアン?
0083デフォルトの名無しさんNGNG
ベジタリアン
0084赤毛のアンNGNG
sage
0085デフォルトの名無しさんNGNG
トレビアン
0086生活の知恵NGNG
>>72,>>74
そーいうソフト立ち上げてると、マウスカーソルを単語の上で遊ばしてた時などに重くてウザイんで、
フリーのテキスト辞書をgrepしている。
選択した文字列をgrepさせるマクロ書いて選択ポップアップメニューに登録するだけで快適。
0087デフォルトの名無しさんNGNG
ハンガリアン記法は、APIなどの低レベルインターフェースを
定義するときに使うと分かりやすいよー。

>>76
lpszclientname は lpszClientname とやるのが正しい。
0088生活の知恵NGNG
ちなみに逆引きも自動対応♥
0089デフォルトの名無しさんNGNG
単にclientnameでいいじゃん>87
ところで配列とかの名前はどうすんの?
LPSTR ??????clientname[10];
↑こういうの
0090デフォルトの名無しさんNGNG
>87
lszClientnameなんて書くとバグになるのかな?
目で全部チェックするのかな?
clientnameで良いと思うよ.
0091デフォルトの名無しさんNGNG
LPがつくと*が付かなくてもポインタになったりするのが気持ち悪い。

FOO foo;
……
foo.bar();

LPFOO foo;
……
foo->bar();

みたいな。
0092デフォルトの名無しさんNGNG
>>89
lplpClientName
てきとーです

>>91
ハァ?
0093デフォルトの名無しさんNGNG
組み込み型にしか効果がない。
構造体にしたら付けようが無いし。
WIN32_FIND_DATAやBITMAPFILEHEADERのメンバなんか
デタラメに付けたとしか思えない。
結局ヘッダやヘルプ見るハメになる。
biとかftとか書かれても想像なんてできねーよ!クソが!
なんかムカついてきた!ハンガリアン記法で書いてる奴氏ね!
0094デフォルトの名無しさんNGNG
ハンガリアン記法って、なんかジジ臭いんですけど。
短い変数名しか付けられなかった時代の名残りだから?
0095デフォルトの名無しさんNGNG
つーかここ、ローマジについてのスレなんだよね。
別に良いけどさ(w

いまのところ、
ローマ字表記->漢字でかけ
ハンガリアン記法->逝って良し
ってことでいいかな?
0096ジジNGNG
>>94変数名短いころのほうがハンガリアン記法ど使えない。
lpszなど4文字も無駄にすることになる。

95>>同意
0097デフォルトの名無しさんNGNG
>>94
短い名前が必要なら型名すら変数名に付けません。
ハンガリアンどっちつかず。使えない。しね。

あとm_hogehogeもダサすぎ。少なくともそんな変数名を
publicに出しているMFCはしぬよろし。

>>81 最後の段落
まさに。ハンガリアンの致命的最大欠陥はこの一言に凝縮。

>>95
やっぱり漢字を通し番号(笑)に変換するフィルタつーかプリプロセッサを
自作すりゃいいんだよ。勿論プリプロ通した「ソース」を
自分で書く「ソース」と同列に見なしてはいけない。
0098デフォルトの名無しさんNGNG
>>97
ハンガリアン記法の是非はさておき、型を変えたら変数名を変えるのかという
のは致命的ではないと思う。

型を安易に変える方がはるかに危険。short から int にした場合でも、ビットシ
フト演算などを使っているとオーバーフロー時の意味が全く変わってしまうし、
かなり嫌なバグになりかねん。

俺は、型を変えたら変数名も変えてチェックし直すよ。
0099デフォルトの名無しさんNGNG
それはハンガリアン記法の害とは関係のない話だろー>98
型変えたらコードチェックするのは同じ。
ハンガリアン記法だと、さらに名前まで変更する必要があり、新たなバグを埋め込みかねない。
怖いねー
0100デフォルトの名無しさんNGNG
>>98
(常に安全に)変えることが出来るなら、ね。

たとえばこんなの書くの厨房だけど、
ハンガリアン枕詞だけ違って後半が同じ名前という
2つの変数があったら、どうよ?
しかも2つの属してるスコープが違ったりして、一目で
敵(笑)がいることを察することができなかったら、どうよ?

混乱の数を、増やしはしても減らしはしないだろうな、と思う。

まぁ型といっても色々あるしね。
shortとintの差だけが型の差じゃなく、
二重ポインタと一重ポインタの差とか
char*とchar[]の差とか、
言い出したらきりがない感じ。
010198NGNG
俺はハンガリアン記法使ってないって。
0102デフォルトの名無しさんNGNG
>>97
漢字をプリプロセッサで変換するには賛成。
でも、C/C++の標準規格に完全に合致していればユニバーサル文字に変換すれば
安全だけど、ほとんどの処理系は規格合致ではないのであまりよい変換方法がない。
規格上はマルチバイト文字で定義された識別子をユニバーサル文字にコンパイラが
変換してもいいみたいだけど、そんなのが実現する可能性ってあるのかな?

これが実現すれば、プリプロセスというよりはシフトJISとEUCの間の変換と大して
変わらないレベルの話になるような気もするけど。
0103デフォルトの名無しさんNGNG
>100
>ハンガリアン枕詞だけ違って後半が同じ名前という
>2つの変数があったら、どうよ?
ゲッ!俺それやってる。考えてみれば確かに嫌だ。
後から型を変更すると大混乱必須だ。
0104デフォルトの名無しさんNGNG
物理的な型でPrefixをつけるのはどうだろうね。
wHogeHogeとdwHogeHogeの違いって16bitか32bitの違いで
表現できる範囲の違いにそれほど意味があるとは思えない。

cxHogeとxHogeならいいかも、Hogeの横サイズと横位置の違いを
明確にするというのは意味があると思う。

cxWidthとかcyHeightってダサくない?
0105デフォルトの名無しさんNGNG
>>102
コンパイルエラーとるのがいやだな。
コンパイルエラー時に変換後の名前じゃなくて、
変換前の名前をだす方法があったような...
#pragmaにあったか?

>104 wHogeHogeとdwHogeHogeの違いって16bitか32bitの違い
他のマシンに移植したらどうなるのだろう??
変数名かえるのかな?

ハンガリアン記法マンセー!!ってやつはいるのか??
0106デフォルトの名無しさんNGNG
>>105
Microsoft
0107デフォルトの名無しさんNGNG
>>97 >>102
Javaがまさにそれやってるな。utf8じゃなくてUNICODEエスケープだけど。
非JIS文字は単にエラーにすればイイでしょ
あと変換表の非互換性問題は毎度毎度Javaでも問題になるけど
この場合は単に識別子に使えるコードを限定すればOKでは?
非互換で問題になるのはだいたい
\を円マークと対応付けるかバックスラッシュにするかとか
−全角横棒と-マイナスとかの記号類と半角カタカナとかだし。
0108デフォルトの名無しさんNGNG
vectorやniftyになかったっけ?
日本語のシンボルをプリプロセスするやつ。
まあperlのスクリプトかなんかで簡単にできそうだけど。
0109デフォルトの名無しさんNGNG
>>102
エラーメッセージの問題は、
日本語シンボルと変換シンボルの対応表も出力させとけば、
そんなに深刻ではないと思う。
0110デフォルトの名無しさんNGNG
>>104
>cxWidthとかcyHeightってダサくない?
cx cyって何よ?
widthとheightじゃだめなの?
0111デフォルトの名無しさんNGNG
物理型名をプレフィックスにしなきゃいいじゃん。
独自型名を作ってそれを使うようにすればいい。

ある環境では
typedef unsigned int DWORD;
ある環境では
typedef unsigned long DWORD;
のように、物理的に一致する型にtypedefしてやればいい。

で、DWORD=32bit符号なし整数とか決めて作ってやれば、
移植の際にいちいち型のオーバーフローとか言い出さなくて済む。

一致するような型が無いようなかけ離れた環境に移植することはできないけど、
そんな環境に移植するならそもそも作り直したほうがいいと思われ。
0112102NGNG
>>105
コンパイルエラーの対応やデバッガでステップ実行させたりする上で、特に問題はない
と思うよ。プリプロセスを通すやり方なら行番号は維持できるか、#lineで対策できるし、
デバッガも元のソースを読み込むはずだから。ただウォッチ機能とかは少し辛いかもね。

>>107
C/C++もUTF-8じゃなくて確かUTF-16とUCSだったような気がする。円記号その他のマッピ
ングは重要な問題じゃないけど、結局、旧来の識別子用の文字(英数字とアンダスコア)
に変換せざるを得ないので、これが非漢字で付けられた識別子とたまたま合致するような
ことがないとは言い切れないのが重要な問題になる。コンパイル時に-Dオプションとかで
マクロを定義されたり、他の処理系に移植したりということを考慮すると、とても現時点
で手を出せそうにはない。
0113デフォルトの名無しさんNGNG
デバッカの問題があるか
0114デフォルトの名無しさんNGNG
>>105
コンパイルエラーメッセージをリダイレクトして
逆変換フィルタを通してから表示したらどうかな?
unix系シェルなら一発で出来そうだし、
そうでなくても簡単なプログラム作れば楽勝かも。

更にunixなら、コンソールデバイスもリダイレクトで小細工すれば
相互変換をやれちゃうかも。
#日本語入力FEPをコンソール小細工で実現する一派があるそうな。
#考えてみたらその手を使えば何でも有りなんだよな、unixだと。

>>111
その辺を、わりと平易なアプローチで、ある程度綺麗にしようと
した試みの一つとして、GtkだかGdkだかのアレがあるようですね。
gpointerとかgintとか使うそうで。
0115デフォルトの名無しさんNGNG
>>114
gpointerやgintのgはGNUのg?
globalのg?
genericのg?
ガンダムのg!?
01161NGNG
>>62
標準で漢字の変数名なり関数名(セクション名)をサポートしているなら、俺も
すすんで使うところ。
だが、そうではない言語に関しては、捨ててしまえってことか。無理だ。

>>81
そゆときは、「nCnt」みたく、型の内容ではなく、型の属性(ここではnumber=数字)を
意識して命名するのが前提っぽい。あくまでも俺の中では。
ま、これもコーディング規約があればそうするってぐらいかな?


で、だな。当初の問題点は、「ローマ字表記は『恥ずかしい』んだよ!!」っつー事なんで
あって、読みにくいかどーかは問題にしとらんのよ。
みんな原点に返ってみてくれ。
0117デフォルトの名無しさんNGNG
きみは問題にしてなくても、こっちは大問題だよ。>116
0118デフォルトの名無しさんNGNG
>>116
たしかに恥ずかしいね。
で、それがどうした?
なお、回答は不要。
0119減点NGNG
たとえば
「口座番号チェック」する関数はどういう名前にする?
0120デフォルトの名無しさんNGNG
TyekkuKouzaBango(int nZinbutuNanbaa);
0121ありきたりNGNG
CheckAccountNumber();
0122デフォルトの名無しさんNGNG
チェックの内容による。
IsValidAccountNumberとか。
0123デフォルトの名無しさんNGNG
1が放置プレイに入った模様
0124もういいよ。。。NGNG
まあ >>1 のまわりにはローマ字で書く奴が居るって
いうのがウザイっていうだけの単なる愚痴なわけで。
残念ながら俺のまわりには、そういった面白い人は
いない。残念。
0125デフォルトの名無しさんNGNG
Name の一時的変数として namae にするのはよくやる(^^;

>>119
CheckKouzaID
0126デフォルトの名無しさんNGNG
>>125一部マンセー
checkKouzaID
なぜにsage嵐なの??sage
01271NGNG
>>123
放置すんな、さびしーだろー(W

>>124
うむ。的を得てるね。でもね、どこ逝ってもそうなんよ。
なんで、俺からすると、そっちの方が特異なケースに思える。俺的には。
0128あそぼNGNG
>>1は
>>120-126のどれが木の実なの?
0129デフォルトの名無しさんNGNG
>>127
的を「得」るのも、かなり恥ずかしいと思われ。
0130デフォルトの名無しさんNGNG
>>128
そだねー。>>121 かな。>>122 のいうように、チェック内容にもよる
けど。
IsValid〜だと、「口座が存在するか?」に絞ってるようなニュアンス
だけど、Check〜だともーちょい大きな括りにもとれる。

どっちを選択するかは、状況次第でしょーな。


>>129
typoです。ATOKなんで警告は出たが、そのまま使用。
まーそーいうなって(W
0131デフォルトの名無しさんNGNG
間違った言葉でも皆が使えば正しい言葉になっていくよね。
ハッカーしかり、ら抜き言葉しかり。
本来はそれが言語の進化なんだろうけど、昨今はそれをメディアが
規制し始めたから言語の進化はなくなるかもな。
0132デフォルトの名無しさんNGNG
どっかで見かけた。

> Variable naming conventions give a hint as to scope, not type:
> 変数名にはタイプではなくスコープのヒントになるような接頭文字をつける。
>
> local a (例 aPoint)
> param p (例 pPoint)
> member instance m (例 mPoint)
> static s (例 sPoint)
> exception X (例. XOutOfBounds)
>
> Choose variable names you can read on the phone. Avoid acronyms and abbreviations.
> 変数名は電話で読みあげるような名前を選ぶこと。acronymや省略はさける。
0133デフォルトの名無しさんNGNG
>>132うーん。説得力ないようにおもわれ。
localにaか?いらないぞ。member instance m???なぜ?
なにより電話で伝えるようなことがあるのか?
かなり昔のはなしとおもわれ。

>>130
気持ちはわからんでもないが、英和辞典引きながら全然違う意味の英語付けてる奴いたぞ。
やめろ!!といってもやめやしない。
会社やめたけど。(W
0134デフォルトの名無しさんNGNG
>>133
スコープを区別できるようにするってのはいい考えらしいぞ。
Rubyでもそうなってるし。
01351再び@毎回ハンドルは変わるかも(WNGNG
>>132
それって、長いスコープだと大変よね。特に、頭にシステムで規約された
名称付与基準があるととたんに使えなくなったりするかも。

例 構造体「REFinfra」「REFidentification」みたいな感じで


>>133
んじゃ、よかったじゃん(W
ちなみに、その人が実際にやった違う意味の単語の例きぼーん。
想像がつかない・・・。
0136デフォルトの名無しさんNGNG
>>131
メディアが規制なんかしてるのか?
0137デフォルトの名無しさんNGNG
>>131
全然関係ないが、誤用の積み重ねが言語進化の牽引車ではないね。
少しは歴史を勉強しなよ。
0138133NGNG
>>135
単語どころか実名も晒したいところだがおれが誰なんだかばれてしまう。
業務用のアプリ作ってるんだけど、業務用語ってあるじゃない、日本語特有のやつ。そいつは無理矢理英語にしてた。

そいつが居なくなった後の改造は俺がやるんだから、ちっともよくない。
そいつが辞めたきっかけは俺なんだけど(W
01391再び@毎回ハンドルは変わるかも(WNGNG
んじゃ、本件に関しては締めとくな。

結論:勝手にせぇ


----------------------- 本件のみ終了 -----------------------
0140デフォルトの名無しさんNGNG
なげやりだなあ・・
0141デフォルトの名無しさんNGNG
ローマ字の関数名もいやだけど、変数名が女の名前だったのもいやだったなぁ。
昔メンテをしたDOSの某家計簿ソフトですが。
int rena; って最初何の変数かわからなかったヨ。
0142デフォルトの名無しさんNGNG
オタク系ソフトにありがち
0143デフォルトの名無しさんNGNG
int haruna;
0144デフォルトの名無しさんNGNG
int pseudo_haruna;
0145デフォルトの名無しさんNGNG
>>141
>最初何の変数かわからなかった

というか最後まで何の変数か判らないよねそれ(w
女Objectの変数とかならまだ許せるけど、
そうでもない限り、名は体を表さない変数名なんて…
0146デフォルトの名無しさんNGNG
int rei_ayanami;
01471再び@毎回ハンドルは変わるかも(WNGNG
つーか、名乗り出ろ(W
おるんだろ、この板に。
0148デフォルトの名無しさんNGNG
古代エジプト語BASIC
0149デフォルトの名無しさんNGNG
古代ヘブライ語ベーシックも捨てがたいぞ
0150デフォルトの名無しさんNGNG
日本語BASICは変数名も縦書きですか?
0151デフォルトの名無しさんNGNG
>150
 毛筆フォント必須だそうです。
01521再び@毎回ハンドルは変わるかも(WNGNG
>>150
縦は、原稿用紙分しか書けません。
0153デフォルトの名無しさんNGNG
>>150
ソースファイルに縦書きも横書きもない。
それは、単にエディタの問題。
0154デフォルトの名無しさんNGNG
>>153
本気で聞いてると思ったの?
0155デフォルトの名無しさんNGNG
>>154
Yes.
0156デフォルトの名無しさんNGNG
以前ハンガリー人の書いた英語圏用のアプリを
日本語にローカライズしたことがあったよ。

シンボル名はほぼ英語で書かれていたので助かったが、
一部「これ何語やねん?」ってのがあったな。
(ハンガリー語?)

ソースは複数の人間によってメンテされたようで、
英語で名前定義するヤツとかハンガリー語(?)
で定義するヤツとか、いろんなヤツがいたんだろうな。

ただコメントはほとんど解読不能だった...
0157名無しNGNG
えー、ハンガリー表記ってマイノリティーか。
MFC全面で使われてるから普通かと思ったのに。

ところで、型変更ってよくあることなの?
0158デフォルトの名無しさんNGNG
おれハンガリーと普通のん混在派。
っていっても滅多にハンガリーは使わないけど。
配列一杯使ってて,ほんの少しだけポインタだったりする時に,
勘違いしないようにpとか付けるようにしてる。

char hoge[8];
char foo[8];
char bar[8];
char *pHogehoge;
0159デフォルトの名無しさんNGNG
>>157
Win16:
LONG FAR PASCAL MainWndProc(HWND hWnd, unsigned message, WORD wParam, LONG lParam)
Win32:
LRESULT CALLBACK MainWndProc(HWND hWnd, UINT message, UINT wParam, LONG lParam)

Win32 でも wParam の名称は残っているので w より WORD(16bit) を
連想したくなりますが、ご存知のとおり UINT(32bit)です。
で、「ナゼー」になるわけです。

現在では UINT/LONG でなく、WPARAM/LPARAM になっとるようですが。
0160デフォルトの名無しさんNGNG
うんうん、間違えそう。勘弁してくれよ。>wParam
つーか、wParamのWってWORDの事だったのか・・
知らんかった。WindowのWか?と。只の記号?
ひょっとしてLRESULTのLはLONGですか、って思ったらそうなのか。
まあtypedefされた型名は許そう・・。
hWndもヤなネーミングだなあ・・
もともと頭が大文字の変数名って嫌いなんだけど
0161デフォルトの名無しさんNGNG
>>159
なんで Win32 に移行するときに wParam の変数名を変更しなかったんだ
ろう。64bit 化をにらんで WPARAM, LPARAM を typedef して、それぞれ
のプリフィクスを w, l にした、ということなんだろうか。

ハンガリー記法とは直接は関係ないけど、私の場合は慣用的に名前が
決まってる変数がいくつかある。カウンタの i, j や文字列の s に加えて、
Win32 でプログラムを書いてるときには、次のような変数名もほぼ固定。

HWND hWnd
HWND *pWnd
HDC hDC
HDC *pDC
PAINTSTRUCT ps
SCROLLINFO si
TEXTMETRIC tm
LPARAM lParam
WPARAM wParam
IUnknown *pUnk
HRESULT hr

探せば、まだまだあると思うが。
0162デフォルトの名無しさんNGNG
HANDLE HWND => h WPARAM => w LPARAM => l
でいいじゃん。
どうせh/w/lなんて他で使わないし。
0163デフォルトの名無しさんNGNG
>>100
>ハンガリアン枕詞だけ違って後半が同じ名前という
>2つの変数があったら、どうよ?
>しかも2つの属してるスコープが違ったりして、一目で
>敵(笑)がいることを察することができなかったら、どうよ?
グローバル変数増やし過ぎと思われ(藁
厨房?それとも言語仕様が終わってるの?
なぜCでグローバル変数を減らすように言われるか知ってる?>>100

個人的にはハンガリアン派だな漏れは。
メンバ変数にはm_
グローバルにはg_
を付ければ良い。
管理能力を超えるほどのクソ多い
グローバル変数を使うドキュソはあぼーんですな。
0164デフォルトの名無しさんNGNG
>>161
>なんで Win32 に移行するときに wParam の変数名を変更しなかったんだ

windowsx.h の HANDLE_MSG マクロが動かんようになるからでわ?
0165デフォルトの名無しさんNGNG
>>163 名前:デフォルトの名無しさん投稿日:2001/05/28(月) 15:26
>> しかも2つの属してるスコープが違ったりして、一目で
>グローバル変数増やし過ぎと思われ(藁

>なぜCでグローバル変数を減らすように言われるか知ってる?>>100

「スコープが違」とまで書いてるのに、
なんでグローバル変数の話だと決め付けるの?
0166デフォルトの名無しさんNGNG
ふぁーあ
■ このスレッドは過去ログ倉庫に格納されています