はじめに
たいていのIDEが備えているソースコードの整形機能―――コードフォーマットについて解説します。Android Studioができるコードフォーマットは次の3種類です。
- インポートの最適化
- インポート文の最適化を行います。Eclipseの
「ソース → インポートの編成」 に相当します。 - コードフォーマット
- 指定されたルールに基づいてソースコードを整形します。Eclipseの
「ソース → フォーマット / 要素のフォーマット」 に相当します。 - アレンジメント
- 指定されたルールに基づいて、
ソースコード内の要素を並び替えます。Eclipseの 「ソース → メンバーのソート」 に相当します。
できることはEclipseとさほど変わりありません。Eclipseとの機能的な大きな違いは ファイルの保存のタイミングで自動でフォーマットできないこと です。
コードフォーマットの基本
Android Studioのコードフォーマットのルール
インスペクションと同じようにコードスタイルも
もうすこし内情について説明します。コードスタイルの設定はProject Structureに属しているにもかかわらず<AS_」
そこで登場するのがデフォルトで登録済みの<PROJECT_」
「Project」
この
「Preferences / Code Style」
インポートの最適化
無駄なインポート文を削除したり、
まずはインポート最適化に関するルール設定について説明します。設定箇所は
設定できる箇所はそれほど多くは無いのですが、
- General
- インポート最適化の全般的な設定です。
-
- Use single class import：ONにするとアスタリスク
（ *）を使わず、 クラスひとつずつ インポート文を記述します。 - Use fully qualified class names：ONにするとインポート文を使わず、
常にクラスの完全修飾名を展開します。正直、 なんのためにあるオプションなのかわかりません。 - Insert imports for inner classes：ONにすると内部クラスに対してもインポート文を展開します。これをONにすると、
一見してそのクラスが内部クラスなのか通常のクラスなのか見分けが付かなくなるので、 筆者はこれをONにするのは好みません。 - Use fully qualified class names in javadoc：ONにすると、
Javadoc中のクラスを完全修飾名で記述します。Javadoc中でしか参照しないクラスのために インポート文を追加するのが許せない人はONにしましょう。筆者は、 そのあたりはおおらかなのでOFFにしています。 - Class count to use import with '*'：インポート文でアスタリスクを使うまでの閾値を指定します。最初に紹介した
「Use single class import」 をONにしていても 同じパッケージのクラス を、 ここで指定した値以上インポートするとアスタリスクに展開します。 - Names count to use static import with '*'：上の項目のスタティックインポート版です。ここで指定した値以上のメンバやメソッドをスタティックインポートするとアスタリスクに展開します。
- Use single class import：ONにするとアスタリスク
- JSP imports layout
- JSP
（JavaServer Pages） でのインポート文の設定です。そもそもAndroid StudioはJSPの編集をサポートしていないので、 この項目自体が無意味です。元になったIntelliJ IDEAのUltimate EditionがJSPをサポートしているので、 その名残です。 - Package to Use Import with '*'
- 「General」
にある 「Use single class import」 や 「Class/ Names count to use～」 に関わりなく、 常にアスタリスク指定でインポートしたいパッケージを指定します （スタティックインポートも扱えます）。 - Import Layout
- インポート文の並び順を指定します。パッケージ別に指定できたり、
空行の挿入箇所を指示できたりと、 見かけによらず高機能です。もちろんスタティックインポートも対象です。
どのような設定が望ましいかは、
-
インポートにアスタリスクを使うのは好きでは無い
「Use single class import」 をON - 「Class count to use import with '*'」
に 99999 を指定 （いかなる場合もアスタリスク展開させない）
-
反対にスタティックインポートにアスタリスクを使うのを好む
「Names count to use static import with '*'」 に 3 を指定 （3つ以上、 同じクラスのメンバをスタティックインポートしたらアスタリスク展開する）
JUnit4やhamcrestの場合は常にアスタリスク展開したかったので、
コーディング時に適時インポートの最適化を行う
「Preferences / Code Style / Java / Imports」
その代表格が
- Insert import on paste
- コード片をペーストした際にインポートが必要だった場合の振る舞いを指定します。
-
- All：必要なインポート文を自動的に追加します。
- Ask：必要なインポート文を確認するダイアログを表示し、
インポートするかどうかを問い合わせます （筆者はこの設定を好んでます）。 - None：インポート文が必要だとしても何もしません。
- Show import popup
- インポートする候補をポップアップ表示します。通常ONにします
（これをOFFにする理由を知りたいくらいです）。遙かかなた昔は意味のあったオプションなのですが、 IntelliJ IDEA13をベースにしているAndroid Studioのコード補完機能はより高度になっているので、 このオプションがONであろうとOFFであろうと、 インポートするパッケージの候補が表示されます。 - Optimize imports on the fly
- コーディングしながらリアルタイムにインポートの最適化を行います。最適化の精度はそれほど高くありません。コードスタイル設定で
「Use single class import」 を有効にしていても、 すでに 「 import java.」util.*; などの記述があれば、 それを優先します。 - 基本的にONにすることをオススメします。ただし、
チーム開発で他人が作ったコードを編集する時など涙をのんでOFFにする場合もあります。時と場合によっては 「インポートの最適化」 は寝た子を起こすな的な意味で余計なお世話になるからです。 - また不要なインポート文を除去する場合は、
これの他にインスペクションの 「Imports / Unused import(editor light)」 を有効にする必要があります。まわりくどいですね。 - Add unambiguous imports on the fly
MapやArrayListなどインポートするパッケージが一意な場合、利用者に問い合わせなく勝手にインポートを追加するかどうかを指定します。通常のコード補完でも似たような振る舞いをしているので、 ONにしておいて邪魔になることはないでしょう。 - Exclude from Inport and Completion
- インポートやコード補完の候補から除外するパッケージを指定します。ここで設定しなくてもコード補完の候補リストから除外パッケージを指定できます。むしろ、
そのほうが便利です。 -
図4 コード補完時に自動インポートの除外パッケージを指定する 
- どちらかというと間違えて除外設定してしまったパッケージ指定を削除するために用いるのが主な使い道になるでしょう。
コーディングしながら半自動的にインポート文を展開していく書き心地はIDEによって微妙に異なるので、
コーディング中のインポートに関わる設定は、
- '*' import
- パッケージ全体のインポート
（アスタリスク指定のインポート文） を警告します。ここをONにすると 「Preferences / Code Style」 の 「imports」 設定に関わりなく警告してきます。 - Import from same package
- 自身が属するパッケージをインポートしている場合に警告します。多くの読者は、
そんなマヌケな事はしないと思いますが、 時折このようなコードを見て世界の広さを感じることがあります。 - 'java.
lang' import java.パッケージをインポートしている場合に警告します。lang - Redundant import
- 重複したインポート文があれば警告します。
- Single class import
- クラス指定のインポートをしている場合に警告します。
「 \*import」の真逆です。こちらも 「Preferences / Code Style」 の 「imports」 設定に関わりなく警告してきます。 - Static import
- スタティックインポートを使っていると警告してきます。Optionsに
「staticインポートを許可するクラス （Statically importable Classes）」を指定することができます。また 「テストコードでのみ許可する （Ignore in test code）」などユニークなオプションがあります。 -
図5 「Static import」 の設定項目 
- Unused import
- 使っていないパッケージのインポート文があれば警告します。次の
「Unused inport(editor light)」 とやることは同じですが、 こちらは第40回で紹介した"Inspect Code..."用です。 - Unused inport(editor light)
- 使っていないパッケージのインポート文があれば警告します。
「Preferences / Editor / Auto Imports」 の 「Optimize imports on the fly」 と組み合わせると、 不要なインポート文を即座に削除します。 - 常にインポート文が最適化してあるのは気持ちの良い事なのですが、
あまりにも即時過ぎると、 ちょっとコードを弄っただけでインポート文を削除するので、 それが思考の妨げになる時があります。インポート文の最適化もやり過ぎ注意ですね。
続いてインテンション
- Declaration / Replace Implements with Static Import
implementsやextendsに指定しているインターフェイスやクラスの利用箇所をスタティックインポートに置き換えます。- Declaration / Replace On Demand Import with Single Class Imports
- パッケージインポート
（アスタリスク指定） をシングルクラスのインポートに置き換えます。 - Declaration / Replace Qualified Name with Import
- 完全修飾で指定しているクラスやインターフェイスをインポート文に置き換えます。
- Imports / Add On Demand Static Import
- スタティックインポートに変換可能ならばスタティックインポートに置き換えます。
- Imports / Add Single-Member Static Import
- スタティックインポートをアスタリスク指定ではなくシングルメンバで記述します。
- Imports / Expand Static Import
- スタティックインポートをやめて元に戻します。これをONにする用途はそう無いでしょう。
これらの設定を行った上で、
コマンドを実行してインポートの最適化を行う
メニューバーの
こちらのコマンドによる方法だと、
コマンドを実行すると図6のようなダイアログが表示されます。
ダイアログには
見ての通り指定したディレクトリ配下に対して
Eclipseの
インポートしていないパッケージが存在する状態は
コードフォーマット
今回のド本命です。コードスタイルの設定は
それぞれの設定項目の詳細については次回まとめて紹介します。今回はコードフォーマットの使い方と予備知識を中心に説明します。
コードフォーマットはメニューバーの
こちらもインポートの最適化同様、
インポートの最適化と違う点は、
「Reformat Code」
インポートの最適化の
この場所が非常にわかりづらいため、
最近のAndroid Studioでは、@formatter:off」@formatter:on」
// @formatter:off
TextView textView = (TextView)findViewById(R.id.textView);
textView.setText(getIntent().
getStringExtra("inputText"));
// @formatter:onこの機能を使うには
コード生成に関連するコードスタイルの設定
コードフォーマットのスタイル設定を行う
ついでなので仕方ないのでしょうがコードスタイルの設定には
- Naming
- インスタンス変数
（Field）、 クラス変数 （Static Field）、 引数 （Parameter）、 ローカル変数 （Local variable） それぞれの接頭子 （Name prefix） と接尾子 （Name suffix） を定義します。採用しているコーディングルールや好みにもよると思いますが、 筆者はここを設定した事はありません。 - 仮に図12のような古典的なルールを定義したとしましょう
（ローカル変数の接頭子にアンダースコア （ _）を付けます）。 -
図12 ローカル変数の接頭子を指定する 
- 一応というか当然それなりの影響力がありまして、
コード補完の候補もここで定義した内容に従うようになります。 -
図13 ローカル変数名のコード補完の候補に接頭子が付くようになる 
- なお
「Prefer longer names」 をONにするとコード補完に出てくる候補は文字数の長い順になります。OFFの場合は、 文字数の短い順になります。これは接頭子、 接尾子とは関係なく機能するオプションです。 -
図14 「Prefer longer names」 のON/ OFFによる補完候補の違い 
- こんなどーでもいいことまで設定できるところを見るにつけ、
すごいなぁという思いとやり過ぎだろうというあきれた思いが交差します （こうゆう拘りが良い方向にはたらく事がよくあるので侮れません）。 - Final Modifier
- 自動生成したコードのローカル変数
（local variable） や引数 （parameter） にFinal修飾子をつけるかどうかを指定します。 -
- Make generated local variables final：ローカル変数に
finalをつける - Make generated parameters final：引数に
finalをつける
- Make generated local variables final：ローカル変数に
finalを付けたい気持ちはわかるのですが、そこまで徹底できないので筆者はこの設定を両方ともOFFにしています。 - Comment Code
- "Comment with Line Comment"や"Comment with Block Comment"でコメントアウトするときに、
その行の最初 （1桁目） にコメント宣言 （ //や/* ～ */）を記述するかどうかを指定します。 -
- Line comment at first column：行コメントを行の先頭から始める
- Block comment at fist column：ブロックコメントを行の先頭から始める
- これがOFFだと文字が始まる直前にコメントが挿入されます。ブロックコメントだとON/
OFFの違いがわかりづらいです。個人的には、 2つともONにしておくのが好みです。 -
図15 「Comment Code」 の設定が両方とのONの場合 （クリックすると動きがわかります） 
「Comment Code」の設定が両方とのONの場合` &title=`図15 「Comment Code」 の設定が両方とのONの場合` &width=`391` /> -
図16 「Comment Code」 の設定が両方とのOFFの場合 （クリックすると動きがわかります） 
「Comment Code」の設定が両方とのOFFの場合` &title=`図16 「Comment Code」 の設定が両方とのOFFの場合` &width=`400` /> - Override Method Signature
- 自動生成したオーバライドメソッド
（インターフェイスの実装メソッド含む） のシグネチャに関する設定です。 -
- Insert @Override annotation：
@Overrideアノテーションを付けるかどうかを指定します。イマドキのJava開発なら迷わずONにしましょう。 - Repeat synchronized modifier：
synchronized宣言を付けるかどうかを指定します。そもそもメソッド宣言にsynchronizedが付いているコードを見かける方が稀です。ほとんど出番がないと思いますが、とりあえずONにしています。
- Insert @Override annotation：
- Order of Members
- 「インテンションやリファクタリングによってメソッドやフィールドを自動生成した場合に、
どこに生成するかを指定します」 とヘルプには記述してありましたが、 実際そうなのか結構アテになりません。次の節で説明する 「アレンジメント」 とも連動していないので、 今となっては死んでる設定項目だと思って無視していよいでしょう。筆者も、 この設定を気にしたことがありません。
「Comment Code」
「Comment Code」アレンジメント
Eclipseの
それと律儀にアレンジメントだけ行います
生い立ちといっても大げさなものではありません。元々この機能、
アレンジメントの設定
「Preferences / Code Style / Java」
元がJetBrains製ではないプラグインという背景もあってか、
Andorid Studio 0.
「Grouping rules」
- Keep getters and setters together
- 同じプロパティに対する
getterとsetterをまとめるかどうかを指定ます。 - Keep overridden methods together
- オーバライド
（または実装） したメソッドの並び順を指定します。 -
- keep order：親クラス
（またはインターフェイス） の定義順に並び替える - order by name：アルファベット順に並び替える
- keep order：親クラス
- Keep dependent method together
- 依存関係のあるメソッドの並び順を指定します。
「依存関係のあるメソッド」 とはリスト2のようなメソッド群を指します。 -
- depth-first order：深さ優先で並び替えします。
- breadth-first order：幅優先で並び替えします。先ほど例示したリストが幅優先の例です。
void aaa() {
bbb();
ccc();
}
void bbb() { AAA(); }
void AAA() {}
void ccc() {}「Matching rules」
「Matching rules」筆者は、
まとめ
Android Studioのソースコード整形機能についてできること
次回は、