【Java】Myコーディングスタイル

今回はアプリを作成する上でのJavaのコーディングスタイルとして、
自分なりに行っているコーディング規約を紹介していきます(^o^)丿

私個人のコーディング規約ですので参考程度に見ていただければと思います(^o^;

概要

細かくわかれますので概要として以下の内容についてコーディング規約を説明していきます。


・コーディングスタイル
　■入れ子のかっこ{}で1行使う

　■字下げはタブ、または半角スペース×2の倍数

・命名規約
　■変数名の規則
　■メンバ変数には「m_」を付ける
　■定数は大文字と下線のみ
　■長くても意味のある名前を付ける
　■クラス名

・コメント

　■出来る限り多くコメントをつける
　■if文やswitch文ではすべてのケースでコメント追加

　■不具合の修正箇所にコメントをつける　

　■現在把握している問題についてコメント

　■入れ子が多い場合には行末コメント

　■Javadocに対応する書き方に統一

・プログラミング規約

　■データ型のクラスにはfinalを宣言

　■例外キャッチ時はprintStackTrace

・メンテナンスによる既存ソースの手入れ

　■既存ソースでは行われていない意外性のある方法で行わない

　■命名規約の注意

　■コメント

コーディングスタイル

■入れ子のかっこ｛｝で1行使う

　if(…)
　{
　　:
　}
　else
　{
　　:
　}

　❏行数は増えますが、統一するとコードが大分見やすくなります。

■字下げはタブ、または半角スペース×2の倍数

class SampleActivity extends Activity
{
..void function(…)
..{
....if(…)
....{
......//処理
....}
..}
}

　❏タブは開発環境によって解釈が異なるため、半角スペースで行うことが統一性が取れます。

　❏EclipseやAndroidStudioを使ってる分にはタブで良いと思います。

命名規約

■変数名の規則

　int nCount;
　String strEditText;
　short iNumber;
　：

　❏int型・・・頭に「n」をつける
　❏String型・・・頭に「str」をつける
　❏short型・・・頭に「i」をつける

　❏etc.


■メンバ変数には「m_」を付ける

class SampleActivity extends Activity
{
　private int m_nDataCount;
}

　※ローカル変数には「m_」をつけないようにします。

■定数は大文字と下線のみ

　public static final int MAX_COUNT = 255;
　public static final int MIN_COUNT = 0;

　※定数以外（クラス名やメソッド名、変数名等）は大文字小文字を含めたものに統一します。

■長くても意味のある名前を付ける

　for(int i=0; i<n; i++)
　{
　　：
　}

　❏これだとfor文のカウントの意味もループする回数の意味もよくわからないので、

　for(int nIndex=0; nIndex<nArraySize; nIndex++)
　{
　　：
　}

　❏変数名を見てfor文で何のループが行われているかわかるようにしておくと他の人がみても
　　理解しやすくなります。

　※Javaは長い名前をつけることで若干動作が遅くなってしまうようですが、
　　多少動作が遅くなるよりメンテナンス性を重視したほうが良いと思っています。
　　（アプリ開発時にはproguardを使って難読化することで、名前が短縮されて動作すると思われるので
　　　この点も解決されるかと思います）

■クラス名

　class AnimalBase
　{
　　：
　}
　class CatAnimal extends AnimalBase
　{
　　：
　}

　class MainActivity extends Activity
　{
　　：
　}

　❏親クラスには「Base」をつけるようにします。

　❏子クラスには継承した親クラスがわかるように名前の一部を付け足します。

　　例）親が「Activity」の場合、子は「XxxxActivity」　

　　例）親が「Adapter」の場合、子は「XxxxAdapter」　

　　例）親が「Dialog」の場合、子は「XxxxDialog」　

コメント

■出来る限り多くコメントをつける

　❏一つの処理のまとまりに説明をつけるようにします。
　　（１つの役割ごとにコメントをつけることで、後々コメントした箇所を関数化も可能だから）
　❏コメントがあればコードの解釈を誤解してもコメントから認識できるため、
　　難しい処理を行っている箇所ではより多く説明を加えます。
　　（複数行のコメントがある場合もあり）

■if文やswitch文ではすべてのケースでコメント追加

　if(…)
　{
　　// 正しく動作した時の処理
　　：
　}
　else
　{
　　// エラー処理
　}

　❏elseでは何も処理をしない場合でも、コメントをつけるために追加することで
　　考えていなかったり漏れてしまうケースをなくすことに繋がります。

■不具合の修正箇所にコメントをつける

　❏以前なぜこの修正を行ったかがわかったほうが良い箇所でコメントがあると、
　　修正前の間違いや同じ様なミスが起きにくくなります。

■現在把握している問題についてコメント

　❏未解決の問題について把握している場合はコメントを残しておきます。

■入れ子が多い場合には行末コメント

　while(…)
　{
　　for(…)
　　{
　　　if(…)
　　　{
　　　　：
　　　} // if
　　} // for
　} // while

　❏行末コメントとは、処理の後ろに追加するコメントのことです。

　※出来る限り入れ子は少なくする。
　　どうしても多くなる場合は関数化することも検討するべき。

■Javadocに対応する書き方に統一

　/*************************************
　 * 関数名：
　 * 　機能：
　 * @param 引数名　説明
　 * @return  戻り値　説明
　 *************************************/

　❏現在詳細検討中(^_^;
　❏メソッドの場合、引数や戻り値の意味をかきます。

　❏HTML文も使用できるため、みやすく統一したコメントにしたいです(・∀・)

プログラミング規約

■データ型のクラスにはfinalを宣言

　❏finalをつけることで親クラスとして使用できないが、データ型のクラスはほとんど拡張しないため

■例外キャッチ時はprintStackTrace

　try
　{
　　：
　}
　catch(Exception e)
　{
　　e.printStackTrace();
　}

　❏万が一の場合にも例外発生していることは確認できるようにしておく必要がある。
　❏あえて例外を発生させている箇所では不要かも…

メンテナンスによる既存ソースの手入れ

■既存ソースでは行われていない意外性のある方法で行わない

　❏既存ソースと修正箇所で統一性がなく読みにくいソースになり、
　　メンテナンス性も悪くなるためできるだけ既存ソースに合わせた書き方をします。

■命名規約の注意

　❏英語の意味は馴染のある英単語を使い、ローマ字で書かれている箇所があれば
　　合わせた名前で命名するようにします。

■コメント

　❏関数やメソッドに付けるコメントも人それぞれの付け方があると思いますが、
　　同じクラス内では同じコメントの書き方に統一する方が誰がみてもみやすくなります。

考察

ここに記載したコーディングスタイルは私個人が現時点で実践しているコーディング規約となります。

もしここをこうしたほうが良い等教えて頂ける場合にはコメントしていただければありがたいです(^0^)／

また、今後も変更があれば定期的に更新していきます～♪