素晴らしいソフトウェア開発の世界へようこそ。 コード、ルール、そしてさらなるコードに満ちた、エキサイティングでスリリングな旅にご期待ください。 そして、ルールがあることを言いましたか？ あなたがコーディングに精通している人であれば、コーディング標準のコンセプトは何も新しいものではありません。 あなたは、これらのガイドラインの強力な支持者かもしれませんし、コードは表現の一形態であると信じる自由の闘士かもしれません。
コーディング規約が存在する一方で、それらは多くのバリエーションで存在し、しばしば従う必要のない単なるガイドラインであることを言及する価値があります。
- Write comments and documentation
- Write readable yet efficient code
- Use helper methods
- If avoidable, do NOT hard-coded!
- テストケースを書け。 エッジケースを忘れてはいけない。 0、空の文字列/リスト、ヌル、など。
- 読みやすく、かつ効率的なコードを書く。現在のプロジェクトのコーディング標準に準拠する。 命名規則、ファイル構造、スペーシングなどに関して、あるスタイルを好むかもしれません。好みのスタイルを設定でき、保存時に自動修正される IDE があります。 プロジェクトのすべてのファイルが同じスタイル、命名規則、スペーシングなどを使用すると、読みやすく、理解しやすくなります。 IDE のドロップダウン メニューを使用する
- API は便利です
- Pair programming/code review
- Backup and Save your work OFTEN
- About the Author
Write comments and documentation
Perhaps one of the first thing you learn as a developer is to comment your code.良いコードを書きたいのでなければ、おそらく何らかの標準にこだわるべきでしょう。 最初は、「彼らも開発者であるなら – 理解できるだろう」という精神に従って、時間の無駄に思えるかもしれません。 しかし、コードをコメントし、適切なドキュメントを提供することで、あなたが実装したアルゴリズムやロジックを他の開発者が理解できるようになります。 しかし、調子に乗ってすべての行をコメントしてはいけません。
Write readable yet efficient code
Readable code is easy to follow, yet use optimal space and time. コードを書くとき、できるだけ少ない行数で書きたいと思うことがよくあります。 おそらく、1 行でメソッドや関数全体を書くことができますが、それでは読みにくく、理解しにくくなるだけです。
Use helper methods
コードを簡潔かつ簡潔に保つことは良い習慣です。 メソッドは、それが行う必要があるものだけを実装する必要があります。 もし、実装の一部が他のことをするなら、それを別のメソッドに置き、メソッド内でそれを呼び出します。
If avoidable, do NOT hard-coded!
ハードコードされるべき唯一のものは、定数です。
テストケースを書け。 エッジケースを忘れてはいけない。 0、空の文字列/リスト、ヌル、など。
このようにして、あなたのメソッドが何を行い、何を取り、何を返すべきかを知ることができます。 いつ動作すべきか、いつ失敗すべきかを知ることができます。 関数は常にテストケースに基づいているべきで、関数のテストではありません。
読みやすく、かつ効率的なコードを書く。現在のプロジェクトのコーディング標準に準拠する。 命名規則、ファイル構造、スペーシングなどに関して、あるスタイルを好むかもしれません。
好みのスタイルを設定でき、保存時に自動修正される IDE があります。 プロジェクトのすべてのファイルが同じスタイル、命名規則、スペーシングなどを使用すると、読みやすく、理解しやすくなります。
IDE のドロップダウン メニューを使用する
標準というよりも、良い習慣ですが、これらは非常に便利で、コーディング エラーを減らすのに役立ちます。
たとえば、
変数またはメソッドの名前を変更したい場合、IDE の「refactor」オプションを使用するだけで、そのメソッド/変数名へのすべての呼び出しが変更されます。
すべてのプライベート変数のゲッター/セッターメソッドを作成したい場合、「create getter/setter」を使用するだけで、IDEが自動的にメソッドを作成します。
API は便利です
メソッドを実装する前に、それらが使用可能でないことを確認することです。 機能をインポートするだけであれば、コーディングする必要はありません。 これは、開発者の生活を超簡単にします。
有名なことわざに「車輪の再発明をするな」というのがありますが、多くの場合、それは真実です。 しかし、特にそれがサードパーティの場合、ライブラリをインポートすることの意味を常に考慮する必要があります。 ライセンスの問題は別として、コードベースが肥大化する可能性があります。
Pair programming/code review
These is very helpful when it comes to refactoring your code. 他の人は、あなたのコードを最適化するためのより良い実装を見るかもしれませんし、あなたのコードをよりエレガントにするだけかもしれません。 また、開発者が標準を遵守し、作業が二重にチェックされることを保証します。 さらに、開発者が互いに学ぶための素晴らしい方法です。
Backup and Save your work OFTEN
Enough said (もう十分です)。 このような状況下において、携帯電話機はその性能を十分に発揮することができます。 頻繁に保存し、何らかのバージョン管理システムにコードをバックアップすることが、コードを安全に保つための簡単な方法です。
コーディング標準とベスト プラクティスは、何ページにもわたる大きなトピックです。 実際、Java コーディング標準について詳しく知りたい場合は、Oracle にその情報があります。 これらの標準とプラクティスのアプリケーションも、巨大な企業プロジェクトに取り組んでいるのか、それとも弟の宿題を手伝っているのか、アプリケーションによって異なります。 多くの要因に基づいて、最終的に、開発するコードが良いコードであることを確認するのはあなた次第です。
About the Author
Denis Kharlamov は Aversan のソフトウェア開発者です。 彼は約2年間、eHealthの領域でソフトウェアのテストと検証を行ってきました。 Aversan の外では、Denis はハイキング、水泳、ソフトウェア & のウェブデザインと開発、ビデオゲーム、そしてもちろん睡眠など、さまざまな活動を楽しんでいます。
免責事項：このブログ記事で提示されたいかなる見解や意見は、あくまでも著者個人のもので、必ずしも Aversan Inc を表すものではありません。