Google。言わずと知れた、インターネット関連の世界最高峰テック企業です。いくつも提供される大規模サービスの裏にある、内部開発のプログラムもすさまじい量であることでしょう。
実は、Googleは内部開発コードで適用しているスタイルガイドを公開しています。
このスタイルガイド、内容がとても濃密です。プログラミングの際に非常にためになります。
Googleスタイルガイドとは
Googleが所有または開発するオープンソースプロジェクトにおいて、Google内部で開発するために定義したスタイルガイドを、外部公開しているものです。
2023/5時点で、以下のスタイルガイドが公開されています。
- AngularJS
- Lisp
- C++
- C#
- Go
- HTML/CSS
- JavaScript
- Java
- Objective-C
- Python
- R
- シェル
- Swift
- TypeScript
- Vim
※Googleなのに、Kotlinのスタイルガイドはないの？と思ったら、Androidのデベロッパーサイトにあります。
Googleスタイルガイドのすごいところ
Googleスタイルガイドは、プログラマー自身が、己の膨大な経験によって描く、血の通ったガイドになっています。
具体的に良いところは、以下の３点。
- 具体的な良い例と悪い例で説明している
- メリットとデメリットの両方を論じている
- 理想論でなく現実論に基づいている
順番に見ていきましょう。
その１：具体的な良い例と悪い例で説明している
スタイルの解釈は、人によって微妙に異なってしまうもの。
このスタイルガイドは、良いスタイルと悪いスタイルを、具体的な例をあげて説明しています。
例えば、HTML/CSSのスタイルガイド。
構造をプレゼンテーションや動作から分離します。
構造(マークアップ)、プレゼンテーション(スタイリング)、および動作(スクリプト)を、厳密に分離し、これら3つの間の相互作用を最小限に抑えるようにしてください。
構造をプレゼンテーションや動作から分離することは、メンテナンス上の理由から重要です。
これについての悪い例と良い例。ウィットが効いてちょっと面白いですね。
<!-- 悪い例 -->
<!DOCTYPE html>
<title>HTMLは最悪だ</title>
<link rel="stylesheet" href="base.css" media="screen">
<link rel="stylesheet" href="grid.css" media="screen">
<link rel="stylesheet" href="print.css" media="print">
<h1 style="font-size: 1em;">HTML sucks</h1>
<p>いくつかのサイトを見たところで、確信しました:
<u>HTMLは大ばかだ!!</u>
<center>Webサイトのスタイルを制御する方法がないなんて、
信じられません!</center><!-- 良い例 -->
<!DOCTYPE html>
<title>初めてのCSSのみでのデザイン</title>
<link rel="stylesheet" href="default.css">
<h1>これは私の、初めてのCSSのみでのデザインです</h1>
<p>いくつかのサイトで見た方法を実行しています。関心事項を分離し、
Web サイトの HTML に、プレゼンテーション上の要素を含めないようにすることです。
<p>なんてすばらしい!その２：メリットとデメリットの両方を論じている
プログラミング言語には、特有な書き方や新しいテクニックがいろいろあります。それを使うべきか否かは、技術者により賛否両論です。
このスタイルガイドでは、その技術のメリットとデメリットを公平に論じた上で、採用すべきか否か、を丁寧に解説しています。
例えばC++スタイルガイド。意外なことにGoogleでは、C++において例外の使用を禁止しています。
賛成と反対の両意見を論じたうえで、結論を出しています。
例外は使用しません。
メリット
- 深くネストされた関数での「起こり得ない」エラーを処理する方法を決定できる
- 例外は、Python、Javaなどの言語でも使用されているので使い慣れている
- C++ライブラリは例外を使用しているものもある
- コンストラクタが失敗する唯一の方法
- フレームワークをテストする場合に便利
デメリット
- throwを既存の関数に追加するときは、すべての呼び出し元を検査する必要がある
- 例外があると、コードを見てプログラムの制御フローを評価することが困難になる
- 例外の安全性には、RAIIとさまざまなコーディング手法の両方が必要になる
- 例外オンで、コンパイル時間が（おそらくわずかに）増加する
- 例外が利用できると、開発者は、適切でない場合に例外をスローしたりする可能性がある
結論
新しいプロジェクトでは、例外を使用するメリットがコストを上回ります。
しかし、既存のコードの場合、例外の導入はすべての依存コードに影響を与えます。
例外が新しいプロジェクトを超えて伝搬する可能性がある場合、新しいプロジェクトを既存の例外のないコードに統合することも問題になります。
Googleの既存のC++コードのほとんどは、例外を処理する準備ができていません。そのため例外を生成する新しいコードを採用するのは困難です。
その３：理想論でなく現実論に基づいている
前述の例外の章には、続きがあります。
例外の使用に対する私たちのアドバイスは、哲学的または道徳的根拠に基づいたものではなく、実際的な根拠に基づいています。
私たちはGoogleでオープンソースプロジェクトを使用したいと考えていますが、それらのプロジェクトで例外が使用されていると使用するのが難しいため、Googleオープンソースプロジェクトでも例外を避けるようアドバイスする必要があります。最初からもう一度作り直すといった場合には、状況はおそらく異なるでしょう。
その技術が正しいのか誤りなのか、といった机上の空論ではありません。
現実的に考えて、メリットがデメリットを本当に上回るのか、で結論を出しています。
数えきれないほど膨大なプログラムを抱える、Googleであればこその結論ではないでしょうか。
まとめ
Googleスタイルガイド、内容は実際のところかなりハイレベルです。（しかも英語）
プログラミング初学者には、ちょっと手が出せないしろものでしょう。
でも、「ある程度この言語も慣れてきたな」と思った頃、一度目を通してみてください。なにか新しい発見が、きっとあるはずです。
コメント