TIPs of Android Studio – #002 コーディングスタイル

前提

OS:Windows 11 Pro
Android Studio:Flamingo 2022.2.1 Patch1
言語:Kotlin

コーディングスタイル

一般的なコーディング規約

趣味ではなく、仕事でプログラミングを行う場合には、通常所属する会社・組織が規定するコーディング規約に従って、ソースコードを記述する必要があります。

それは、新人さんでもベテランでもソースコードの記載を統一し、可読性・メンテナンス性を向上させるためにそうなっていると認識しています。

また、作成したソースコードを未来永劫「自分だけ」「作成者だけ」がメンテナンスするのならコーディング規約は不要だと思います。

しかし、作成したソースコードは納品先の所有物になり、また、自分の仕事も変わり、過去の仕事は別の人に引き継いだり、もしくは他の人の仕事を引き継ぐ事もあるでしょう。その時に自分(もしくは他人)が好き勝手に書いたコードだと、引き継いだ人(自分)が苦労する事になります…。

Android Kotlinスタイルガイド

Android StudioでKotlinを利用する場合にも、コーディングスタイルが規定されています。

Kotlin スタイルガイド

https://developer.android.com/kotlin/style-guide?hl=ja

ここには、ソースコードの書き方について細かく規定されています。

もちろん、ここに記載されている通りに記載しなくても、コンパイル・ビルドは完了し、アプリは正常に動作します。

しかし「自分のソースコードはGoogle Android スタイルです」と言うためには、Kotlinスタイルガイドに則ったコーディングが必要になります。

それでもちょっと読みにくい…

ただ、個人的にはAndroidの「Kotlinスタイルガイド」にそったコードは少し読みにくいと感じます。

Android Studioで「Empty Views Activity」のプロジェクトを作成すると、以下の様なソースコードが自動生成されます。

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
}

どうも「ごちゃ」っと詰まった感じがしてしまいます。

以下は、開発している間は自分なりに読みやすくしたいというものを記載しています。

ちょっと読みやすくしたい

行末にセミコロン「;」を付ける

理由

Kotlinでは行末にセミコロン「;」を付ける必要はありませんが、個人的には文章の句読点がない様な印象を受けてしまうので、セミコロン「;」を付けるようにしています。

コード

行末にセミコロンを付けると下記の様になります。

セミコロンを付ける事で、コードの区切りがはっきりした気がします(個人的に…)。

しかし「本来不要なセミコロン」という事でセミコロンを付けた行に警告が表示されます。

すべての行にセミコロンを付けると警告数が増えて、重要な警告が埋もれてしまう可能性があります。

警告を非表示にする

セミコロンについての警告は下記の設定で非表示にする事ができます。

① 追加したセミコロンの位置にキャレット(テキストカーソル)を移動

② 行頭示される電球マークをマウスでクリックしてサブメニューを選択

選択するのは「Remove redundant semicolon」(冗長なセミコロンの削除)の中の「Edit inspection profile setting」(検査プロファイル設定の編集)になります。

※キャレットがセミコロンのところにないと上記の様には表示されません。

③ 警告しない様に設定を変更

表示される「Inspections」ウィンドウの中から「Redundant Semicolon」の項目の右端のチェックボックスのチェックを外し、「OK」ボタンを押します。

これにより、行末にセミコロンを付けても警告は表示されなくなります。

リリース時の作業

もし、納入条件のコーディング規約に「セミコロンは付けない」とか「Android Kotlinコーディングスタイルに従う事」などがあれば、セミコロンは削除しなければなりません。

方法1. Clean up code機能を利用

警告を表示しない様にした方法と逆を行います。

① 「File」→「Settings」を選択し、「Settings」ウィンドウを表示

②「Editor」→「Inspections」→「Redundant semicolon」のチェックボックスにチェックを入れ「OK」ボタンを押下

これにより、セミコロンの警告が表示されるようになります。

③ セミコロンの位置にキャレット(テキストカーソル)を移動

④ 行頭示される電球マークをマウスでクリックしてサブメニューを選択

「Cleanup code」を実行する事で、そのファイル内のセミコロンが除去され、当然警告もなくなります。

【注意】Cleanup code機能は開いているファイルのみしか機能しないので、複数のActivity/Fragmentがある場合、それぞれのファイル内でCleanup codeを実行する必要があります。

方法2. 一括置換機能を利用

一括置換機能を使ってプロジェクト内の全ファイルの行末のセミコロンを一括除去する事も可能です。

① CTRL+SHIFT+「R」キーで「Replace in Files」ウインドウを表示

② File Maskのチェックボックスにチェックをいれ、「*.kt」を指定

※セミコロンはソースコード以外のファイルでは普通に利用されるので、Kotlinコードのみに限定する必要があります。

③ 正規表現スイッチをON、検索文字列は「;$」、置換文字列は無指定を設定

※単なる「;」を指定すると、文字列中の「;」も削除されてしまうため、正規表現で「末尾の;」(=”;$”)を指定する必要があります。

④ 置換される部分を確認の後「Replace All」ボタンを押下

以上によって、Kotlinコードの行末セミコロンをすべて除去する事が可能です。

【注意】ファイル置換は置換前後のコードの正誤に関わらずコードの語句を置換するので、ファイル種別、置換する語句などは十分気を付ける必要があります。


ブロックの左中かっこ「{」の位置を変更したい

理由

Kotlinスタイルガイドでは、「左中かっこの前には改行を入れません」と規定されているのに対して、「右中かっこの前に改行を入れます。」と規定されています。

これによって、左中かっこと右中かっこの左端からの位置が一致しません。

個人的にはブロックの開始(左中かっこ)と終了(右中かっこ)の位置があっている方が見やすいと思うので、開発時は左中かっこの前に改行を入れるようにしています。(例外あり)

コード

左中かっこの前に改行を入れると下記のようなコードになります。

クラスのボディ、メソッドのボディがはっきりとし、また前後の行のつながりや切れ目がはっきりしました(個人的には…)。

上記の例では。左中かっこの前に改行を入れてもエラーも警告もありませんが、問題(エラー)になるケースもあります。

例外

apply句、also句、リスナーブロックなどの左中かっこの前に改行を入れるとエラーになります。

仕方がないので、改行するとエラーになる左中かっこはそのままにすることにします。

※実際には、下記の様に「()」を付けて改行をすればエラーにはなりませんが、後々修正が面倒なので…。(置換すれば良さそうですが、継承する親クラスのプライマリコンストラクタの形式と区別がつかないのです)

リリース時の作業

もし、納入条件のコーディング規約に「左中かっこの前に改行は入れない」とか「Android Kotlinコーディングスタイルに従う事」などがあれば、左中かっこの位置を変更しなければなりません。

一括置換機能を使ってプロジェクト内の全ファイルに対して対処します。

① CTRL+SHIFT+「R」キーで「Replace in Files」ウインドウを表示

② File Maskのチェックボックスにチェックをいれ、「*.kt」を指定

※プロジェクトにはKotlinコード以外も含まれるので、Kotlinソースコードのみに限定します。

③ 正規表現スイッチをON、検索文字列は「\n\s*{」、置換文字列は「 {」(スペース+”{“)に設定

※検索は正規表現で「改行+0個以上の空白文字+左中かっこ」という意味になります。

④ 置換される部分を確認の後「Replace All」ボタンを押下

以上によって、Kotlinコード中の左中かっこの位置をKotlinスタイルガイドの様に前に改行を入れないコードに変換できます。

まとめ

今回は開発時のコードが読みやすくなる方法と、リリース時のコードの戻し方についてのTIPSでした。

ただ、マイルール・マイスタイルが増えると、リリース時のコード変更作業が増え、また、コードを変更する事はバグが入り込む可能性が高まるので、あまり数は増やさない方がいいと思います。

また、必ず過不足なく一括置換が可能なマイルール・マイスタイルに限定した方が良いでしょう。(もとに戻すのが途方もなく大変な作業になります…)

あと「正規表現」はとっつきにくい部分もありますが、覚えると何かと役に立ちます。