Kotlin言語での作業の1年半の間、すべてのプロジェクトとフレームワークをKotlin言語に移行しました。 開発者がプロジェクトの作業にすばやく参加できるように、またレビューコードが終わりのない議論にならないように、蓄積された経験を形式化し、独自のコードスタイルを開発しました。
行こう！
各開発者は、独自の経験と習慣に基づいてコードを記述します。 1人の開発者またはコードがプロジェクトで自分用に記述されている場合、これは問題ではありません。 しかし、いくつかのプロジェクトに取り組んでいる大規模なチームでは、必然的に問題が発生します。
- コードのレビューには多くの時間と神経がかかります-単一の標準がなければ、無限に議論することができます。
- 新しい人をコードに浸すには、はるかに多くの時間と労力が必要です。
- コードが実行する機能に集中することはより困難です。
- その結果、プロジェクトは、それに参加したすべての専門家の痕跡のように見えます。
そして、あなたがプロジェクトの唯一の開発者であっても、忘れないでください-いつかは終了します。 そして、チームの新しい人があなたに感謝するのか、それともまずあなたの住所を見つけようとするのかはあなた次第です。
単一のスタイルのコードを記述することで、これらすべての問題を解決できます。
なぜ今そしてなぜ私たち
KotlinはAndroid開発者コミュニティで非常に人気があり、毎日より多くのサポーターを集めています。 しかし、あなたが従うことができるコードを書くスタイルを見つけることは依然として問題であり、言語の公式ウェブサイトで公開された合意は包括的な答えを与えません。そこに存在する規則の数はチームのニーズのほとんどをカバーできないためです。 たとえば、関数、その呼び出し、および説明のフォーマットに関するルールは含まれていません。
記事の執筆中に、Googleからの公式ガイドが出てきて、Kotlinでのコードの記述に関する質問への回答を掲載しました。 結果を比較し、意見が一致したものと同意しなかったものを分析することは興味深いものでした。
ルール開発プロセスについて
私たちのような大規模なチームが同意する統一されたスタイルを開発するプロセスは簡単ではありません。アイデアや提案を収集し、全員の意見を考慮し、コードレビューで論争を引き起こすポイントを思い出すことです。 すべての問題について単一の評決を達成することはほとんど不可能であると予想されますが、プロセスの重要性と有用性を全員が理解し、譲歩し、下された決定に従う準備ができていることが重要です。
もちろん、時間の経過とともに、一連の規則は改訂および補足される可能性があります-一連の契約を最新の状態に保つ予定です。
問題のある問題
コードの記事の最後にあるリンクをどのように見るべきかというアイデアに慣れることができます。以下では、特に論争の的となる論争の的となる点を示します。
1. Android拡張機能のフィールド名の表示とKotlin
Kotlin Android拡張機能ビューのフィールドは、lower_snake_case命名スタイルを使用します
標準の開発では、外部の依存関係またはIDEを使用する可能性から抽象化して、最も純粋な形式の言語に焦点を当てようとしました。 ただし、Kotlin Android Extensionsについては例外があります。 ほとんどの場合、Android開発ではKotlinを使用し、XMLを使用せずにアプリケーションを実行することはできないため、ほとんどのリソースはlower_snake_caseのスタイルでこの形式で記述されているためです。 したがって、View識別子の例外を作成し（このスタイルで説明します）、これらのフィールドを呼び出します（ただし、このマジックが実行時にどのように機能するかを見ると、これらは変数ではなく、HashMapから値を取得するためのキーであることがわかります） 。 コードからは、lower_snake_caseのスタイルで記述されたフィールドへのアピールのように見えますが、同時に、ビューフィールドへのアピールがコード内で常に表示されます。
2.プライベートメソッドの順序
クラス構造：
1）コンパニオンオブジェクト
2）フィールド：抽象、オーバーライド、パブリック、内部、保護、プライベート
3）初期化ブロック：init、コンストラクター
4）抽象メソッド
5）親クラスのオーバーライドされたメソッド（親クラスで従うのと同じ順序が望ましい）
6）インターフェースメソッドの実装（クラス自体の説明でこれらのメソッドの記述の順序を観察しながら、クラスの記述で従うのと同じ順序で行うことが望ましい）
7）パブリックメソッド
8）内部メソッド
9）保護されたメソッド
10）プライベートメソッド
11）内部クラス
別の問題は、プライベートメソッドの場所です。 2つの一般的なオプションがあります。それらを使用したメソッドの直後に記述するか、すべてのメソッドの後にクラス構造に記述します。 2番目のオプションに同意しました。 クラスを何らかのインターフェースと見なしているため、何をするのかを知ることはまず興味深いです。すべてのプライベートメソッドが最後に配置されているという事実により、インターフェースによってこのクラスの責任をすばやく理解できます。 プライベートメソッドでは、原則として、具体的な実装が既に含まれており、変更を加えたい場合にのみそれらを使用することがよくあります。 この場合、クラスの構造は常に一貫したままです。
3.定数
（コンパニオン）オブジェクトの不変フィールドとコンパイル時定数は、SCREAMING_SNAKE_CASEのスタイルで名前が付けられます
定数の命名の問題には、別の重要な問題が伴います。Kotlinの定数とは何ですか？ この言語は、コンパイル時定数「const」を示すキーワードを提供しますが、コンパイル時定数はプリミティブ型と文字列のみになります。 定数として、Objectブロックにある他の不変変数を使用したいと思います。そのような場合、名前にそのような不変変数を含む名前を付けるときの定数の理解を広げました。 興味深いことに、これで私たちの意見はGoogleの位置と一致しました。
4.パッケージ名
パッケージはlower_snake_caseのスタイルで名前が付けられます
作業の過程で、パッケージの命名にしばしば問題がありました。異なる機能はそれほど明確ではないため、新しいパッケージを作成するときに、意味を正確に反映するために2つ以上の単語を使用する必要があります。 OracleのJavaのパッケージ命名規則では、パッケージ名はセパレータなしでマージされることが提案されています。これにより、プロジェクトでは読みにくい名前のパッケージが表示される可能性があります。 そのため、パッケージをアンダースコア記号で区切る機能を追加しました。 このようなスタイルの使用は、規則ではなく強制的な例外である必要があり、これは可能な限り避ける必要があることを強調する価値があります。
5.注釈
私たちのビジョンが一般的なビジョンと異なるもう1つのポイントは、単一の注釈の使用です：いくつかの推奨事項では、説明されたメソッド/フィールドを使用して、1行にパラメータなしで複数の注釈を記述したり、1行にパラメータなしで1つの注釈を残すことも可能です 私たちの意見では、そのようなアプローチはほとんど役に立ちません（スペースを節約します）、そしてそのような例外のためにコードの一貫性が低下するため、すべての注釈に単一のルールを残すことにしました：常に新しい行からそれらを示します。
6.式としての機能
また、関数式を使用する可能性を制限しました-関数を1行に収まる場合にのみ式として記述できるようにしました（このため、最大行長を120文字に増やしました）。 式が1行に収まらない場合、さらに変更を加えると、この関数を通常のスペルに変換する必要が生じる可能性があり、そのような式は読みにくくなります。
何がありますか
最後に、Googleがスタイルガイドをリリースしたにもかかわらず、プレゼンテーションを公開する理由を示したいと思います。 前述のように、言語自体の開発者からの一連の合意-JetBrainsは、その簡潔さのために、チームのすべてのニーズをほとんどカバーしていないため、Kotlin開発チームが傍観者のままではなく、このリストをさらに開発することを本当に望んでいます。 詳細に見ると、GoogleのルールのほとんどはJavaのスタイルガイドでコピーまたは再定式化されていますが、他の関連プログラミング言語の経験を考慮しようとしましたが、スタイルへのさまざまなアプローチの使用によって大幅に導かれ、このアプローチが許可されましたいくつかのポイント（クラス構造、説明、関数呼び出し、その他のルール）を明らかにします。
次は何ですか
コードを記述するための単一の標準を採用した後でも、問題が発生する可能性があります。誰かがルールを忘れるか、さらに悪いことに、それらを妨害し始める可能性があります。 このコードがコードレビューの段階で拒否されてもよいのですが、検査官はこれらのエラーに気付かなかったり、破壊的な活動に参加することさえできません。 Kotlinの若さにもかかわらず、静的コード分析のためのツールはすでに存在します。そのため、すべてのルールを記述し、違反を自動的に追跡することができます。これはすでにバックログにあります。 このサービスは、開発者が規律を守って、レビュー担当者がコードが受け入れられた標準に準拠していることを確認する手間を省き、これらのツールがプロジェクトのクリーンさを維持するのに役立ちます。
参照：