ライブラリを C++ から Java に移植しています。これは初めてのことで、「移植」が実際に何を意味するのかよくわかりません。具体的には、作成者が変数に「A」という名前を付けた場合、「B」の方が適切な名前だと思います。メソッド、クラス、名前空間についても同様です。また、何かもっとうまくできると思ったらどうしますか?移植とは、元のコードの精神を可能な限り維持するように努める必要があることを意味しますが、それでも自由に改善できるようにする必要がありますか?
ありがとう
ライブラリを C++ から Java に移植しています。これは初めてのことで、「移植」が実際に何を意味するのかよくわかりません。具体的には、作成者が変数に「A」という名前を付けた場合、「B」の方が適切な名前だと思います。メソッド、クラス、名前空間についても同様です。また、何かもっとうまくできると思ったらどうしますか?移植とは、元のコードの精神を可能な限り維持するように努める必要があることを意味しますが、それでも自由に改善できるようにする必要がありますか?
ありがとう
必ずしも 1 対 1 の変換である必要はありません (多くの場合、変換できません)。移植とは、ソフトウェアの一部を別の言語/環境などで書き直すことです。移植では、微調整してさまざまな方法で実装する必要がある場合があるため、投稿の最後の文は物事の要点をほぼ捉えていると思います.
本を英語から別の言語に翻訳するようなものだと私は考えています。ソース素材の意図/機能をどのように表現するかという観点から、判断を下す必要がある場合があります。
システム A からシステム B に移植するとき、世界はあなたのカキです。改善だと信じるなら、ほとんど何でも変えることができます。それに対する唯一の注意点は、インターフェースを扱うときです。たとえば、API を移植しているとします。たとえば、外部から利用可能なメソッドに名前を付けるのは良い考えではありません。複数のクラスにまたがる命名の問題を追跡することは、大きな苦痛です。
言語から言語へのかなりの移植を行ってきた者として、何よりもまず実装の詳細に固執することをお勧めします。優れたエンジニアリングの原則は、いつでも 1 つのことを変更することです。そうすれば、物事が期待どおりに動作しない場合、責任があるのは実装であり、ばかげた命名の問題ではないことがわかります。そして、名前を変更するときは、言うまでもなく、非常に注意して頻繁にバックアップしてください。これは、ソフトウェアのバージョン管理によって時間を節約できる 1 つのケースです。
あるプラットフォームから別のプラットフォームにライブラリを「移植」すると、機能が移植されます。コードのスタイルを移植していません。比喩や弱強五歩格などを念頭に置いて、作品のスタイルを維持しなければならない文学とは異なります。