クライアント開発仕様-Android

10153 ワード
なぜ開発規範が必要なのか
1つのソフトウェアのライフサイクルの80%がのメンテナンスに費やされています.
開発者と保守者が同一人物であることは保証できないソースコードを作品として発表すれば、彼は機械に理解するだけでなく、を理解する必要がある.
開発規範はソフトウェアの理解性を改善し、ソフトウェアの明確さを維持することができる.

原則


符号化前にコードの論理構造を明確にし、必要に応じてグラフィックグラフを用いての思考を助けることができる.
単純なCopy-Paste符号化は絶対にしないでください.
「悪い味」のコードを手当たり次第に再構築します.
コードの単純明瞭性を維持するsdkが提供する統合ツールクラスを使用して、車輪を繰り返さないでください.例えば、StringUtils、LogCatLogなど.

書式設定


インデントレイアウト、4つのスペースをインデント単位として行の長さ、できるだけ1行の長さが120文字のを超えることを避けます
行を改行します.1つの式が1行に書けない場合は、次のルールに従って行をブレークできます.
1つのカンマの後でを切断
1つの操作記号の前でを切断する.
下位レベルのブレークダウンではなく、上位レベルのブレークダウンを選択します.
新しい行は、前の行と同じレベルの式の先頭に揃えなければなりません.
上記のルールがコードを混乱させたり、右側にコードを積み上げたりした場合は、代わりに2単位(8スペース)をインデントします.

文ブロックの「{」は、新しい行を追加しないでください.
演算子優先度の問題を回避するためにカッコを使用する
例:
    private static synchronized horkingLongMethodName(int anArg, 
            Object anotherArg, String yetAnotherArg, 
            Object andStillAnother) { 
            ... 
    }

コメント


コード自体はソフトウェアの大部分の情報を含むべきで、コードを通じてその意味を理解することができます良い注釈はソフトウェアの意図を説明するためにあるいはプログラムの機能を総括するために、簡単な繰り返しコードではありませんて、彼は“どうして”を説明して“何です”のではありません
注釈ではなく、困惑するコードを書き換える.
期限切れの注釈に対して更新修正を行い、冗長性と矛盾した注釈を削除し、注釈がはっきりしていることを確保する.
次の状況についてコメントする必要があります.
各javaファイルのヘッダには、@authorと明記されており、連絡が便利です.このjavaファイルの主要クラスの機能説明と、コメントブロックにマージできます.
各クラスの機能(特にpublicクラス)メソッドの機能(アクセスメソッドを除く、特にpublicメソッド)クラス変数の機能冗長または複雑な制御構造入力パラメータの特殊制限
自動生成「//TODO Auto-generated method stub」を削除
改善すべきコードは「//FIXMME:」で注釈例:
    /**
     * @author sanping.li
     * AST 
     *
     */
    public interface Node {

        /**
         *   ， 
         */
        public void open();
        ...
    }

名前を付ける


ネーミングはアルパカネーミング法を採用
変数名、関数名、コントロールViewid、頭文字小文字、後の単語の頭文字定数名全大文字クラス名の頭文字パッケージ名全小文字
命名は識別を区別するためで、同じレベルのすべての要素に同じ名前の「装飾」があれば、レイアウトファイル、クラス名の前のAlipayなどのを削除することができます.
変数名は変数の意味を正確に記述し、意味のない名前を使用しないで、勝手に略語を使用しないでください.特に曖昧な略語はです.
命名は長すぎず短すぎず、4つの単語を超えないでください.
例:
    package com.alipay.android.core;// 
    public class ActivityShell extends RootActivity {// 
    private int mType;// 
    private boolean checkRequisite();// 
    public static final int STATE_NOMARL = 0;// 
    android:id="@+id/titleDivider"

変数＃ヘンスウ＃


行ごとに1つの変数のみを宣言することを推奨します.
異なるタイプの変数宣言を1つのに配置しないでください.
変数宣言は、タブを使用してに整列できます.
明示的な宣言変数の役割ドメイン変数の役割ドメインをできるだけ縮小し,パッケージング性を強化する.十分な理由がなければpublicクラスの変数を使用しないでください.
例:
    private int                     mState;
    private String                  mName;
    private Map<String,Object>      mCache;

ステートメント


各行には1つの文しか含まれていません.
1つの文で複数の変数にを割り当てることを避ける.
文ブロックは1行の文のみであるにもかかわらず、できるだけ「{}」を加える.
switch文の各caseの後にはbreak文またはreturn文が必要です.
switch文はdefault文でなければなりません
必要がない限り、死の循環を禁止し、万全を保証することができます.そうでない場合は、最大サイクル数の制御を加えます.
例:
    if (mType == TYPE_XML){
        ...
    }

    switch (mState) {
        case STATE_PAUSE:
            ...
            break;
        case STATE_INSTALLING:
            ...
            break;
        default:
            throw new Exception("error msg");
    }

方法


それぞれの方法は1つのことをしてをします.
各メソッドの長さは47行を超えないでください.
メソッドのパラメータの個数はできるだけ少なく、5つのを超えないでください.
論理ネスト階層は3層より大きくない
1つの方法は1つの出口しかありません
例:
    public int doSomething(int arg1,int arg2){
        int retVal = 0;
        ...
        return retVal;
    }

クラス#クラス#


1つのクラスは、データをカプセル化するだけでなく、をカプセル化する.
「魔法の数字」の代わりに定数を使用
各クラスの長さは1000行を超えないでください.
オブジェクトを使用して静的変数とメソッドにアクセスしないでください.
例:
    public class Sample{
        private static final int TYPE_XML = 0;
        ...
        Processor.parser(argument);// new Processor().parser(argument) 
        ...
        if(mType == TYPE_XML){// “ ”， if(mType == 0){
    }

パッケージ


バッグは太すぎず細すぎずパッケージの区分機能およびサブ機能をセグメント別に区分するモジュール

例外処理


tryブロックのボリュームをできるだけ小さくし、tryブロックをネストしないでください.
異常をキャプチャするには、破棄するのではなく、適切な処理が必要です.そうしないと、を上げる必要があります.
catch文では、可能な限り特定の例外タイプを指定し、必要に応じて複数のcatchを使用して、発生する可能性のあるすべての例外を処理しようとしないでください.
finallyを十分に運用し、すべてのリソースが正しく解放されることを保証するfinallyにreturn文が表示されないでください.
例外処理モジュールに適切なエラー原因情報を提供し、エラー情報を整理して理解しやすくし、読みやすくします.
発生する可能性のある異常とこれらの異常が実行プロセスに与える影響を全面的に考慮し、異常を使用してプロセス制御を行わないでください.
異常捕獲は万能ではありません.問題が発生しないでください.
例:
    try {
        ...
    } catch (FileNotFoundException fe) {
        Log.e(TAG,fe.getMessage());// 
    } catch (IOException ie) {
        Log.e(TAG,ie.getMessage());// 
    } catch (Exception e){
        ...// 
    } finally {
        ...
    }


スレッド


常駐スレッドに名前を付けて、識別しやすいようにしなければなりません.
ロックを持っているときにThreadを呼び出すことは許されません.sleep

しげん


できるだけコードではなくリソースを使用して機能を完了する.
レイアウトファイルはできるだけ簡潔で、モジュールがはっきりしているレイアウト要素の外観をできるだけスタイルで制御する.
文字定数はstringsに置く.xml
9 pngの4つの領域は全を描くことが望ましい.
ストリームを閉じることを忘れないでください.
カーソル使用者チェックカーソルを閉じる

パフォーマンス プライマリスレッド上でi/o、ネットワークリクエストなどの時間のかかる操作を実行しないでください。このような操作は、UIが応答せずにANRを生成する可能性があります。 現在の表示画面のLayoutは80個のViewsを超えてはならない。（From Google I/O 2009 Sesstion Optimize layout） Layoutのネストはできるだけ少なくしなければならない。1つのPageの最も深いLayoutネストは8つを超えないでください。Scroll操作ができるLayoutネストの深さは5個を超えてはいけません


ライフサイクル


アプリケーションライフサイクルのオブジェクト関連付けは、Application Context である必要があります.
Activityライフサイクルのデータ関連付けはActivity Context です.
Activityが回収されたときのデータの保存と復元を考慮すると、ActivityのデータだけでなくApplicationのデータもあります.
他のクラスでActivityを強く引用することはできません.適切なタイミングで解縛を完了する必要がある場合は、Activityが正常に回収できず、リソースが漏洩します.

メモリ管理


同じデータは1つのコピーのみ保存されます.
リストクラスのデータは、できるだけAdapterViewを使用してを表示します.
Adapterを使用する場合はconvertViewの処理に注意し、ViewHolder を考慮することができます.
bitmap はできるだけ処理(合成、コピー)しないでください.
bitmapオブジェクトが多すぎる場合はソフトリファレンスを使用することを考慮する.
view ではなくandroidのactivityをできるだけ使用します.
静的変数をできるだけ少なく使用しないでください.そうしないと、表示されるメモリを解放する必要があります.
例:
    public View getView(int position, View convertView, ViewGroup parent) {
        if (convertView == null) {
            ...// 
        }
        ...// 
    }



安全


ローカルにパスワードを保存したり、対称的に暗号化したパスワードを保存したりしてはいけません.
ユーザーのプライバシーデータをローカルに保存するには、関連する規定に従う必要があります.プライバシーデータには、ユーザー名、携帯電話番号、身分証明書番号、銀行カード番号、取引記録などが含まれています.
クライアントが出力するログには、機密情報がフィルタリングされるべきである.
クライアント・コードが発行される前に、を混同する必要があります.

インタフェースの互換性

  • 外部露出インタフェースを定義する際には、拡張不可能な構造体の代わりにk−v文字列を用い、拡張パラメータを予め残すなど、インタフェースの拡張を考慮する必要がある.
  • インタフェースに開示されているメソッドの定義(メソッド名、パラメータ、戻り値などを含む)を変更しようとしないでください.新しい機能要件がある場合は、新しい方法またはインタフェースを拡張する必要があります.これにより、インタフェースの互換性がうまく処理されます.

    • 操作習慣


    通常フォーマットコード(eclipseはctrl+shift+Fを使用)コードファイルはutf-8符号化を統一して使用します.eclipseのworkspaceをutf-8に設定してください.設定方法は、Preferences->General->Workspace 不要なパケットインポートの除去(eclipseはctrl+oを使用)および不要な変数および方法コードコミット
    コードをコミットする前にバージョン管理ツールで変更内容を表示するコードをコミットする前にupdate を行います.
    コードをコミットするにはコメントを書く必要があります.今回の変更の詳細は、fixバグの場合、バグのheadlineまたはリンクを与える必要があります.

    デバッグが容易なログなど、不要なログ出力は、正式なコードに残さないで削除してください.
    不要なパケットインポートの除去(eclipseはctrl+oを使用)および不要な変数および方法
    HTML(2)::Semantic Web
    Graph