プログラムコード(私の場合はロシア語)のネイティブ言語で名前(クラス、変数、メソッド)を使用することについてです。
ロシアの識別子は、オブジェクトモデルの作成および顧客との議論(国内プロジェクトの場合)に最適であることが経験により示されています。
ITの開発における一般的な傾向の1つは、技術の段階的な「人間化」です。 各新技術は当初、特定の専門家の狭いサークルに焦点を当てていましたが、さまざまな文化を含むユーザーのかつてない範囲に徐々に適応しています。 少なくともキリル文字ドメイン(*.)の導入を検討してください-すべてのブラウザが通常キリル文字アドレスの表示をサポートしているわけではありませんが、プロセスは進行中です!
90年代前半にプログラミングを開始して、ファイルはラテン文字で8文字以下で呼び出す必要があるため問題は発生しませんでしたが、Windowsの次のバージョンではこれらの制限がなくなったことに気付きました-これは:便利です! 毎回、新しいファイルに名前を付けて、習慣的に考えました。キリル文字をサポートしていないシステムでこのファイルを開こうとしたらどうでしょうか。 しかし、この可能性は次第に少なくなり、時間の経過とともに習慣は消えていきました。
約3年前、私は突然、識別子が任意の文字(英語でもロシア語でもかまいません)の識別子と呼ばれることを発見しました。 これは、dotNETがUnicodeで動作するように方向付けられているという事実から生じました。 最初に頭に浮かんだのは、ロシア語の名前の使用にはどのような問題があるのでしょうか? さまざまなバージョンのWindowsおよびdotNET Frameworkで「Russified」コードを試したが、単一の問題を特定できなかった。
したがって、dotNETにはロシアの識別子の使用に技術的な問題はないという結論に達しました。
もちろん、ロシア語の名前を使用するという疑問が自然に消える場合があります。
- 何らかの理由で製品の顧客がすべてのコードを英語にする必要がある場合;
- プロジェクトがオープンソースに投稿されるか、外国の開発者に譲渡される疑いがある場合;
- 開発チームの全員がロシア語を話せない場合;
- プロジェクトがさまざまな言語と技術の動物園である場合(MS-DOSの時代を含む)。
- ロシアの識別子が継承されたコードを混乱させる場合。
機会が利用できるからといって、それを使用する必要があるわけではないことは明らかです。
私はほとんどすべてのプロジェクトでロシア語の識別子を使い始めました。 そして時間の経過とともに、彼はそのような結論を出しました。
ロシアの識別子はオブジェクトモデルの作成に理想的であり、残りのコードでは役に立たないのです。
次に例を示します。
顧客が教育機関であり、学生、クラス、科目、成績などの会計システムが必要だとします。顧客との会話では、「学生」、「被験者」、「学業成績」という言葉を使用します。 ? オブジェクトモデルを作成します。
VisualStudioで、クラス図を作成します。
このようなクラス図は、顧客に表示することもできますし、同時に文字通り「1つの言語で」、つまり同じ用語を使用して顧客と話すこともできます。 顧客は自分のコードに精通しているとさえ感じるかもしれません:)
もちろん、この場合、「File」、「Stream」、「Collection」、「WebClient」など、元々英語を話す技術用語をロシア語のコードで呼び出して呼び出すべきではありません。
このトピックについて同僚とコミュニケーションをとると、ロシアの識別子に対する態度が時間とともに徐々に変化することに気付きました。 急激にネガティブなものから、やや落ち着いたものへ。 プログラマーが英語のみでコードを記述したい理由のリストを次に示します。
- 怠azineはしばしばレイアウトを切り替えます。 これは奇妙な問題です。たとえば、レイアウトを切り替えるとパフォーマンスが低下することがよくあります。 10本の指をすばやくコーディングするのは本当に開発者の仕事ですか? 私の意見では、コードの読みやすさは、レイアウトの切り替えに費やされる1日あたり数秒(または数分)よりも重要です。 それでは、Console.Write( "Hello、World!")のようなコードを書くときにプログラマーが文句を言わないのはなぜですか。 -ここでも切り替える必要があるため。 さらに、これらの同じ開発者は、ディスク上の個人ファイルをロシア語で呼び出します。 したがって、この問題は「指から吸い出され」、実際の問題がなかったことを意味します。
UPD:コードの編集時にレイアウトを切り替えることは完全に習慣の問題です。 脳は2〜3日でこのタスクに適応し、緊張をやめます-実験的にテストされています。 - 可能な限り複雑なコードを探してください。 顧客、他のプログラマー、上司にコードが明確な場合-プログラミングはそれほど難しくないという意見があるかもしれません。これにより、魔術師のように誰かに奇妙なキャラクターを書くプログラマーのイメージが薄暗くなります...言い換えれば、とてもスマートでかけがえのないものにしたいという願望を表しています。
- グリッチの恐怖ロシアの名前が原因で問題を説明するのが難しいと主張するために、少なくともそれらを使用してみるべきです。 そして、実践によって裏付けられていない根拠のない申し立ては、思考の慣性に対するカバーにすぎません。 私の個人的な練習では、このような小さな不具合が(Silverlightプロジェクトで)ありましたが、他の多くの不具合を背景にすると、それは取るに足りないものです。 何らかの理由で、この恐怖は、プログラマーが64ビットRussified Windowsで作業し、ローカライズされたGoogle Jを使用することを妨げません。
- 外国人がコードを購入したらどうなりますか? コードを外国の顧客に転送する目的で最初に記述されている場合、質問はありません。 それ以外の場合、コードがブルジョアまたはヒンズー教徒に行く確率は非常に小さいです。 その場合-エンドユーザーが次のオフィスの会計士であっても、ユーザーインターフェイスは英語のみで行う必要があります。
- オブジェクトモデルは、データベースの構造を繰り返します。 多くの場合、データベース内のテーブルとそれらの間の関係は、アプリケーションオブジェクトモデルと見なされます。 この場合、データベースのテーブルとフィールドが呼び出されるのと同じ方法でクラスとプロパティに名前を付けると便利です。 イデオロギー的に、そのようなアプローチは時代遅れになりました-今では、ドメイン駆動設計(DDD)を推進し、顧客のサブジェクト領域が基礎として採用されています。
ところで、最近、1Cプログラマーが文字通り「ロシア語で」コードを書くことを知りました。
結論として、結論:
- ロシアの識別子は、国内プロジェクトのオブジェクトモデルを記述するのに最適です
- 私は思う-時間の経過とともに、開発者はロシアの識別子を使用することを恐れなくなります
- 極端なことは必要ありません。すべてのコードをロシア語で書くのはばかげています。
更新:開発で使用するツールのブルジョアは、母国語でコードを表示します...