9

ほとんどのプログラミングコードは英語で書かれていると思います。しかし、私は人々がここでの命名の問題をどのように扱っているのか興味があります。多くのプログラミングは、通常、特定の手順、項目について十分に確立された用語を使用して、いくつかのビジネスドメイン内で行われます。

たとえば、私はデンマーク出身です。よく仕事をしているものには、「indblikskode」という用語があります。これは、一種の「インサイトコード」を意味します。それで、これに関連するいくつかのWebサービスのC＃コードで「stringindblikskode = ...」という行を使用しますか？または、「insightcode」などの翻訳を使用しようとしますか？私がいる忙しさは、その言語でさえ一貫していません。たとえば、「organisatorisk enhed」（組織単位）という用語を使用していますが、英語から明らかに省略されている略語「OU」を使用することもよくあります。

他の人は、一貫性と正気を保ちながら、この命名の問題をどのように処理しますか（コード内の単純な変数名からデータベーステーブル、サーバー名まで）？

重複：

4

8 に答える 8

7

私は自分自身でしか話すことができませんが、クラスや変数に名前を付けるときは常に用語を英語に翻訳します。これは、私たちが書いたものではないベストコーディングプラクティスの1つでもあります。いつ開発を海外の安価な労働者や町の専門家の外国人コンサルタントに引き渡す必要があるのか​​、あなたは決して知りません。

于 2009-03-26T12:07:21.223 に答える
2

クラスと関数の英語以外の命名の問題は、常にマカロニックなピジンになってしまうことです。キーワードは英語で、命名規則 (getter/setter など) も英語で、デザイン パターンの標準名と同じです。

あなたは次のようなものになってしまうでしょう：

OrganisatoriskEnhedFactory::getInstance()->getIndblikskode();
于 2009-03-26T13:03:14.397 に答える
0

スイス（ドイツ側、つまりチューリッヒ）で働き、しばらくドイツに住んでいたので、コードが英語でない環境はまだ見たことがありません。確かに、アプリケーションはドイツ語である可能性があります（ただし、多くの専門的な環境はとにかく英語を話します）が、コード（私が見た）はほとんどすべて英語です。

他の言語でコードを書くのは難しいです。一つには、APIは（ほぼ）すべて英語です。たとえば、JavaはJavaBeansの命名を使用するため、とにかくsetとgetを使用する必要があり、「getGeburtstag」には「getDateOfBirth」とまったく同じリングがありません。

これはゲルマン諸国からの私の経験であるため、他の国は異なる場合があります。

于 2009-03-26T12:07:50.520 に答える
0

私たちは通常、確立された英語の用語を使用しています（私たちのビジネスドメインには通常英語の用語があります）が、適切な用語がわからない場合は、フィンランド語を使用することもできます。ちなみに、コード内のコメントでさえ混合言語です...

もちろん、賢明なアプローチは、ソースコードが建物の外で使用されるかどうかに大きく依存します。小さなお店ではそれほど大したことではありません。

于 2009-03-26T12:12:29.480 に答える
0

私はドイツに住んで働いていますが、英語のコードのみを書いています。それは物事を簡単にします。質問をしたり、自分の仕事に関するチュートリアルを公開したりする場合は、コードをネットに投稿できます。

また、コードは私にとってより「プロフェッショナル」に見えます。

于 2009-03-26T12:39:50.647 に答える
0

私はオーストリアの会社で働いており（ドイツ語を話しているので）、英語（変数名、ドメインオブジェクト、GUI）でプログラミングしています。プログラムをリリースする前に英語の翻訳を見つける必要があり、GUIを翻訳する必要があるため、少し面倒になります。すべての名前が本当に正しいかどうかはよくわかりません。

以前の会社とは対照的に、私は厳密にドイツ語でプログラムされて働いていました。これはかなり良かったです（ドイツ語の単語は英語の単語よりも長くなる傾向がありますが）。数年後、同社は米国で同じプログラムを使用したいと考えていたため、英語を話すプログラマーは同じコードベースを使用する必要がありました。この後、すべてがかなり一貫性のないものになりました-変数、データベースフィールド..両方の言語で（英語を話すチームメンバーはドイツ語を話しませんでした）。

私の経験では、10000 LOCアプリケーションをローカライズするのはそれほど楽しいことではないため、アプリケーションの初期段階（英語でプログラムを作成する場合は強制的に国際化を行う必要があります）で国際化を処理する方が簡単です。別の言語で書くことの利点は、ローカライズされているものとされていないものを即座に確認できることです。ただし、それを考慮に入れる必要がある作業です。

翻訳できない言葉に：私たちはまだそれを経験していませんでした-それは「コミュニティ内配達」（それはEUのものです）の英語のフレーズを見つけるためのいくつかの仕事でしたが。しかし、それが起こった場合、私たちはドイツ語を使用すると確信しています。

于 2009-03-26T12:16:00.173 に答える
0

ここで私の質問と回答を参照してください。

基本的には、組織とアプリケーションによって異なります。あなたの会社、開発者、顧客がすべて同じ母国語を話し、それがそのまま続くことを期待している場合、全員がパートタイムの翻訳者になることは非常に非生産的です. 純粋に仮説的な将来の利点に対するかなりの生産性の損失。ヤグニ。

それが大規模な国際企業である場合、または国際的に拡大する具体的な計画がある場合、またはオフショアで何らかの作業を行う場合は、もちろん別の問題です.

于 2009-03-26T12:57:39.183 に答える
0

私も今のところドイツに住んで働いており、ドイツ語の古いコメントを除いて、ほとんど英語を使用しています。英語以外のコメントは、理解するのに時間を費やす必要があるため（そして正しく理解する必要があるため）、一般的に非常に悪い考えだと思います。ドイツ語も英語も私の母国語ではありませんが、英語以外で書かれたコードは奇妙に思えます。

翌日、誰があなたのコードに取り組んでいるかは決してわかりません。したがって、IT 共通言語を使用する必要があります。

PS 私は自分の開発環境で英語以外の言語が好きではないので、自分の PC にドイツ語の Windows、ドイツ語の Office、およびドイツ語の Visual Studio をインストールすることを拒否したとき、ローカル管理者を非常に怒らせました。私だけのために英語版をダウンロードするのに何時間もかかりました。

言語パックをインストールするか、用語を学ぶためだけに同じソフトウェアの別のコピーをインストールするのは良いことだと思いますが。Skype をスペイン語に切り替えようとしたときと同じように、フランス語の SQL Management Studio には本当に興奮しました。

于 2009-03-26T13:08:46.677 に答える