cppguide.ja.html

<!DOCTYPE html>
<html lang="ja">

<head>
    <meta charset="utf-8">
    <title>Google C++ スタイルガイド(日本語全訳) Google C++ Style Guide (Japanese)</title>
    <link rel="stylesheet" href="include/styleguide.ja.css">
    <script src="include/styleguide.ja.js"></script>

    <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.1.1/jquery.min.js"></script>
    <style>
        /* 翻訳ポップアップ */
        span:hover {
            background-color: #FaFC;
        }

        #tip_popup {
            position: absolute;
            border: 1px solid black;
            max-width: 50%;
            background-color: #EFF;
            padding: 8px;
            z-index: 100;
            left: -99999px;
        }

        span.src,
        div.src {
            display: none;
        }
    </style>
    <script>
        // 翻訳ポップアップ
        $(document).ready(function () {
            $("body").append('<div id="tip_popup"></div>');
            var tip = $('#tip_popup');
            $("span,div").each(function () {
                if ($(this).attr("title")) {
                    $(this).attr("data-title", $(this).attr("title"));
                    $(this).removeAttr("title");
                    $(this).mousemove(function (m) { tip.html($(this).attr("data-title")); });
                    $(this).mousemove(function (m) { tip.css({ left: (m.pageX + 20) + "px", top: (m.pageY + 20) + "px" }); });
                    $(this).mouseout(function () { tip.css({ left: "-99999px" }); });
                }
                else if ($(this).children(".src").html()) {
                    $(this).mousemove(function (m) { tip.html($(this).children(".src").html()); });
                    $(this).mousemove(function (m) { tip.css({ left: (m.pageX + 20) + "px", top: (m.pageY + 20) + "px" }); });
                    $(this).mouseout(function () { tip.css({ left: "-99999px" }); });
                }
            });
        });
    </script>
    <link rel="shortcut icon" href="https://www.google.com/favicon.ico" />
</head>

<body onload="initStyleGuide();">
    <div id="content">
        <h1>
            <span title="Google C++ Style Guide">Google C++ スタイルガイド</span> 日本語全訳
        </h1>
        <p>
            本ドキュメントは<a href="https://github.com/google/styleguide/">https://github.com/google/styleguide/</a> にて公開されているGoogle C++ Style Guideを日本語に訳したものです。<br>
            commit <a href="https://github.com/google/styleguide/blob/8638b2665f29e46a505df55887b28900e4ceb3ff/cppguide.html">8638b26 (Oct 14, 2022)</a> を底本としています。<br>
            オリジナルの最新版は <a href="https://google.github.io/styleguide/cppguide.html">https://google.github.io/styleguide/cppguide.html</a>で読むことができます。
        </p>
        <p>
            オリジナルと同様
            <a href="https://creativecommons.org/licenses/by/3.0/">CC-By 3.0 License</a>で頒布します。
        </p>

        <p>
            免責: 訳者はGoogleと無関係です。私訳や誤訳を含んでいる恐れがあります。
            訳文にマウスを重ねると原文が表示されますので、そちらもあわせて参照してください。
        </p>

        <p>
            誤訳の指摘・改善案は
            <a href="https://github.com/ttsuki/styleguide/issues">Issues</a> or
            <a href="https://github.com/ttsuki/styleguide/pulls">Pull Requests</a>までお願いします。
        </p>

        <div class="horizontal_toc" id="tocDiv"></div>

        <h2 id="Background" class="ignoreLink">
            <span title="Background">本ガイドの背景</span>
        </h2>

        <p>
            <span>
                <span class="src">
                    C++ is one of the main development languages used by
                    many of Google's open-source projects.
                </span>
                C++は、多くのGoogleのオープンソースプロジェクトで使われている主要言語のうちのひとつです。
            </span>
            <span>
                <span class="src">
                    As every C++
                    programmer knows, the language has many powerful features, but
                    this power brings with it complexity, which in turn can make
                    code more bug-prone and harder to read and maintain.
                </span>
                C++のプログラマなら誰でも知っているように、この言語にはパワフルな機能がありますが、同時に、そのパワフルさが複雑さを招き、バグを発生させやすくしたり、また可読性やメンテナンス性の妨げになったりもしています。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    The goal of this guide is to manage this complexity by
                    describing in detail the dos and don'ts of writing C++ code.
                </span>
                本ガイドの目的は、C++のコードを書く際に、すべきこと、すべきでないことを詳しく説明することによって、この複雑性をコントロール下に置くことです。
            </span>
            <span>
                <span class="src">
                    These rules exist to
                    keep the code base manageable while still allowing
                    coders to use C++ language features productively.
                </span>
                これらのルールは、C++プログラマが、言語機能の生産性を生かしつつも、コードベースを管理可能な状態に保つために存在します。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    <em>Style</em>, also known as readability, is what we call
                    the conventions that govern our C++ code.
                </span>
                「<em>スタイル</em>」は、可読性(リーダビリティ)としても知られ、私たちのC++コードを管理するための規約のことです。
            </span>
            <span>
                <span class="src">
                    The term Style is a
                    bit of a misnomer, since these conventions cover far more than
                    just source file formatting.
                </span>
                これらの規約は、単なるソースファイルのフォーマットだけではなく、広い範囲を含むため<em>スタイル</em>という用語はちょっとふさわしくないかもしれません。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Most open-source projects developed by
                    Google conform to the requirements in this guide.
                </span>
                Googleで開発されるほとんどのオープンソースプロジェクトが、本ガイドに則っています。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Note that this guide is not a C++ tutorial: we assume that
                    the reader is familiar with the language.
                </span>
                注意してほしいのは、このガイドはC++のチュートリアルではないということです。むしろ、このガイドは読者がC++に精通していることを想定して書かれています。
            </span>
        </p>

        <h3 id="Goals">
            <span title="Goals of the Style Guide">本ガイドの目的</span>
        </h3>
        <p>
            <span>
                <span class="src">
                    Why do we have this document?
                </span>
                なぜ、このガイドは書かれたのでしょうか？
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    There are a few core goals that we believe this guide should
                    serve.
                </span>
                本ガイドによって提供される、いくつかの核となる目標があります。
            </span>
            <span>
                <span class="src">
                    These are the fundamental <b>why</b>s that
                    underlie all of the individual rules.
                </span>
                その目標とは、このガイドで示されるすべての個々のルールの根底にある、基礎的な「なぜ」の集まりです。
            </span>
            <span>
                <span class="src">
                    By bringing these ideas to
                    the fore, we hope to ground discussions and make it clearer to our
                    broader community why the rules are in place and why particular
                    decisions have been made.
                </span>
                私たちは、この考え方を前面に出すことで、議論を根付かせ、より広範囲のコミュニティにおいて、これらのルールがなぜ作られ、なぜそのように決められたのか、より明確に伝わることを望んでいます。
            </span>
            <span>
                <span class="src">
                    If you understand what goals each rule is
                    serving, it should be clearer to everyone when a rule may be waived
                    (some can be), and what sort of argument or alternative would be
                    necessary to change a rule in the guide.
                </span>
                個々のルールがどのような目的を果たそうとしているか理解すれば、いつルールの採用を取りやめるべきか、ルールを変更するためにどんな議論や代替案が必要か、より明確になることでしょう。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    The goals of the style guide as we currently see them are as
                    follows:
                </span>
                本スタイルガイドの目的は、現時点では次のとおりです。
            </span>
        </p>
        <dl>
            <dt>
                <span>
                    <span class="src">
                        Style rules should pull their weight
                    </span>
                    スタイルルールを重くしすぎないこと
                </span>
            </dt>
            <dd>
                <span>
                    <span class="src">
                        The benefit of a style rule
                        must be large enough to justify asking all of our engineers to
                        remember it.
                    </span>
                    個々のスタイルルールは「所属するすべてのエンジニアが覚えなくてはならない」ことを正当化できるくらいに価値のあるものでなければなりません。
                </span>
                <span>
                    <span class="src">
                        The benefit is measured relative to the codebase we would
                        get without the rule, so a rule against a very harmful practice may
                        still have a small benefit if people are unlikely to do it
                        anyway.
                    </span>
                    ルールの価値は「仮にそのルールが無かったら書かれたかもしれないコード」との比較で測定します。仮に「非常に有害な慣行に対するルール」を考えたとしても、「そもそも、そのようなルールがなくとも、普通はそんなことはしない」ならば、そのルールは価値が低いという風に考えます。
                </span>
                <span>
                    <span class="src">
                        This principle mostly explains the rules we don&#8217;t have, rather
                        than the rules we do: for example, <code>goto</code> contravenes many
                        of the following principles, but is already vanishingly rare, so the Style
                        Guide doesn&#8217;t discuss it.
                    </span>
                    この原則は、どちらかというと、本スタイルガイドに書かれていないルールについて説明しています。例えば、<code>goto</code>の濫用はこれに続く多くの原則に違反しますが、すでにそれが行われること自体がレアケースになっています。このため、本ガイドでは<code>goto</code>の濫用については取り扱いません。
                </span>
            </dd>

            <dt>
                <span>
                    <span class="src">
                        Optimize for the reader, not the writer
                    </span>
                    コードの書き手ではなく、コードの読み手にとって優しいこと
                </span>
            </dt>
            <dd>
                <span>
                    <span class="src">
                        Our codebase (and most individual components submitted to it) is
                        expected to continue for quite some time.
                    </span>
                    我々のコードベース(と、それに含まれるほとんどの個々のコンポーネント)は、今後、長い長い時を経ていくでしょう。
                </span> <span>
                    <span class="src">
                        As a result, more time will
                        be spent reading most of our code than writing it.
                    </span>
                    結果的に、そのコードを書くのに費やした時間に比べて、はるかに多くの時間がコードを読むために割かれることでしょう。
                </span> <span>
                    <span class="src">
                        We explicitly
                        choose to optimize for the experience of our average software engineer
                        reading, maintaining, and debugging code in our codebase rather than
                        ease when writing said code.
                    </span>
                    私たちは、私たちの平均的なエンジニアが「簡単にコードが書けること」よりも、「コードを読み、メンテし、デバッグがやりやすいこと」に最適化することを明示的に選択します。
                </span>
                <span>
                    <span class="src">
                        "Leave a trace for the reader" is a
                        particularly common sub-point of this principle:
                    </span>
                    特に「コード読者のためのヒントを残す」は、この原則の共通のサブテーマになっています。
                </span>
                <span>
                    <span class="src">
                        When something
                        surprising or unusual is happening in a snippet of code (for example,
                        transfer of pointer ownership), leaving textual hints for the reader
                        at the point of use is valuable (<code>std::unique_ptr</code>
                        demonstrates the ownership transfer unambiguously at the call
                        site).
                    </span>
                    コードの中で見慣れないことをするとき(たとえばポインタの所有権を移す)、読み手のためにヒントを残しておくことは価値があります(ただのポインタではなく、<code>std::unique_ptr</code>を使えば、所有権が移されることを曖昧性なく表現できます)。
                </span>
            </dd>

            <dt>
                <span>
                    <span class="src">
                        Be consistent with existing code
                    </span>
                    既存のコードと一貫性が保たれていること
                </span>
            </dt>
            <dd>
                <span>
                    <span class="src">
                        Using one style consistently through our codebase lets us focus on
                        other (more important) issues.
                    </span>
                    １つのスタイルをコードベース全体で一貫して用いることで、私たちは他の(より重要な)問題にフォーカスすることができます。
                </span>
                <span>
                    <span class="src">
                        Consistency also allows for automation:
                        tools that format your code or adjust your <code>#include</code>s only
                        work properly when your code is consistent with the expectations of
                        the tooling.
                    </span>
                    一貫性は自動化を進めやすくもします。コードフォーマットツールは、あなたのコードがツールの期待と一貫しているときにのみきちんと動作するでしょう。
                </span>
                <span>
                    <span class="src">
                        In many cases, rules that are attributed to "Be
                        Consistent" boil down to "Just pick one and stop worrying about it";
                    </span>
                    多くの場合「一貫性を保つ」に帰結するルールは「ある１つのやり方を選ぶと決め、それについて悩むことをやめる」ということです。
                </span>
                <span>
                    <span class="src">
                        the potential value of allowing flexibility on these points is
                        outweighed by the cost of having people argue over them. 
                    </span>
                    これらの点で多様性を認めることによって得られる潜在的な価値よりも、それについて議論するコストの方が上回る場合がほとんどでしょう。
                </span>
                <span>
                    <span class="src">
                        However,
                        there are limits to consistency; it is a good tie breaker when there
                        is no clear technical argument, nor a long-term direction.
                    </span>
                    その一方で、一貫性には限界があります。一貫性は、明確な技術的論拠や長期的な方向性がない場合には、よい判断材料となるでしょう。
                </span>
                <span>
                    <span class="src">
                        It applies
                        more heavily locally (per file, or for a tightly-related set of
                        interfaces).
                    </span>
                    ローカル（ファイルごと、もしくは密に関連するインターフェイスの集合）には、より重く適用されます。
                </span>
                <span>
                    <span class="src">
                        Consistency should not generally be used as a
                        justification to do things in an old style without considering the
                        benefits of the new style, or the tendency of the codebase to converge
                        on newer styles over time.
                    </span>
                    新しいスタイルの利点や、コードベースが時間とともに新しいスタイルに移り変わっていく傾向を無視して、古いスタイルのまま物事を進めるための言い訳として、一貫性を用いるべきではありません。
                </span>
            </dd>

            <dt>
                <span>
                    <span class="src">
                        Be consistent with the broader C++ community when appropriate
                    </span>
                    より広範囲なC++コミュニティと一貫性があること
                </span>
            </dt>
            <dd>
                <span>
                    <span class="src">
                        Consistency with the way other organizations use C++ has value for
                        the same reasons as consistency within our code base.
                    </span>
                    C++を使う他の組織の手法と一貫性を保つことも、我々のコードベース内で一貫性を保つことと同じ理由で価値があります。
                </span><span>
                    <span class="src">
                        If a feature in
                        the C++ standard solves a problem, or if some idiom is widely known
                        and accepted, that's an argument for using it.
                    </span>
                    もし、あるC++標準の機能を使って問題を解決できるのならば、あるいは、あるイディオムが広く知られて受け入れられているのならば、それを使う理由になるでしょう。
                </span> <span>
                    <span class="src">
                        However, sometimes
                        standard features and idioms are flawed, or were just designed without
                        our codebase's needs in mind.
                    </span>
                    しかし、時折、標準的な機能やイディオムには、不備があったり、あるいは単に私たちのコードベースのニーズを満たさない形でデザインされていたりします。
                </span> <span>
                    <span class="src">
                        In those cases (as described below) it's
                        appropriate to constrain or ban standard features.
                    </span>
                    後述しますが、そのような場合は、これらの標準機能は制限または禁止する方が適切です。
                </span> <span>
                    <span class="src">
                        In some cases we
                        prefer a homegrown or third-party library over a library defined in
                        the C++ Standard, either out of perceived superiority or insufficient
                        value to transition the codebase to the standard interface.
                    </span>
                    いくつかのケースでは、C++標準ライブラリよりも自家製もしくはサードパーティのライブラリを選ぶ場合もあります。そちらの方が優れていたり、コードベースを標準のインターフェースに移行する十分な価値がなかったりするためです。
                </span>
            </dd>

            <dt>
                <span>
                    <span class="src">
                        Avoid surprising or dangerous constructs
                    </span>
                    見慣れない構成や危険な構成は避けること
                </span>
            </dt>
            <dd>
                <span>
                    <span class="src">
                        C++ has features that are more surprising or dangerous than one
                        might think at a glance.
                    </span>
                    C++には、ちょっと考えただけでは気が付かないかもしれない、驚くような、あるいは危険な機能も存在します。
                </span> <span>
                    <span class="src">
                        Some style guide restrictions are in place to
                        prevent falling into these pitfalls.
                    </span>
                    本ガイドのいくつかの制限ルールは、それらの落とし穴を避けるためのものです。
                </span> <span>
                    <span class="src">
                        There is a high bar for style
                        guide waivers on such restrictions, because waiving such rules often
                        directly risks compromising program correctness.
                    </span>
                    これらのルールを取り消すと、直接的にプログラムの正しさを損なう危険性があるため、そのようなルールの破棄については高いハードルがあります。
                </span>
            </dd>

            <dt>
                <span>
                    <span class="src">
                        Avoid constructs that our average C++ programmer would find tricky
                        or hard to maintain
                    </span>
                    平均的なC++プログラマがトリッキーと感じたり、メンテしにくいと感じたりするような構成は避けること
                </span>
            </dt>
            <dd>
                <span>
                    <span class="src">
                        C++ has features that may not be generally appropriate because of
                        the complexity they introduce to the code.
                    </span>
                    C++には、複雑すぎて通常はコードに導入すべきでないような機能もあります。
                </span> <span>
                    <span class="src">
                        In widely used
                        code, it may be more acceptable to use
                        trickier language constructs, because any benefits of more complex
                        implementation are multiplied widely by usage, and the cost in understanding
                        the complexity does not need to be paid again when working with new
                        portions of the codebase.
                    </span>
                    広く使われているコードの中は、トリッキーな言語構造の方が受け入れられることもあるかもしれません。その理由は、その複雑な実装が使用されることによって価値が広く倍増しており、かつ、コードベースの新しい部分で仕事をする時には、その複雑さを再度理解するためのコストを払う必要がなくなっているからです。
                </span> <span>
                    <span class="src">
                        When in doubt, waivers to rules of this type
                        can be sought by asking your project leads.
                    </span>
                    これについて疑問を感じる場合は、このタイプのルールを取り消すことについてプロジェクトリーダーと相談してください。
                </span> <span>
                    <span class="src">
                        This is specifically
                        important for our codebase because code ownership and team membership
                        changes over time: even if everyone that works with some piece of code
                        currently understands it, such understanding is not guaranteed to hold a
                        few years from now.
                    </span>
                    これは我々のコードベースでは特に重要です。なぜなら、コードの担当者やチームメンバーは時とともに変わっていくからです。現時点で全員がそのコードを理解していたとしても、その状態が今から2年後にも保たれている保証はどこにもありません。
                </span>
            </dd>

            <dt>
                <span>
                    <span class="src">
                        Be mindful of our scale
                    </span>
                    我々の「規模」に留意すること
                </span>
            </dt>
            <dd>
                <span>
                    <span class="src">
                        With a codebase of 100+ million lines and thousands of engineers,
                        some mistakes and simplifications for one engineer can become costly
                        for many.
                    </span>
                    1億行以上のコードベースがあり、何千人ものエンジニアがいる状況において、ある一人のエンジニアのミスや単純化が、非常に高いコストを招くことがあります。
                </span> <span>
                    <span class="src">
                        For instance it's particularly important to
                        avoid polluting the global namespace: name collisions across a
                        codebase of hundreds of millions of lines are difficult to work with
                        and hard to avoid if everyone puts things into the global
                        namespace.
                    </span>
                    たとえば、グローバル名前空間汚染を避けることは非常に重要です。何億行ものコードベースの間で、もし、誰もがグローバル名前空間に何でもかんでもおいていたら、名前の衝突を避けるのは困難でしょう。
                </span>
            </dd>

            <dt>
                <span>
                    <span class="src">
                        Concede to optimization when necessary
                    </span>
                    必要な最適化は容認する
                </span>
            </dt>
            <dd>
                <span>
                    <span class="src">
                        Performance optimizations can sometimes be necessary and
                        appropriate, even when they conflict with the other principles of this
                        document.
                    </span>
                    たとえ本ガイドのルールと競合したとしても、ときにパフォーマンスの最適化が必要で、かつ適切な場合もあります。
                </span>
            </dd>
        </dl>

        <p>
            <span>
                <span class="src">
                    The intent of this document is to provide maximal guidance with
                    reasonable restriction.
                </span>
                本文書の趣旨は、理にかなった制限の下での最大限の道しるべを提供することです。
            </span>
            <span>
                <span class="src">
                    As always, common sense and good taste should
                    prevail.
                </span>
                いつもどおり、常識や良識が優先されるべきです。
            </span>
            <span>
                <span class="src">
                    By this we specifically refer to the established conventions
                    of the entire Google C++ community, not just your personal preferences
                    or those of your team.
                </span>
                このガイダンスは、あなた個人の好みやチームの好みについてだけではなく、GoogleのC++コミュニティ全体で確立された慣習に言及しています。
            </span>
            <span>
                <span class="src">
                    Be skeptical about and reluctant to use
                    clever or unusual constructs: the absence of a prohibition is not the
                    same as a license to proceed.
                </span>
                巧妙(clever)な構成、見慣れない構成に対して、懐疑的な姿勢を持ち、避けるようにしてください(禁止されていなければやってもよい、というわけではありません)。
            </span>
            <span>
                <span class="src">
                    Use your judgment, and if you are
                    unsure, please don't hesitate to ask your project leads to get additional
                    input.
                </span>
                自分の判断に従ってください。ルールに対して不明な点がある場合は、ためらわず自プロジェクトのリーダーに対して質問し、更なるインプットを得てください。
            </span>
        </p>

        <h2 id="C++_Version">
            <span title="C++ Version">C++のバージョン</span>
        </h2>

        <p>
            <span>
                <span class="src">
                    Currently, code should target C++17, i.e., should not use C++2x
                    features, with the exception of <a href="#Designated_initializers">designated
                        initializers</a>.
                </span>
                現状、コードはC++17をターゲットとします。C++2xの機能は<a href="#Designated_initializers">指示付き初期化子</a>を除いて使うべきではありません。
            </span>
            <span>
                <span class="src">
                    The C++ version targeted by this guide will advance
                    (aggressively) over time.
                </span>
                このガイドがターゲットとするC++のバージョンは、時とともに(かつ積極的に)進行します。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Do not use
                    <a href="#Nonstandard_Extensions">non-standard extensions</a>.
                </span>
                <a href="#Nonstandard_Extensions">非標準の拡張</a>は使わないでください。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Consider portability to other environments
                    before using features from C++14 and C++17 in your project.
                </span>
                C++14やC++17からの新機能を使用する際は、他の環境への移植性について配慮してください。
            </span>
        </p>

        <h2 id="Header_Files">
            <span title="Header Files">ヘッダーファイル</span>
        </h2>

        <p>
            <span>
                <span class="src">
                    In general, every <code>.cc</code> file should have an
                    associated <code>.h</code> file.
                </span>
                原則的に、全ての<code>.cc</code>ファイルは、それに紐付く<code>.h</code>ファイルを持つようにします。
            </span>
            <span>
                <span class="src">
                    There are some common
                    exceptions, such as unit tests and
                    small <code>.cc</code> files containing just a
                    <code>main()</code> function.
                </span>
                ただし、ユニットテストや<code>main()</code>だけを含むような小さな<code>.cc</code>は例外です。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Correct use of header files can make a huge difference to
                    the readability, size and performance of your code.
                </span>
                正しくヘッダーファイルを扱うことは、コードの可読性やサイズ、パフォーマンスに大きな違いをもたらします。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    The following rules will guide you through the various
                    pitfalls of using header files.
                </span>
                以下のルールはヘッダーファイルに関する様々な落とし穴を避けて通るための道しるべとなるはずです。
            </span>
        </p>

        <a id="The_-inl.h_Files"></a>
        <h3 id="Self_contained_Headers">
            <span title="Self-contained Headers">自己完結型ヘッダー</span>
        </h3>

        <p>
            <span>
                <span class="src">
                    Header files should be self-contained (compile on their own) and
                    end in <code>.h</code>.
                </span>
                ヘッダーファイルは自己完結(単体でコンパイルできる)していなくてはならず、名前は<code>.h</code>で終わります。
            </span>
            <span>
                <span class="src">
                    Non-header files that are meant for inclusion
                    should end in <code>.inc</code> and be used sparingly.
                </span>
                ヘッダーファイルではない、includeして使われるべきものは<code>.inc</code>で終わるようにしますが、なるべく使用は控えるようにしましょう。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    All header files should be self-contained.
                </span>
                すべてのヘッダーは自己完結していなくてはなりません。
            </span>
            <span>
                <span class="src">
                    Users and refactoring
                    tools should not have to adhere to special conditions to include the
                    header.
                </span>
                ヘッダーの使用者やリファクタリングツールは、そのヘッダーがincludeされる際に、なんら特別な条件を守る必要がないようにします。
            </span>
            <span>
                <span class="src">
                    Specifically, a header should
                    have <a href="#The__define_Guard">header guards</a> and include all
                    other headers it needs.
                </span>
                特に、ヘッダーには<a href="#The__define_Guard">インクルードガード</a>を持たせ、そのヘッダー自身が必要とするすべての他のヘッダーをincludeします。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    When a header declares inline functions or templates that clients of the
                    header will instantiate, the inline functions and templates must also have
                    definitions in the header, either directly or in files it includes.
                </span>
                ヘッダーが、インライン関数や、そのヘッダーの利用側でインスタンス化するテンプレートを宣言している場合、それらインライン関数やテンプレートの定義もまた同ヘッダー内もしくは同ヘッダーからインクルードされるファイルの中で行われなければなりません。
            </span>
            <span>
                <span class="src">
                    Do not move
                    these definitions to separately included header (<code>-inl.h</code>) files;
                    this practice was common in the past, but is no longer allowed.
                </span>
                これらの定義を別途インクルードされるヘッダーファイル (<code>-inl.h</code>) に移動しないでください。
                昔は、そのやり方が一般的でしたが、現在ではもはや許容されません。
            </span>
            <span>
                <span class="src">
                    When all
                    instantiations of a template occur in one <code>.cc</code> file, either because
                    they're <a href="https://en.cppreference.com/w/cpp/language/class_template#Explicit_instantiation">
                    explicit</a> or because the definition is accessible to only
                    the <code>.cc</code> file, the template definition can be kept in that file.
                </span>
                <a href="https://en.cppreference.com/w/cpp/language/class_template#Explicit_instantiation">テンプレートのインスタンス化が明示的に行われる</a>、あるいは、そもそもそのテンプレートの定義にアクセスできる<code>.cc</code>ファイルが1つしかない等の理由で、すべてのテンプレートのインスタンス化が単一の<code>.cc</code>ファイル内でのみ行われる場合には、テンプレートの定義はそのファイルに残してもかまいません。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    There are rare cases where a file designed to be included is not
                    self-contained.
                </span>
                レアケースながら、includeされるが自己完結でないようなデザインも存在します。
            </span>
            <span>
                <span class="src">
                    These are typically intended to be included at unusual
                    locations, such as the middle of another file.
                </span>
                これらはたいていの場合、別のファイルの途中(中ほど)など、変わった場所でinlucdeされることを想定しています。
            </span>
            <span>
                <span class="src">
                    They might not
                    use <a href="#The__define_Guard">header guards</a>, and might not include their prerequisites.
                </span>
                それらのファイルは、<a href="#The__define_Guard">インクルードガード</a>を持っていなかったり、そのヘッダー内で必要なものをincludeしていなかったりします。
            </span>
            <span>
                <span class="src">
                    Name such files with the <code>.inc</code>
                    extension.
                </span>
                このようなファイルには、<code>.inc</code>拡張子を持たせるようにします。
            </span>
            <span>
                <span class="src">
                    Use sparingly, and prefer self-contained headers when possible.
                </span>
                また、なるべく使用は避け、可能な限り自己完結型ヘッダーを使うことを選択しましょう。
            </span>
        </p>

        <h3 id="The__define_Guard">
            <span title="The #define Guard">インクルードガード</span>
        </h3>

        <p>
            <span>
                <span class="src">
                    All header files should have <code>#define</code> guards to
                    prevent multiple inclusion.
                </span>
                すべてのヘッダーファイルは、インクルードガード(<code>#define</code> guards)を持たなくてはなりません。
            </span>
            <span>
                <span class="src">
                    The format of the symbol name
                    should be
                    <code><i>&lt;PROJECT&gt;</i>_<i>&lt;PATH&gt;</i>_<i>&lt;FILE&gt;</i>_H_</code>.
                </span>
                その際のシンボル名は<code><i>&lt;PROJECT&gt;</i>_<i>&lt;PATH&gt;</i>_<i>&lt;FILE&gt;</i>_H_</code>の形でなくてはなりません。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    To guarantee uniqueness, they should
                    be based on the full path in a project's source tree.
                </span>
                ユニーク性を保証するため、プロジェクト内ソースツリーのフルパスに基づくものにします。
            </span>
            <span>
                <span class="src">
                    For example, the file <code>foo/src/bar/baz.h</code> in
                    project <code>foo</code> should have the following
                    guard:
                </span>
                たとえば、プロジェクトfooに含まれるファイル<code>foo/src/bar/baz.h</code>のガードは次のようにします。
            </span>
        </p>

        <pre>#ifndef FOO_BAR_BAZ_H_
#define FOO_BAR_BAZ_H_

...

#endif  // FOO_BAR_BAZ_H_
</pre>

        <h3 id="Include_What_You_Use"><span title="Include What You Use">必要なものはインクルードする</span></h3>

        <p>
            <span>
                <span class="src">
                    If a source or header file refers to a symbol defined elsewhere,
                    the file should directly include a header file which properly intends
                    to provide a declaration or definition of that symbol.
                </span>
                ソースファイルやヘッダーファイルから他の場所で定義されたシンボルを参照する場合、そのシンボルの宣言・定義の提供が意図されたヘッダーファイルを直接インクルードするようにします。
            </span>
            <span>
                <span class="src">
                    It should not
                    include header files for any other reason.
                </span>
                それ以外の理由ではヘッダーファイルをインクルードすべきではありません。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Do not rely on transitive inclusions.
                </span>
                遷移的・間接的なインクルードに頼ってはいけません。
            </span>
            <span>
                <span class="src">
                    This allows people to remove
                    no-longer-needed <code>#include</code> statements from their headers without
                    breaking clients.
                </span>
                遷移的なインクルードを行っていると、ヘッダーの作者が、ヘッダー内で不要になった<code>#include</code>を削除した場合に、クライアントのコードが壊れてしまうことがあります。
            </span>
            <span>
                <span class="src">
                    This also applies to related headers
                    - <code>foo.cc</code> should include <code>bar.h</code> if it uses a
                    symbol from it even if <code>foo.h</code>
                    includes <code>bar.h</code>.
                </span>
                これは紐付くヘッダーにも適用されます。たとえば<code>foo.cc</code>で<code>bar.h</code>のシンボルを使用する場合に、
                たとえ<code>foo.h</code>において既に<code>bar.h</code>をインクルードしていたとしても、<code>foo.cc</code>で改めて<code>bar.h</code>をインクルードすべきということです。
            </span>
        </p>

        <h3 id="Forward_Declarations">
            <span title="Forward Declarations">前方宣言</span>
        </h3>

        <p>
            <span>
                <span class="src">
                    Avoid using forward declarations where possible.
                </span>
                前方宣言は可能な限り避けましょう。
            </span>
            <span>
                <span class="src">
                    Instead, <a href="#Include_What_You_Use">include the headers you need</a>.
                </span>
                そのかわりに<a href="#Include_What_You_Use">必要なヘッダーをinclude</a>してください。
            </span>
        </p>

        <p class="definition"></p>
        <p>
            <span>
                <span class="src">
                    A "forward declaration" is a declaration of an entity
                    without an associated definition.
                </span>
                前方宣言とは、関連付く定義のない何らかの宣言のことです。
            </span>
        </p>
        <pre>// In a C++ source file:
class B;
void FuncInB();
extern int variable_in_b;
ABSL_DECLARE_FLAG(flag_in_b);
</pre>
        <p class="pros"></p>
        <ul>
            <li>
                <span>
                    <span class="src">
                        Forward declarations can save compile time, as
                        <code>#include</code>s force the compiler to open
                        more files and process more input.
                    </span>
                    前方宣言を用いると、コンパイラが<code>#include</code>によって多数のファイルを開いて処理する分のコンパイル時間を節約することができます。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        Forward declarations can save on unnecessary
                        recompilation.
                    </span>
                    前方宣言は、不必要な再コンパイルを抑えることができます。
                </span>
                <span>
                    <span class="src">
                        <code>#include</code>s can force
                        your code to be recompiled more often, due to unrelated
                        changes in the header.
                    </span>
                    <code>#include</code>は、ヘッダーの変更があなたのコードに無関係な場合でもコードを再コンパイルする必要があるため、再コンパイルの頻度が上がります。
                </span>
            </li>
        </ul>

        <p class="cons"></p>
        <ul>
            <li>
                <span>
                    <span class="src">
                        Forward declarations can hide a dependency, allowing
                        user code to skip necessary recompilation when headers
                        change.
                    </span>
                    前方宣言は、依存性を隠してしまうため、実際には必要なコードの再コンパイルをスキップさせてしまうことがあります。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        A forward declaration as opposed to an #include statement
                        makes it difficult for automatic tooling to discover the module
                        defining the symbol.
                    </span>
                    自動化ツールを利用する場合に、前方宣言は<code>#include</code>に比べて、シンボルを定義するモジュールを発見させることが難しくなります。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        A forward declaration may be broken by subsequent
                        changes to the library.
                    </span>
                    前方宣言は、将来のライブラリ側の変更によって壊れることがあります。
                </span>
                <span>
                    <span class="src">
                        Forward declarations of functions
                        and templates can prevent the header owners from making
                        otherwise-compatible changes to their APIs, such as
                        widening a parameter type, adding a template parameter
                        with a default value, or migrating to a new namespace.
                    </span>
                    関数やテンプレートの前方宣言があると、ヘッダーのメンテナが、APIに対して互換性のない変更(パラメータの型を拡張したり、デフォルト値とともにテンプレートパラメータを増やしたり、新しい名前空間への移行したり)を行う際に妨げとなる場合があります。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        Forward declaring symbols from namespace
                        <code>std::</code> yields undefined behavior.
                    </span>
                    <code>std::</code>名前空間のシンボルに対する前方宣言は未定義動作を引き起こします。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        It can be difficult to determine whether a forward
                        declaration or a full <code>#include</code> is needed.
                    </span>
                    前方宣言だけで済むのか、<code>#include</code>が必要かを判断するのは、難しいことがあります。
                </span>
                <span>
                    <span class="src">
                        Replacing an <code>#include</code> with a forward
                        declaration can silently change the meaning of
                        code:
                    </span>
                    次のコードの<code>#include</code>を単に前方宣言に置き換えてしまうと、コードの意味が変わってしまいます。
                </span>
                <pre>// b.h:
struct B {};
struct D : B {};

// good_user.cc:
#include "b.h"
void f(B*);
void f(void*);
void test(D* x) { f(x); }  // Calls f(B*)</pre>
                <span>
                    <span class="src">
                        If the <code>#include</code> was replaced with forward
                        decls for <code>B</code> and <code>D</code>,
                        <code>test()</code> would call <code>f(void*)</code>.
                    </span>
                    <code>B</code>と<code>D</code>に対する<code>#include</code>を、単に前方宣言に置き換えてしまった場合、test()は<code>f(void*)</code>を呼び出すことになるでしょう。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        Forward declaring multiple symbols from a header
                        can be more verbose than simply
                        <code>#include</code>ing the header.
                    </span>
                    ある1つのヘッダーに含まれる複数のシンボルを前方宣言することは、単にそのヘッダーを<code>#include</code>するよりも冗長になってしまいます。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        Structuring code to enable forward declaration
                        (e.g., using pointer members instead of object members)
                        can make the code slower and more complex.
                    </span>
                    前方宣言を使ってコードを作ろうとすると、(メンバにオブジェクトではなくポインタにしなくてはならないなど)、実行速度を下げ、しかも複雑なコードを書く羽目になるかもしれません。
                </span>
            </li>
        </ul>

        <p class="decision"></p>
        <ul>
            <li>
                <span>
                    <span class="src">
                        Try to avoid forward declarations of entities
                        defined in another project.
                    </span>
                    外部プロジェクト内に存在するエンティティの前方宣言は避けましょう。
                </span>
            </li>
        </ul>

        <h3 id="Inline_Functions">
            <span title="Inline Functions">インライン関数</span>
        </h3>

        <p>
            <span>
                <span class="src">
                    Define functions inline only when they are small, say, 10
                    lines or fewer.
                </span>
                インライン関数は、関数の定義が小さいとき(10行以下程度)だけ使うようにしましょう。
            </span>
        </p>

        <p class="definition"></p>
        <p>
            <span>
                <span class="src">
                    You can declare functions in a way that allows the compiler to expand
                    them inline rather than calling them through the usual
                    function call mechanism.
                </span>
                関数は、通常の関数呼び出しのかわりに、コンパイラが直接その場に展開することを許す形で宣言することができます。
            </span>
        </p>
        <p class="pros"></p>
        <p>
            <span>
                <span class="src">
                    Inlining a function can generate more efficient object
                    code, as long as the inlined function is small.
                </span>
                関数が十分に小さければ、その関数をインライン化するこによって、効率的なオブジェクトコードを生成することができるようになります。
            </span>
            <span>
                <span class="src">
                    Feel free
                    to inline accessors and mutators, and other short,
                    performance-critical functions.
                </span>
                getter関数(原: accessors)やsetter関数(原: mutators)、パフォーマンスクリティカルな小さい関数はためらわずにインライン化しましょう。
            </span>
        </p>
        <p class="cons"></p>
        <p>
            <span>
                <span class="src">
                    Overuse of inlining can actually make programs slower.
                </span>
                インライン関数を濫用すると、実際にはプログラムの実行速度を下げてしまうこともあります。
            </span>
            <span>
                <span class="src">
                    Depending on a function's size, inlining it can cause the
                    code size to increase or decrease.
                </span>
                関数のサイズによって、インライン化後のコードのサイズは増えたり減ったりします。
            </span>
            <span>
                <span class="src">
                    Inlining a very small
                    accessor function will usually decrease code size while
                    inlining a very large function can dramatically increase code size.
                </span>
                とても小さいgetter関数をインライン化する場合たいていコードのサイズは小さくなりますが、一方で、大きな関数をインライン化してしまうと全体のコードサイズが劇的に大きくなってしまうこともあります。
            </span>
            <span>
                <span class="src">
                    On modern processors smaller code usually runs
                    faster due to better use of the instruction cache.
                </span>
                現代のCPUにおいては、通常は、より小さいコードの方が、命令キャッシュをうまく使えるため、高速に動作します。
            </span>
        </p>
        <p class="decision"></p>
        <p>
            <span>
                <span class="src">
                    A decent rule of thumb is to not inline a function if
                    it is more than 10 lines long.
                </span>
                経験的なルールとして、関数が10行より多くなったらインライン化を避けるべきです。
            </span>
            <span>
                <span class="src">
                    Beware of destructors,
                    which are often longer than they appear because of
                    implicit member- and base-destructor calls!
                </span>
                特に、デストラクタに気を付けましょう。デストラクタは、暗黙的にメンバのデストラクタと基底デストラクタを呼び出すため、実際には見た目より長くなっていることがままあるのです。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Another useful rule of thumb: it's typically not cost
                    effective to inline functions with loops or switch
                    statements (unless, in the common case, the loop or
                    switch statement is never executed).
                </span>
                もう１つ、有用な経験的なルールとして、大抵の場合、ループやswitch文のある関数は(それらの文がまったく実行されないような場合を除いて)インライン化しても効率的になりません。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    It is important to know that functions are not always
                    inlined even if they are declared as such; for example,
                    virtual and recursive functions are not normally inlined.
                </span>
                重要な知識として、インライン関数はインラインと宣言されたからといって、必ずインライン化されるわけではありません。たとえば仮想関数や再帰関数は通常インライン化されません。
            </span>
            <span>
                <span class="src">
                    Usually recursive functions should not be inline.
                </span>
                通常、再帰関数はインライン化すべきではありません。
            </span>
            <span>
                <span class="src">
                    The
                    main reason for making a virtual function inline is to
                    place its definition in the class, either for convenience
                    or to document its behavior, e.g., for accessors and
                    mutators.
                </span>
                仮想関数をクラス内にインラインで定義する理由は、利便性や、(getterやsetterの場合など)動作に関するドキュメントとしての役割があるからです。
            </span>
        </p>
        <h3 id="Names_and_Order_of_Includes">
            <span title="Names and Order of Includes">インクルードの名前と順序</span>
        </h3>

        <p>
            <span>
                <span class="src">
                    Include headers in the following order: Related header, C system headers,
                    C++ standard library headers,
                    other libraries' headers, your project's
                    headers.
                </span>
                インクルードは次の順番で行います: 紐付くヘッダー、C言語のシステムヘッダー、C++標準ライブラリヘッダー、その他のライブラリのヘッダー、自分のプロジェクト内のヘッダー
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    All of a project's header files should be
                    listed as descendants of the project's source
                    directory without use of UNIX directory aliases
                    <code>.</code> (the current directory) or <code>..</code>
                    (the parent directory).
                </span>
                プロジェクトヘッダーはプロジェクトソースディレクトリ以下に配置しなくてはなりません。UNIXディレクトリのエイリアスである<code>.</code>(カレントディレクトリ)や、<code>..</code>(親ディレクトリ)は省きます。
            </span>
            <span>
                <span class="src">
                    For example,
                    <code>google-awesome-project/src/base/logging.h</code>
                    should be included as:
                </span>
                たとえば、<code>google-awesome-project/src/base/logging.h</code>は次のようにインクルードされます。
            </span>
        </p>

        <pre>#include "base/logging.h"
</pre>

        <p>
            <span>
                <span class="src">
                    In <code><var>dir/foo</var>.cc</code> or
                    <code><var>dir/foo_test</var>.cc</code>, whose main
                    purpose is to implement or test the stuff in
                    <code><var>dir2/foo2</var>.h</code>, order your includes
                    as follows:
                </span>
                <code><var>dir2/foo2</var>.h</code>の宣言を実装もしくはテストする目的のファイル、<code><var>dir/foo</var>.cc</code>や<code><var>dir/foo_test</var>.cc</code>の中では、次の順序でincludeします。
            </span>
        </p>

        <ol>
            <li><code><var>dir2/foo2</var>.h</code>.</li>

            <li>
                <span class="src">
                    A blank line
                </span>
                空行
            </li>

            <li>
                <span class="src">
                    C system headers (more precisely: headers in angle brackets with the
                    <code>.h</code> extension), e.g., <code>&lt;unistd.h&gt;</code>,
                    <code>&lt;stdlib.h&gt;</code>.
                </span>
                C言語のシステムヘッダー(より正確には、<code>&lt;&gt;</code>で囲み、拡張子<code>.h</code>を持つもの)、たとえば<code>&lt;unistd.h&gt;</code>や<code>&lt;stdlib.h&gt;</code>
            </li>

            <li>
                <span class="src">
                    A blank line
                </span>
                空行
            </li>

            <li>
                <span class="src">
                    C++ standard library headers (without file extension), e.g.,
                    <code>&lt;algorithm&gt;</code>, <code>&lt;cstddef&gt;</code>.
                </span>
                C++標準ライブラリのヘッダー(拡張子のないもの)、たとえば<code>&lt;algorithm&gt;</code>や<code>&lt;cstddef&gt;</code>
            </li>

            <li>
                <span class="src">
                    A blank line
                </span>
                空行
            </li>

            <li>
                <span>
                    <span class="src">
                        Other libraries' .h files.
                    </span>
                    ほかのライブラリの<code>.h</code>ファイル
                </span>
            </li>

            <li>
                <span class="src">
                    A blank line
                </span>
                空行
            </li>

            <li>
                <span>
                    <span class="src">
                        Your project's <code>.h</code> files.
                    </span>
                    あなたのプロジェクトの.hファイル
                </span>
            </li>
        </ol>

        <p>
            <span>
                <span class="src">
                    Separate each non-empty group with one blank line.
                </span>
                空でないグループの間には空行を1つ入れます。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    With the preferred ordering, if the related header
                    <code><var>dir2/foo2</var>.h</code> omits any necessary
                    includes, the build of <code><var>dir/foo</var>.cc</code>
                    or <code><var>dir/foo</var>_test.cc</code> will break.
                </span>
                この順番にしておけば、紐付くヘッダー<code><var>dir2/foo2</var>.h</code>で必要なインクルードを省いてしまったときに、<code><var>dir/foo</var>.cc</code>や<code><var>dir/foo</var>_test.cc</code>のビルドが失敗します。
            </span>

            <span>
                <span class="src">
                    Thus, this rule ensures that build breaks show up first
                    for the people working on these files, not for innocent
                    people in other packages.
                </span>
                このルールによって、ビルドが壊れたときに、他のパッケージで作業している無実の人ではなく、それらのファイルで作業をしていた本人に最初に見せることができます。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    <code><var>dir/foo</var>.cc</code> and
                    <code><var>dir2/foo2</var>.h</code> are usually in the same
                    directory (e.g., <code>base/basictypes_test.cc</code> and
                    <code>base/basictypes.h</code>), but may sometimes be in different
                    directories too.
                </span>
                <code><var>dir/foo</var>.cc</code>と<code><var>dir2/foo2</var>.h</code>は、通常は同じディレクトリに置きますが(たとえば、<code>base/basictypes_test.cc</code>と<code>base/basictypes.h</code>)、異なるディレクトリに置くこともできます。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Note that the C headers such as <code>stddef.h</code>
                    are essentially interchangeable with their C++ counterparts
                    (<code>cstddef</code>).
                    Either style is acceptable, but prefer consistency with existing code.
                </span>
                <code>stddef.h</code>のようなC言語のヘッダーは、C++の相当するヘッダーと置き換えることができます(<code>cstddef</code>)。
                どちらのスタイルでもかまいませんが、既存のコードとの一貫性を優先してください。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Within each section the includes should be ordered
                    alphabetically.
                </span>
                各セクション内ではアルファベット順に並べます。
            </span>
            <span>
                <span class="src">
                    Note that older code might not conform to
                    this rule and should be fixed when convenient.
                </span>
                古いコードはこのルールに沿ってないかもしれませんが、修正したほうが利便性がよければ修正しましょう。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    For example, the includes in
                    <code>google-awesome-project/src/foo/internal/fooserver.cc</code>
                    might look like this:
                </span>

                たとえば、<code>google-awesome-project/src/foo/internal/fooserver.cc</code>のインクルードは次のようになります。
            </span>
        </p>

        <pre>#include "foo/server/fooserver.h"

#include &lt;sys/types.h&gt;
#include &lt;unistd.h&gt;

#include &lt;string&gt;
#include &lt;vector&gt;

#include "base/basictypes.h"
#include "foo/server/bar.h"
#include "third_party/absl/flags/flag.h"
</pre>
        <p class="exception">
            <span>
                <span class="src">
                    Sometimes, system-specific code needs
                    conditional includes.
                </span>
                システム特有のコードは、しばしば条件付きのインクルードを必要とする場合があります。
            </span>
            <span>
                <span class="src">
                    Such code can put conditional
                    includes after other includes.
                </span>
                そのような場合、それ以外のインクルードの後に条件付きインクルードを配置します。
            </span>
            <span>
                <span class="src">
                    Of course, keep your
                    system-specific code small and localized.
                </span>
                もちろんのことですが、システム特有のコードは小さく局所的に保ってください。
            </span>
            <span>
                <span class="src">
                    Example:
                </span>
                例:
            </span>
        </p>

        <pre>#include "foo/public/fooserver.h"

#include "base/port.h"  // For LANG_CXX11.

#ifdef LANG_CXX11
#include &lt;initializer_list&gt;
#endif  // LANG_CXX11
</pre>

        <h2 id="Scoping">
            <span title="Scoping">スコープ</span>
        </h2>

        <h3 id="Namespaces">
            <span title="Namespaces">名前空間</span>
        </h3>

        <p>
            <span>
                <span class="src">
                    With few exceptions, place code in a namespace.
                </span>
                細かい例外を除いて、コードは名前空間の中に置いてください。
            </span>
            <span>
                <span class="src">
                    Namespaces should have unique names based on the project name, and possibly its path.
                </span>
                名前空間はプロジェクト名やファイルのパスに基づいてユニークな名前をつけてください。
            </span>
            <span>
                <span class="src">
                    Do not use <i>using-directives</i> (e.g.,
                    <code>using namespace foo</code>).
                </span>また、usingディレクティブ(<code>using namespace foo</code>)は使ってはいけません。
            </span>
            <span>
                <span class="src">
                    Do not use inline namespaces.
                </span>
                インライン名前空間を使ってはいけません。
            </span>

            <span>
                <span class="src">
                    For unnamed namespaces, see
                    <a href="#Internal_Linkage">Internal Linkage</a>.
                </span>
                無名名前空間については<a href="#Internal_Linkage">内部リンケージ</a>を参照してください。
            </span>.
        </p>

        <p class="definition"></p>
        <p>
            <span>
                <span class="src">
                    Namespaces subdivide the global scope
                    into distinct, named scopes, and so are useful for preventing
                    name collisions in the global scope.
                </span>
                名前空間は、グローバルなスコープを名前付きのスコープに分割し、グローバルスコープにおいて名前が衝突するのを防ぐために有用です。
            </span>
        </p>
        <p class="pros"></p>

        <p>
            <span>
                <span class="src">
                    Namespaces provide a method for preventing name conflicts
                    in large programs while allowing most code to use reasonably
                    short names.
                </span>
                名前空間を用いると、大きなプログラム内での名前の衝突を避け、コードの大部分で理にかなった短い名前を使うことができるようになります。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    For example, if two different projects have a class
                    <code>Foo</code> in the global scope, these symbols may
                    collide at compile time or at runtime.
                </span>たとえば、2つのプロジェクトが同じ名前のクラス<code>Foo</code>をグローバル名前空間に持っていたとすると、これらのシンボルはコンパイル時や実行時に衝突してしまうかもしれません。
            </span>
            <span>
                <span class="src">
                    If each project
                    places their code in a namespace, <code>project1::Foo</code>
                    and <code>project2::Foo</code> are now distinct symbols that
                    do not collide, and code within each project's namespace
                    can continue to refer to <code>Foo</code> without the prefix.
                </span>
                しかし、各プロジェクトが独自の名前空間を持っていれば、同名だったシンボル<code>project1::Foo</code>と<code>project2::Foo</code>は区別できるようになり、衝突しなくなります。しかも、各プロジェクトの名前空間内のコードは、引き続き、プレフィクスなしの<code>Foo</code>で参照することができます。
            </span>
        </p>

        <p>
            <span>
                <span class="src">Inline namespaces automatically place their names in the enclosing scope.</span>
                インライン名前空間は、その内部に持つ名前を、自動的に外側のスコープに配置します。
            </span>

            <span>
                <span class="src">Consider the following snippet, for example:</span>
                例として、次のスニペットについて考えます。
            </span>
        </p>

        <pre class="neutralcode">namespace outer {
inline namespace inner {
  void foo();
}  // namespace inner
}  // namespace outer
</pre>

        <p>
            <span>
                <span class="src">
                    The expressions <code>outer::inner::foo()</code> and
                    <code>outer::foo()</code> are interchangeable.
                </span>
                このとき、式<code>outer::inner::foo()</code>は<code>outer::foo()</code>とも書けます。
            </span>
            <span>
                <span class="src">
                    Inline namespaces are primarily intended for ABI compatibility across versions.
                </span>
                インライン名前空間は、主にバージョン間におけるABIの互換性を保つことを目的としています。
            </span>
        </p>
        <p class="cons"></p>

        <p>
            <span>
                <span class="src">
                    Namespaces can be confusing, because they complicate
                    the mechanics of figuring out what definition a name refers
                    to.
                </span>
                名前空間は、その名前解決の仕組みの複雑さから、混乱を招くこともあります。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Inline namespaces, in particular, can be confusing
                    because names aren't actually restricted to the namespace
                    where they are declared.
                </span>
                インライン名前空間は、事実上その中で宣言される名前を名前空間の中に閉じ込めないため、特に混乱しやすいです。
            </span>
            <span>
                <span class="src">
                    They are only useful as part of
                    some larger versioning policy.
                </span>
                インライン名前空間は、バージョン管理ポリシーの一部としてのみ役に立ちます。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    In some contexts, it's necessary to repeatedly refer to
                    symbols by their fully-qualified names.
                </span>
                いくつかの文脈では、シンボルを解決するのに完全修飾された名前を用いる必要があります。
            </span>
            <span>
                <span class="src">
                    For deeply-nested
                    namespaces, this can add a lot of clutter.
                </span>
                名前空間のネストが深い場合、コードが散らってしまうことになりかねません。
            </span>
        </p>
        <p class="decision"></p>

        <p>
            <span>
                <span class="src">
                    Namespaces should be used as follows:
                </span>
                名前空間は次のように使いましょう:
            </span>
        </p>

        <ul>
            <li>
                <span>
                    <span class="src">
                        Follow the rules on <a href="#Namespace_Names">Namespace Names</a>
                    </span>
                    <a href="#Namespace_Names">名前空間の名前</a>のルールに従ってください。
                </span>
            </li>
            <li>
                <span>
                    <span class="src">
                        Terminate multi-line namespaces with comments as shown in the given
                        examples.
                    </span>
                    複数行にわたる名前空間の終わりには、先の例の通り、コメントをつけてください。
                </span>
            </li>
            <li>
                <p>
                    <span>
                        <span class="src">
                            Namespaces wrap the entire source file after
                            includes,
                            <a href="https://gflags.github.io/gflags/">gflags</a> definitions/declarations
                            and forward declarations of classes from other namespaces.
                        </span>
                        名前空間は、include文や<a href="https://gflags.github.io/gflags/">gflags</a>の定義と宣言、他の名前空間のクラスの前方宣言の後に続くソースコードをすべて包むようにしてください。
                    </span>
                </p>
                <div>
                    <div class="src">
                        <pre>// In the .h file
namespace mynamespace {

// All declarations are within the namespace scope.
// Notice the lack of indentation.
class MyClass {
 public:
  ...
  void Foo();
};

}  // namespace mynamespace
</pre>
                    </div>
                    <pre>// .h ファイル
namespace mynamespace {

// すべての宣言は名前空間のスコープに含めます。
// インデントはしません。
class MyClass {
 public:
  ...
  void Foo();
};

}  // namespace mynamespace
</pre>
</div>
<div>
                    <div class="src">
                        <pre>// In the .cc file
namespace mynamespace {

// Definition of functions is within scope of the namespace.
void MyClass::Foo() {
    ...
}

}  // namespace mynamespace
</pre>
                    </div>
                    <pre>// .ccファイル
namespace mynamespace {

// 関数の定義は名前空間に含めます。
void MyClass::Foo() {
  ...
}

}  // namespace mynamespace
</pre>
</div>
                <p>
                    <span>
                        <span class="src">
                            More complex <code>.cc</code> files might have additional details,
                            like flags or using-declarations.
                        </span>
                        より複雑な <code>.cc</code>ファイルは、flagsやusing宣言などを含む場合もあります。
                    </span>
                </p>
                <div>
                    <div class="src">
                        <pre>#include "a.h"

ABSL_FLAG(bool, someflag, false, "a flag");

namespace mynamespace {

using ::foo::Bar;

...code for mynamespace...    // Code goes against the left margin.

}  // namespace mynamespace
</pre>
                    </div>
                    <pre>#include "a.h"

ABSL_FLAG(bool, someflag, false, "a flag");

namespace a {

using ::foo::bar;

...code for a...         // コードの左側には余白を入れない。

}  // namespace a
</pre>
                </div>
            </li>

            <li>
                <span>
                    <span class="src">
                        To place generated protocol
                        message code in a namespace, use the
                        <code>package</code> specifier in the
                        <code>.proto</code> file.
                    </span>
                    Protocol Buffer が生成したメッセージコードを名前空間に入れる際は、<code>.proto</code>ファイル内の<code>package</code>指定子を使ってください。
                </span>
                <span>
                    <span class="src">
                        See
                        <a href="https://developers.google.com/protocol-buffers/docs/reference/cpp-generated#package">
                            Protocol Buffer Packages</a>
                        for details.
                    </span>
                    詳細は <a href="https://developers.google.com/protocol-buffers/docs/reference/cpp-generated#package">Protocol Buffer Packages</a> を参照してください。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        Do not declare anything in namespace
                        <code>std</code>, including forward declarations of
                        standard library classes.
                    </span><code>std</code>名前空間の中には、標準ライブラリの前方宣言を含めて、何も宣言してはいけません。
                </span>
                <span>
                    <span class="src">
                        Declaring entities in
                        namespace <code>std</code> is undefined behavior, i.e.,
                        not portable.
                    </span><code>std</code>名前空間の中に何かを宣言することは、コードの移植性を失わせ、未定義の動作を引き起こします。
                </span>
                <span>
                    <span class="src">
                        To declare entities from the standard
                        library, include the appropriate header file.
                    </span>標準ライブラリのエンティティを宣言するためには適切なヘッダーファイルをインクルードします。
                </span>
            </li>

            <li>
                <p>
                    <span>
                        <span class="src">
                            You may not use a <i>using-directive</i>
                            to make all names from a namespace available.
                        </span>
                        名前空間内のすべての名前を利用できるようにするための<i>usingディレクティブ</i>は使ってはいけません。
                    </span>
                </p>
                <div>
                    <div class="src">
                        <pre class="badcode">// Forbidden -- This pollutes the namespace.
using namespace foo;
</pre>
                    </div>
                    <pre class="badcode">// ダメ。名前空間を汚染している。
using namespace foo;
</pre>
                </div>
            </li>

            <li>
                <p>
                    <span>
                        <span class="src">
                            Do not use <i>Namespace aliases</i> at namespace scope
                            in header files except in explicitly marked
                            internal-only namespaces, because anything imported into a namespace
                            in a header file becomes part of the public
                            API exported by that file.
                        </span>
                        内部的に使用すると明示した名前空間の中を除いて、名前空間の別名(Namespace ailiases)をヘッダーファイルの名前空間のスコープで使ってはいけません。なぜならば、ヘッダーファイルで名前空間にインポートされたすべてのものが、そのヘッダーファイルが提供するパブリックなAPIの一部として公開されることになるからです。
                    </span>
                </p>

                <div>
                    <div class="src">
                        <pre>// Shorten access to some commonly used names in .cc files.
namespace baz = ::foo::bar::baz;
</pre>
                    </div>
                    <pre>// .ccファイルの中でたくさん使われる名前へのショートカットを作る。
namespace baz = ::foo::bar::baz;
</pre>
                </div>
                <div>
                    <div class="src">
                        <pre>// Shorten access to some commonly used names (in a .h file).
namespace librarian {
namespace impl {  // Internal, not part of the API.
namespace sidetable = ::pipeline_diagnostics::sidetable;
}  // namespace impl

inline void my_inline_function() {
  // namespace alias local to a function (or method).
  namespace baz = ::foo::bar::baz;
  ...
}
}  // namespace librarian
</pre>
                    </div>
                    <pre>// .hファイルの中で、よく使われる名前へのショートカットを作る。
namespace librarian {
namespace impl {  // 内部用。APIではありません。
namespace sidetable = ::pipeline_diagnostics::sidetable;
}  // namespace impl

inline void my_inline_function() {
  // 関数内に限定された名前空間の別名。
  namespace baz = ::foo::bar::baz;
  ...
}
}  // namespace librarian
</pre>
                </div>

            </li>
            <li>
                <span><span class="src">Do not use inline namespaces.</span>インライン名前空間は使ってはいけません。</span>
            </li>
        </ul>

        <a id="Unnamed_Namespaces_and_Static_Variables"></a>
        <h3 id="Internal_Linkage"><span title="Internal Linkage">内部リンケージ</span></h3>

        <p>
            <span>
                <span class="src">
                    When definitions in a <code>.cc</code> file do not need to be
                    referenced outside that file, give them internal linkage by placing
                    them in an unnamed namespace or declaring them <code>static</code>.
                </span>
                <code>.cc</code>ファイル中に、ファイル外から参照される必要がない定義を行うときは、それらを無名の名前空間内におくか、<code>static</code>に宣言することで、内部リンケージを持たせてください。
            </span>
            <span>
                <span class="src">
                    Do not use either
                    of these constructs in <code>.h</code> files.
                </span>
                これらのいずれの構成も<code>.h</code>で行ってはいけません。
            </span>
        </p>

        <p class="definition"></p>
        <p>
            <span>
                <span class="src">
                    All declarations can be given internal linkage by placing them in unnamed
                    namespaces.
                </span>
                無名名前空間内のすべての宣言は内部リンケージとなります。
            </span>
            <span>
                <span class="src">
                    Functions and variables can also be given internal linkage by
                    declaring them <code>static</code>.
                </span>
                また<code>static</code>に宣言された関数や変数も内部リンケージとなります。
            </span>
            <span>
                <span class="src">
                    This means that anything you're declaring
                    can't be accessed from another file.
                </span>
                内部リンケージとして宣言することは、他のファイルからアクセスできないことを意味します。
            </span>
            <span>
                <span class="src">
                    If a different file declares something with
                    the same name, then the two entities are completely independent.
                </span>
                仮に、他のファイルで同じ名前が宣言されていたとしても、それらは2つの独立した別々の実体として扱われます。
            </span>
        </p>
        <p class="decision"></p>

        <p>
            <span>
                <span class="src">
                    Use of internal linkage in <code>.cc</code> files is encouraged
                    for all code that does not need to be referenced elsewhere.
                </span>
                <code>.cc</code>で内部リンケージを使うことで、他の場所からこれらのコードは参照されてないということを強調できます。
            </span>
            <span>
                <span class="src">
                    Do not use internal linkage in <code>.h</code> files.
                </span>
                <code>.h</code>ファイルでは内部リンケージは使用してはいけません。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Format unnamed namespaces like named namespaces.
                </span>
                無名名前空間も、名前付きの名前空間と同じようにフォーマットします。
            </span>
            <span>
                <span class="src">
                    In the
                    terminating comment, leave the namespace name empty:
                </span>
                無名名前空間が終わるときのコメントは、以下の例のように名前空間名を空白のままにしておきます。
            </span>
        </p>

        <pre>namespace {
...
}  // namespace
</pre>

        <h3 id="Nonmember,_Static_Member,_and_Global_Functions">
            <span title="Nonmember, Static Member, and Global Functions">非メンバ関数、静的メンバ関数、グローバル関数</span>
        </h3>

        <p>
            <span>
                <span class="src">
                    Prefer placing nonmember functions in a namespace; use completely global
                    functions rarely.
                </span>
                非メンバ関数(通常の関数)はいずれかの名前空間内におきましょう。完全なグローバル関数はまず使いません。
            </span>
            <span>
                <span class="src">
                    Do not use a class simply to group static members.
                </span>
                静的メンバをグループにまとめるためにクラスを使ってはいけません。
            </span>
            <span>
                <span class="src">
                    Static
                    methods of a class should generally be closely related to instances of the
                    class or the class's static data.
                </span>
                静的メンバ関数は、そのクラスのインスタンスや静的メンバ変数と関連性が強い場合にのみ用います。
            </span>
        </p>

        <p class="pros"></p>
        <p>
            <span>
                <span class="src">
                    Nonmember and static member functions can be useful in
                    some situations.
                </span>
                通常の関数や静的メンバ関数は、いくつかのシチュエーションで有用です。
            </span>
            <span>
                <span class="src">
                    Putting nonmember functions in a
                    namespace avoids polluting the global namespace.
                </span>
                通常の関数はいずれかの名前空間内に置くことで、グローバル名前空間の汚染を避けられます。
            </span>
        </p>
        <p class="cons"></p>
        <p>
            <span>
                <span class="src">
                    Nonmember and static member functions may make more sense
                    as members of a new class, especially if they access
                    external resources or have significant dependencies.
                </span>
                通常の関数や、静的メンバ関数は、それらが外部のリソースにアクセスしたり強く依存したりしているときに、クラスのメンバとするよりも理にかなっている場合があります。
            </span>
        </p>
        <p class="decision"></p>
        <p>
            <span>
                <span class="src">
                    Sometimes it is useful to define a
                    function not bound to a class instance.
                </span>
                場合により、関数はクラスインスタンスに紐付けない方が便利なことがあります。
            </span>
            <span>
                <span class="src">
                    Such a function
                    can be either a static member or a nonmember function.
                </span>
                このような関数は、静的メンバ関数やメンバではない通常の関数とすることができます。
            </span>
            <span>
                <span class="src">
                    Nonmember functions should not depend on external
                    variables, and should nearly always exist in a namespace.
                </span>
                通常の関数は、外部の変数に依存すべきではありません。
                また、常に近しい名前空間の中に存在していなければなりません。
            </span>
            <span>
                <span class="src">
                    Do not create classes only to group static members;
                    this is no different than just giving the names a
                    common prefix, and such grouping is usually unnecessary anyway.
                </span>
                静的なメンバをグループにまとめるためだけにクラスを作ってはいけません。
                これは、名前に共通の接頭辞をつけることと何ら違いがありません。
                そして、いずれにせよ、そのようなグルーピングは、通常は不要なはずです。
            </span>
        </p>
        <p>
            <span>
                <span class="src">
                    If you define a nonmember function and it is only
                    needed in its <code>.cc</code> file, use
                    <a href="#Internal_Linkage">internal linkage</a> to limit
                    its scope.
                </span>
                非メンバ関数が特定の<code>.cc</code>ファイルでのみ使用される場合、<a href="#Internal_Linkage">内部リンケージ</a>を用いることで、スコープを制限することができます。
            </span>
        </p>

        <h3 id="Local_Variables">
            <span title="Local Variables">ローカル変数</span>
        </h3>

        <p>
            <span>
                <span class="src">
                    Place a function's variables in the narrowest scope
                    possible, and initialize variables in the declaration.
                </span>
                関数内の変数は、可能な限りそのスコープを狭めるようにしてください。また、関数内の変数は、宣言と同時に初期化してください。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    C++ allows you to declare variables anywhere in a
                    function.
                </span>
                C++では、関数のどこでも変数を宣言することができます。
            </span>
            <span>
                <span class="src">
                    We encourage you to declare them in as local a
                    scope as possible, and as close to the first use as
                    possible.
                </span>
                変数のスコープをできる限り局所的にし、できる限り初めて使用する場所の近くで宣言することをおすすめします。
            </span>
            <span>
                <span class="src">
                    This makes it easier for the reader to find the
                    declaration and see what type the variable is and what it
                    was initialized to.
                </span>
                そうすることで、コードの読者が、変数の宣言がどこにあるか、型は何か、どのように初期化されたか、といったことを見つけやすくなります。
            </span>
            <span>
                <span class="src">
                    In particular, initialization should
                    be used instead of declaration and assignment, e.g.,:
                </span>
                特に、変数の初期化は宣言と同時に行うようにし、宣言と代入を別に行うようなことは避けてください。例:
            </span>
        </p>
        <div>
            <div class="src">
                <pre class="badcode">int i;
i = f();      // Bad -- initialization separate from declaration.
</pre>
            </div>
            <pre class="badcode">int i;
i = f();      // 悪い例。初期化が宣言と分かれている。
</pre>
        </div>
        <div>
            <div class="src">
                <pre>int j = g();  // Good -- declaration has initialization.
</pre>
            </div>
            <pre>int j = g();  // よい例。宣言と同時に初期化が行われている。
</pre>
        </div>
        <div>
            <div class="src">
                <pre class="badcode">std::vector&lt;int&gt; v;
v.push_back(1);  // Prefer initializing using brace initialization.
v.push_back(2);
</pre>
            </div>
            <pre class="badcode">std::vector&lt;int&gt; v;
v.push_back(1);  // {}による初期化を使う方がよい。
v.push_back(2);
</pre>
        </div>
        <div>
            <div class="src">
                <pre>std::vector&lt;int&gt; v = {1, 2};  // Good -- v starts initialized.
</pre>
            </div>
            <pre>std::vector&lt;int&gt; v = {1, 2};  // よい例。 vは初期化されている。
</pre>
        </div>

        <p>
            <span>
                <span class="src">
                    Variables needed for <code>if</code>, <code>while</code>
                    and <code>for</code> statements should normally be declared
                    within those statements, so that such variables are confined
                    to those scopes. E.g.,:
                </span>

                <code>if</code>文や<code>while</code>文、<code>for</code>文で使用される変数は、通常は、それらの文の中で宣言します。そうすることで、変数のスコープを制限することができます。例：
            </span>
        </p>
        <pre>while (const char* p = strchr(str, '/')) str = p + 1;
</pre>
        <p>
            <span>
                <span class="src">
                    There is one caveat: if the variable is an object, its
                    constructor is invoked every time it enters scope and is
                    created, and its destructor is invoked every time it goes
                    out of scope.
                </span>
                ただし、もし変数がオブジェクトだったとすると、スコープに入るたびに毎回コンストラクタが呼ばれ、オブジェクトが生成され、スコープから出るたびに毎回デストラクタが呼ばれることになります。
            </span>
        </p>
        <div>
            <div class="src">
                <pre class="badcode">// Inefficient implementation:
for (int i = 0; i &lt; 1000000; ++i) {
  Foo f;  // My ctor and dtor get called 1000000 times each.
  f.DoSomething(i);
}
</pre>
            </div>
            <pre class="badcode">// 非効率的な実装
for (int i = 0; i &lt; 1000000; ++i) {
  Foo f;  // コンストラクタとデストラクタがそれぞれ 1000000 回ずつ呼ばれる。
  f.DoSomething(i);
}
</pre>
        </div>

        <p>
            <span>
                <span class="src">
                    It may be more efficient to declare such a variable
                    used in a loop outside that loop:
                </span>
                こういった場合、変数はループの外で宣言する方が効率的になる場合があります。
            </span>
        </p>
        <div>
            <div class="src">
                <pre>Foo f;  // My ctor and dtor get called once each.
for (int i = 0; i &lt; 1000000; ++i) {
  f.DoSomething(i);
}
</pre>
            </div>
            <pre>Foo f;  // コンストラクタとデストラクタは1回ずつ呼ばれる。
for (int i = 0; i &lt; 1000000; ++i) {
  f.DoSomething(i);
}
</pre>
        </div>

        <h3 id="Static_and_Global_Variables">
            <span title="Static and Global Variables">静的変数とグローバル変数</span>
        </h3>

        <p>
            <span>
                <span class="src">
                    Objects with
                    <a href="http://en.cppreference.com/w/cpp/language/storage_duration#Storage_duration">
                        static storage duration</a> are forbidden unless they are
                    <a href="http://en.cppreference.com/w/cpp/types/is_destructible">trivially
                        destructible</a>.
                </span>
                「<a href="http://en.cppreference.com/w/cpp/language/storage_duration#Storage_duration">静的な記憶域の有効期間(static storage duration)</a>」を持つオブジェクトは、
                それらが「<a href="http://en.cppreference.com/w/cpp/types/is_destructible">自明に破壊可能(trivially destructible)</a>」でない限り禁止します。
            </span>
            <span>
                <span class="src">
                    Informally this means that the destructor does not do
                    anything, even taking member and base destructors into account.
                </span>
                「自明に破壊可能」とは、ざっくり言うと、そのメンバ変数や基底クラスのデストラクタまで考慮に含めたとしても、デストラクタが何もしないことを意味します。
            </span>
            <span>
                <span class="src">
                    More formally it
                    means that the type has no user-defined or virtual destructor and that all bases
                    and non-static members are trivially destructible.
                </span>
                より正式には、型にユーザー定義デストラクタまたは仮想デストラクタがなく、かつ、すべての基底クラスおよび非静的メンバもまた同様に「自明に破壊可能」であることを意味します。
            </span>
            <span>
                <span class="src">
                    Static function-local variables may use dynamic initialization.
                </span>
                静的な関数ローカルスコープの変数は、動的な初期化を行うことができます。
            </span>
            <span>
                <span class="src">
                    Use of dynamic initialization for static class member variables or variables at
                    namespace scope is discouraged, but allowed in limited circumstances; see below
                    for details.
                </span>
                クラスの静的メンバ変数や名前空間スコープ変数に対して、動的な初期化を行うことは非推奨ですが、いくつかの限られた状況では認められます。このような状況についての詳細は後述します。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    As a rule of thumb: a global variable satisfies these requirements if its
                    declaration, considered in isolation, could be <code>constexpr</code>.
                </span>
                大雑把なルールとして、グローバル変数は、その宣言が単独で考えた場合に<code>constexpr</code>たり得るとき、これらの要件を満たします。
            </span>
        </p>

        <p class="definition"></p>
        <p>
            <span>
                <span class="src">
                    Every object has a <dfn>storage duration</dfn>, which correlates with its
                    lifetime.
                </span>
                すべてのオブジェクトには<dfn>記憶域の有効期間(storage duration)</dfn>があり、その寿命と相関しています。
            </span>
            <span>
                <span class="src">
                    Objects with static storage duration live from the point of their
                    initialization until the end of the program.
                </span>
                静的な記憶域の有効期間を持つオブジェクトは、それらが初期化された時点からプログラムの終了まで存続します。
            </span>
            <span>
                <span class="src">
                    Such objects appear as variables at
                    namespace scope ("global variables"), as static data members of classes, or as
                    function-local variables that are declared with the <code>static</code>
                    specifier.
                </span>
                このようなオブジェクトは、名前空間スコープの変数 (「グローバル変数」)や、クラスの静的データメンバ、
                <code>static</code>指定子で宣言された関数ローカル変数として現れます。
            </span>
            <span>
                <span class="src">
                    Function-local static variables are initialized when control first
                    passes through their declaration; all other objects with static storage duration
                    are initialized as part of program start-up.
                </span>
                関数ローカルの静的変数は、プログラムの実行が初めてその宣言を通過するときに初期化されます。
                そして、その他のすべての静的な記憶域期間を持つオブジェクトは、プログラムの起動処理の一部として初期化されます。
            </span>
            <span>
                <span class="src">
                    All objects with static storage
                    duration are destroyed at program exit (which happens before unjoined threads
                    are terminated).
                </span>
                静的な記憶域の有効期間を持つすべてのオブジェクトは、プログラムの終了時(バックグラウンドスレッドが存在する場合、それらが強制終了される前)に破壊されます。
            </span>
        </p>
        <p>
            <span>
                <span class="src">
                    Initialization may be <dfn>dynamic</dfn>, which means that something
                    non-trivial happens during initialization.
                </span>
                初期化は<dfn>動的(dynamic)</dfn>に行われる場合があり、その初期化中には「自明でない(non-trivial)」ことも発生するかもしれません。
            </span>
            <span>
                <span class="src">
                    (For example, consider a constructor
                    that allocates memory, or a variable that is initialized with the current
                    process ID.)
                </span>
                (たとえば、メモリを割り当てるコンストラクタや、現在のプロセス ID で初期化される変数などがそれにあたります。)
            </span>
            <span>
                <span class="src">
                    The other kind of initialization is <dfn>static</dfn>
                    initialization.
                </span>
                もう1つの種類の初期化は<dfn>静的(static)</dfn>初期化です。
            </span>
            <span>
                <span class="src">
                    The two aren't quite opposites, though: static
                    initialization <em>always</em> happens to objects with static storage duration
                    (initializing the object either to a given constant or to a representation
                    consisting of all bytes set to zero), whereas dynamic initialization happens
                    after that, if required.
                </span>
                この2つの初期化は完全に正反対というわけではありません。
                静的初期化は、すべての静的な記憶域期間を持つオブジェクトに対して、<em>必ず</em>発生します。
                (オブジェクトを、何らかの与えられた定数やゼロで埋めることで初期化します。)
                一方で、動的初期化は、静的初期化の後に、必要に応じて行われます。
            </span>
        </p>
        <p class="pros"></p>
        <p>
            <span>
                <span class="src">
                    Global and static variables are very useful for a large number of
                    applications: named constants, auxiliary data structures internal to some
                    translation unit, command-line flags, logging, registration mechanisms,
                    background infrastructure, etc.
                </span>
                グローバル変数と静的変数は、名前付き定数、一部の翻訳単位内部の補助データ構造、コマンドラインフラグ、
                ロギング、登録メカニズム、バックグラウンドインフラストラクチャなど、多数のアプリケーションで非常に役立ちます。
            </span>
        </p>
        <p class="cons"></p>
        <p>
            <span>
                <span class="src">
                    Global and static variables that use dynamic initialization or have
                    non-trivial destructors create complexity that can easily lead to hard-to-find
                    bugs.
                </span>
                動的初期化や自明でないデストラクタを持つグローバル変数や静的変数は、プログラムを複雑化させ、簡単には発見することができない困難なバグを引き起こします。
            </span>
            <span>
                <span class="src">
                    Dynamic initialization is not ordered across translation units, and
                    neither is destruction (except that destruction
                    happens in reverse order of initialization).
                </span>
                動的初期化や破壊は、翻訳単位間では順序付けられません(破壊が初期化の逆順で行われることを除いて)。
            </span>
            <span>
                <span class="src">
                    When one initialization refers to
                    another variable with static storage duration, it is possible that this causes
                    an object to be accessed before its lifetime has begun (or after its lifetime
                    has ended).
                </span>
                ある1つの初期化が、他の静的記憶域時間を持つ変数を参照している場合、そのオブジェクトが初期化される前(あるいは寿命が終わった後)にそのオブジェクトにアクセスしてしまう恐れがあります。
            </span>
            <span>
                <span class="src">
                    Moreover, when a program starts threads that are not joined at exit,
                    those threads may attempt to access objects after their lifetime has ended if
                    their destructor has already run.
                </span>
                もっといえば、もしプログラム内で、プログラム終了時に終了を待機(join)されないスレッドを作っていた場合、既にデストラクタが実行さて寿命が終わっているオブジェクトにアクセスしようとしてしまうかもしれません。
            </span>
        </p>
        <p class="decision"></p>
        <h4 title="Decision on destruction">破壊に関する結論</h4>

        <p>
            <span>
                <span class="src">
                    When destructors are trivial, their execution is not subject to ordering at
                    all (they are effectively not "run"); otherwise we are exposed to the risk of
                    accessing objects after the end of their lifetime.
                </span>
                デストラクタが自明(trivial)な場合、それらの実行は順序付けの対象とはなりません(そもそも「実行」されません)。
                そうでない場合は、オブジェクトが破壊されて寿命が終わった後にアクセスしてしまうリスクにさらされることになります。
            </span>
            <span>
                <span class="src">
                    Therefore, we only allow
                    objects with static storage duration if they are trivially destructible.
                </span>
                したがって、静的な記憶域の有効期間を持つオブジェクトは、それらが「自明に破壊できる(trivially destructible)」場合にのみ認めることとします。
            </span>
            <span>
                <span class="src">
                    Fundamental types (like pointers and <code>int</code>) are trivially
                    destructible, as are arrays of trivially destructible types. Note that
                    variables marked with <code>constexpr</code> are trivially destructible.
                </span>
                基本的な型(ポインタや<code>int</code>など)は自明に破壊できます。自明に破壊可能な型の配列も同様です。
                また、<code>constexpr</code>な変数は自明に破壊可能であるということも覚えておくとよいでしょう。
            </span>
        </p>
<div>
            <div class="src">
                <pre>const int kNum = 10;  // Allowed

struct X { int n; };
const X kX[] = {{1}, {2}, {3}};  // Allowed

void foo() {
  static const char* const kMessages[] = {"hello", "world"};  // Allowed
}

// Allowed: constexpr guarantees trivial destructor.
constexpr std::array&lt;int, 3&gt; kArray = {1, 2, 3};</pre>
            </div>
            <pre>const int kNum = 10;  // OK

struct X { int n; };
const X kX[] = {{1}, {2}, {3}};  // OK

void foo() {
  static const char* const kMessages[] = {"hello", "world"};  // OK
}

// OK: constexpr は trivial destructor.
constexpr std::array&lt;int, 3&gt; kArray = {1, 2, 3};</pre>
</div>
<div>
<div class="src">
        <pre class="badcode">// Bad: non-trivial destructor
const std::string kFoo = "foo";

// Bad for the same reason, even though kBar is a reference (the
// rule also applies to lifetime-extended temporary objects).
const std::string&amp; kBar = StrCat("a", "b", "c");

void bar() {
  // Bad: non-trivial destructor.
  static std::map&lt;int, int&gt; kData = {{1, 0}, {2, 0}, {3, 0}};
}</pre>
            </div>
        <pre class="badcode">// ダメ: non-trivial destructor
const std::string kFoo = "foo";

// 同様の理由でダメ。kBarが参照であったとしても。
// このルールは、一時オブジェクトの有効期限の延長が行われた場合も対象。
const std::string&amp; kBar = StrCat("a", "b", "c");

void bar() {
  // Bad: non-trivial destructor.
  static std::map&lt;int, int&gt; kData = {{1, 0}, {2, 0}, {3, 0}};
}</pre>
        </div>
        <p>
            <span>
                <span class="src">
                    Note that references are not objects, and thus they are not subject to the
                    constraints on destructibility.
                </span>
                参照はオブジェクトではないため、破壊可能性に関する制約を受けないことに注意してください。
            </span>
            <span>
                <span class="src">
                    The constraint on dynamic initialization still
                    applies, though.
                </span>
                ただし、動的初期化に関する制約は引き続き適用されます。
            </span>
            <span>
                <span class="src">
                    In particular, a function-local static reference of the form
                    <code>static T&amp; t = *new T;</code> is allowed.
                </span>
                特に、<code>static T&amp; t = *new T;</code> 形式の関数ローカルな静的参照変数は許可されます。
            </span>
        </p>

        <h4 title="Decision on initialization">初期化に関する結論</h4>

        <p>
            <span>
                <span class="src">
                    Initialization is a more complex topic.
                </span>
                初期化は、より複雑なトピックです。
            </span>
            <span>
                <span class="src">
                    This is because we must not only
                    consider whether class constructors execute, but we must also consider the
                    evaluation of the initializer:
                </span>
                これは、クラスのコンストラクタが実行されるかどうかを考慮するだけでなく、初期化子の評価についても考慮する必要があるためです。
            </span>
        </p>
<div>
<div class="src">
        <pre class="neutralcode">int n = 5;    // Fine
int m = f();  // ? (Depends on f)
Foo x;        // ? (Depends on Foo::Foo)
Bar y = g();  // ? (Depends on g and on Bar::Bar)</pre>
            </div>
        <pre class="neutralcode">int n = 5;    // OK
int m = f();  // ? (fに依存)
Foo x;        // ? (Fooのコンストラクタに依存)
Bar y = g();  // ? (gとBarのコンストラクタに依存)</pre>
</div>
        
        <p>
            <span>
                <span class="src">
                    All but the first statement expose us to indeterminate initialization
                    ordering.
                </span>
                最初の例を除くすべてのステートメントで、初期化順序の不確定性にさらされます。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    The concept we are looking for is called <em>constant initialization</em> in
                    the formal language of the C++ standard.
                </span>
                私たちが探している概念は、C++標準の形式言語において「<em>定数初期化</em>」と呼ばれているものです。
            </span>
            <span>
                <span class="src">
                    It means that the initializing
                    expression is a constant expression, and if the object is initialized by a
                    constructor call, then the constructor must be specified as
                    <code>constexpr</code>, too:
                </span>
                定数初期化とは、初期化式が定数式であるということを意味し、オブジェクトがコンストラクタ呼び出しによって初期化される場合には、そのコンストラクタも <code>constexpr</code> として指定されている必要があります。
            </span>
        </p>
<div>
<div class="src">
        <pre>struct Foo { constexpr Foo(int) {} };

int n = 5;  // Fine, 5 is a constant expression.
Foo x(2);   // Fine, 2 is a constant expression and the chosen constructor is constexpr.
Foo a[] = { Foo(1), Foo(2), Foo(3) };  // Fine</pre>
            </div>
        <pre>struct Foo { constexpr Foo(int) {} };

int n = 5;  // OK、 5 は定数式。
Foo x(2);   // OK、 2 は定数式で、選ばれるコンストラクタもconstexpr。
Foo a[] = { Foo(1), Foo(2), Foo(3) };  // OK</pre>
</div>
        

        <p>
            <span>
                <span class="src">
                    Constant initialization is always allowed.
                </span>
                定数初期化はいつでも使ってかまいません。
            </span>
            <span>
                <span class="src">
                    Constant initialization of
                    static storage duration variables should be marked with <code>constexpr</code>
                    or where possible the
                    <a
                        href="https://github.com/abseil/abseil-cpp/blob/03c1513538584f4a04d666be5eb469e3979febba/absl/base/attributes.h#L540">
                        <code>ABSL_CONST_INIT</code></a>
                    attribute.
                </span>
                静的記憶域期間を持つ変数の定数初期化は、<code>constexpr</code>でマークするか、可能な場合は
                <a href="https://github.com/abseil/abseil-cpp/blob/03c1513538584f4a04d666be5eb469e3979febba/absl/base/attributes.h#L540">
                    <code>ABSL_CONST_INIT</code></a>
                属性でマークする必要があります。
            </span>
            <span>
                <span class="src">
                    Any non-local static storage
                    duration variable that is not so marked should be presumed to have
                    dynamic initialization, and reviewed very carefully.
                </span>
                そのようにマークされていない非ローカルな静的記憶域期間の変数は、動的に初期化されるであろうという前提のもと、非常に慎重にレビューされる必要があります。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    By contrast, the following initializations are problematic:
                </span>
                対照的に、次の初期化には問題があります。
            </span>
        </p>
<div>
<div class="src">
       <pre class="badcode">// Some declarations used below.
time_t time(time_t*);      // Not constexpr!
int f();                   // Not constexpr!
struct Bar { Bar() {} };

// Problematic initializations.
time_t m = time(nullptr);  // Initializing expression not a constant expression
Foo y(f());                // Ditto
Bar b;                     // Chosen constructor Bar::Bar() not constexpr</pre>
            </div>
        <pre class="badcode">// 宣言
time_t time(time_t*);      // constexprでない!
int f();                   // constexprでない!
struct Bar { Bar() {} };

// 問題のある初期化
time_t m = time(nullptr);  // 初期化式が定数式でない
Foo y(f());                // 同上
Bar b;                     // 選択されるコンストラクタ Bar::Bar() がconstexprでない</pre>
</div>
        <p>
            <span>
                <span class="src">
                    Dynamic initialization of nonlocal variables is discouraged, and in general
                    it is forbidden.
                </span>
                非ローカル変数の動的初期化は推奨されておらず、原則として使用禁止とします。
            </span>
            <span>
                <span class="src">
                    However, we do permit it if no aspect of the program depends
                    on the sequencing of this initialization with respect to all other
                    initializations.
                </span>
                ただし、プログラムのあらゆる側面からみて、この初期化と他のすべての初期化との間における順序付けに関して、まったく依存していないと見なせる場合は、使用することができます。
            </span>
            <span>
                <span class="src">
                    Under those restrictions, the ordering of the initialization
                    does not make an observable difference.
                    For example:
                </span>
                そのような制限の下では、初期化の順序によって目に見える違いが生じることはありません。例えば：
            </span>
        </p>
<div>
<div class="src">
        <pre>int p = getpid();  // Allowed, as long as no other static variable
                   // uses p in its own initialization.</pre>
            </div>
       <pre>int p = getpid();  // OK。ただし、他の静的変数の初期化において
                   // pを使用していないときに限る。</pre>
</div>
        <p>
            <span>
                <span class="src">
                    Dynamic initialization of static local variables is allowed (and common).
                </span>
                静的ローカル変数の動的初期化は使用してかまいません(そして一般的です)。
            </span>
        </p>
        <h4 title="Common patterns">よくあるパターン</h4>
        <ul>
            <li>
                <span>
                    <span class="src">
                        Global strings: if you require a named global or static string constant,
                        consider using a <code>constexpr</code> variable of
                        <code>string_view</code>, character array, or character pointer, pointing
                        to a string literal.
                    </span>
                    グローバル文字列: 名前付きのグローバル文字列定数または静的な文字列定数が必要な場合は、
                    <code>constexpr</code>な<code>string_view</code>や文字配列、文字列ポインタ、文字列リテラルへのポインタを使用することを検討してください。
                </span>
                <span>
                    <span class="src">
                        String literals have static storage duration already
                        and are usually sufficient.
                        See <a href="https://abseil.io/tips/140">TotW #140.</a>
                    </span>
                    文字列リテラルは、予め静的記憶域期間があり、通常はそれで十分です。 <a href="https://abseil.io/tips/140">TotW #140.</a>を参照してください。
                </span>
            </li>
            <li>
                <span>
                    <span class="src">
                        Maps, sets, and other dynamic containers: if you require a static, fixed
                        collection, such as a set to search against or a lookup table, you cannot
                        use the dynamic containers from the standard library as a static variable,
                        since they have non-trivial destructors.
                    </span>
                    連想配列(map)、集合(set)、およびその他の動的コンテナ: 検索対象の集合やルックアップテーブルなどの用途で、静的かつ不変のコレクションが必要になった場合、
                    標準ライブラリの動的コンテナは非自明なデストラクタ(non-trivial destructors)を持つため、静的変数として使用してはなりません。
                </span>
                <span>
                    <span class="src">
                        Instead, consider
                        a simple array of trivial types, e.g., an array of arrays of ints (for a "map from int
                        to
                        int"), or an array of pairs (e.g., pairs of <code>int</code> and <code>const
    char*</code>).
                    </span>
                    かわりに、自明(trivial)な型の単純な配列、たとえば <code>int</code>の配列の配列 (「int から int への連想配列」として)や、値ペア(たとえば、<code>int</code> と <code>const
    char*</code>の値ペア)の配列等を検討してください。
                </span>

                <span>
                    <span class="src">
                        For small collections, linear search is entirely sufficient
                        (and efficient, due to memory locality); consider using the facilities from
                        <a href="https://github.com/abseil/abseil-cpp/blob/master/absl/algorithm/container.h">absl/algorithm/container.h</a>
                        for the standard operations.
                    </span>
                    小さなコレクションの場合は、線形検索で十分です(また、メモリ局所性の面から、その方が効率的でもあります)。より一般的な操作を必要とする場合は
                    <a href="https://github.com/abseil/abseil-cpp/blob/master/absl/algorithm/container.h">absl/algorithm/container.h</a>
                    を採用することを検討してください。
                </span>

                <span>
                    <span class="src">
                        If necessary, keep the collection in sorted
                        order and use a binary search algorithm.
                    </span>
                    必要ならば、コレクションをソート済みの状態に保ち、二分探索アルゴリズムを使用することもできます。
                </span>

                <span>
                    <span class="src">
                        If you do really prefer a dynamic container from the standard library, consider using
                        a function-local static pointer, as described below.
                    </span>
                    どうしても標準ライブラリの動的コンテナを使いたい場合、以下で説明するように、関数ローカルな静的ポインタの使用を検討してください。
                </span>

            </li>
            <li>
                <span>
                    <span class="src">
                        Smart pointers (<code>unique_ptr</code>, <code>shared_ptr</code>): smart
                        pointers execute cleanup during destruction and are therefore forbidden.
                    </span>
                    スマートポインタ (<code>unique_ptr</code>, <code>shared_ptr</code>): スマートポインタはデストラクタ内でクリーンアップ処理が実行されるため、静的変数として使用してはなりません。
                </span>
                <span>
                    <span class="src">
                        Consider whether your use case fits into one of the other patterns described
                        in this section.
                    </span>
                    その使用方法について、このセクションで説明している他のパターンのいずれかに当てはめられないか考えてみてください。
                </span>
                <span>
                    <span class="src">
                        One simple solution is to use a plain pointer to a
                        dynamically allocated object and never delete it (see last item).
                    </span>
                    簡単な解決策の1つは、単純な生のポインタ変数を用意し、動的に割り当てられたオブジェクトへのポインタを保持して、以降、そのオブジェクトをdeleteしないままにすることです(最後の項目を参照)。
                </span>
            </li>
            <li>
                <span>
                    <span class="src">
                        Static variables of custom types: if you require static, constant data of
                        a type that you need to define yourself, give the type a trivial destructor
                        and a <code>constexpr</code> constructor.
                    </span>
                    独自の型の静的変数: 自分で定義する必要がある型の静的な定数データを必要とする場合は、
                    その型に自明なデストラクタと <code>constexpr</code> コンストラクタを持たせるようにしてください。
                </span>
            </li>
            <li>
                <span>
                    <span class="src">
                        If all else fails, you can create an object dynamically and never delete
                        it by using a function-local static pointer or reference (e.g.,
                        <code>static const auto&amp; impl = *new T(args...);</code>).
                    </span>
                    上記のいずれの方法も採用できない場合は、関数ローカルの静的な生ポインタ変数または参照を用意して、オブジェクトを動的に作成し、deleteしないままにします。
                    (例: <code>static const auto&amp; impl = *new T(args...);</code>)
                </span>
            </li>
        </ul>

        <h3 id="thread_local" title="thread_local Variables">thread_local 変数</h3>
        <p>
            <span>
                <span class="src">
                    <code>thread_local</code> variables that aren't declared inside a function
                    must be initialized with a true compile-time constant,
                    and this must be enforced by using the

                    <a href="https://github.com/abseil/abseil-cpp/blob/master/absl/base/attributes.h">
                        <code>ABSL_CONST_INIT</code></a>
                    attribute.
                </span>
                関数内で宣言されていない<code>thread_local</code>変数は、真のコンパイル時定数で初期化されなくてはなりません。これは
                <a href="https://github.com/abseil/abseil-cpp/blob/master/absl/base/attributes.h">
                    <code>ABSL_CONST_INIT</code></a>
                属性を使用して強制されていなくてはなりません。
            </span>
            <span>
                <span class="src">
                    Prefer
                    <code>thread_local</code> over other ways of defining thread-local data.
                </span>
                スレッドローカルなデータを定義する他の方法よりも、<code>thread_local</code>を優先的に使用します。
            </span>
        </p>

        <p class="definition"></p>
        <p>
            <span>
                <span class="src">
                    Variables can be declared with the
                    <code>thread_local</code> specifier:
                </span>
                変数は、<code>thread_local</code>指定子で宣言できます。
            </span>
        </p>
        <pre>thread_local Foo foo = ...;
</pre>
        <p>
            <span>
                <span class="src">
                    Such a variable is actually a collection of objects, so that when different
                    threads access it, they are actually accessing different objects.
                </span>
                このような変数は、実際にはオブジェクトのコレクションです。そのため、異なるスレッドからアクセスすると、実際にはそれぞれ異なるオブジェクトにアクセスしています。
            </span>

            <span>
                <span class="src">
                    <code>thread_local</code> variables are much like
                    <a href="#Static_and_Global_Variables">static storage duration variables</a>
                    in many respects.
                </span>
                <code>thread_local</code>変数は、多くの側面で<a href="#Static_and_Global_Variables">静的な記憶域の有効期間の変数</a>によく似ています。
            </span>
            <span>
                <span class="src">
                    For instance, they can be declared at namespace scope,
                    inside functions, or as static class members, but not as ordinary class
                    members.
                </span>
                たとえば、名前空間スコープ、関数内、または静的クラスメンバとして宣言できますが、通常のクラスメンバとして宣言することはできません。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    <code>thread_local</code> variable instances are initialized much like
                    static variables, except that they must be initialized separately for each
                    thread, rather than once at program startup.
                </span>
                <code>thread_local</code>変数インスタンスは、プログラムの起動時に一度ではなくスレッドごとに個別に初期化されるという点を除けば、静的変数と同じように初期化されます。
            </span>

            <span>
                <span class="src">
                    This means that
                    <code>thread_local</code> variables declared within a function are safe, but
                    other <code>thread_local</code> variables are subject to the same
                    initialization-order issues as static variables (and more besides).
                </span>
                これは、関数内で宣言された<code>thread_local</code>変数は安全であることを意味しますが、他の<code>thread_local</code>変数は、静的変数と同じ初期化順序やそれ以外の問題の影響を受けるということを意味します。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    <code>thread_local</code> variable instances are not destroyed before their
                    thread terminates, so they do not have the destruction-order issues of static
                    variables.
                </span>
                <code>thread_local</code>変数インスタンスは、そのスレッドが終了する前に破壊されないため、静的変数の破壊順序の問題はありません。
            </span>
        </p>

        <p class="pros">
        </p>
        <ul>
            <li>
                <span>
                    <span class="src">
                        Thread-local data is inherently safe from races (because only one thread
                        can ordinarily access it), which makes <code>thread_local</code> useful for
                        concurrent programming.
                    </span>
                    スレッドローカルなデータは、通常は1つのスレッドしかアクセスできないので、本質的に競合(race)に対して安全なため、
                    <code>thread_local</code>は並行プログラミングに役立ちます。
                </span>
            </li>
            <li>
                <span>
                    <span class="src">
                        <code>thread_local</code> is the only standard-supported way of creating
                        thread-local data.
                    </span>
                    <code>thread_local</code>は、標準がサポートする唯一のスレッドローカルなデータの作成方法です。
                </span>
            </li>
        </ul>

        <p class="cons">
        </p>
        <ul>
            <li>
                <span>
                    <span class="src">
                        Accessing a <code>thread_local</code> variable may trigger execution of
                        an unpredictable and uncontrollable amount of other code.
                    </span>
                    <code>thread_local</code>変数にアクセスすると、予測不能で制御不能な量の他のコードが実行される可能性があります。
                </span>
            </li>
            <li>
                <span>
                    <span class="src">
                        <code>thread_local</code> variables are effectively global variables,
                        and have all the drawbacks of global variables other than lack of
                        thread-safety.
                    </span>
                    <code>thread_local</code>変数は事実上グローバル変数であり、スレッドセーフの欠如以外のグローバル変数のすべての欠点があります。
                </span>
            </li>
            <li>
                <span>
                    <span class="src">
                        The memory consumed by a <code>thread_local</code> variable scales with
                        the number of running threads (in the worst case), which can be quite large
                        in a program.
                    </span>
                    <code>thread_local</code>変数によって消費されるメモリは、最悪の場合、実行中のスレッド数に比例し、プログラム内で非常に大きくなる可能性があります。
                </span>
            </li>
            <li>
                <span>
                    <span class="src">
                        Non-static data members cannot be <code>thread_local</code>.
                    </span>
                    静的でないデータメンバを<code>thread_local</code>にすることはできません。
                </span>
            </li>
            <li>
                <span>
                    <span class="src">
                        <code>thread_local</code> may not be as efficient as certain compiler
                        intrinsics.
                    </span>
                    <code>thread_local</code>は、一部のコンパイラが持つ組み込みの機能(intrinsics)ほど効率的ではない場合があります。
                </span>
            </li>

        </ul>

        <p class="decision">
        </p>
        <p>
            <span>
                <span class="src">
                    <code>thread_local</code> variables inside a function have no safety
                    concerns, so they can be used without restriction.
                </span>
                関数内の<code>thread_local</code>変数には安全上の懸念がないため、制限なく使用してかまいません。
            </span>

            <span>
                <span class="src">
                    Note that you can use
                    a function-scope <code>thread_local</code> to simulate a class- or
                    namespace-scope <code>thread_local</code> by defining a function or
                    static method that exposes it:
                </span>
                あわせて、公開された関数やメソッドの中で関数スコープの<code>thread_local</code>を用いれば、クラススコープや名前空間スコープの<code>thread_local</code>変数をシミュレートできることも覚えておくとよいでしょう。
            </span>
        </p>

        <pre>Foo&amp; MyThreadLocalFoo() {
    thread_local Foo result = ComplicatedInitialization();
    return result;
}</pre>

        <p>
            <span>
                <span class="src">
                    <code>thread_local</code> variables at class or namespace scope must be
                    initialized with a true compile-time constant (i.e., they must have no
                    dynamic initialization).
                </span>
                クラススコープまたは名前空間スコープの<code>thread_local</code>変数は、真のコンパイル時定数での初期化されなくてはなりません(動的初期化してはいけません)。
            </span>

            <span>
                <span class="src">
                    To enforce this, <code>thread_local</code> variables
                    at class or namespace scope must be annotated with


                    <a href="https://github.com/abseil/abseil-cpp/blob/master/absl/base/attributes.h">
                        <code>ABSL_CONST_INIT</code></a>
                    (or <code>constexpr</code>, but that should be rare):
                </span>
                これを強制するために、クラスや名前空間スコープの<code>thread_local</code>変数は
                <a href="https://github.com/abseil/abseil-cpp/blob/master/absl/base/attributes.h">
                    <code>ABSL_CONST_INIT</code></a>
                (または<code>constexpr</code>ですが、まれなはずです)でマークする必要があります。
            </span>
        </p>

        <pre>ABSL_CONST_INIT thread_local Foo foo = ...;
        </pre>

        <p>
            <span>
                <span class="src">
                    <code>thread_local</code> should be preferred over other mechanisms for
                    defining thread-local data.
                </span>
                スレッドローカルなデータを定義するときは、他の仕組みよりも<code>thread_local</code>を優先しましょう。
            </span>
        </p>

        <h2 id="Classes">
            <span title="Classes">クラス</span>
        </h2>

        <p>
            <span>
                <span class="src">
                    Classes are the fundamental unit of code in C++.
                </span>
                クラスはC++におけるコードの基本単位です。
            </span>
            <span>
                <span class="src">
                    Naturally, we use them extensively.
                </span>
                もちろん、我々は、それらを広く使っています。
            </span>
            <span>
                <span class="src">
                    This section lists the main dos and
                    don'ts you should follow when writing a class.
                </span>
                このセクションでは、クラスを書くときに、すべきこと、すべきでないことについて述べます。
            </span>
        </p>

        <h3 id="Doing_Work_in_Constructors">
            <span title="Doing Work in Constructors">コンストラクタで行うこと</span>
        </h3>

        <p>
            <span>
                <span class="src">
                    Avoid virtual method calls in constructors, and avoid
                    initialization that can fail if you can't signal an error.
                </span>
                コンストラクタで仮想メンバ関数を呼んではいけません。エラーを伝える手段がない場合、失敗するかもしれない初期化処理を行ってはいけません。
            </span>
        </p>

        <p class="definition"></p>
        <p>
            <span>
                <span class="src">
                    It is possible to perform arbitrary initialization in the body
                    of the constructor.
                </span>
                コンストラクタでは任意の初期化処理を行うことができます。
            </span>
        </p>
        <p class="pros"></p>
        <ul>
            <li>
                <span>
                    <span class="src">
                        No need to worry about whether the class has been initialized or
                        not.
                    </span>
                    クラスが初期化済みであるかどうか、気にかけなくてよくなります。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        Objects that are fully initialized by constructor call can
                        be <code>const</code> and may also be easier to use with standard containers
                        or algorithms.
                    </span>
                    コンストラクタで完全に初期化されるオブジェクトは、<code>const</code>にしやすく、標準コンテナや標準アルゴリズムで扱いやすくなります。
                </span>
            </li>
        </ul>

        <p class="cons"></p>
        <ul>
            <li>
                <span>
                    <span class="src">
                        If the work calls virtual functions, these calls
                        will not get dispatched to the subclass
                        implementations.
                    </span>
                    コンストラクタで仮想関数が呼び出されたとしても、それらは派生クラスの実装を呼び出しません。
                </span>
                <span>
                    <span class="src">
                        Future modification to your class can
                        quietly introduce this problem even if your class is
                        not currently subclassed, causing much confusion.
                    </span>
                    現時点で派生クラスがなくとも、将来的なクラスの変更によって、静かにこの問題を引き起こし、混乱を招くかもしれません。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        There is no easy way for constructors to signal errors, short of
                        crashing the program (not always appropriate) or using exceptions
                        (which are <a href="#Exceptions">forbidden</a>).
                    </span>
                    コンストラクタには、簡単にエラーを伝える方法がありません。せいぜい、プログラムをクラッシュさせる(常にそれが適切とは限らない)方法や、例外を使う(ルール上<a href="#Exceptions">禁止</a>)方法くらいです。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        If the work fails, we now have an object whose initialization
                        code failed, so it may be an unusual state requiring a <code>bool
                        IsValid()</code> state checking mechanism (or similar) which is easy
                        to forget to call.
                    </span>
                    コンストラクタの処理が失敗した場合、初期化に失敗したオブジェクトができてしまいます。<code>bool IsValid()</code>のような状態をチェックする仕組みを用意しても、それを呼び出さなくてはいけないこと自体、簡単に忘れられてしまいます。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        You cannot take the address of a constructor, so whatever work
                        is done in the constructor cannot easily be handed off to, for
                        example, another thread.
                    </span>
                    コンストラクタのアドレスを得ることはできません。このため、コンストラクタで行われる処理の内容を他のスレッドに渡したりするようなことは、簡単にはできません。
                </span>
            </li>
        </ul>

        <p class="decision"></p>
        <p>
            <span>
                <span class="src">
                    Constructors should never call virtual functions.
                </span>
                コンストラクタでは仮想関数を呼び出してはいけません。
            </span>
            <span>
                <span class="src">
                    If appropriate
                    for your code ,
                    terminating the program may be an appropriate error handling
                    response.
                </span>
                それが適切と考えられるのであれば、プログラムを強制終了するのもエラー処理の1つのやり方でしょう。
            </span>
            <span>
                <span class="src">
                    Otherwise, consider a factory function
                    or <code>Init()</code> method as described in
                    <a href="https://abseil.io/tips/42">TotW #42</a>
                    .
                </span>
                さもなくば、<a href="https://abseil.io/tips/42">TotW #42</a>で説明されているような、ファクトリ関数や<code>Init()</code>メソッドの導入を検討しましょう。
            </span>
            <span>
                <span class="src">
                    Avoid <code>Init()</code> methods on objects with
                    no other states that affect which public methods may be called
                    (semi-constructed objects of this form are particularly hard to work
                    with correctly).
                </span>
                どのパブリックメソッドが呼びだすことができるかに影響する他の状態を持たないオブジェクトについて<code>Init()</code>メソッドは避けてください(中途半端に生成されたオブジェクトを正しく動作させるのは特に困難です)。
            </span>
        </p>

        <a id="Explicit_Constructors"></a>
        <h3 id="Implicit_Conversions">
            <span title="Implicit Conversions">暗黙的型変換</span>
        </h3>

        <p>
            <span>
                <span class="src">
                    Do not define implicit conversions.
                </span>
                暗黙的型変換を新たに定義してはいけません。
            </span>
            <span>
                <span class="src">
                    Use the <code>explicit</code>
                    keyword for conversion operators and single-argument
                    constructors.
                </span>
                型変換演算子や、1つの引数をとるコンストラクタにおいては<code>explicit</code>キーワードを使用してください。
            </span>
        </p>

        <p class="definition"></p>
        <p>
            <span>
                <span class="src">
                    Implicit conversions allow an
                    object of one type (called the <dfn>source type</dfn>) to
                    be used where a different type (called the <dfn>destination
                    type</dfn>) is expected, such as when passing an
                    <code>int</code> argument to a function that takes a
                    <code>double</code> parameter.
                </span>
                暗黙的型変換によって、ある型(<dfn>source type</dfn>と呼ぶ)のオブジェクトを異なる型(<dfn>destination
                    type</dfn>と呼ぶ)が期待されるところに用いることができます。たとえば、<code>double</code>型の仮引数をとる関数に<code>int</code>型の値を渡す場合です。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    In addition to the implicit conversions defined by the language,
                    users can define their own, by adding appropriate members to the
                    class definition of the source or destination type.
                </span>
                言語で元々定義されている暗黙的型変換に加えて、変換元の型(source type)か変換先の型(destination
                    type)のクラス定義に適切なメンバを加えることで、新たに独自の暗黙的型変換を定義することができます。
            </span>
            <span>
                <span class="src">
                    An implicit
                    conversion in the source type is defined by a type conversion operator
                    named after the destination type (e.g., <code>operator
                    bool()</code>).
                </span>
                変換元の型における暗黙的型変換は、変換先型の名前をつけた型変換演算子によって定義されます(例:<code>operator bool()</code>)。
            </span>
            <span>
                <span class="src">
                    An implicit conversion in the destination
                    type is defined by a constructor that can take the source type as
                    its only argument (or only argument with no default value).
                </span>
                変換先の型における暗黙的型変換は、変換元の型の引数を1つだけとる(またはデフォルト値のない引数を1つだけとる)コンストラクタによって定義されます。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    The <code>explicit</code> keyword can be applied to a constructor
                    or a conversion operator, to ensure that it can only be
                    used when the destination type is explicit at the point of use,
                    e.g., with a cast.
                </span>
                <code>explicit</code>キーワードは、コンストラクタや型変換演算子につけることができます。これによって、変換先の型が明示された場合にのみ型変換が行われるよう強制することができます。
            </span>
            <span>
                <span class="src">
                    This applies not only to implicit conversions, but to
                    list initialization syntax:
                </span>
                これは、暗黙的型変換だけではなく、以下に示すようなリスト初期化構文にも適用されます。
            </span>
        </p>
        <pre>class Foo {
  explicit Foo(int x, double y);
  ...
};

void Func(Foo f);
</pre>
        <pre class="badcode">Func({42, 3.14});  // Error
</pre>
        <span>
            <span class="src">
                This kind of code isn't technically an implicit conversion, but the
                language treats it as one as far as <code>explicit</code> is concerned.
            </span>
            このようなコードは何らテクニカルな暗黙的型変換はしていませんが、言語上は<code>explicit</code>の懸念があると見なして扱われます。
        </span>

        <p class="pros"></p>
        <ul>
            <li>
                <span>
                    <span class="src">
                        Implicit conversions can make a type more usable and
                        expressive by eliminating the need to explicitly name a type
                        when it's obvious.
                    </span>
                    暗黙的型変換は、型の利便性を高め、型が明確であるときには型の名前を省略可能であるため表現上も優れています。
                </span>
            </li>
            <li>
                <span>
                    <span class="src">
                        Implicit conversions can be a simpler alternative to
                        overloading, such as when a single
                        function with a <code>string_view</code> parameter takes the
                        place of separate overloads for <code>std::string</code> and
                        <code>const char*</code>.
                    </span>
                    暗黙的型変換は単にオーバーロードの代替手段としても利用可能です。
                    たとえば、<code>string_view</code>を引数に受け取る関数が1つあるだけで、
                    別々に定義される<code>std::string</code>や<code>const char*</code>のオーバーロードの代わりになるでしょう。
                </span>
            </li>
            <li>
                <span>
                    <span class="src">
                        List initialization syntax is a concise and expressive
                        way of initializing objects.
                    </span>
                    リスト初期化子による構文は、簡潔で表現的に優れたオブジェクトの初期化方法です。
                </span>
            </li>
        </ul>

        <p class="cons"></p>
        <ul>
            <li>
                <span>
                    <span class="src">
                        Implicit conversions can hide type-mismatch bugs, where the
                        destination type does not match the user's expectation, or
                        the user is unaware that any conversion will take place.
                    </span>
                    暗黙的型変換は、型の不一致によるバグを隠してしまうことがあります。たとえば、変換先の型がユーザーの期待どおりにならなかったり、そもそもその場で型変換が行わることに気づかなかったりします。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        Implicit conversions can make code harder to read, particularly
                        in the presence of overloading, by making it less obvious what
                        code is actually getting called.
                    </span>
                    暗黙的型変換は、コードの可読性を下げる場合があります。特に、関数にオーバーロードが存在する場合、どれが実際に呼び出されるのかをわかりにくくしてしまうことがあります。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        Constructors that take a single argument may accidentally
                        be usable as implicit type conversions, even if they are not
                        intended to do so.
                    </span>
                    1つの引数をとるコンストラクタが、意図せず型変換のために呼び出されてしまうことがあります。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        When a single-argument constructor is not marked
                        <code>explicit</code>, there's no reliable way to tell whether
                        it's intended to define an implicit conversion, or the author
                        simply forgot to mark it.
                    </span>
                    1つの引数をとるコンストラクタが<code>explicit</code>でマークされていなかったとき、それが意図した暗黙的型変換のために書かれているのか、単にコードの著者が<code>explicit</code>をつけるのを忘れてしまっただけなのか、信頼できる判断方法がありません。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        Implicit conversions can lead to call-site ambiguities, especially
                        when there are bidirectional implicit conversions.
                    </span>
                    暗黙的型変換は、呼び出し元における曖昧性を引き起こします。特に、それらが双方向に暗黙的変換が可能な場合です。
                </span>
                <span>
                    <span class="src">
                        This can be caused
                        either by having two types that both provide an implicit conversion,
                        or by a single type that has both an implicit constructor and an
                        implicit type conversion operator.
                    </span>
                    これは、そのような型同士の双方が暗黙的型変換の機能を提供していたり、一方の型が暗黙的型変換を行うコンストラクタと型変換演算子の両方を実装している場合に起こります。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        List initialization can suffer from the same problems if
                        the destination type is implicit, particularly if the
                        list has only a single element.
                    </span>
                    リストによる初期化では、変換先の型が暗黙的型変換を持つとき同じ問題にぶつかります(特にリストに1要素しか持っていなかった場合)。
                </span>
            </li>
        </ul>

        <p class="decision"></p>
        <p>
            <span>
                <span class="src">
                    Type conversion operators, and constructors that are
                    callable with a single argument, must be marked
                    <code>explicit</code> in the class definition.
                </span>
                型変換演算子と1つの引数で呼び出せるコンストラクタは<code>explicit</code>でマークされていなくてはなりません。
            </span>
            <span>
                <span class="src">
                    As an
                    exception, copy and move constructors should not be
                    <code>explicit</code>, since they do not perform type
                    conversion.
                </span>
                例外として、コピーコンストラクタとムーブコンストラクタは<code>explicit</code>でマークされているべきではありません。これらは型変換を行うものではないからです。
            </span>
            <span>
                <span class="src">
                    Implicit conversions can sometimes be necessary and appropriate for
                    types that are designed to be interchangeable, for example when objects
                    of two types are just different representations of the same underlying
                    value.
                </span>
                また、型を相互に交換可能なようにデザインする場合など、暗黙的型変換が必要かつ適切な時もあります。
                たとえば、ある値に対して、2つの型の間で表現方法のみが異なるというような場合です。
            </span>
            <span>
                <span class="src">
                    In that case, contact
                    your project leads to request
                    a waiver of this rule.
                </span>
                そのような場合においては、プロジェクトリーダーと相談し、このルールの適用対象外としてください。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Constructors that cannot be called with a single argument
                    may omit <code>explicit</code>.
                </span>
                1つの引数では呼び出せないコンストラクタにおいては、<code>explicit</code>を省略できます。
            </span>
            <span>
                <span class="src">
                    Constructors that
                    take a single <code>std::initializer_list</code> parameter should
                    also omit <code>explicit</code>, in order to support copy-initialization
                    (e.g., <code>MyType m = {1, 2};</code>).
                </span>
                また、1つの<code>std::initializer_list</code>型の引数をとるコンストラクタについも、コピーによる初期化(例: <code>MyType m = {1, 2};</code>)をサポートするために<code>explicit</code>を省略してください。
            </span>
        </p>

        <h3 id="Copyable_Movable_Types">
            <span title="Copyable and Movable Types">コピー可能な型・ムーブ可能な型</span>
        </h3>
        <a id="Copy_Constructors"></a>

        <p>
            <span>
                <span class="src">
                    A class's public API must make clear whether the class is copyable,
                    move-only, or neither copyable nor movable.
                </span>
                公開APIとしてのクラスは、そのクラスがコピー可能なのか、ムーブのみ可能なのか、そのいずれも不可能なのかを明示しなくてはなりません。
            </span>
            <span>
                <span class="src">
                    Support copying and/or
                    moving if these operations are clear and meaningful for your type.
                </span>
                新しく型を作るときには、その型において、コピー操作やムーブ操作が、明確かつ有意義である場合に、それらの操作をサポートしましょう。
            </span>
        </p>

        <p class="definition"></p>
        <p>
            <span>
                <span class="src">
                    A movable type is one that can be initialized and assigned
                    from temporaries.
                </span>
                ムーブ可能な型は、一時オブジェクトからの初期化または代入が可能な型です。
            </span>
        </p>
        <p>
            <span>
                <span class="src">
                    A copyable type is one that can be initialized or assigned from
                    any other object of the same type (so is also movable by definition), with the
                    stipulation that the value of the source does not change.
                </span>
                コピー可能な型は、元のオブジェクトの値を変化させずに、同じ型の任意のオブジェクト（ムーブ可能も含む）からの初期化または代入が可能な型です。
            </span>
            <span>
                <span class="src">
                    <code>std::unique_ptr&lt;int&gt;</code> is an example of a movable but not
                    copyable type (since the value of the source
                    <code>std::unique_ptr&lt;int&gt;</code> must be modified during assignment to
                    the destination).
                </span>
                たとえば、<code>std::unique_ptr&lt;int&gt;</code>は、ムーブ可能かつコピー不可な型の一例です。
                (別の<code>std::unique_ptr&lt;int&gt;</code>変数への代入操作を行うとき、代入元は変更される必要があります。)
            </span>

            <span>
                <span class="src">
                    <code>int</code> and <code>std::string</code> are examples of
                    movable types that are also copyable.
                </span>
                <code>int</code>や<code>std::string</code>は、ムーブもコピーも可能な例です。
            </span>

            <span>
                <span class="src">
                    (For <code>int</code>, the move and copy
                    operations are the same; for <code>std::string</code>, there exists a move operation
                    that is less expensive than a copy.)
                </span>
                (<code>int</code>において、ムーブ操作とコピー操作は同一です。
                <code>std::string</code>においては、コピー操作よりも安価なムーブ操作が存在します。)
            </span>

            <span>
                <span class="src">
                    For user-defined types, the copy behavior is defined by the copy
                    constructor and the copy-assignment operator.
                </span>
                ユーザー定義の型においては、コピーの挙動は、コピーコンストラクタとコピー代入演算子によって定義されます。
            </span>

            <span>
                <span class="src">
                    Move behavior is defined by the
                    move constructor and the move-assignment operator, if they exist, or by the
                    copy constructor and the copy-assignment operator otherwise.
                </span>
                ムーブの挙動は、ムーブコンストラクタとムーブ代入演算子が存在する場合にそれらによって定義されます。
                それらが存在しない場合は、ムーブの挙動は、コピーコンストラクタとコピー代入演算子によって定義されます。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    The copy/move constructors can be implicitly invoked by the compiler
                    in some situations, e.g., when passing objects by value.
                </span>
                コピーコンストラクタやムーブコンストラクタは、オブジェクトの値渡しなどの際、コンパイラによって暗黙的に呼び出されます。
            </span>
        </p>
        <p class="pros"></p>
        <p>
            <span>
                <span class="src">
                    Objects of copyable and movable types can be passed and returned by value,
                    which makes APIs simpler, safer, and more general.
                </span>
                コピー可能・ムーブ可能なオブジェクトは、値渡し・値戻しができるため、APIがシンプルかつ安全で、より一般的な形になります。
            </span>
            <span>
                <span class="src">
                    Unlike when passing objects
                    by pointer or reference, there's no risk of confusion over ownership,
                    lifetime, mutability, and similar issues, and no need to specify them in the
                    contract.
                </span>
                オブジェクトのポインタ渡し・参照渡しと違って、オブジェクトの所有権や寿命、可変性(mutability)、あるいはそれらに類する危険がなく、それらに関する前提条件を述べる必要もなくなります。
            </span>
            <span>
                <span class="src">
                    It also prevents non-local interactions between the client and the
                    implementation, which makes them easier to understand, maintain, and optimize by
                    the compiler.
                </span>
                また、呼び出し元と実装をつないでしまうような局所的でない相互作用も自動的に防がれます。これによって、理解しやすく、メンテナンスしやすく、コンパイラによって最適化が掛かりやすくなります。
            </span>
            <span>
                <span class="src">
                    Further, such objects can be used with generic APIs that
                    require pass-by-value, such as most containers, and they allow for additional
                    flexibility in e.g., type composition.
                </span>
                さらに、このようなオブジェクトは、多くのコンテナ型のような値渡しを要求するAPIに利用することができるようになったり、型の抱合などにおいて柔軟な扱い方ができるようになったりします。
            </span>
        </p>
        <p>
            <span>
                <span class="src">
                    Copy/move constructors and assignment operators are usually
                    easier to define correctly than alternatives
                    like <code>Clone()</code>, <code>CopyFrom()</code> or <code>Swap()</code>,
                    because they can be generated by the compiler, either implicitly or
                    with <code>= default</code>.
                </span>
                コピー・ムーブを行うコンストラクタや代入演算子は、一般に、<code>Clone()</code>, <code>CopyFrom()</code>あるいは<code>Swap()</code>といった代替的な方法に比べて、正しく定義することが容易です。これらのコンストラクタや代入演算子は暗黙的に、または明示的に<code>= default</code>と記載することで、コンパイラに生成させることができるためです。
            </span>
            <span>
                <span class="src">
                    They are concise, and ensure
                    that all data members are copied.
                </span>
                自動的に生成されるコンストラクタや代入演算子は、明瞭で、かつすべてのメンバーがコピーされることが保証されます。
            </span>
            <span>
                <span class="src">
                    Copy and move
                    constructors are also generally more efficient, because they don't
                    require heap allocation or separate initialization and assignment
                    steps, and they're eligible for optimizations such as

                    <a href="http://en.cppreference.com/w/cpp/language/copy_elision">
                        copy elision</a>.
                </span>
                また、一般的に、コピーコンストラクタやムーブコンストラクタは、効率的に動作します。これらはヒープメモリは確保せず、初期化と割り当てをまとめて行い、<a href="http://en.cppreference.com/w/cpp/language/copy_elision">copy elision</a>のような適切な最適化が行われるためです。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Move operations allow the implicit and efficient transfer of
                    resources out of rvalue objects.
                </span>
                ムーブ操作によって、右辺値オブジェクトから暗黙的かつ効率的にリソースを取り出すことが可能になります。
            </span>
            <span>
                <span class="src">
                    This allows a plainer coding style
                    in some cases.
                </span>
                これによって、よりわかりやすいコーディングスタイルを採用できる場合があります。
            </span>
        </p>
        <p class="cons"></p>
        <p>
            <span>
                <span class="src">
                    Some types do not need to be copyable, and providing copy
                    operations for such types can be confusing, nonsensical, or outright
                    incorrect.
                </span>
                型によってはコピーができることを必要としない場合や、コピー操作を提供しようとすること自体が理屈的におかしい場合もあります。
            </span>
            <span>
                <span class="src">
                    Types representing singleton objects (<code>Registerer</code>),
                    objects tied to a specific scope (<code>Cleanup</code>), or closely coupled to
                    object identity (<code>Mutex</code>) cannot be copied meaningfully.
                </span>
                たとえば、(<code>Registerer</code>のような)シングルトンのオブジェクトや、(<code>Cleanup</code>のような)そのスコープに紐付くオブジェクト、あるいは(<code>Mutex</code>のような)個別のオブジェクトと密接に繋がっているようなオブジェクトは、意味のあるコピーはできません。
            </span>
        </p>
        <p>
            <span>
                <span class="src">
                    Copy operations for base class types that are to be used
                    polymorphically are hazardous, because use of them can lead to
                    <a href="https://en.wikipedia.org/wiki/Object_slicing">object slicing</a>.
                </span>
                ポリモーフィズムを使用しているような型の基底クラスに対するコピー操作は、<a href="https://en.wikipedia.org/wiki/Object_slicing">オブジェクトのスライシング</a>を引き起こす可能性があり危険です。
            </span>
            <span>
                <span class="src">
                    Defaulted or carelessly-implemented copy operations can be incorrect, and the
                    resulting bugs can be confusing and difficult to diagnose.
                </span>
                デフォルト実装や雑に実装されたコピー操作は誤ったものとなる可能性があり、見つけるのが難しいバグを招くことがあります。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Copy constructors are invoked implicitly, which makes the
                    invocation easy to miss.
                </span>
                コピーコンストラクタは暗黙的に呼び出されるため、その呼び出しを見落としやすいです。
            </span>
            <span>
                <span class="src">
                    This may cause confusion for programmers used to
                    languages where pass-by-reference is conventional or mandatory.
                </span>
                これは、参照渡しが慣習的なプログラミング言語に馴染んだプログラマにとっての混乱ポイントになるでしょう。
            </span>
            <span>
                <span class="src">
                    It may also
                    encourage excessive copying, which can cause performance problems.
                </span>
                また、余計なコピーを助長し、パフォーマンス上の問題になることもあります。
            </span>
        </p>
        <p class="decision"></p>
        <p>
            <span>
                <span class="src">
                    Every class's public interface must make clear which copy and move
                    operations the class supports. This should usually take the form of explicitly
                    declaring and/or deleting the appropriate operations in the <code>public</code>
                    section of the declaration.
                </span>
                すべてのクラスの公開インターフェイスは、クラスがコピーやムーブのどの操作をサポートしているかを明らかにしておかなければなりません。
                これは通常、クラス宣言の<code>public</code>セクションで適切な操作を明示的に宣言するか削除するという形式で行うようにします。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Specifically, a copyable class should explicitly declare the copy
                    operations, a move-only class should explicitly declare the move operations,
                    and a non-copyable/movable class should explicitly delete the copy operations.
                </span>
                特に、コピー可能なクラスはコピー操作を明示的に宣言するようにし、ムーブ専用クラスはムーブ操作を明示的に宣言するようにし、コピーもムーブも不可なクラスはコピー操作を明示的に削除するようにします。
            </span>
            <span>
                <span class="src">
                    A
                    copyable class may also declare move operations in order to support efficient
                    moves.
                </span>
                コピー可能なクラスは、効率的なムーブをサポートするために、ムーブ操作を宣言することもできます。
            </span>
            <span>
                <span class="src">
                    Explicitly declaring or deleting all four copy/move operations is permitted,
                    but not required. If you provide a copy or move assignment operator, you
                    must also provide the corresponding constructor.
                </span>
                4つのコピー/ムーブ操作すべてを明示的に宣言または削除してもよいですが、必須ではありません。
                ただし、コピーまたはムーブ代入演算子を提供する場合は、それに対応するコンストラクタも提供しなくてはなりません。
            </span>
        </p>
<div>
<div class="src">
        <pre>class Copyable {
 public:
  Copyable(const Copyable&amp; other) = default;
  Copyable&amp; operator=(const Copyable&amp; other) = default;

  // The implicit move operations are suppressed by the declarations above.
  // You may explicitly declare move operations to support efficient moves.
};

class MoveOnly {
 public:
  MoveOnly(MoveOnly&amp;&amp; other) = default;
  MoveOnly&amp; operator=(MoveOnly&amp;&amp; other) = default;

  // The copy operations are implicitly deleted, but you can
  // spell that out explicitly if you want:
  MoveOnly(const MoveOnly&amp;) = delete;
  MoveOnly&amp; operator=(const MoveOnly&amp;) = delete;
};

class NotCopyableOrMovable {
 public:
  // Not copyable or movable
  NotCopyableOrMovable(const NotCopyableOrMovable&amp;) = delete;
  NotCopyableOrMovable&amp; operator=(const NotCopyableOrMovable&amp;)
      = delete;

  // The move operations are implicitly disabled, but you can
  // spell that out explicitly if you want:
  NotCopyableOrMovable(NotCopyableOrMovable&amp;&amp;) = delete;
  NotCopyableOrMovable&amp; operator=(NotCopyableOrMovable&amp;&amp;)
      = delete;
};
</pre>
            </div>
       <pre>class Copyable {
 public:
  Copyable(const Copyable&amp; other) = default;
  Copyable&amp; operator=(const Copyable&amp; other) = default;

  // この例では、暗黙的ムーブ操作は上の宣言により抑制されます。
  // 効率的なムーブ操作をサポートするために、明示的にムーブ操作を宣言してもOK。
};

class MoveOnly {
 public:
  MoveOnly(MoveOnly&amp;&amp; other) = default;
  MoveOnly&amp; operator=(MoveOnly&amp;&amp; other) = default;

  // この例では、コピー操作は暗黙的に削除されます。
  // ただし、望む場合は、明示的に、次のように宣言してもかまいません。
  MoveOnly(const MoveOnly&amp;) = delete;
  MoveOnly&amp; operator=(const MoveOnly&amp;) = delete;
};

class NotCopyableOrMovable {
 public:
  // コピーもムーブも不可
  NotCopyableOrMovable(const NotCopyableOrMovable&amp;) = delete;
  NotCopyableOrMovable&amp; operator=(const NotCopyableOrMovable&amp;)
      = delete;

  // この例では、ムーブ操作は暗黙的に無効になります。
  // ただし、望む場合は、明示的に、次のように宣言してもかまいません。
  NotCopyableOrMovable(NotCopyableOrMovable&amp;&amp;) = delete;
  NotCopyableOrMovable&amp; operator=(NotCopyableOrMovable&amp;&amp;)
      = delete;
};
</pre>
</div>

        <p>
            <span>
                <span class="src">
                    These declarations/deletions can be omitted only if they are obvious:
                </span>
                これらの宣言/削除は、明らかな場合にのみ省略できます。
            </span>
        </p>
        <ul>
            <li>
                <span>
                    <span class="src">
                        If the class has no <code>private</code> section, like a
                        <a href="#Structs_vs._Classes">struct</a> or an interface-only base class,
                        then the copyability/movability can be determined by the
                        copyability/movability of any public data members.
                    </span>
                    <a href="#Structs_vs._Classes">構造体</a>やインターフェイスのみの基底クラスのように、クラスに<code>private</code>セクションがない場合、コピーやムーブの可能性は、パブリックデータメンバのコピーやムーブ可能性によって決定できます。
                </span>
            </li>
            <li>
                <span>
                    <span class="src">
                        If a base class clearly isn't copyable or movable, derived classes
                        naturally won't be either.
                    </span>
                    基底クラスが明らかにコピー可能やムーブ可能でない場合、派生クラスも当然にコピー可能やムーブ可能ではありません。
                </span>
                <span>
                    <span class="src">
                        An interface-only base class that leaves these
                        operations implicit is not sufficient to make concrete subclasses clear.
                    </span>
                    基底クラスがインターフェイスのみを提供し、これらの操作について暗黙のままにしているとき、具体的なサブクラスにとって十分に明確であるということはできません。
                </span>
            </li>
            <li>
                <span>
                    <span class="src">
                        Note that if you explicitly declare or delete either the constructor or
                        assignment operation for copy, the other copy operation is not obvious and
                        must be declared or deleted.
                    </span>
                    コピーコンストラクタまたはコピー代入演算子のいずれかを明示的に宣言または削除する場合、もう一方のコピー操作も自明となるわけではないため、それらも同時に宣言または削除する必要があることに注意してください。
                </span>
                <span>
                    <span class="src">
                        Likewise for move operations.
                    </span>
                    ムーブ操作についても同様です。
                </span>
            </li>
        </ul>
        <p>
            <span>
                <span class="src">
                    A type should not be copyable/movable if the meaning of
                    copying/moving is unclear to a casual user, or if it incurs unexpected
                    costs.
                </span>
                コピー/ムーブの意味がカジュアルなユーザーにとってわかりにくい場合、または予期しないコストが発生する場合、型をコピー可能/ムーブ可能にしないでください。
            </span>
            <span>
                <span class="src">
                    Move operations for copyable types are strictly a performance
                    optimization and are a potential source of bugs and complexity, so
                    avoid defining them unless they are significantly more efficient than
                    the corresponding copy operations.
                </span>
                コピー可能な型におけるムーブ操作は、厳密にはパフォーマンスの最適化であり、潜在的にバグや複雑さの原因になります。関連するコピー操作よりもはるかに効率的に機能するというような場合を除いて、ムーブ操作を定義するのは避けてください。
            </span>
            <span>
                <span class="src">
                    If your type provides copy operations, it is
                    recommended that you design your class so that the default implementation of
                    those operations is correct.
                </span>
                新しい型でコピー操作を提供しようとする際には、コンパイラが生成するデフォルト実装が、そのまま正しい動作となるように型を設計することをおすすめします。
            </span>
            <span>
                <span class="src">
                    Remember to review the correctness of any
                    defaulted operations as you would any other code.
                </span>
                その際、デフォルト実装でコピーが行われることの正しさについて、他のコードと同じように、レビューするのも忘れないようにしましょう。
            </span>
        </p>
        <p>
            <span>
                <span class="src">
                    To eliminate the risk of slicing, prefer to make base classes abstract,
                    by making their constructors protected, by declaring their destructors protected,
                    or by giving them one or more pure virtual member functions.
                </span>
                スライシングのリスクを排除するために、基底クラスは抽象クラスとなるようにしましょう。そのためには、コンストラクタを protected にするか、デストラクタを protected 宣言するか、1つ以上の純粋な仮想メンバ関数を与えるようにします。
            </span>
            <span>
                <span class="src">
                    Prefer to avoid
                    deriving from concrete classes.
                </span>
                具象クラスからの派生を避けましょう。
            </span>
        </p>

        <h3 id="Structs_vs._Classes">
            <span title="Structs vs. Classes">構造体かクラスか</span>
        </h3>

        <p>
            <span>
                <span class="src">
                    Use a <code>struct</code> only for passive objects that
                    carry data; everything else is a <code>class</code>.
                </span>
                <code>struct</code>はデータを運ぶための受動的なオブジェクトにのみ使用し、それ以外は<code>class</code>を使用してください。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    The <code>struct</code> and <code>class</code>
                    keywords behave almost identically in C++.
                </span>
                <code>struct</code>と<code>class</code>は、C++においてほとんど同じです。
            </span>
            <span>
                <span class="src">
                    We add our own
                    semantic meanings to each keyword, so you should use the
                    appropriate keyword for the data-type you're
                    defining.
                </span>
                我々は、それぞれのキーワードに独自の意味づけをしています。そのため、定義されるデータの種類に応じて適切なキーワードを用いなくてはなりません。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    <code>structs</code> should be used for passive objects that carry
                    data, and may have associated constants.
                </span>
                構造体(<code>struct</code>)はデータと関連する定数を運ぶ、受動的なオブジェクトに使用してください。
            </span>
            <span>
                <span class="src">
                    All fields must be public.
                </span>
                すべてのフィールドはパブリックでなければなりません。
            </span>
            <span>
                <span class="src">
                    The
                    struct must not have invariants that imply relationships between
                    different fields, since direct user access to those fields may
                    break those invariants.
                </span>
                フィールド間の暗黙的な不変条件を持たせてはいけません(ユーザーは直接フィールドにアクセスするため、そのような条件は崩れてしまうかもしれません)。
            </span>
            <span>
                <span class="src">
                    Constructors, destructors, and helper methods may
                    be present; however, these methods must not require or enforce any
                    invariants.
                </span>
                コンストラクタやデストラクタ、ヘルパメソッドを持つことはかまいません。しかし、それらのメンバ関数が不変条件を要求したり強制したりしてはいけません。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    If more functionality or invariants are required, a
                    <code>class</code> is more appropriate.
                </span>
                それ以上の機能性や不変条件が必要な場合は、クラス(<code>class</code>)の方が適切です。
            </span>
            <span>
                <span class="src">
                    If in doubt, make
                    it a <code>class</code>.
                </span>
                迷ったらクラスにしましょう。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    For consistency with STL, you can use
                    <code>struct</code> instead of <code>class</code> for
                    stateless types, such as traits,
                    <a href="#Template_metaprogramming">template metafunctions</a>,
                    and some functors.
                </span>
                STLとの一貫性を持たせるため、traitsや<a href="#Template_metaprogramming">テンプレートメタ関数</a>、いくつかの関数オブジェクトなどの、状態を持たない型については、<code>class</code>のかわりに<code>struct</code>を使ってもかまいません。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Note that member variables in structs and classes have
                    <a href="#Variable_Names">different naming rules</a>.
                </span>
                構造体とクラスでは、<a href="#Variable_Names">命名規則が異なる</a>ことに注意してください。
            </span>
        </p>

        <h3 id="Structs_vs._Tuples"><span title="Structs vs. Pairs and Tuples">構造体か 値ペア/タプルか</span></h3>
 
        <p>
            <span>
                <span class="src">
                    Prefer to use a <code>struct</code> instead of a pair or a
                    tuple whenever the elements can have meaningful names.
                </span>
                要素に意味のある名前を付けることができる場合は、値ペアまたはタプルを使うのではなく、常に<code>struct</code>を使いましょう。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    While using pairs and tuples can avoid the need to define a custom type,
                    potentially saving work when <em>writing</em> code, a meaningful field
                    name will almost always be much clearer when <em>reading</em> code than
                    <code>.first</code>, <code>.second</code>, or <code>std::get&lt;X&gt;</code>.
                </span>
                値ペアやタプルを使用すると、カスタム型を定義する必要がなくなり、コードを<em>書く</em>ときの作業量を節約できるかもしれません。しかし、コードを<em>読む</em>ときのことを考えれば、ほとんど、ほぼ常に、<code>.first</code>、<code>.second</code>や<code>std::get&lt;X&gt;</code>よりも、意味のあるフィールド名がつけられていた方がずっとわかりやすいはずです。
            </span>

            <span>
                <span class="src">
                    While C++14's introduction of <code>std::get&lt;Type&gt;</code> to access a
                    tuple element by type rather than index (when the type is unique) can
                    sometimes partially mitigate this, a field name is usually substantially
                    clearer and more informative than a type.
                </span>
                型が一意である場合には、C++14で導入された<code>std::get&lt;Type&gt;</code>によって、インデックスではなく型名によってタプルの要素にアクセスできるので、部分的には軽減される場合もありますが、一般的には、フィールド名の方が、型名よりもずっと明確で情報量も多いです。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Pairs and tuples may be appropriate in generic code where there are not
                    specific meanings for the elements of the pair or tuple.
                </span>
                値ペアとタプルは、その要素に特定の意味がない、またはつけられない、汎用的なコードで適切な場合があります。
            </span>
            <span>
                <span class="src">
                    Their use may
                    also be required in order to interoperate with existing code or APIs.
                </span>
                あるいは、既存のコードやAPIとの相互運用には必要となる場合もあるかもしれません。
            </span>
        </p>

        <a id="Multiple_Inheritance"></a>
        <h3 id="Inheritance">
            <span title="Inheritance">継承</span>
        </h3>

        <p>
            <span>
                <span class="src">
                    Composition is often more appropriate than inheritance.
                </span>
                しばしば、抱合(composition)の方が、継承よりも適切な場合があります。
            </span>
            <span>
                <span class="src">
                    When using inheritance, make it <code>public</code>.
                </span>
                継承を使うのであれば、必ず<code>public</code>にします。
            </span>
        </p>

        <p class="definition"></p>
        <p>
            <span>
                <span class="src">
                    When a sub-class
                    inherits from a base class, it includes the definitions
                    of all the data and operations that the base class
                    defines.
                </span>
                派生クラスが基底クラスを継承するとき、派生クラスは基底クラスで定義されているすべてのデータと操作の定義を含むようになります。
            </span>
            <span>
                <span class="src">
                    "Interface inheritance" is inheritance from a
                    pure abstract base class (one with no state or defined
                    methods); all other inheritance is "implementation
                    inheritance".
                </span>
                「インターフェースの継承」は、純粋抽象基底クラス(状態やメソッドの定義を持たないクラス)からの継承のことを言い、それ以外の継承はすべて「実装の継承」です。
            </span>
        </p>
        <p class="pros"></p>
        <p>
            <span>
                <span class="src">
                    Implementation inheritance reduces code size by re-using
                    the base class code as it specializes an existing type.
                </span>
                実装の継承は、基底クラスのコードを再利用するため、コードのサイズが小さくなります。
            </span>
            <span>
                <span class="src">
                    Because inheritance is a compile-time declaration, you
                    and the compiler can understand the operation and detect
                    errors.
                </span>
                継承はコンパイル時の宣言であるため、コンパイラは操作を理解し、エラーを検出できます。
            </span>
            <span>
                <span class="src">
                    Interface inheritance can be used to
                    programmatically enforce that a class expose a particular
                    API.
                </span>
                インターフェースの継承では、プログラム的に、クラスが特定のAPIを公開することを強制させることができます。
            </span>
            <span>
                <span class="src">
                    Again, the compiler can detect errors, in this case,
                    when a class does not define a necessary method of the
                    API.
                </span>
                同様に、コンパイラは、クラスが必要なメソッドを定義していない場合に、それをエラーとして検出できます。
            </span>
        </p>
        <p class="cons"></p>
        <p>
            <span>
                <span class="src">
                    For implementation inheritance, because the code
                    implementing a sub-class is spread between the base and
                    the sub-class, it can be more difficult to understand an
                    implementation.
                </span>
                実装の継承においては、派生クラスの実装コードが基底クラスと派生クラスとの間に分離するため、実装を理解するのをより難しくするかもしれません。
            </span>
            <span>
                <span class="src">
                    The sub-class cannot override functions
                    that are not virtual, so the sub-class cannot change
                    implementation.
                </span>
                派生クラスは、基底クラスでvirtualとして宣言されていないものをオーバーライドすることはできず、実装を変えることはできません。
            </span>
        </p>
        <p>
            <span>
                <span class="src">
                    Multiple inheritance is especially problematic, because
                    it often imposes a higher performance overhead (in fact,
                    the performance drop from single inheritance to multiple
                    inheritance can often be greater than the performance
                    drop from ordinary to virtual dispatch), and because
                    it risks leading to "diamond" inheritance patterns,
                    which are prone to ambiguity, confusion, and outright bugs.
                </span>
                多重継承は特に問題を引き起こしやすいです。多重継承はパフォーマンス上のオーバーヘッドが大きくなることがあります(実際、多重継承によって発生するパフォーマンス低下は、通常の呼び出しを仮想ディスパッチにするよりも大きくなりがちです)。また、曖昧、混乱、あからさまなバグを引き起こしがちな、ダイヤモンド継承パターンに繋がる危険性も内包しています。
            </span>
        </p>
        <p class="decision"></p>

        <p>
            <span>
                <span class="src">
                    All inheritance should be <code>public</code>.
                </span>
                すべての継承は<code>public</code>で行いましょう。
            </span>
            <span>
                <span class="src">
                    If you
                    want to do private inheritance, you should be including
                    an instance of the base class as a member instead.
                </span>
                privateな継承を行いたい場合は、継承のかわりに基底クラスのインスタンスをメンバーとして持つようにしましょう。
            </span>
            <span>
                <span class="src">
                    You may use
                    <code>final</code> on classes when you don't intend to support using
                    them as base classes.
                </span>
                基底クラスとしての使用されることを想定しないクラスには<code>final</code>をつけるとよいでしょう。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Do not overuse implementation inheritance.
                </span>
                実装の継承を使いすぎないようにしましょう。
            </span>
            <span>
                <span class="src">
                    Composition
                    is often more appropriate.
                </span>
                抱合(composition)の方が適切な場合もしばしばあります。
            </span>
            <span>
                <span class="src">
                    Try to restrict use of
                    inheritance to the "is-a" case: <code>Bar</code>
                    subclasses <code>Foo</code> if it can reasonably be said
                    that <code>Bar</code> "is a kind of"
                    <code>Foo</code>.
                </span>
                継承は「is-a」関係が成立する場合のみ使うように制限してみてください。たとえば<code>Foo</code>を継承して<code>Bar</code>を作ってよいのは、理屈の上で「<code>Bar</code>は<code>Foo</code>の一種」といえる時だけです。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Limit the use of <code>protected</code> to those
                    member functions that might need to be accessed from
                    subclasses.
                </span>
                <code>protected</code>は、派生クラスからアクセスが必要となるメンバ関数だけにとどめてください。
            </span>
            <span>
                <span class="src">
                    Note that <a href="#Access_Control">
                        data
                        members should be private
                    </a>.
                </span>
                <a href="#Access_Control">データメンバはすべてprivate</a>としてください。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Explicitly annotate overrides of virtual functions
                    or virtual destructors with exactly one of an <code>override</code>
                    or (less frequently) <code>final</code> specifier.
                </span>
                オーバーライドする仮想関数や仮想デストラクタには、<code>override</code>あるいは<code>final</code>指定子のいずれか1つをつけて、オーバーライドすることを明示してください。
            </span>
            <span>
                <span class="src">
                    Do not use <code>virtual</code> when declaring an override.
                </span>
                オーバーライドを宣言するために<code>virtual</code>を使ってはいけません。
            </span>
            <span>
                <span class="src">
                    Rationale: A function or destructor marked
                    <code>override</code> or <code>final</code> that is
                    not an override of a base class virtual function will
                    not compile, and this helps catch common errors.
                </span>
                この根拠は、<code>override</code>か<code>final</code>でマークされた関数やデスクトラクタは、基底クラスの仮想関数をオーバーライドしていないときにコンパイルエラーとなるため、問題に気づきやすくできるからです。
            </span>
            <span>
                <span class="src">
                    The
                    specifiers serve as documentation; if no specifier is
                    present, the reader has to check all ancestors of the
                    class in question to determine if the function or
                    destructor is virtual or not.
                </span>
                これらの指定子はドキュメントの役割も果たします。もし、指定子がない場合、コードの読者は関数やデストラクタが仮想なのかそうでないのかを解決するために、すべての継承元をたどって調べなくてはなりません。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Multiple inheritance is permitted, but multiple <em>implementation</em>
                    inheritance is strongly discouraged.
                </span>
                多重継承は禁止されていません。しかし、<em>実装の</em>多重継承は、強く非推奨です。
            </span>
        </p>

        <h3 id="Operator_Overloading">
            <span title="Operator Overloading">演算子のオーバーロード</span>
        </h3>

        <p>
            <span>
                <span class="src">
                    Overload operators judiciously.
                </span>
                演算子のオーバーロードは慎重に行わなくてはなりません。
            </span>
            <span>
                <span class="src">
                    Do not use user-defined literals.
                </span>
                ユーザー定義のリテラルは使用してはいけません。
            </span>
        </p>

        <p class="definition"></p>
        <p>
            <span>
                <span class="src">
                    C++ permits user code to
                    <a href="http://en.cppreference.com/w/cpp/language/operators">
                        declare
                        overloaded versions of the built-in operators
                    </a> using the
                    <code>operator</code> keyword, so long as one of the parameters
                    is a user-defined type.
                </span>
                C++では、<code>operator</code>キーワードを使うことで、ユーザー定義の型を引数とした<a href="http://en.cppreference.com/w/cpp/language/operators">組み込み演算子のオーバーロードを宣言</a>することができます。
            </span>
            <span>
                <span class="src">
                    The <code>operator</code> keyword also
                    permits user code to define new kinds of literals using
                    <code>operator""</code>, and to define type-conversion functions
                    such as <code>operator bool()</code>.
                </span>
                また、<code>operator</code>キーワードは、<code>operator""</code>を用いることで新しいリテラルを定義することもできます。<code>operator bool()</code>など、型変換を定義することもできます。
            </span>
        </p>
        <p class="pros"></p>
        <p>
            <span>
                <span class="src">
                    Operator overloading can make code more concise and
                    intuitive by enabling user-defined types to behave the same
                    as built-in types.
                </span>
                演算子のオーバーロードを用いると、ユーザー定義の型に組み込み型と同様の振る舞いをさせることができるようになるため、コードを簡潔で直感的にすることができます。
            </span>
            <span>
                <span class="src">
                    Overloaded operators are the idiomatic names
                    for certain operations (e.g., <code>==</code>, <code>&lt;</code>,
                    <code>=</code>, and <code>&lt;&lt;</code>), and adhering to
                    those conventions can make user-defined types more readable
                    and enable them to interoperate with libraries that expect
                    those names.
                </span>
                オーバーロードされた演算子は、よくある操作に対する慣例的な見た目を持ちます(<code>==</code>や<code>&lt;</code>、<code>=</code>、<code>&lt;&lt;</code>など)。これらの慣例に従うことは、ユーザー定義の型に対する可読性を向上させ、それらの演算子を期待しているライブラリとの相互運用性を高めることができます。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    User-defined literals are a very concise notation for
                    creating objects of user-defined types.
                </span>
                ユーザー定義のリテラルは、ユーザー定義のオブジェクトを生成する非常に簡潔な表記方法です。
            </span>
        </p>
        <p class="cons"></p>
        <ul>
            <li>
                <span>
                    <span class="src">
                        Providing a correct, consistent, and unsurprising
                        set of operator overloads requires some care, and failure
                        to do so can lead to confusion and bugs.
                    </span>
                    正しく、一貫性を持つ、よくある形の演算子の組を提供するためには、細やかな注意が必要となり、失敗すると、混乱やバグを引き起こしかねません。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        Overuse of operators can lead to obfuscated code,
                        particularly if the overloaded operator's semantics
                        don't follow convention.
                    </span>
                    演算子の過剰な使用、特に、慣例に従わないような意味を演算子に持たせた場合、コードがわかりにくくなります。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        The hazards of function overloading apply just as
                        much to operator overloading, if not more so.
                    </span>
                    関数のオーバーロードを行う場合と同様の危険性が、演算子のオーバーロードを行う場合にも当てはまります。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        Operator overloads can fool our intuition into
                        thinking that expensive operations are cheap, built-in
                        operations.
                    </span>
                    演算子のオーバーロードは、その見た目に反して本来高コストな処理を、組み込み演算子のように低コストに見せかけてしまうことができてしまいます。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        Finding the call sites for overloaded operators may
                        require a search tool that's aware of C++ syntax, rather
                        than e.g., grep.
                    </span>
                    オーバーロードされた演算子の呼び出し元を検索しようとする場合、grepでは要をなさず、C++の文法を理解するツールを使用する必要があります。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        If you get the argument type of an overloaded operator
                        wrong, you may get a different overload rather than a
                        compiler error.
                    </span>
                    オーバーロードされた演算子の引数の型を間違えたとき、コンパイルエラーにならずに、別の演算子の呼び出しに解決されてしまうことがあります。
                </span>
                <span>
                    <span class="src">
                        For example, <code>foo &lt; bar</code>
                        may do one thing, while <code>&amp;foo &lt; &amp;bar</code>
                        does something totally different.
                    </span>
                    たとえば、<code>foo &lt; bar</code>と<code>&amp;foo &lt; &amp;bar</code>はまったく意味の異なる演算です。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        Certain operator overloads are inherently hazardous.
                    </span>
                    演算子の中には、オーバーロードすること自体に潜在的な危険性をはらんでいるものがあります。
                </span>
                <span>
                    <span class="src">
                        Overloading unary <code>&amp;</code> can cause the same
                        code to have different meanings depending on whether
                        the overload declaration is visible.
                    </span>
                    単項演算子<code>&amp;</code>のオーバーロードは、その宣言が見えているかどうかで、意味が変わってしまうことになります。
                </span>
                <span>
                    <span class="src">
                        Overloads of
                        <code>&amp;&amp;</code>, <code>||</code>, and <code>,</code>
                        (comma) cannot match the evaluation-order semantics of the
                        built-in operators.
                    </span>
                    また、<code>&amp;&amp;</code>, <code>||</code>, and
                    <code>,</code>(カンマ演算子)をオーバーロードした場合、組み込み演算子で定められている式の評価順序と一致させることはできません。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        Operators are often defined outside the class,
                        so there's a risk of different files introducing
                        different definitions of the same operator.
                    </span>
                    演算子はしばしばクラスの外で定義されますが、その場合、異なるファイルにある異なる定義を引き込んでしまう危険性があります。
                </span>
                <span>
                    <span class="src">
                        If both
                        definitions are linked into the same binary, this results
                        in undefined behavior, which can manifest as subtle
                        run-time bugs.
                    </span>
                    同じバイナリ内でそれらの実装の異なる演算子の両方がリンクされてしまった場合、未定義の動作を引き起こし、細かい実行時バグとなるでしょう。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        User-defined literals (UDLs) allow the creation of new
                        syntactic forms that are unfamiliar even to experienced C++
                        programmers, such as <code>"Hello World"sv</code> as a
                        shorthand for <code>std::string_view("Hello World")</code>.
                        Existing notations are clearer, though less terse.
                    </span>
                    ユーザー定義のリテラル(UDL)は、文法的に新しい形式を生み出します。しかし、それらは十分経験を積んだC++プログラマにとっても親しみの薄いものです。
                    (例えば<code>std::string_view("Hello World")</code>の略記としての<code>"Hello World"sv</code>など)
                    従来からの表記は、簡潔でこそありませんが、より明瞭です。
                </span>
            </li>
            <li>
                <span>
                    <span class="src">
                        Because they can't be namespace-qualified, uses of UDLs also require
                        use of either using-directives (which <a href="#Namespaces">we ban</a>) or
                        using-declarations (which <a href="#Aliases">we ban in header files</a> except
                        when the imported names are part of the interface exposed by the header
                        file in question).
                    </span>
                    UDLは名前空間修飾ができないので、UDLを使うには、usingディレクティブ(<a href="#Namespaces">名前空間の章で禁止</a>)か using宣言(<a href="#Aliases">ヘッダーファイルでは禁止</a>。ただし、取り込んだ名前が当該ヘッダーファイルで公開されるインターフェースの一部である場合を除く)のいずれかを使う必要があります。
                </span>
                <span>
                    <span class="src">
                        Given that header files would have to avoid UDL
                        suffixes, we prefer to avoid having conventions for literals differ
                        between header files and source files.
                    </span>
                    ヘッダーファイルでUDL接尾辞を避ける以上、ヘッダーファイルとソースファイルとでリテラルに関する規約を別々にしなくてはなりませんが、それも避けたいです。
                </span>
            </li>
        </ul>

        <p class="decision"></p>
        <p>
            <span>
                <span class="src">
                    Define overloaded operators only if their meaning is
                    obvious, unsurprising, and consistent with the corresponding
                    built-in operators.
                </span>
                演算子のオーバーロードを定義できるのは、意味が明らかであり、動作を予測可能であり、かつ、組み込み演算子との一貫性が保てる場合のみに限定します。
            </span>
            <span>
                <span class="src">
                    For example, use <code>|</code> as a
                    bitwise- or logical-or, not as a shell-style pipe.
                </span>
                たとえば、<code>|</code>は、ビット和か論理和の意味でのみ使い、シェルでいうパイプのような意味では使いません。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Define operators only on your own types.
                </span>
                演算子は自分の型に対するもののみ定義してください。
            </span>
            <span>
                <span class="src">
                    More precisely,
                    define them in the same headers, .cc files, and namespaces
                    as the types they operate on.
                </span>
                より厳密には、それらは型と同じヘッダーか.ccファイル、そして型と同じ名前空間の中で定義してください。
            </span>
            <span>
                <span class="src">
                    That way, the operators are available
                    wherever the type is, minimizing the risk of multiple
                    definitions.
                </span>
                そうすることで、型が利用可能なところでは演算子も利用できるようになり、演算子の多重定義に関するリスクを最小限にとどめることができます。
            </span>
            <span>
                <span class="src">
                    If possible, avoid defining operators as templates,
                    because they must satisfy this rule for any possible template
                    arguments.
                </span>
                可能であれば、演算子をテンプレートとして定義するのは避けてください。テンプレートとして宣言された演算子は、取り得る限りすべてのテンプレート引数において、ここで述べているルールを満たさなくてはなりません。
            </span>
            <span>
                <span class="src">
                    If you define an operator, also define
                    any related operators that make sense, and make sure they
                    are defined consistently.
                </span>
                ある演算子を定義する場合、関連する演算子も定義し、必ず一貫性を持たせるようにしてください。
            </span>
            <span>
                <span class="src">
                    For example, if you overload
                    <code>&lt;</code>, overload all the comparison operators,
                    and make sure <code>&lt;</code> and <code>&gt;</code> never
                    return true for the same arguments.
                </span>
                たとえば、<code>&lt;</code>をオーバーロードしたのであれば、すべての比較演算子をオーバーロードし、ある引数の組に対する比較演算<code>&lt;</code>と<code>&gt;</code>の結果が両方ともtrueになるようなことがないようにしてください。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Prefer to define non-modifying binary operators as
                    non-member functions.
                </span>
                引数に対して変更を伴わない二項演算子は、非メンバ関数として定義されることが好ましいです。
            </span>
            <span>
                <span class="src">
                    If a binary operator is defined as a
                    class member, implicit conversions will apply to the
                    right-hand argument, but not the left-hand one.
                </span>
                仮に二項演算子がクラスのメンバとして定義された場合、演算子の右辺については暗黙的型変換を適用できますが、左辺には適用できなくなってしまいます。
            </span>
            <span>
                <span class="src">
                    It will
                    confuse your users if <code>a &lt; b</code> compiles but
                    <code>b &lt; a</code> doesn't.
                </span>
                <code>a &lt; b</code>はコンパイルできるけど<code>b &lt; a</code>はコンパイルできないというような状況は、ユーザーを混乱させることになります。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Don't go out of your way to avoid defining operator
                    overloads.
                </span>
                演算子のオーバーロードをわざわざ避けるようなことはしないでください。
            </span>
            <span>
                <span class="src">
                    For example, prefer to define <code>==</code>,
                    <code>=</code>, and <code>&lt;&lt;</code>, rather than
                    <code>Equals()</code>, <code>CopyFrom()</code>, and
                    <code>PrintTo()</code>.
                </span>
                <code>Equals()</code>や<code>CopyFrom()</code>、<code>PrintTo()</code>などを実装するよりも、<code>==</code>、<code>=</code>、<code>&lt;&lt;</code>を定義するようにしましょう。
            </span>
            <span>
                <span class="src">
                    Conversely, don't define
                    operator overloads just because other libraries expect
                    them.
                </span>
                逆に、他のライブラリを使いたいがためだけに演算子をオーバーロードすることは避けてください。
            </span>
            <span>
                <span class="src">
                    For example, if your type doesn't have a natural
                    ordering, but you want to store it in a <code>std::set</code>,
                    use a custom comparator rather than overloading
                    <code>&lt;</code>.
                </span>
                たとえば、型の値同士で順序づけできない、<code>std::set</code>に入れたいがためだけに<code>&lt;</code>をオーバーロードしてはなりません。このような型を<code>std::set</code>に入れたい場合は、カスタムの比較子(comparator)を使うようにします。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Do not overload <code>&amp;&amp;</code>, <code>||</code>,
                    <code>,</code> (comma), or unary <code>&amp;</code>.
                </span>
                演算子<code>&amp;&amp;</code>と<code>||</code>と<code>,</code>
                (カンマ演算子)、単項演算子<code>&amp;</code>はオーバーロードをしてはなりません。
            </span>
            <span>
                <span class="src">
                    Do not overload
                    <code>operator""</code>, i.e., do not introduce user-defined
                    literals.
                </span>
                また、<code>operator""</code>のオーバーロードもしてはいけません。つまり、ユーザー定義リテラルを導入してはなりません。
            </span>
            <span>
                <span class="src">
                    Do not use any such literals provided by others
                    (including the standard library).
                </span>
                標準ライブラリも含めて、他者から提供されるいかなるリテラル演算子も使用してはなりません。
            </span>
        </p>

        <p>
            <span>
                <span class="src">
                    Type conversion operators are covered in the section on
                    <a href="#Implicit_Conversions">implicit conversions</a>.
                </span>
                型変換演算子については<a href="#Implicit_Conversions">暗黙的型変換</a>のセクションでカバーします。
            </span>
            <span>
                <span class="src">
                    The <code>=</code> operator is covered in the section on
                    <a href="#Copy_Constructors">copy constructors</a>.
                </span>
                <code>=</code>演算子は<a href="#Copy_Constructors">コピーコンストラクタ</a>のセクションでカバーします。
            </span>
            <span>
                <span class="src">
                    Overloading
                    <code>&lt;&lt;</code> for use with streams is covered in the
                    section on <a href="#Streams">streams</a>.
                </span>
                <code>&lt;&lt;</code>をストリーム用途で使うオーバーロードについては、<a href="#Streams">ストリーム</a>のセクションでカバーします。
            </span>
            <span>
                <span class="src">
                    See also the rules on
                    <a href="#Function_Overloading">function overloading</a>, which
                    apply to operator overloading as well.
                </span>
                そのほか、演算子のオーバーロードは<a href="#Function_Overloading">関数のオーバーロード</a>にあるルールも同様に適用されますので、あわせてそちらも参照してください。
            </span>
        </p>


    <h3 id="Access_Control">
        <span title="Access Control">アクセス制限</span>
    </h3>

    <p>
        <span>
            <span class="src">
                Make classes' data members <code>private</code>, unless they are
                <a href="#Constant_Names">constants</a>.
            </span>
            クラスのデータメンバは<a href="#Constant_Names">定数</a>を除いて<code>private</code>にします。
        </span>
        <span>
            <span class="src">
                This simplifies reasoning about invariants, at the cost
                of some easy boilerplate in the form of accessors (usually <code>const</code>) if necessary.
            </span>
            これによって、アクセッサ(普通は<code>const</code>)の実装こそ必要になりますが、それを差し置いても、不変条件の議論の面で、簡潔になるメリットがあります。
        </span>
    </p>
    <p>
        <span>
            <span class="src">
                For technical
                reasons, we allow data members of a test fixture class defined in a .cc file to
                be <code>protected</code> when using
                <a href="https://github.com/google/googletest">
                    Google
                    Test
                </a>).
            </span>
            <a href="https://github.com/google/googletest">Google Test</a>を使う場合、
            技術的な理由により、.ccファイル内で定義されたテスト用のクラスのデータメンバは<code>protected</code>であってもよいものとします。
        </span>
        <span>
            <span class="src">
                If a test fixture class is defined outside of the .cc file it is used in, for example in a .h file,
                make data members <code>private</code>.
            </span>
            ただし、テストフィクスチャクラスが、そのクラスを利用する .cc ファイル外で定義される場合(たとえば .h ファイル内)は、データメンバは<code>private</code>にしてください。
        </span>
    </p>
    <h3 id="Declaration_Order">
        <span title="Declaration Order">宣言の順序</span>
    </h3>

    <p>
        <span>
            <span class="src">
                Group similar declarations together, placing public parts
                earlier.
            </span>
            似ている宣言は1つにまとめ、パブリックな部分を先におきます。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                A class definition should usually start with a
                <code>public:</code> section, followed by
                <code>protected:</code>, then <code>private:</code>.
            </span>
            クラスの定義は、通常は<code>public:</code>セクションから始め、<code>protected:</code>、<code>private:</code>と続けます。
        </span>
        <span>
            <span class="src">
                Omit
                sections that would be empty.
            </span>
            空になるセクションは省略してください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Within each section, prefer grouping similar
                kinds of declarations together, and prefer the
                following order:
            </span>
            各セクションにおいて、似た宣言は1カ所にまとるようにしましょう。また、以下の順となるようにしましょう。
        </span>
    </p>
    <ol>
        <li>
            <span>
                <span class="src">
                    Types and type aliases (<code>typedef</code>, <code>using</code>,
                    <code>enum</code>, nested structs and classes, and <code>friend</code> types)
                </span>
                型と型エイリアス (<code>typedef</code>, <code>using</code>,
                <code>enum</code>, ネストされた構造体とクラス, <code>friend</code> 型)
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Static constants
                </span>
                静的定数
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Factory functions
                </span>
                ファクトリ関数
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Constructors and assignment operators
                </span>
                コンストラクタと代入演算子
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Destructor
                </span>
                デストラクタ
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    All other functions (<code>static</code> and non-<code>static</code> member
                    functions, and <code>friend</code> functions)
                </span>
                その他すべての関数 (<code>static</code> と非<code>static</code> メンバ関数、<code>friend</code>関数)
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Data members (static and non-static)
                </span>
                データメンバ(静的と非静的)
            </span>
        </li>
    </ol>

    <p>
        <span>
            <span class="src">
                Do not put large method definitions inline in the
                class definition.
            </span>
            クラス定義の中では、大きなメソッドの定義をインラインで行わないでください。
        </span>
        <span>
            <span class="src">
                Usually, only trivial or
                performance-critical, and very short, methods may be
                defined inline.
            </span>
            通常は、ささいな関数、パフォーマンス的に重要な関数、非常に短い関数のみがインラインで定義されます。
        </span>
        <span>
            <span class="src">
                See <a href="#Inline_Functions">
                    Inline
                    Functions
                </a> for more details.
            </span>
            詳細は<a href="#Inline_Functions">インライン関数</a>で述べます。
        </span>
    </p>
    <h2 id="Functions">
        <span title="Functions">関数</span>
    </h2>

    <a id="Function_Parameter_Ordering"></a>
    <a id="Output_Parameters"></a>
    <h3 id="Inputs_and_Outputs">
        <span title="Inputs and Outputs">入力と出力</span>
    </h3>

    <p>
        <span>
            <span class="src">
                The output of a C++ function is naturally provided via
                a return value and sometimes via output parameters (or in/out parameters).
            </span>
            C++関数の出力は、通常は戻り値で与えられますが、しばしば出力用(もしくは入出力用)の引数も使われます。
        </span>

    </p>

    <p>
        <span>
            <span class="src">
                Prefer using return values over output parameters: they
                improve readability, and often provide the same or better
                performance.
            </span>
            出力用引数よりも戻り値を使用しましょう。
            可読性が向上し、同等以上のパフォーマンスが得られます。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Prefer to return by value or, failing that, return by reference.
            </span>
            できるだけ値返しを使用し、無理であれば参照返しを使いましょう。
        </span>
        <span>
            <span class="src">
                Avoid returning a pointer unless it can be null.
            </span>
            ポインタ返しは、ヌルを取りうる場合以外は避けましょう。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Parameters are either inputs to the function, outputs from the
                function, or both.
            </span>
            引数は、関数への入力用、関数からの出力用、あるいは入出力の両方のいずれかです。
        </span>
        <span>
            <span class="src">
                Non-optional input parameters should usually be values
                or <code>const</code> references, while non-optional output and
                input/output parameters should usually be references (which cannot be null).
            </span>
            必須の入力用引数は、通常、値渡しか<code>const</code>参照渡しとし、必須の出力用・入出力用の引数は非<code>const</code>参照渡し（nullは不可）とします。
        </span>
        <span>
            <span class="src">
                Generally, use <code>std::optional</code> to represent optional by-value
                inputs, and use a <code>const</code> pointer when the non-optional form would
                have used a reference.
            </span>
            一般的に、必須でない入力には値渡しの<code>std::optional</code>か、(仮に必須だったとしたら参照を使うという場面では、)<code>const</code>ポインタを使います。
        </span>
        <span>
            <span class="src">
                Use non-<code>const</code> pointers to represent
                optional outputs and optional input/output parameters.
            </span>
            必須でない出力や必須でない入出力には、非<code>const</code>ポインタを使用します。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Avoid defining functions that require a <code>const</code> reference parameter
                to outlive the call, because <code>const</code> reference parameters bind
                to temporaries.
            </span>
            <code>const</code>参照引数が呼び出し後も存続していることを要求するような関数を定義してはいけません。<code>const</code>参照引数には一時オブジェクトにも紐づくことがあるためです。
        </span>

        <span>
            <span class="src">
                Instead, find a way to eliminate the lifetime requirement
                (for example, by copying the parameter), or pass it by <code>const</code>
                pointer and document the lifetime and non-null requirements.
            </span>
            かわりに、その寿命が存続していなくてもよい方法を探す(例えば引数をコピーするなど)か、
            もしくはその引数を<code>const</code>ポインタ渡しとして、寿命と非nullに関する要件をドキュメントにします。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                When ordering function parameters, put all input-only
                parameters before any output parameters.
            </span>
            引数の順番を決めるときは、すべての入力専用引数を、いかなる出力引数よりも前に配置します。
        </span>

        <span>
            <span class="src">
                In particular,
                do not add new parameters to the end of the function just
                because they are new; place new input-only parameters before
                the output parameters.
            </span>
            特に、関数に新しい引数を追加するとき、新しいという理由だけで最後に追加することは避け、入力専用引数は出力引数よりも前に来るようにしましょう。
        </span>

        <span>
            <span class="src">
                This is not a hard-and-fast rule.
            </span>
            これは絶対のルールではありません。
        </span>

        <span>
            <span class="src">
                Parameters that
                are both input and output muddy the waters, and, as always,
                consistency with related functions may require you to bend the rule.
            </span>
            入力と出力の両方の役割を持つ引数は、明確な線引きはできません。
            また、関連する関数との一貫性を保つためにはこのルールを曲げる必要があるかもしれません。
        </span>

        <span>
            <span class="src">
                Variadic functions may also require unusual parameter ordering.
            </span>
            可変長引数関数もまた、通常とは異なる引数の順序を必要とするでしょう。
        </span>

    </p>

    <h3 id="Write_Short_Functions">
        <span title="Write Short Functions">関数は短く</span>
    </h3>

    <p>
        <span>
            <span class="src">
                Prefer small and focused functions.
            </span>
            関数は、短く、焦点を絞ったものにしましょう。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                We recognize that long functions are sometimes
                appropriate, so no hard limit is placed on functions
                length.
            </span>
            時には長い関数の方が適切なこともあるため、関数の長さに関する固定の限界値は定めません。
        </span>
        <span>
            <span class="src">
                If a function exceeds about 40 lines, think about
                whether it can be broken up without harming the structure
                of the program.
            </span>
            だいたい40行程度を超えるようであれば、プログラムの構造を破壊することなく関数を分割できないか考えてみてください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Even if your long function works perfectly now,
                someone modifying it in a few months may add new
                behavior.
            </span>
            長い関数が、現時点では完璧に動いていたとしても、1～2ヶ月後に誰かがそれを変更し、新しい動作を足すかもしれません。
        </span>
        <span>
            <span class="src">
                This could result in bugs that are hard to
                find.
            </span>
            その結果として見つけるのが困難なバグを引き起こすかもしれません。
        </span>
        <span>
            <span class="src">
                Keeping your functions short and simple makes it
                easier for other people to read and modify your code.
            </span>
            関数を短くシンプルであるように保つことで、コードをより読みやすく、より変更しやすくできるのです。
        </span>
        <span>
            <span class="src">
                Small functions are also easier to test.
            </span>
            小さな関数はテストも容易です。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                You could find long and complicated functions when
                working with
                some code.
            </span>
            作業をしていると、長く複雑なコードに出くわすこともあるでしょう。
        </span>
        <span>
            <span class="src">
                Do not be
                intimidated by modifying existing code: if working with
                such a function proves to be difficult, you find that
                errors are hard to debug, or you want to use a piece of
                it in several different contexts, consider breaking up
                the function into smaller and more manageable pieces.
            </span>
            既存のコードを変更することにおびえてはいけません。
            そのコードを使って仕事を進めることが困難であることがわかった場合やエラーのデバッグが難しいことがわかった場合、あるいは別の文脈においてその関数の一部分だけを切り出して使いたくなった場合には関数をより小さく扱いやすい複数の断片に分割することを検討してください。
        </span>
    </p>

    <h3 id="Function_Overloading">
        <span title="Function Overloading">関数のオーバーロード</span>
    </h3>

    <p>
        <span>
            <span class="src">
                Use overloaded functions (including constructors) only if a
                reader looking at a call site can get a good idea of what
                is happening without having to first figure out exactly
                which overload is being called.
            </span>
            コンストラクタを含めて関数のオーバーロードは、コードの読者が呼び出し元のコードを読んだときに、具体的にどのオーバーロードが呼び出されるか正確に把握していなくとも、何が起こるか理解できるであろう場合に限って使うようにしてください。
        </span>
    </p>

    <p class="definition"></p>
    <p>
        <span>
            <span class="src">
                You may write a function that takes a <code>
                                    const
                                    std::string&amp;
                                </code> and overload it with another that
                takes <code>const char*</code>.
            </span>
            たとえば、<code>const std::string&amp;</code>を引数にとる関数と、<code>const char*</code>を引数にとるオーバーロードとを書くことができるでしょう。
        </span>
        <span>
            <span class="src">
                However, in this case consider
                <code>std::string_view</code>
                instead.
            </span>
            ただ、この例の場合、<code>std::string_view</code>を採用することを検討してください。
        </span>
    </p>

    <pre>class MyClass {
 public:
  void Analyze(const std::string &amp;text);
  void Analyze(const char *text, size_t textlen);
};
</pre>

    <p class="pros"></p>
    <p>
        <span>
            <span class="src">
                Overloading can make code more intuitive by allowing an
                identically-named function to take different arguments.
            </span>
            オーバーロードは、関数に同一の名前をもたせたまま異なる引数をとらせることができるため、コードをより直感的なものにすることができます。
        </span>
        <span>
            <span class="src">
                It may be necessary for templatized code, and it can be
                convenient for Visitors.
            </span>
            この機能は、コードのテンプレート化や、ビジターパターンにおいて有用です。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Overloading based on const or ref qualification may make utility
                code more usable, more efficient, or both.
                (See <a href="http://abseil.io/tips/148">TotW 148</a> for more.)
            </span>
            constや 参照修飾子によるオーバーロードは、ユーティリティコードをより有用にしたり効率的にしたり、またその両方の恩恵をもたらします。
            (詳しくは <a href="http://abseil.io/tips/148">TotW 148</a> を見てください)
        </span>

    </p>
    <p class="cons"></p>
    <p>
        <span>
            <span class="src">
                If a function is overloaded by the argument types alone,
                a reader may have to understand C++'s complex matching
                rules in order to tell what's going on.
            </span>
            ある関数が引数の型だけでオーバーロードされている場合、コードの読者がそこで実際に起きることを知るためには、C++の複雑なマッチングルールについて理解していなくてはなりません。
        </span>
        <span>
            <span class="src">
                Also many people
                are confused by the semantics of inheritance if a derived
                class overrides only some of the variants of a
                function.
            </span>
            また、複数のオーバーロードを持つ仮想関数を、派生先で部分的にオーバーライドした場合の挙動は、多くの人を困惑させています。
        </span>
    </p>
    <p class="decision"></p>
    <p>
        <span>
            <span class="src">
                You may overload a function when there are no semantic differences
                between variants.
            </span>
            互いに意味上の違いがないのであれば、関数をオーバーロードしてもかまいません。
        </span>
        <span>
            <span class="src">
                These overloads may vary in types, qualifiers, or
                argument count.
            </span>
            これらのオーバーロードは、型が異なったり、修飾子が異なったり、引数の数が違ったりするものを含むでしょう。
        </span>
        <span>
            <span class="src">
                However, a reader of such a call must not need to know
                which member of the overload set is chosen, only that <b>something</b>
                from the set is being called.
            </span>
            しかし、そのようなオーバーロードを呼び出すコードを読んでいるときに、オーバーロードのセットのうちの<b>いずれか</b>が呼び出されているということまでわかればよく、具体的にどの定義が呼び出されているのかを知る必要はありません。
        </span>
        <span>
            <span class="src">
                If you can document all entries in the
                overload set with a single comment in the header, that is a good sign
                that it is a well-designed overload set.
            </span>
            あるオーバーロードのセットについて、ヘッダーファイルにドキュメントコメントを書こうとしているとき、もし、それらのオーバーロードのすべてについて1つのコメントで賄えるのならば、それは、そのセットがよくデザインされているということを示しています。
        </span>
    </p>

    <h3 id="Default_Arguments">
        <span title="Default Arguments">デフォルト引数</span>
    </h3>

    <p>
        <span>
            <span class="src">
                Default arguments are allowed on non-virtual functions
                when the default is guaranteed to always have the same
                value.
            </span>
            関数が仮想関数ではなく、その値が常に同じになることが保証されているとき、引数にデフォルトの値を持てます。
        </span>
        <span>
            <span class="src">
                Follow the same restrictions as for <a href="#Function_Overloading">function overloading</a>, and
                prefer overloaded functions if the readability gained with
                default arguments doesn't outweigh the downsides below.
            </span>
            <a href="#Function_Overloading">関数のオーバーロード</a>と同様の制限に従ってください。引数にデフォルト値を与えることによって得られる可読性よりも、以下に述べるマイナス面の方が勝る場合、かわりに関数のオーバーロードを使いましょう。
        </span>
    </p>

    <p class="pros"></p>
    <p>
        <span>
            <span class="src">
                Often you have a function that uses default values, but
                occasionally you want to override the defaults.
            </span>
            普段はデフォルトの値で使っている関数でも、時々別の値に変えて呼び出したくなることがあります。
        </span>
        <span>
            <span class="src">
                Default
                parameters allow an easy way to do this without having to
                define many functions for the rare exceptions.
            </span>
            引数にデフォルト値を与えることで、このような"時々"のための関数をたくさん定義することなく、簡単にやりたいことを実現できます。
        </span>
        <span>
            <span class="src">
                Compared
                to overloading the function, default arguments have a
                cleaner syntax, with less boilerplate and a clearer
                distinction between 'required' and 'optional'
                arguments.
            </span>
            関数のオーバーロードと比較して、このやり方は、文法的にきれいで、より少ない定型文で済み、さらに、引数が必須か任意かをより明確に区別できるようにもなります。
        </span>
    </p>
    <p class="cons"></p>
    <p>
        <span>
            <span class="src">
                Defaulted arguments are another way to achieve the
                semantics of overloaded functions, so all the <a href="#Function_Overloading">
                    reasons not to overload
                    functions
                </a> apply.
            </span>
            引数にデフォルト値を与える方法は、関数のオーバーロードでできることを実現する別の方法でもあるため、すべての<a href="#Function_Overloading">関数をオーバーロードしない理由</a>を適用します。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                The defaults for arguments in a virtual function call are
                determined by the static type of the target object, and
                there's no guarantee that all overrides of a given function
                declare the same defaults.
            </span>
            仮想関数呼び出しにおける引数のデフォルト値は、オブジェクトの静的な型に基づいて決定されますが、その関数のすべてのオーバーライドが、同じデフォルト値とともに宣言されている保証がありません。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Default parameters are re-evaluated at each call site,
                which can bloat the generated code.
            </span>
            引数のデフォルト値は、すべての呼び出し元で再評価されるため、予期せず生成されるコード量がふくれることがあります。
        </span>
        <span>
            <span class="src">
                Readers may also expect
                the default's value to be fixed at the declaration instead
                of varying at each call.
            </span>
            また、コードの読者は、関数が呼び出されるたびにデフォルト値が変わるのではなく、宣言時点で決まった値に固定されていることを期待してしまうかもしれません。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Function pointers are confusing in the presence of
                default arguments, since the function signature often
                doesn't match the call signature.
            </span>
            関数ポインタを引数のデフォルト値として与えると混乱の元になります。関数のシグネチャはしばしば、呼び出す際のシグネチャと一致しないことがあるからです。
        </span>
        <span>
            <span class="src">
                Adding
                function overloads avoids these problems.
            </span>
            関数のオーバーロードであれば、これらの問題は回避することができます。
        </span>
    </p>
    <p class="decision"></p>
    <p>
        <span>
            <span class="src">
                Default arguments are banned on virtual functions, where
                they don't work properly, and in cases where the specified
                default might not evaluate to the same value depending on
                when it was evaluated.
            </span>
            仮想関数における引数にデフォルト値を与えても、それらは意図した通りに動作しないため禁止とします。また、デフォルト値が評価のタイミングによって必ず同じ値にならない場合についても禁止とします。
        </span>
        <span>
            <span class="src">
                (For example, don't write <code>
                                    void
                                    f(int n = counter++);
                                </code>.)
            </span>
            (たとえば、次のように書いてはいけません: <code>void f(int n = counter++);</code>)
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                In some other cases, default arguments can improve the
                readability of their function declarations enough to
                overcome the downsides above, so they are allowed.
            </span>
            その他のいくつかの場合において、引数にデフォルト値を与えることで、ここまで述べた悪い点を差し引いても十分に関数宣言の可読性を高めることができる場合があります。このとき、それらの使用が認められます。
        </span>
        <span>
            <span class="src">
                When in
                doubt, use overloads.
            </span>
            迷ったときは関数のオーバーロードを選択します。
        </span>
    </p>

    <h3 id="trailing_return">
        <span title="Trailing Return Type Syntax">戻り値の型を後置する関数宣言構文</span>
    </h3>

    <p>
        <span>
            <span class="src">
                Use trailing return types only where using the ordinary syntax (leading
                return types) is impractical or much less readable.
            </span>
            戻り値の型を後置する関数宣言構文は、従来からの通常の構文(戻り値の型から始まる構文)を使うことができない場合か、その構文では可読性に劣ってしまう場合にのみ使用します。
        </span>
    </p>
    <p class="definition"></p>
    <p>
        <span>
            <span class="src">
                C++ allows two different forms of function declarations.
            </span>
            C++では、2種類の異なる関数宣言の構文が認められています。
        </span>
        <span>
            <span class="src">
                In the older
                form, the return type appears before the function name.
                For example:
            </span>
            従来の形では、戻り値の型を関数名より先に書きます。
            例えば、
        </span>
    </p>
    <pre>int foo(int x);
</pre>
    <p>
        <span>
            <span class="src">
                The newer form uses the <code>auto</code>
                keyword before the function name and a trailing return type after
                the argument list.
            </span>
            新しい構文では<code>auto</code>キーワードを関数名の前に置き、戻り値の型を引数リストの後に置きます。
        </span>
        <span>
            <span class="src">
                For example, the declaration above could
                equivalently be written:
            </span>
            例として、先ほどの宣言と等価な宣言は次のようになります。
        </span>
    </p>
    <pre>auto foo(int x) -&gt; int;
</pre>
    <p>
        <span>
            <span class="src">
                The trailing return type is in the function's scope.
            </span>
            この戻り値の型は関数内スコープとなります。
        </span>
        <span>
            <span class="src">
                This doesn't
                make a difference for a simple case like <code>int</code> but it matters
                for more complicated cases, like types declared in class scope or
                types written in terms of the function parameters.
            </span>
            <code>int</code>のように単純な場合はこれらの間に違いはありませんが、より複雑な場合にはこれは重要となってきます。
            たとえば、型がクラススコープで宣言されている場合や、型が関数の引数によって決まったりする場合です。
        </span>
    </p>

    <p class="pros"></p>
    <p>
        <span>
            <span class="src">
                Trailing return types are the only way to explicitly specify the
                return type of a <a href="#Lambda_expressions">lambda expression</a>.
            </span>
            戻り値の型を後置する構文は、<a href="#Lambda_expressions">ラムダ式</a>の戻り値の型を明示できる唯一の方法です。
        </span>
        <span>
            <span class="src">
                In some cases the compiler is able to deduce a lambda's return type,
                but not in all cases.
            </span>
            コンパイラはラムダ式の戻り値の型を推論しますが、常にそれができるわけではありません。
        </span>
        <span>
            <span class="src">
                Even when the compiler can deduce it automatically,
                sometimes specifying it explicitly would be clearer for readers.
            </span>
            また、コンパイラが自動的に型を推論できる場合であっても、型を明示することでコードの可読性を向上させる場合もあります。
        </span>
    </p>
    <p>
        <span>
            <span class="src">
                Sometimes it's easier and more readable to specify a return type
                after the function's parameter list has already appeared.
            </span>
            時に、戻り値の型を関数の引数の後ろに明示することで、より簡単で可読性が高くなることがあります。
        </span>
        <span>
            <span class="src">
                This is
                particularly true when the return type depends on template parameters.
            </span>
            特に、戻り値の型がテンプレートパラメータによって決まる場合にはこのことが言えます。
        </span>
        <span>
            <span class="src">
                For example:
            </span>
            次の例を見てください。
        </span>
    </p>
    <div>
        <pre>    template &lt;typename T, typename U&gt;
    auto add(T t, U u) -&gt; decltype(t + u);
</pre>
        <span>
            <span class="src">
                versus
            </span>
            対
        </span>
        <pre>    template &lt;typename T, typename U&gt;
    decltype(declval&lt;T&amp;&gt;() + declval&lt;U&amp;&gt;()) add(T t, U u);
</pre>
    </div>
    <p class="cons"></p>
    <p>
        <span>
            <span class="src">
                Trailing return type syntax is relatively new and it has no
                analogue in C++-like languages such as C and Java, so some readers may
                find it unfamiliar.
            </span>
            戻り値の型を後置する構文は、比較的新しく、他のC++系言語(C言語やJavaなど)には類似の構文がありません。このため、コードの読者にとってなじみが薄いかもしれません。
        </span>
    </p>
    <p>
        <span>
            <span class="src">
                Existing code bases have an enormous number of function
                declarations that aren't going to get changed to use the new syntax,
                so the realistic choices are using the old syntax only or using a mixture
                of the two.
            </span>
            既存のコードベースには既に膨大な数の関数宣言があり、それらが新しい構文に替わることはないでしょう。このため、現実的には、古い構文と新しい構文との両方を混合させて使っていくという道を選択することになります。
        </span>
        <span>
            <span class="src">
                Using a single version is better for uniformity of style.
            </span>
            スタイルの一様性のためには、1種類だけを使うことが好ましいです。
        </span>
    </p>
    <p class="decision"></p>
    <p>
        <span>
            <span class="src">
                In most cases, continue to use the older style of function
                declaration where the return type goes before the function name.
            </span>
            ほとんどの場合において、従来からある、戻り値の型が関数名より先に来る関数宣言の構文を使い続けてください。
        </span>
        <span>
            <span class="src">
                Use the new trailing-return-type form only in cases where it's
                required (such as lambdas) or where, by putting the type after the
                function's parameter list, it allows you to write the type in a much
                more readable way.
            </span>
            新しい構文を使うのは、それがどうしても必要な場合(ラムダ式のような)と、引数のリストの後ろに戻り値の型を置くことで可読性を大きく向上させられる場合に限定します。
        </span>
        <span>
            <span class="src">
                The latter case should be rare; it's mostly an
                issue in fairly complicated template code, which is
                <a href="#Template_metaprogramming">discouraged in most cases</a>.
            </span>
            後者の状況はまれです。というのも、大抵、複雑すぎるテンプレートのコードが問題なのであって、<a href="#Template_metaprogramming">それらのほとんどは推奨されていない</a>からです。
        </span>
    </p>

    <h2 id="Google-Specific_Magic">
        <span title="Google-Specific Magic">Google特有のマジック</span>
    </h2>

    <p>
        <span>
            <span class="src">
                There are various tricks and utilities that
                we use to make C++ code more robust, and various ways we use
                C++ that may differ from what you see elsewhere.
            </span>
            我々はC++のコードをより堅牢にするために、様々なトリックやユーティリティを使っています。
            これらの手法は、一般的に見られるC++の使い方とは異なっている部分もあるかもしれません。
        </span>
    </p>

    <h3 id="Ownership_and_Smart_Pointers">
        <span title="Ownership and Smart Pointers">スマートポインタの所有権</span>
    </h3>

    <p>
        <span>
            <span class="src">
                Prefer to have single, fixed owners for dynamically
                allocated objects.
            </span>
            動的に確保されるオブジェクトの所有者は、単一かつ固定されるようにしましょう。
        </span>
        <span>
            <span class="src">
                Prefer to transfer ownership with smart
                pointers.
            </span>
            オブジェクトの所有権を移すときは、スマートポインタを使用しましょう。
        </span>
    </p>

    <p class="definition"></p>
    <p>
        <span>
            <span class="src">
                "Ownership" is a bookkeeping technique for managing
                dynamically allocated memory (and other resources).
            </span>
            「所有権」は、動的に確保されるメモリ(や、その他のリソース)を管理するための帳簿的なテクニックの一つです。
        </span>
        <span>
            <span class="src">
                The
                owner of a dynamically allocated object is an object or
                function that is responsible for ensuring that it is
                deleted when no longer needed.
            </span>
            動的に確保されるオブジェクトの所有者は、1つのオブジェクトか関数であり、オブジェクトが不要になったときにそれを解放する責任を負います。
        </span>
        <span>
            <span class="src">
                Ownership can sometimes be
                shared, in which case the last owner is typically
                responsible for deleting it.
            </span>
            所有権は時には共有されることもあります。その場合、一般的に最後の所有者が解放の責任を負います。
        </span>
        <span>
            <span class="src">
                Even when ownership is not
                shared, it can be transferred from one piece of code to
                another.
            </span>
            所有権は、共有まではされなくとも、あるコードから他のコードへと移されることもあります。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                "Smart" pointers are classes that act like pointers,
                e.g., by overloading the <code>*</code> and
                <code>-&gt;</code> operators.
            </span>
            「スマート」ポインタとは、ポインタのように振る舞うクラスです(たとえば演算子<code>*</code>と<code>-&gt;</code>をオーバーロードしています)。
        </span>
        <span>
            <span class="src">
                Some smart pointer types
                can be used to automate ownership bookkeeping, to ensure
                these responsibilities are met.
            </span>
            スマートポインタの中には、このような所有権管理を自動的に行い、解放の責任を確実に果たすために使われるものがあります。
        </span>
        <span>
            <span class="src">
                <a href="http://en.cppreference.com/w/cpp/memory/unique_ptr">
                    <code>std::unique_ptr</code>
                </a> is a smart pointer type
                introduced in C++11, which expresses exclusive ownership
                of a dynamically allocated object; the object is deleted
                when the <code>std::unique_ptr</code> goes out of scope.
            </span>
            <a href="http://en.cppreference.com/w/cpp/memory/unique_ptr"><code>std::unique_ptr</code></a>は、スマートポインタの一種で、C++11で導入されました。このスマートポインタは、動的に確保されたオブジェクトに対する排他的な所有権を表します。<code>std::unique_ptr</code>によって所有されるオブジェクトは、<code>std::unique_ptr</code>がスコープの外に出たときに解放されます。
        </span>
        <span>
            <span class="src">
                It cannot be copied, but can be <em>moved</em> to
                represent ownership transfer.
            </span>
            <code>std::unique_ptr</code>をコピーすることはできませんが、所有権を移動するために<em>ムーブ</em>することはできます。
        </span>
        <span>
            <span class="src">
                <a href="http://en.cppreference.com/w/cpp/memory/shared_ptr">
                    <code>std::shared_ptr</code>
                </a> is a smart pointer type
                that expresses shared ownership of
                a dynamically allocated object.
            </span>
            <a href="http://en.cppreference.com/w/cpp/memory/shared_ptr"><code>std::shared_ptr</code></a>は、動的に確保されたオブジェクトの所有権を他者と共有することを表すために使われるスマートポインタです。
        </span>

        <span>
            <span class="src">
                <code>std::shared_ptr</code>s
                can be copied; ownership of the object is shared among
                all copies, and the object is deleted when the last
                <code>std::shared_ptr</code> is destroyed.
            </span>
            <code>std::shared_ptr</code>はコピーすることができます。オブジェクトの所有権はすべてのコピーの間で共有され、オブジェクトは最後の<code>std::shared_ptr</code>が破壊されるときに解放されます。
        </span>
    </p>
    <p class="pros"></p>
    <ul>
        <li>
            <span>
                <span class="src">
                    It's virtually impossible to manage dynamically
                    allocated memory without some sort of ownership
                    logic.
                </span>
                所有権の概念がなければ、動的に確保されるメモリを管理するのは実質的に不可能です。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Transferring ownership of an object can be cheaper
                    than copying it (if copying it is even possible).
                </span>
                所有権を移すだけであれば、オブジェクトをコピーする(それが可能だったとして)よりも低コストとなるでしょう。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Transferring ownership can be simpler than
                    'borrowing' a pointer or reference, because it reduces
                    the need to coordinate the lifetime of the object
                    between the two users.
                </span>
                オブジェクトの所有権を移すことは、参照やポインタを「借りてくる」よりも単純です。なぜならば、そのオブジェクトを扱う二者間での、オブジェクトの生存期間に関する認識合わせの必要性が減らせるからです。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Smart pointers can improve readability by making
                    ownership logic explicit, self-documenting, and
                    unambiguous.
                </span>
                スマートポインタは、所有権を明示化し、それ自体にドキュメントの意味合いを持たせられるため、可読性が向上します。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Smart pointers can eliminate manual ownership
                    bookkeeping, simplifying the code and ruling out large
                    classes of errors.
                </span>
                スマートポインタは手作業による所有権管理をなくし、コードを単純化し、エラーのうち大きな分類を除外することができます。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    For const objects, shared ownership can be a simple
                    and efficient alternative to deep copying.
                </span>
                constなオブジェクトについていえば、所有権を共有することは、単純かつ効率的なディープコピーの代替手段ともなりえます。
            </span>
        </li>
    </ul>

    <p class="cons"></p>
    <ul>
        <li>
            <span>
                <span class="src">
                    Ownership must be represented and transferred via
                    pointers (whether smart or plain).
                </span>
                所有権は、スマートポインタであろうと生のポインタであろうと、何らかのポインタによって扱われ、ポインタ間で受け渡しが行われます。
            </span>
            <span>
                <span class="src">
                    Pointer semantics
                    are more complicated than value semantics, especially
                    in APIs: you have to worry not just about ownership,
                    but also aliasing, lifetime, and mutability, among
                    other issues.
                </span>
                ポインタの概念は値を直接扱うよりも複雑で、特にAPIの層では、所有権だけではなく、エイリアシング、寿命、可変性などについても気にしなくてはなりません。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    The performance costs of value semantics are often
                    overestimated, so the performance benefits of ownership
                    transfer might not justify the readability and
                    complexity costs.
                </span>
                値を直接扱った場合のパフォーマンスコストは、しばしば、実際よりも高めに見積もられがちです。このため、所有権を移す方法を採用することで得られるパフォーマンス上のメリットは、それによる可読性の低下や複雑化のコストに見合わないかもしれません。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    APIs that transfer ownership force their clients
                    into a single memory management model.
                </span>
                所有権を移すAPIは、その使用者にシングルメモリマネジメントモデルを強制します。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Code using smart pointers is less explicit about
                    where the resource releases take place.
                </span>
                スマートポインタ使ったコードは、リソースがいつどこで解放されるかの明示性が低下します。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    <code>std::unique_ptr</code> expresses ownership
                    transfer using move semantics, which are
                    relatively new and may confuse some programmers.
                </span>
                <code>std::unique_ptr</code> は、ムーブのセマンティクスを使って所有権を移しますが、ムーブの概念は比較的新しく、プログラマによっては混乱するかもしれません。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Shared ownership can be a tempting alternative to
                    careful ownership design, obfuscating the design of a
                    system.
                </span>
                所有権に関するデザインを注意深く行うのに比べて、単純に所有権を共有させて済ませてしまうことは、魅惑的な代替手段と思えるかもしれませんが、それはシステムのデザインをわかりにくくしてしまいます。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Shared ownership requires explicit bookkeeping at
                    run-time, which can be costly.
                </span>
                所有権を共有する場合、実行時に明示的な所有権管理が必要となり、そのためのコストが高くつく場合があります。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    In some cases (e.g., cyclic references), objects
                    with shared ownership may never be deleted.
                </span>
                所有権を共有されたオブジェクトが決して解放されない状態に陥ることがあります(たとえば循環参照)。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Smart pointers are not perfect substitutes for
                    plain pointers.
                </span>
                スマートポインタは生のポインタに対する代替手段として完璧ではありません。
            </span>
        </li>
    </ul>

    <p class="decision"></p>
    <p>
        <span>
            <span class="src">
                If dynamic allocation is necessary, prefer to keep
                ownership with the code that allocated it.
            </span>
            動的なオブジェクトの確保が必要な場合、その所有権はそれを確保したコードが持つようにしましょう。
        </span>
        <span>
            <span class="src">
                If other code
                needs access to the object, consider passing it a copy,
                or passing a pointer or reference without transferring
                ownership.
            </span>
            他のコードからそのオブジェクトにアクセスする場合は、単にオブジェクトのコピーを渡すか、所有権の移動なしにポインタや参照を渡す方法を検討してください。
        </span>
        <span>
            <span class="src">
                Prefer to use <code>std::unique_ptr</code> to
                make ownership transfer explicit.
            </span>
            所有権の移動を明示的に行うためには、<code>std::unique_ptr</code>を使うようにしましょう。
        </span>
        <span>
            <span class="src">
                For example:
            </span>
            以下に例を示します。
        </span>
    </p>

    <pre>std::unique_ptr&lt;Foo&gt; FooFactory();
void FooConsumer(std::unique_ptr&lt;Foo&gt; ptr);
</pre>

    <p>
        <span>
            <span class="src">
                Do not design your code to use shared ownership
                without a very good reason.
            </span>
            非常に良い理由がない限り、オブジェクトの所有権を共有させるデザインにしてはいけません。
        </span>
        <span>
            <span class="src">
                One such reason is to avoid
                expensive copy operations, but you should only do this if
                the performance benefits are significant, and the
                underlying object is immutable (i.e.,
                <code>std::shared_ptr&lt;const Foo&gt;</code>).
            </span>
            そのような理由としては、高価なコピーを避けるためといったものがあげられますが、それでも、所有権の共有は、パフォーマンス上の利益が非常に大きく、かつ対象のオブジェクトが不変である場合にのみ行ってください(言い換えると、<code>std::shared_ptr&lt;const Foo&gt;</code>)。
        </span>
        <span>
            <span class="src">
                If you
                do use shared ownership, prefer to use
                <code>std::shared_ptr</code>.
            </span>
            所有権を共有したい場合、<code>std::shared_ptr</code>を使いましょう。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Never use <code>std::auto_ptr</code>.
            </span>
            <code>std::auto_ptr</code>を使ってはなりません。
        </span>
        <span>
            <span class="src">
                Instead, use
                <code>std::unique_ptr</code>.
            </span>
            かわりに、<code>std::unique_ptr</code>を使いましょう。
        </span>
    </p>

    <h3 id="cpplint">
        <span title="cpplint">cpplint</span>
    </h3>

    <p>
        <span>
            <span class="src">
                Use <code>cpplint.py</code>
                to detect style errors.
            </span>
            スタイルに関する問題を検出するため、<code>cpplint.py</code>を使ってください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                <code>cpplint.py</code>
                is a tool that reads a source file and identifies many
                style errors.
            </span>
            <code>cpplint.py</code>は、ソースファイルを読み、スタイルに関するたくさんのエラーを識別してくれるツールです。
        </span>
        <span>
            <span class="src">
                It is not perfect, and has both false
                positives and false negatives, but it is still a valuable
                tool.
            </span>
            このツールは完璧ではなく、誤診もありますが、それでも価値があります。
        </span>
        <span>
            <span class="src">
                False positives can be ignored by putting <code>
                                //
                                NOLINT
                            </code> at the end of the line or
                <code>// NOLINTNEXTLINE</code> in the previous line.
            </span>
            偽陽性の診断がなされる場合は、行末に<code>// NOLINT</code>を書くか、前の行に<code>// NOLINTNEXTLINE</code>を書くことで、無視させることができます。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Some projects have instructions on
                how to run <code>cpplint.py</code> from their project
                tools.
            </span>
            いくつかのプロジェクトにおいては、プロジェクトのツールから<code>cpplint.py</code>を起動するやり方が用意されています。
        </span>
        <span>
            <span class="src">
                If the project you are contributing to does not,
                you can download
                <a href="https://raw.githubusercontent.com/google/styleguide/gh-pages/cpplint/cpplint.py">
                    <code>cpplint.py</code>
                </a> separately.
            </span>
            あなたのプロジェクトでそのような環境が用意されていない場合は<a href="https://raw.githubusercontent.com/google/styleguide/gh-pages/cpplint/cpplint.py"><code>cpplint.py</code></a>から個別にダウンロードすることができます。
        </span>
    </p>

    <h2 id="Other_C++_Features">
        <span title="Other C++ Features">その他のC++の機能</span>
    </h2>

    <h3 id="Rvalue_references">
        <span title="Rvalue References">右辺値参照</span>
    </h3>

    <p>
        <span>
            <span class="src">
                Use rvalue references only in certain special cases listed below.
            </span>
            右辺値参照は次に挙げるような特殊な場合のみに使用します。
        </span>
    </p>

    <p class="definition"></p>
    <p>
        <span>
            <span class="src">
                Rvalue references
                are a type of reference that can only bind to temporary
                objects.
            </span>
            右辺値参照とは、一時オブジェクトにのみ紐付く参照のことです。
        </span>
        <span>
            <span class="src">
                The syntax is similar to traditional reference
                syntax.
            </span>
            文法は従来からある参照に似ています。
        </span>
        <span>
            <span class="src">
                For example, <code>
                                    void f(std::string&amp;&amp;
                                    s);
                                </code> declares a function whose argument is an
                rvalue reference to a std::string.
            </span>
            たとえば、<code>void f(string&amp;&amp; s);</code>は、stringの右辺値参照を引数にとる関数を宣言しています。
        </span>
    </p>

    <p id="Forwarding_references">
        <span>
            <span class="src">
                When the token '&amp;&amp;' is applied to
                an unqualified template argument in a function
                parameter, special template argument deduction
                rules apply.
            </span>
            関数のパラメータにおいて、修飾子のないテンプレート引数に '&amp;&amp;' が使われた場合、特殊な推論ルールが適用されます。
        </span>
        <span>
            <span class="src">
                Such a reference is called forwarding reference.
            </span>
            このような参照は、「転送参照(Forwarding Reference)」と呼ばれます。
        </span>
    </p>
    <p class="pros"></p>
    <ul>
        <li>
            <span>
                <span class="src">
                    Defining a move constructor (a constructor taking
                    an rvalue reference to the class type) makes it
                    possible to move a value instead of copying it.
                </span>
                ムーブコンストラクタ(クラスの右辺値参照をとるコンストラクタ)を定義すると、値をコピーではなくムーブすることができるようになります。
            </span>
            <span>
                <span class="src">
                    If
                    <code>v1</code> is a <code>std::vector&lt;std::string&gt;</code>,
                    for example, then <code>auto v2(std::move(v1))</code>
                    will probably just result in some simple pointer
                    manipulation instead of copying a large amount of data.
                </span>
                たとえば、変数<code>v1</code>が<code>std::vector&lt;std::string&gt;</code>であるとき、<code>auto v2(std::move(v1))</code>は、大量のデータをコピーするのではなく、単なるポインタ操作だけで済ませることができるでしょう。
            </span>
            <span>
                <span class="src">
                    In many cases this can result in a major performance
                    improvement.
                </span>
                多くの場合において、これらは大きなパフォーマンス向上に繋がります。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Rvalue references make it possible to implement
                    types that are movable but not copyable, which can be
                    useful for types that have no sensible definition of
                    copying but where you might still want to pass them as
                    function arguments, put them in containers, etc.
                </span>
                右辺値参照によって、ムーブはできるがコピーできない型を実装することができるようになります。このような型は、細やかなコピー操作の定義を持たないにも関わらず、関数の引数に渡したり、コンテナに格納したりできるため便利です。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    <code>std::move</code> is necessary to make
                    effective use of some standard-library types, such as
                    <code>std::unique_ptr</code>.
                </span>
                <code>std::move</code>は、<code>std::unique_ptr</code>のような、いくつかの標準ライブラリを効率的に使うために必要とされます。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    <a href="#Forwarding_references">Forwarding references</a> which
                    use the rvalue reference token, make it possible to write a
                    generic function wrapper that forwards its arguments to
                    another function, and works whether or not its
                    arguments are temporary objects and/or const.
                    This is called 'perfect forwarding'.
                </span>
                右辺値参照と同じ記号を使う<a href="#Forwarding_references">転送参照</a>によって、引数を転送する汎用的な関数のラッパーを書くことができるようになります。
                これは、引数が一時オブジェクトであるか否か、constであるか否かにかかわらず動作します。
                これを「完全転送('perfect forwarding')」と呼びます。
            </span>
        </li>
    </ul>

    <p class="cons"></p>
    <ul>
        <li>
            <span>
                <span class="src">
                    Rvalue references are not yet widely understood.
                </span>
                右辺値参照は まだ広く理解されていません。
            </span>
            <span>
                <span class="src">
                    Rules like reference
                    collapsing and the special deduction rule for forwarding references
                    are somewhat obscure.
                </span>
                参照の折り畳み(reference collapsing)や転送参照といったルールは、あまり知られていません。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Rvalue references are often misused.
                </span>
                右辺値参照はしばしば間違った使い方がなされます。
            </span>
            <span>
                <span class="src">
                    Using rvalue
                    references is counter-intuitive in signatures where the argument is expected
                    to have a valid specified state after the function call, or where no move
                    operation is performed.
                </span>
                右辺値参照を使うことは見た目に対して非直感的です。右辺値参照に与えた引数が関数呼び出しの後にも有効な状態を持っていそうに見えたり、ムーブ操作が行われなかったりします。
            </span>
        </li>
    </ul>

    <p class="decision"></p>
    <p>
        <span>
            <span class="src">
                Do not use rvalue references (or apply the <code>&amp;&amp;</code>
                qualifier to methods), except as follows:
            </span>
            右辺値参照(や、メソッドの<code>&amp;&amp;</code>参照修飾子)は、以下のときを除いて使わないようにしましょう。
        </span>
    </p>

    <ul>
        <li>
            <span>
                <span class="src">
                    You may use them to define move constructors and move assignment
                    operators (as described in
                    <a href="#Copyable_Movable_Types">Copyable and Movable Types</a>)
                </span>
                ムーブコンストラクタ・ムーブ代入演算子(詳細は<a href="#Copyable_Movable_Types">コピー可能な型・ムーブ可能な型</a>にて記載)を定義するために使用できます。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    You may use them to define <code>&amp;&amp;</code>-qualified methods that
                    logically "consume" <code>*this</code>, leaving it in an unusable
                    or empty state.
                </span>
                <code>*this</code>を、理論上「消費」して、以降利用不能もしくは空の状態にするようなメソッドを定義するために<code>&amp;&amp;</code>参照修飾子を使用できます。
            </span>
            <span>
                <span class="src">
                    Note that this applies only to method qualifiers (which come
                    after the closing parenthesis of the function signature); if you want to
                    "consume" an ordinary function parameter, prefer to pass it by value.
                </span>
                ここでいう<code>&amp;&amp;</code>参照修飾子とは、関数シグネチャの閉じ丸括弧のあとに続く、メソッド修飾指定子にのことです。関数への引数を「消費」したいときは、値渡しをしてください。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    You may use forwarding references in conjunction with <code>
                    <a href="http://en.cppreference.com/w/cpp/utility/forward">std::forward</a></code>,
                    to support perfect forwarding.
                </span>
                完全転送(perfect forwarding)をサポートするために<a href="http://en.cppreference.com/w/cpp/utility/forward">std::forward</a>とあわせて使う場合に、転送参照を使用できます。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    You may use them to define pairs of overloads, such as one taking
                    <code>Foo&amp;&amp;</code> and the other taking <code>const Foo&amp;</code>.
                </span>
                <code>Foo&amp;&amp;</code> と <code>const Foo&amp;</code> を引数にとるオーバーロードの組を定義するために使用できます。
            </span>
            <span>
                <span class="src">
                    Usually the preferred solution is just to pass by value, but an overloaded
                    pair of functions sometimes yields better performance and is sometimes
                    necessary in generic code that needs to support a wide variety of types.
                </span>
                通常は、単に値渡しをするのがもっとも好ましい方法ですが、このようなオーバーロード関数の組を用いることで、パフォーマンスが向上したり、多くの型をサポートする汎用的なコードを書くために必要となったりします。
            </span>
            <span>
                <span class="src">
                    As always: if you're writing more complicated code for the sake of
                    performance, make sure you have evidence that it actually helps.
                </span>
                ただし、パフォーマンス向上を理由にコードを複雑化させる場合は、いつでも、そのコードが実際にパフォーマンスに貢献しているという証拠を確かめるようにしてください。
            </span>
        </li>
    </ul>

    <h3 id="Friends"><a title="Friends">フレンド</a></h3>

    <p>
        <span>
            <span class="src">
                We allow use of <code>friend</code> classes and functions,
                within reason.
            </span>
            理に叶う場合に、<code>friend</code>クラスや<code>friend</code>関数を使用できます。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Friends should usually be defined in the same file so
                that the reader does not have to look in another file to
                find uses of the private members of a class.
            </span>
            フレンドは、通常は同じファイル内に定義されるべきです。これは、コードの読者が、フレンドによるクラスのprivateメンバーの取り扱い方を、他のファイルに探しにいかなくてもいいようにするためです。
        </span>
        <span>
            <span class="src">
                A common use
                of <code>friend</code> is to have a
                <code>FooBuilder</code> class be a friend of
                <code>Foo</code> so that it can construct the inner state
                of <code>Foo</code> correctly, without exposing this
                state to the world.
            </span>
            <code>friend</code>のよくある使い方は、<code>FooBuilder</code>クラスを<code>Foo</code>クラスのフレンドにして、<code>FooBuilder</code>が<code>Foo</code>の内部状態を(publicに晒すことなく)正しく構築できるようにするといったようなものです。
        </span>
        <span>
            <span class="src">
                In some cases it may be useful to
                make a unittest class a friend of the class it tests.
            </span>
            あるいは、クラスのユニットテストを行うために、テストを担うクラスを、テスト対象のクラスのフレンドにすると便利な場合もあります。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Friends extend, but do not break, the encapsulation
                boundary of a class.
            </span>
            フレンドを使うと、クラスのカプセル化の壁を、壊さないように、拡張できます。
        </span>
        <span>
            <span class="src">
                In some cases this is better than
                making a member public when you want to give only one
                other class access to it.
            </span>
            この方法は、あるクラスのメンバーについて、他のある特定のただ一つのクラスにだけアクセスさせたいという場合に、単にそのメンバーをpublicにするよりも優れています。
        </span>
        <span>
            <span class="src">
                However, most classes should
                interact with other classes solely through their public
                members.
            </span>
            しかし、ほとんどのクラスは、クラス間のやりとりについて、publicメンバを通してのみ行うべきです。
        </span>
    </p>
    <h3 id="Exceptions"><span title="Exceptions">例外</span></h3>

    <p>
        <span>
            <span class="src">
                We do not use C++ exceptions.
            </span>
            C++の例外は使いません。
        </span>
    </p>

    <p class="pros"></p>
    <ul>
        <li>
            <span>
                <span class="src">
                    Exceptions allow higher levels of an application to
                    decide how to handle "can't happen" failures in deeply
                    nested functions, without the obscuring and error-prone
                    bookkeeping of error codes.
                </span>
                例外の仕組みを用いると、曖昧で取り違えやすいエラーコードの表を使わずに、深くネストされた関数の中で起きた「起こらないはずの」失敗に対する扱い方を、アプリケーションの高レベルの層で決めることができるようになります。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Exceptions are used by most other
                    modern languages.
                </span>
                例外は、多くのモダンな言語で取り入れられています。
            </span>
            <span>
                <span class="src">
                    Using them in C++ would make it more
                    consistent with Python, Java, and the C++ that others
                    are familiar with.
                </span>
                C++でも例外を使えば、PythonやJavaやその他のC++に似た言語との一貫性が高くできるでしょう。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Some third-party C++ libraries use exceptions, and
                    turning them off internally makes it harder to
                    integrate with those libraries.
                </span>
                サードパーティのC++ライブラリの中には例外を使っているものもあります。例外の機能を無効にしてしまうと、それらのライブラリとの統合が難しくなります。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Exceptions are the only way for a constructor to
                    fail.
                </span>
                例外はコンストラクタでおきた失敗を伝える唯一の方法です。
            </span>
            <span>
                <span class="src">
                    We can simulate this with a factory function or
                    an <code>Init()</code> method, but these require heap
                    allocation or a new "invalid" state, respectively.
                </span>
                コンストラクタの役割は、ファクトリ関数や<code>Init()</code>メソッドで担うこともできますが、その場合は、ヒープの確保を要したり、「不正」を表す新しい状態を必要としたりします。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Exceptions are really handy in testing
                    frameworks.
                </span>
                例外はテストフレームワークにおいては非常に扱いやすいものです。
            </span>
        </li>
    </ul>

    <p class="cons"></p>
    <ul>
        <li>
            <span>
                <span class="src">
                    When you add a <code>throw</code> statement to an
                    existing function, you must examine all of its
                    transitive callers.
                </span>
                既に存在している関数に<code>throw</code>文を加えるときには、その関数の呼び出し元をすべてを確認しなくてはなりません。
            </span>
            <span>
                <span class="src">
                    Either they must make at least the
                    basic exception safety guarantee, or they must never
                    catch the exception and be happy with the program
                    terminating as a result.
                </span>
                それらは、最低限の基本的な例外安全が保証しているか、あるいは、例外を一切キャッチせずに結果的にプログラムを終了させてしまうかのどちらかでしょう。
            </span>
            <span>
                <span class="src">
                    For instance, if
                    <code>f()</code> calls <code>g()</code> calls
                    <code>h()</code>, and <code>h</code> throws an
                    exception that <code>f</code> catches, <code>g</code>
                    has to be careful or it may not clean up properly.
                </span>
                たとえば、<code>f()</code>が<code>g()</code>を呼び、<code>g()</code>が<code>h()</code>を呼び出していて、<code>h</code>が例外を投げ<code>f</code>がキャッチするような場合においては、<code>g</code>を注意深く確かめないと、<code>g</code>の持つリソースが解放されないままになってしまうかもしれません。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    More generally, exceptions make the control flow of
                    programs difficult to evaluate by looking at code:
                    functions may return in places you don't expect.
                </span>
                より一般的には、例外を使用すると、プログラムのコードからコントロールフローを評価するのが難しくなります。
            </span>
            <span>
                <span class="src">
                    This
                    causes maintainability and debugging difficulties.
                </span>
                これは、そのままメンテナンスやデバッグの難しさにつながります。
            </span>
            <span>
                <span class="src">
                    You
                    can minimize this cost via some rules on how and where
                    exceptions can be used, but at the cost of more that a
                    developer needs to know and understand.
                </span>
                例外の扱い方に関するルールを設けることで、こういったコストは低くすることができるかもしれません。しかし、プログラマがそのルールを知り理解するためにはより多くのコストが掛かってしまいます。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Exception safety requires both RAII and different
                    coding practices.
                </span>
                例外安全なプログラムを組むためには、RAIIとそれと異なるコーディングプラクティスとの両方を必要とします。
            </span>
            <span>
                <span class="src">
                    Lots of supporting machinery is
                    needed to make writing correct exception-safe code
                    easy.
                </span>
                例外安全なコードを正しく簡単に書けるようにするためには、それをサポートするための多くの仕組みが必要となります。
            </span>
            <span>
                <span class="src">
                    Further, to avoid requiring readers to understand
                    the entire call graph, exception-safe code must isolate
                    logic that writes to persistent state into a "commit"
                    phase.
                </span>
                さらに、コードの読者に全体の呼び出しグラフを理解してもらう必要を避けるために、例外安全なコードでは、永続的な状態を書き込むロジックを「コミット」フェーズに分離しておかなければなりません。
            </span>
            <span>
                <span class="src">
                    This will have both benefits and costs (perhaps
                    where you're forced to obfuscate code to isolate the
                    commit).
                </span>
                これには、いい面と悪い面があるでしょうが、おそらく、コミットを分離するために、コードを複雑化せざるを得なくなります。
            </span>
            <span>
                <span class="src">
                    Allowing exceptions would force us to always
                    pay those costs even when they're not worth it.
                </span>
                例外の使用を認めると、たとえ価値が見合わない場合ですら、常にこれらのコストを支払わないといけなくなってしまいます。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Turning on exceptions adds data to each binary
                    produced, increasing compile time (probably slightly)
                    and possibly increasing address space pressure.
                </span>
                例外を有効にすると、各バイナリにデータが追加され、(わずかですが)コンパイル時間が延びます。使用できるアドレス空間も減ることになるかもしれません。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    The availability of exceptions may encourage
                    developers to throw them when they are not appropriate
                    or recover from them when it's not safe to do so.
                </span>
                例外は、それが使えることで、本来適切でないときに例外を投げたり、安全でないにもかかわらず復旧を試みたりするようなことを、開発者に促してしまうかもしれません。
            </span>
            <span>
                <span class="src">
                    For
                    example, invalid user input should not cause exceptions
                    to be thrown.
                </span>
                たとえば、ユーザーの入力が不正だった場合には、例外を投げるべきではありません。
            </span>
            <span>
                <span class="src">
                    We would need to make the style guide
                    even longer to document these restrictions!
                </span>
                例外を認めると、このような制限を書くために、本ガイドをさらに長くしなくてはなりません。
            </span>
        </li>
    </ul>

    <p class="decision"></p>
    <p>
        <span>
            <span class="src">
                On their face, the benefits of using exceptions
                outweigh the costs, especially in new projects.
            </span>
            特に新しいプロジェクトの場合は、例外を扱うコストよりも、その恩恵が上回るでしょう。
        </span>
        <span>
            <span class="src">
                However,
                for existing code, the introduction of exceptions has
                implications on all dependent code.
            </span>
            しかし、既存のコードに例外を導入すると、すべての従属するコードに影響を及ぼします。
        </span>
        <span>
            <span class="src">
                If exceptions can be
                propagated beyond a new project, it also becomes
                problematic to integrate the new project into existing
                exception-free code.
            </span>
            例外が新しいプロジェクトから波及してきうる場合、そのプロジェクトを既存の例外フリーなコードと統合するのは難しくなります。
        </span>
        <span>
            <span class="src">
                Because most existing C++ code at
                Google is not prepared to deal with exceptions, it is
                comparatively difficult to adopt new code that generates
                exceptions.
            </span>
            GoogleのほとんどのC++コードは例外を扱えるように作られていないため、例外を生成する新しいコードに適応するのは非常に難しいことです。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Given that Google's existing code is not
                exception-tolerant, the costs of using exceptions are
                somewhat greater than the costs in a new project.
            </span>
            Googleの既存のコードは例外を扱えないため、例外を扱うコストは、新規プロジェクトのそれよりも、いくぶん大きいです。
        </span>
        <span>
            <span class="src">
                The
                conversion process would be slow and error-prone.
            </span>
            それへの対応は遅く、エラーも起こしやすいでしょう。
        </span>
        <span>
            <span class="src">
                We
                don't believe that the available alternatives to
                exceptions, such as error codes and assertions, introduce
                a significant burden.
            </span>
            私たちは、例外のかわりに、エラーコードやアサーションといった代替品を使うことが、大きな負担になるとは考えていません。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Our advice against using exceptions is not predicated
                on philosophical or moral grounds, but practical ones.
            </span>
            我々の例外の使用に対するアドバイスは、哲学的あるいは道徳的背景に基づくものではなく、あくまで実践的なものとしての話です。
        </span>
        <span>
            <span class="src">
                Because we'd like to use our open-source
                projects at Google and it's difficult to do so if those
                projects use exceptions, we need to advise against
                exceptions in Google open-source projects as well.
            </span>
            私たちは、Googleのオープンソースプロジェクトを使いたいのですが、もしそれらのプロジェクトが例外を使っていたら、そうするのは難しくなってしまいます。そのため、私たちはGoogleのオープンソースプロジェクトに対しても、この例外に対するアドバイスをしています。
        </span>
        <span>
            <span class="src">
                Things would probably be different if we had to do it all
                over again from scratch.
            </span>
            もし、スクラッチからすべてのことをやり直さなくてはならないのであれば、何かが違っていたかもしれません。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                This prohibition also applies to exception handling related
                features such as
                <code>std::exception_ptr</code> and
                <code>std::nested_exception</code>.
            </span>
            この禁止は例外に関連する機能(<code>std::exception_ptr</code>、<code>std::nested_exception</code>など)についても同様に適用されます。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                There is an <a href="#Windows_Code">exception</a> to
                this rule (no pun intended) for Windows code.
            </span>
            これらのルールには<a href="#Windows_Code">Windowsのコードに関する例外</a>があります(ダジャレじゃないですよ)。
        </span>
    </p>

    <h3 id="noexcept"><code>noexcept</code></h3>

    <p>
        <span>
            <span class="src">
                Specify <code>noexcept</code> when it is useful and correct.
            </span>
            有用かつ正しいときに<code>noexcept</code>を指定します。
        </span>
    </p>

    <p class="definition">
    </p>
    <p>
        <span>
            <span class="src">
                The <code>noexcept</code> specifier is used to specify whether
                a function will throw exceptions or not.
            </span>
            <code>noexcept</code>指定子は、関数が例外を投げるかどうかを指定するために使用されます。
        </span>
        <span>
            <span class="src">
                If an exception
                escapes from a function marked <code>noexcept</code>, the program
                crashes via <code>std::terminate</code>.
            </span>
            <code>noexcept</code>とマークされた関数から例外が抜け出すと、プログラムは <code>std::terminate</code> を介してクラッシュします。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                The <code>noexcept</code> operator performs a compile-time
                check that returns true if an expression is declared to not
                throw any exceptions.
            </span>
            <code>noexcept</code>演算子は、式が例外を投げないと宣言されている場合に true を返すコンパイル時のチェックを実行します。
        </span>
    </p>

    <p class="pros">
    </p>
    <ul>
        <li>
            <span>
                <span class="src">
                    Specifying move constructors as <code>noexcept</code>
                    improves performance in some cases, e.g.,
                    <code>std::vector&lt;T&gt;::resize()</code> moves rather than
                    copies the objects if T's move constructor is
                    <code>noexcept</code>.
                </span>
                ムーブコンストラクタを <code>noexcept</code> として指定すると、場合によってはパフォーマンスが向上します。
                たとえば、<code>std::vector&lt;T&gt;::resize()</code>において、Tのムーブコンストラクタが<code>noexcept</code>の場合、オブジェクトはコピーではなくムーブされます。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Specifying <code>noexcept</code> on a function can
                    trigger compiler optimizations in environments where
                    exceptions are enabled, e.g., compiler does not have to
                    generate extra code for stack-unwinding, if it knows
                    that no exceptions can be thrown due to a
                    <code>noexcept</code> specifier.
                </span>
                関数を <code>noexcept</code> 指定すると、例外が有効になっている環境でコンパイラの最適化をトリガーできるかもしれません。
                たとえば、<code>noexcept</code>指定子によって、関数が例外を投げないことがわかっている場合、コンパイラはスタックを巻き戻す(stack-unwinding)ための追加のコードを生成する必要がなくなるでしょう。
            </span>
        </li>
    </ul>

    <p class="cons">
    </p>
    <ul>
        <li>
            <span>
                <span class="src">
                    In projects following this guide
                    that have exceptions disabled it is hard
                    to ensure that <code>noexcept</code>
                    specifiers are correct, and hard to define what
                    correctness even means.
                </span>
                このガイドに沿って例外を無効にしているプロジェクトでは、<code>noexcept</code> 指定子の正しさを保証することは難しく、そもそも、その「正しさ」とは何を意味するのか定義することさえ困難です。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    It's hard, if not impossible, to undo <code>noexcept</code>
                    because it eliminates a guarantee that callers may be relying
                    on, in ways that are hard to detect.
                </span>
                一度指定した<code>noexcept</code>を元に戻すのは、不可能ではないにしても困難です。なぜなら、そのコードの呼び出し元が、コードが<code>noexcept</code>であることに依存して実装されているかもしれず、<code>noexcept</code>を取り去ることは、その保証を取り去ってしまう上、呼び出し元でそのことを検出することも難しいからです。
            </span>
        </li>
    </ul>

    <p class="decision">
    </p>
    <p>
        <span>
            <span class="src">
                You may use <code>noexcept</code> when it is useful for
                performance if it accurately reflects the intended semantics
                of your function, i.e., that if an exception is somehow thrown
                from within the function body then it represents a fatal error.
            </span>
            関数本体内から何らかの方法で例外が投げられたとき、それが常に致命的なエラーを表している場合など、関数の意図されたセマンティクスを正確に反映している場合は、パフォーマンスのために<code>noexcept</code>を使用することができます。
        </span>
        <span>
            <span class="src">
                You can assume that <code>noexcept</code> on move constructors
                has a meaningful performance benefit.
            </span>
            ムーブコンストラクタの <code>noexcept</code> には、有意にパフォーマンス上の利点があると想定してかまいません。
        </span>
        <span>
            <span class="src">
                If you think
                there is significant performance benefit from specifying
                <code>noexcept</code> on some other function, please discuss it
                with
                your project leads.
            </span>
            他の関数について、 <code>noexcept</code> を指定することで大幅なパフォーマンスの向上が見込めると考える場合は、それについてプロジェクトリーダーと話し合ってください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Prefer unconditional <code>noexcept</code> if exceptions are
                completely disabled (i.e., most Google C++ environments).
            </span>
            例外が完全に無効になっている場合(つまりほとんどのGoogleのC++環境)は、無条件の <code>noexcept</code> を使用します。
        </span>
        <span>
            <span class="src">
                Otherwise, use conditional <code>noexcept</code> specifiers
                with simple conditions, in ways that evaluate false only in
                the few cases where the function could potentially throw.
            </span>
            それ以外の場合は、条件付きの <code>noexcept</code> 指定子を使用します。この際に指定する条件は、関数が潜在的に例外を投げる可能性のあるいくつかのケースでのみ false と評価されるようにします。
        </span>
        <span>
            <span class="src">
                The tests might include type traits check on whether the
                involved operation might throw (e.g.,
                <code>std::is_nothrow_move_constructible</code> for
                move-constructing objects), or on whether allocation can throw
                (e.g., <code>absl::default_allocator_is_nothrow</code> for
                standard default allocation).
            </span>
            テストには、関連する操作が例外を投げるかどうか (ムーブコンストラクトされたオブジェクトの <code>std::is_nothrow_move_constructible</code> など)、またはアロケーション操作が例外を投げられるかどうか (標準のデフォルト割り当ての <code>absl::default_allocator_is_nothrow</code> など)に関する型トレイトのチェックが含まれる場合があります。
        </span>
        <span>
            <span class="src">
                Note in many cases the only
                possible cause for an exception is allocation failure (we
                believe move constructors should not throw except due to
                allocation failure), and there are many applications where it’s
                appropriate to treat memory exhaustion as a fatal error rather
                than an exceptional condition that your program should attempt
                to recover from.
            </span>
            多くの場合、例外の唯一の原因はアロケーション失敗であることに注意してください(ムーブコンストラクタは、アロケーションの失敗以外で例外を投げるべきではありません)。
            そして、多くのアプリケーションにおいては、メモリの枯渇は、その状態からプログラムが回復を試みるような例外的な状況として扱うよりも、致命的なエラーとして扱う方が適切でしょう。
        </span>
        <span>
            <span class="src">
                Even for other
                potential failures you should prioritize interface simplicity
                over supporting all possible exception throwing scenarios:
                instead of writing a complicated <code>noexcept</code> clause
                that depends on whether a hash function can throw, for example,
                simply document that your component doesn’t support hash
                functions throwing and make it unconditionally
                <code>noexcept</code>.
            </span>
            他の潜在的なエラーの場合でも、考えられるすべての種類の例外シナリオに対応しようとするよりも、インターフェイスのシンプルさを優先すべきです。
            たとえば、ハッシュ関数が例外を投げるかどうかに依存する複雑な<code>noexcept</code>句を記述するのではなく、そのコンポーネントが例外を投げるようなハッシュ関数をサポートしていないことをドキュメントに記載し、無条件に <code>noexcept</code> にしましょう。
        </span>
    </p>

    <h3 id="Run-Time_Type_Information__RTTI_"><span title="Run-Time Type Information (RTTI)">実行時型情報(RTTI)</span></h3>

    <p>
        <span>
            <span class="src">
                Avoid using run-time type information (RTTI).
            </span>
            実行時型情報(RTTI)は使わないでください。
        </span>
    </p>

    <p class="definition"></p>
    <p>
        <span>
            <span class="src">
                RTTI allows a
                programmer to query the C++ class of an object at
                run-time.
            </span>
            実行時型情報によって、実行時にオブジェクトの型を調べられるようになります。
        </span>
        <span>
            <span class="src">
                This is done by use of <code>typeid</code> or
                <code>dynamic_cast</code>.
            </span>
            これは、<code>typeid</code>や<code>dynamic_cast</code>を使うことで行われます。
        </span>
    </p>
    <p class="pros"></p>
    <p>
        <span>
            <span class="src">
                The standard alternatives to RTTI (described below)
                require modification or redesign of the class hierarchy
                in question.
            </span>
            実行時型情報に対応する標準的な代替手段(後述)を使おうとすると、クラスの階層構造を変更したり設計しなおしたりする必要があります。
        </span>
        <span>
            <span class="src">
                Sometimes such modifications are infeasible
                or undesirable, particularly in widely-used or mature
                code.
            </span>
            特にそのコードが既に広く使われている場合には、そのような変更を施すことは実現不可能、あるいは望ましくない場合があります。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                RTTI can be useful in some unit tests.
            </span>
            実行時型情報はユニットテストにおいて都合が良い場合があります。
        </span>
        <span>
            <span class="src">
                For example, it
                is useful in tests of factory classes where the test has
                to verify that a newly created object has the expected
                dynamic type.
            </span>
            たとえば、ファクトリクラスをテストする場合において、生成されたオブジェクトが正しい型であるか確認するためには、実行時型情報は有用です。
        </span>
        <span>
            <span class="src">
                It is also useful in managing the
                relationship between objects and their mocks.
            </span>
            また、オブジェクトとそのモックとの関係を管理するのにも便利です。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                RTTI is useful when considering multiple abstract
                objects.
            </span>
            実行時型情報は、多数の抽象オブジェクトを考えるときにも有用です。
        </span>
        <span>
            <span class="src">
                Consider
            </span>
            以下の例を見てください。
        </span>
    </p>

    <pre>bool Base::Equal(Base* other) = 0;
bool Derived::Equal(Base* other) {
  Derived* that = dynamic_cast&lt;Derived*&gt;(other);
  if (that == nullptr)
    return false;
  ...
}
</pre>

    <p class="cons"></p>
    <p>
        <span>
            <span class="src">
                Querying the type of an object at run-time frequently
                means a design problem.
            </span>
            実行時にオブジェクトの型を調べるのは、大抵の場合、プログラムに設計上の問題があることを意味しています。
        </span>
        <span>
            <span class="src">
                Needing to know the type of an
                object at runtime is often an indication that the design
                of your class hierarchy is flawed.
            </span>
            実行時にオブジェクトの型を知る必要があるということは、クラス階層構造の設計に欠陥があることを示しています。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Undisciplined use of RTTI makes code hard to maintain.
            </span>
            実行時型情報を雑に扱っていると、コードのメンテナンスが難しくなります。
        </span>
        <span>
            <span class="src">
                It can lead to type-based decision trees or switch
                statements scattered throughout the code, all of which
                must be examined when making further changes.
            </span>
            実行時型情報を扱うことで、型による分岐やswitch文がコード中に点在してしまうと、将来コードを変更したときに、点在したコードのすべてを確かめなくてならなくなってしまいます。
        </span>
    </p>

    <p class="decision"></p>
    <p>
        <span>
            <span class="src">
                RTTI has legitimate uses but is prone to abuse, so you
                must be careful when using it.
            </span>
            実行時型情報には妥当な使い方もあります。ただ、その妥当性から逸脱した使われ方をする傾向もあります。実行時型情報を使うときには十分注意してください。
        </span>
        <span>
            <span class="src">
                You may use it freely in
                unittests, but avoid it when possible in other code.
            </span>
            実行時型情報はユニットテストにおいては自由に使ってもかまいません。それ以外のコードにおいては可能な限り避けてください。
        </span>
        <span>
            <span class="src">
                In
                particular, think twice before using RTTI in new code.
            </span>
            特に、新しいコードで実行時型情報を使おうとする前には、もう一度よく考えてみてください。
        </span>
        <span>
            <span class="src">
                If
                you find yourself needing to write code that behaves
                differently based on the class of an object, consider one
                of the following alternatives to querying the type:
            </span>
            もし、オブジェクトの型によって動作が変わるようなコードを書く必要があるとわかったときには、次に示す代替手段を検討してください。
        </span>
    </p>

    <ul>
        <li>
            <span>
                <span class="src">
                    Virtual methods are the preferred way of executing
                    different code paths depending on a specific subclass
                    type.
                </span>
                仮想関数を使えば、派生クラスの型によって実行するコードパスを変えることができます。
            </span>
            <span>
                <span class="src">
                    This puts the work within the object itself.
                </span>
                この方法は、分岐する処理をオブジェクト内に書くことができます。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    If the work belongs outside the object and instead
                    in some processing code, consider a double-dispatch
                    solution, such as the Visitor design pattern.
                </span>
                その作業がオブジェクト外に属しており、処理コードも多数ある場合、Visitorパターンのような二重ディスパッチが使えないかを検討してください。
            </span>
            <span>
                <span class="src">
                    This
                    allows a facility outside the object itself to
                    determine the type of class using the built-in type
                    system.
                </span>
                この方法は、オブジェクトの外にある設備が、組み込みの型システムで、型を決定することができます。
            </span>
        </li>
    </ul>

    <p>
        <span>
            <span class="src">
                When the logic of a program guarantees that a given
                instance of a base class is in fact an instance of a
                particular derived class, then a
                <code>dynamic_cast</code> may be used freely on the
                object.
            </span>
            プログラムの構造的に、ある基底クラスのインスタンスが特定の派生クラスのものであると保証されている場合、<code>dynamic_cast</code>を使うことができるでしょう。
        </span>
        <span>
            <span class="src">
                Usually one
                can use a <code>static_cast</code> as an alternative in
                such situations.
            </span>
            通常、このような場合においては、代替手段として<code>static_cast</code>を使うこともできます。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Decision trees based on type are a strong indication
                that your code is on the wrong track.
            </span>
            型による分岐が出てきたときには、そのコードは間違った方向に進んでいることを強く示しています。
        </span>
    </p>

    <pre class="badcode">if (typeid(*data) == typeid(D1)) {
  ...
} else if (typeid(*data) == typeid(D2)) {
  ...
} else if (typeid(*data) == typeid(D3)) {
...
</pre>

    <p>
        <span>
            <span class="src">
                Code such as this usually breaks when additional
                subclasses are added to the class hierarchy.
            </span>
            このようなコードは、大抵の場合、クラスの階層構造に新たな派生クラスが増えたときに崩壊してしまいます。
        </span>
        <span>
            <span class="src">
                Moreover,
                when properties of a subclass change, it is difficult to
                find and modify all the affected code segments.
            </span>
            また、派生クラスの性質が変わったときには、その影響があるすべてのコードを検索し、それらを変更していくことも非常に難しいでしょう。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Do not hand-implement an RTTI-like workaround.
            </span>
            実行時型情報のようなものを自前で実装するのもやめてください。
        </span>
        <span>
            <span class="src">
                The
                arguments against RTTI apply just as much to workarounds
                like class hierarchies with type tags.
            </span>
            ここまでしてきた実行時型情報に関する議論は、オブジェクトに型を表すタグをつけるような手法にも同様に当てはまります。
        </span>
        <span>
            <span class="src">
                Moreover,
                workarounds disguise your true intent.
            </span>
            その上、このような手法は、あなたの真の意図を隠してしまいます。
        </span>
    </p>

    <h3 id="Casting"><span title="Casting">キャスト</span></h3>

    <p>
        <span>
            <span class="src">
                Use C++-style casts
                like <code>static_cast&lt;float&gt;(double_value)</code>, or brace
                initialization for conversion of arithmetic types like
                <code>int64_t y = int64_t{1} &lt;&lt; 42</code>.
            </span>
            <code>static_cast&lt;float&gt;(double_value)</code>のようなC++スタイルのキャストや、<code>int64_t y = int64_t{1} &lt;&lt; 42</code>のような算術型の変換には波括弧による初期化を使ってください。
        </span>
        <span>
            <span class="src">
                Do not use
                cast formats like <code>(int)x</code> unless the cast is to
                <code>void</code>.
            </span>
            <code>void</code>にキャストする場合を除いて<code>(int)x</code>の形のキャストは使わないでください。
        </span>
        <span>
            <span class="src">
                You may use cast formats like `T(x)` only when
                `T` is a class type.
            </span>
            また、<code>T(x)</code>のような形のキャストは、型<code>T</code>がクラスである場合に限り、使用してもかまいません。
        </span>
    </p>

    <p class="definition"></p>
    <p>
        <span>
            <span class="src">
                C++ introduced a
                different cast system from C that distinguishes the types
                of cast operations.
            </span>
            C++には、C言語とは異なり、操作の種類によって区別されるキャストの仕組みが導入されています。
        </span>
    </p>
    <p class="pros"></p>
    <p>
        <span>
            <span class="src">
                The problem with C casts is the ambiguity of the operation;
                sometimes you are doing a <em>conversion</em>
                (e.g., <code>(int)3.5</code>) and sometimes you are doing
                a <em>cast</em> (e.g., <code>(int)"hello"</code>).
            </span>
            C言語のキャストの問題点は、操作が曖昧ということです。ときに<em>変換</em>(例:<code>(int)3.5</code>)であり、ときに<em>キャスト</em>(例:<code>(int)"hello"</code>)を表しています。
        </span>
        <span>
            <span class="src">
                Brace
                initialization and C++ casts can often help avoid this
                ambiguity.
            </span>
            波括弧による初期化とC++のキャストは、この曖昧さを回避するための役に立ちます。
        </span>
        <span>
            <span class="src">
                Additionally, C++ casts are more visible when searching for
                them.
            </span>
            加えて、C++のキャストは検索性も高いです。
        </span>
    </p>
    <p class="cons"></p>
    <p>
        <span>
            <span class="src">
                The C++-style cast syntax is verbose and cumbersome.
            </span>
            C++のキャストは長くて面倒くさいです。
        </span>
    </p>
    <p class="decision"></p>
    <p>
        <span>
            <span class="src">
                In general, do not use C-style casts.
            </span>
            原則として、C言語スタイルのキャストを使わないでください。
        </span>
        <span>
            <span class="src">
                Instead, use these C++-style casts when
                explicit type conversion is necessary.
            </span>
            明示的に型変換が必要な場合は、C言語スタイルのキャストのかわりに、C++スタイルのキャストを使ってください。
        </span>
    </p>

    <ul>
        <li>
            <span>
                <span class="src">
                    Use brace initialization to convert arithmetic types
                    (e.g., <code>int64_t{x}</code>).
                </span>
                算術型の変換には、波括弧による初期化を使用してください(例:<code>int64_t{x}</code>)。
            </span>
            <span>
                <span class="src">
                    This is the safest approach because code
                    will not compile if conversion can result in information loss.
                </span>
                この方法は、型変換によって情報が失われる場合にコンパイルエラーとなるため、最も安全です。
            </span>
            <span>
                <span class="src">
                    The
                    syntax is also concise.
                </span>
                文法も簡単です。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Use <code>absl::implicit_cast</code>
                    to safely cast up a type hierarchy,
                    e.g., casting a <code>Foo*</code> to a
                    <code>SuperclassOfFoo*</code> or casting a
                    <code>Foo*</code> to a <code>const Foo*</code>.
                </span>
                型階層におけるアップキャストを安全に行うためには<code>absl::implicit_cast</code>を使用してください。これには<code>Foo*</code>から<code>SuperclassOfFoo*</code>のようなキャストや、
                <code>Foo*</code>から<code>const Foo*</code>のようなキャストを含みます。
            </span>
            <span>
                <span class="src">
                    C++
                    usually does this automatically but some situations
                    need an explicit up-cast, such as use of the
                    <code>?:</code> operator.
                </span>
                C++は、通常は、自動的にこれを行いますが、<code>?:</code>演算子をつかうときなど、明示的にアップキャストを記述しなくてはならない状況もあります。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Use <code>static_cast</code> as the equivalent of a C-style cast
                    that does value conversion, when you need to
                    explicitly up-cast a pointer from a class to its superclass, or when
                    you need to explicitly cast a pointer from a superclass to a
                    subclass.
                </span>
                あるクラスのポインタを基底クラスのポインタに変換する明示的なアップキャストや、基底クラスのポインタを派生クラスのポインタに明示的にキャストするダウンキャストを行いたい場合には、値の変換を行うC言語スタイルのキャストと等価な、<code>static_cast</code>を使用してください。
            </span>
            <span>
                <span class="src">
                    In this last case, you must be sure your object is
                    actually an instance of the subclass.
                </span>
                ダウンキャストを行う場合は、オブジェクトが実際にその派生クラスのインスタンスであることが確信できていないといけません。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Use <code>const_cast</code> to remove the
                    <code>const</code> qualifier (see <a href="#Use_of_const">const</a>).
                </span>
                <code>const</code>修飾子(<a href="#Use_of_const">const</a>を参照)を外すためには<code>const_cast</code>を使用してください。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Use <code>reinterpret_cast</code> to do unsafe
                    conversions of pointer types to and from integer and
                    other pointer types,
                    including <code>void*</code>.
                </span>
                ポインタ型と整数型との間の変換や、型の異なるポインタ型との間の変換(<code>void*</code>も含みます)のような、安全でない変換を行う場合は<code>reinterpret_cast</code>を使用してください。
            </span>
            <span>
                <span class="src">
                    Use this only if you know what you
                    are doing and you understand the aliasing issues.
                </span>
                ただし、<code>reinterpret_cast</code>は、あなたが何をしようとしているのかわかっていて、エイリアシングの問題についても十分理解している場合に限って使用するようにしてください。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Use <code>absl::bit_cast</code> to interpret the raw bits of a
                    value using a different type of the same size (a type pun), such as
                    interpreting the bits of a <code>double</code> as
                    <code>int64_t</code>.
                </span>
                <code>double</code>のビット列を<code>int64_t</code>として解釈するような、同じサイズの違う型を使って生のビット列を解釈したい(type-punning)場合は<code>absl::bit_cast</code>を使用してください。
            </span>
        </li>

    </ul>

    <p>
        <span>
            <span class="src">
                See the <a href="#Run-Time_Type_Information__RTTI_">
                RTTI section</a> for guidance on the use of
                <code>dynamic_cast</code>.
            </span>
            <code>dynamic_cast</code>に関するガイドについては<a href="#Run-Time_Type_Information__RTTI_">実行時型情報のセクション</a>も参照してください。
        </span>
    </p>

    <h3 id="Streams"><span title="Streams">ストリーム</span></h3>

    <p>
        <span>
            <span class="src">
                Use streams where appropriate, and stick to "simple"
                usages.
            </span>
            ストリームは、それを使うのが適切な場合に、「シンプルな使い方」に限定して、使用してください。
        </span>
        <span>
            <span class="src">
                Overload <code>&lt;&lt;</code> for streaming only for types
                representing values, and write only the user-visible value, not any
                implementation details.
            </span>
            ストリームにおける<code>&lt;&lt;</code>のオーバーロードは、値を表す型に対してその値を出力するだけの実装とし、それ以外の実装は持たないようにしてください。
        </span>
    </p>

    <p class="definition"></p>
    <p>
        <span>
            <span class="src">
                Streams are the standard I/O abstraction in C++, as
                exemplified by the standard header <code>&lt;iostream&gt;</code>.
            </span>
            ストリームは、標準ヘッダー<code>&lt;iostream&gt;</code>で例示されるように、C++における標準的な入出力の抽象概念です。
        </span>
        <span>
            <span class="src">
                They are widely used in Google code, mostly for debug logging
                and test diagnostics.
            </span>
            多くはデバッグログやテスト診断のためですが、Googleのコードでは広く使われています。
        </span>
    </p>
    <p class="pros"></p>
    <p>
        <span>
            <span class="src">
                The <code>&lt;&lt;</code> and <code>&gt;&gt;</code>
                stream operators provide an API for formatted I/O that
                is easily learned, portable, reusable, and extensible.
            </span>
            ストリーム演算子<code>&lt;&lt;</code>と<code>&gt;&gt;</code>はフォーマットされた入出力のためのAPIを提供します。これらは、学びやすく、移植性があり、再利用可能で拡張性もあります。
        </span>
        <span>
            <span class="src">
                <code>printf</code>, by contrast, doesn't even support
                <code>std::string</code>, to say nothing of user-defined types,
                and is very difficult to use portably.
            </span>
            <code>printf</code>は、それとは対照的に、<code>std::string</code>をサポートしませんし、ユーザー定義型もサポートしません。また、移植性の面では非常に難があります。
        </span>
        <span>
            <span class="src">
                <code>printf</code> also obliges you to choose among the
                numerous slightly different versions of that function,
                and navigate the dozens of conversion specifiers.
            </span>
            <code>printf</code>はまた、微妙に異なるたくさんの関数のバージョンがあり、さらに、たくさんの変換指定子があり、それらの中から適切なものを選ばなくてはなりません。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Streams provide first-class support for console I/O
                via <code>std::cin</code>, <code>std::cout</code>,
                <code>std::cerr</code>, and <code>std::clog</code>.
            </span>
            ストリームは、<code>std::cin</code>や<code>std::cout</code>、<code>std::cerr</code>、<code>std::clog</code>を通して、一級のコンソール入出力サポートを提供します。
        </span>
        <span>
            <span class="src">
                The C APIs do as well, but are hampered by the need to
                manually buffer the input.
            </span>
            C言語のAPIでも同様のことができますが、入力は手動でバッファする必要があるため、面倒です。
        </span>
    </p>
    <p class="cons"></p>
    <ul>
        <li>
            <span>
                <span class="src">
                    Stream formatting can be configured by mutating the
                    state of the stream.
                </span>
                ストリームの書式化はストリームの状態を変更することで設定できます。
            </span>
            <span>
                <span class="src">
                    Such mutations are persistent, so
                    the behavior of your code can be affected by the entire
                    previous history of the stream, unless you go out of your
                    way to restore it to a known state every time other code
                    might have touched it.
                </span>
                この変更は持続するため、ストリームに関するあなたのコードの挙動は、他のコードがストリームに触れるたびに毎回それを既知の状態に戻す独自の方法でも踏まない限り、そこまでのストリーム操作の履歴すべての影響を受けることになります。
            </span>
            <span>
                <span class="src">
                    User code can not only modify the
                    built-in state, it can add new state variables and behaviors
                    through a registration system.
                </span>
                ユーザーコードは、組み込みの状態を変更できるだけでなく、新しい状態変数や動作の追加も、登録の仕組みを通して行うことができます。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    It is difficult to precisely control stream output, due
                    to the above issues, the way code and data are mixed in
                    streaming code, and the use of operator overloading (which
                    may select a different overload than you expect).
                </span>
                ストリームの出力を正確に制御するのは難しいです。ここまで述べた問題の他、ストリームを扱うコードにおいてはコードとデータが混ざり合ってしまうこと、さらに、演算子のオーバーロードの扱い方も関わっています(意図に反するオーバーロードが選択されてしまうかもしれません)。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    The practice of building up output through chains
                    of <code>&lt;&lt;</code> operators interferes with
                    internationalization, because it bakes word order into the
                    code, and streams' support for localization is  <a href="http://www.boost.org/doc/libs/1_48_0/libs/locale/doc/html/rationale.html#rationale_why">
                    flawed</a>.
                </span>
                <code>&lt;&lt;</code>演算子による連結によって出力を構築する方法は、国際化対応を妨げます。なぜならば、このやり方は、語順を固定しなくてはならず、ストリームの多言語対応自体にも<a
                    href="http://www.boost.org/doc/libs/1_48_0/libs/locale/doc/html/rationale.html#rationale_why">欠陥がある</a>からです。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    The streams API is subtle and complex, so programmers must
                    develop experience with it in order to use it effectively.
                </span>
                ストリームAPIは繊細で複雑なため、プログラマがそれらを効率的に扱うためにはストリームに関するそれなりの経験を要します。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Resolving the many overloads of <code>&lt;&lt;</code> is
                    extremely costly for the compiler.
                </span>
                <code>&lt;&lt;</code>演算子のたくさんのオーバーロードがある中から、それを解決するのは、コンパイラにとって非常にコストの掛かる仕事です。
            </span>
            <span>
                <span class="src">
                    When used pervasively in a
                    large code base, it can consume as much as 20% of the parsing
                    and semantic analysis time.
                </span>
                大きなコードベースであまねくそれが使われたとき、構文解析と意味解析の時間のうちの20％を消費し得ます。
            </span>
        </li>
    </ul>

    <p class="decision"></p>
    <p>
        <span>
            <span class="src">
                Use streams only when they are the best tool for the job.
            </span>
            ストリームは、目的を達成するために最適なツールとなる場合のみ使いましょう。
        </span>
        <span>
            <span class="src">
                This is typically the case when the I/O is ad-hoc, local,
                human-readable, and targeted at other developers rather than
                end-users.
            </span>
            これは、典型的には、エンドユーザー向けというよりも、開発者たちのために、アドホックで、局所的で、ヒューマンリーダブルな入出力を行いたいときのことを指しています。
        </span>
        <span>
            <span class="src">
                Be consistent with the code around you, and with the
                codebase as a whole; if there's an established tool for
                your problem, use that tool instead.
            </span>
            周りのコードやコードベース全体と一貫性を持たせてください。もし、この問題に対応するためのツールが既にあるのならば、それを使うようにしてください。
        </span>

        <span>
            <span class="src">
                In particular,

                logging libraries are usually a better
                choice than <code>std::cerr</code> or <code>std::clog</code>
                for diagnostic output, and the libraries in

                <code>absl/strings</code>
                or the equivalent are usually a
                better choice than <code>std::stringstream</code>.
            </span>
            特に、診断に関する出力については<code>std::cerr</code> や <code>std::clog</code> より、ロギングのためのライブラリを使う方がいいでしょう。
            <code>absl/strings</code>やそれと同等のライブラリを使うことは、<code>std::stringstream</code>よりもよい選択となるでしょう。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Avoid using streams for I/O that faces external users or
                handles untrusted data.
            </span>
            ストリームを外部のユーザーとの入出力のために使用してはいけません。また、ストリームでは信頼できないデータを扱ってはいけません。
        </span>
        <span>
            <span class="src">
                Instead, find and use the appropriate
                templating libraries to handle issues like internationalization,
                localization, and security hardening.
            </span>
            このような目的においては、ストリームのかわりに、多言語化の問題に対応し、セキュリティに強固な、より適切なテンプレート化ライブラリを探して、それを使うようにしてください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                If you do use streams, avoid the stateful parts of the
                streams API (other than error state), such as <code>imbue()</code>,
                <code>xalloc()</code>, and <code>register_callback()</code>.
            </span>
            ストリームを使うと決めた場合でも、ストリームAPIのうち、エラー状態を除いて、ステートフルなものは使用しないでください。
            たとえば、<code>imbue()</code>や<code>xalloc()</code>、<code>register_callback()</code>などが当てはまります。
        </span>
        <span>
            <span class="src">
                Use explicit formatting functions (such as
                <code>absl::StreamFormat()</code>) rather than
                stream manipulators or formatting flags to control formatting
                details such as number base, precision, or padding.
            </span>
            基数や精度、出力幅などの制御のためには、マニピュレータやフラグではなく、明示的なフォーマット関数(たとえば<code>absl::StreamFormat()</code>)を使用してください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Overload <code>&lt;&lt;</code> as a streaming operator
                for your type only if your type represents a value, and
                <code>&lt;&lt;</code> writes out a human-readable string
                representation of that value.
            </span>
            独自の型でストリーム演算子として<code>&lt;&lt;</code>をオーバーロードするのは、
            その型が何らかの値を表現したものであり、かつ、<code>&lt;&lt;</code>がヒューマンリーダブルな文字列を出力する場合のみに限定してください。
        </span>
        <span>
            <span class="src">
                Avoid exposing implementation
                details in the output of <code>&lt;&lt;</code>; if you need to print
                object internals for debugging, use named functions instead
                (a method named <code>DebugString()</code> is the most common
                convention).
            </span>
            <code>&lt;&lt;</code>による出力で、クラスの内部実装を公開してしまわないようにしてください。オブジェクトの内部状態をデバッグのために出力したい場合は、<code>&lt;&lt;</code>のかわりに、名前をつけた関数(慣習的には<code>DebugString()</code>という名前がもっともよく使われます)を用意してください。
        </span>
    </p>

    <h3 id="Preincrement_and_Predecrement"><span title="Preincrement and Predecrement">前置インクリメントと前置デクリメント</span></h3>

    <p>
        <span>
            <span class="src">
                Use the prefix form (<code>++i</code>) of the increment and
                decrement operators unless you need postfix semantics.
            </span>
            インクリメントとデクリメント演算子は、後置する必要がある場合を除いて、前置の形(<code>++i</code>)を使用してください。
        </span>
    </p>

    <p class="definition"></p>
    <p>
        <span>
            <span class="src">
                When a variable
                is incremented (<code>++i</code> or <code>i++</code>) or
                decremented (<code>--i</code> or <code>i--</code>) and
                the value of the expression is not used, one must decide
                whether to preincrement (decrement) or postincrement
                (decrement).
            </span>
            変数がインクリメント(<code>++i</code>もしくは<code>i++</code>)あるいはデクリメント(<code>--i</code>もしくは<code>i--</code>)され、かつ、その式の結果が使われないとき、前置インクリメント(デクリメント)を使うか後置インクリメント(デクリメント)を使うかを決めなければなりません。
        </span>
    </p>
    <p class="pros"></p>
    <p>
        <span>
            <span class="src">
                A postfix increment/decrement expression evaluates to the value
                <i>as it was before it was modified</i>.
            </span>
            後置インクリメント/デクリメント式は、<em>変更される前の値として</em>評価されます。
        </span>
        <span>
            <span class="src">
                This can result in code that is more
                compact but harder to read.
            </span>
            その結果、コードはよりコンパクトになりますが、読みにくくもなります。
        </span>
        <span>
            <span class="src">
                The prefix form is generally more readable, is
                never less efficient, and can be more efficient because it doesn't need to
                make a copy of the value as it was before the operation.
            </span>
            前置する形は、一般に読みやすく、決して非効率にならず、操作前の値のコピーを作成する必要がないことから、むしろ効率的になることもあります。
        </span>
    </p>
    <p class="cons"></p>
    <p>
        <span>
            <span class="src">
                The tradition developed, in C, of using post-increment, even
                when the expression value is not used, especially in
                <code>for</code> loops.
            </span>
            C言語における伝統的な開発では、<code>for</code>ループなど、式の結果が使われないときでさえ、後置の形が使われていました。
        </span>
        <span>
            <span class="src">
                Some find post-increment easier
                to read, since the "subject" (<code>i</code>) precedes
                the "verb" (<code>++</code>), just like in English.
            </span>
            後置インクリメントは、英語と同じように、主語(<code>i</code>)の後に動詞(<code>++</code>)と続くため、読みやすいと感じる人もいます。
        </span>
    </p>
    <p class="decision"></p>
    <p>
        <span>
            <span class="src">
                Use prefix increment/decrement, unless the code explicitly
                needs the result of the postfix increment/decrement expression.
            </span>
            コードが明示的に後置インクリメント/デクリメント式の結果を必要としない限り、前置インクリメント/デクリメントを使用します。
        </span>
    </p>

    <h3 id="Use_of_const"><span title="Use of const">constの使い方</span></h3>

    <p>
        <span>
            <span class="src">
                In APIs, use <code>const</code> whenever it makes sense.
            </span>
            APIでは、理にかなっているのならば、常に<code>const</code>を使ってください。
        </span>
        <span>
            <span class="src">
                <code>constexpr</code> is a better choice for some uses of
                const.
            </span>
            <code>const</code>よりも<code>constexpr</code>を使うほうがよい場面もあります。
        </span>
    </p>

    <p class="definition"></p>
    <p>
        <span>
            <span class="src">
                Declared variables and parameters can be preceded
                by the keyword <code>const</code> to indicate the variables
                are not changed (e.g., <code>const int foo</code>).
            </span>
            変数や引数の宣言には、その変数が変更されないことを示すために、<code>const</code>キーワードを前置することができます(例:<code>const int foo</code>)。
        </span>
        <span>
            <span class="src">
                Class
                functions can have the <code>const</code> qualifier to
                indicate the function does not change the state of the
                class member variables (e.g., <code>class Foo { int
                Bar(char c) const; };</code>).
            </span>
            クラスのメンバ関数は、その関数がクラスのメンバ変数の状態を変更しないということを示すために、<code>const</code>修飾子を持つことができます(例:<code>class Foo { int Bar(char c) const; };</code>)。
        </span>
    </p>
    <p class="pros"></p>
    <p>
        <span>
            <span class="src">
                Easier for people to understand how variables are being
                used.
            </span>
            <code>const</code>は変数の扱われ方に関する理解の助けとなります。
        </span>
        <span>
            <span class="src">
                Allows the compiler to do better type checking,
                and, conceivably, generate better code.
            </span>
            <code>const</code>はコンパイラによる型チェックを助け、場合によってはよりよいコードを生成できるようにします。
        </span>
        <span>
            <span class="src">
                Helps people
                convince themselves of program correctness because they
                know the functions they call are limited in how they can
                modify your variables.
            </span>
            関数に<code>const</code>があることで、その関数が変数の変更に対して制限されていることがわかり、それはプログラムの正しさについて納得するための助けになります。
        </span>
        <span>
            <span class="src">
                Helps people know what functions
                are safe to use without locks in multi-threaded
                programs.
            </span>
            <code>const</code>は、マルチスレッド下において、どの関数がロックなしで呼び出してもよいかを知る手助けにもなります。
        </span>
    </p>
    <p class="cons"></p>
    <p>
        <span>
            <span class="src">
                <code>const</code> is viral: if you pass a
                <code>const</code> variable to a function, that function
                must have <code>const</code> in its prototype (or the
                variable will need a <code>const_cast</code>).
            </span>
            <code>const</code>は伝染します。<code>const</code>な変数を関数に渡すとき、関数はそのプロトタイプで<code>const</code>を持っていなくてはなりません(さもなくば、変数は<code>const_cast</code>を必要とします)。
        </span>
        <span>
            <span class="src">
                This can
                be a particular problem when calling library
                functions.
            </span>
            これは、特に、ライブラリ関数を呼び出すときに問題になることもあります。
        </span>
    </p>
    <p class="decision"></p>
    <p>
        <span>
            <span class="src">
                We strongly recommend using <code>const</code>
                in APIs (i.e., on function parameters, methods, and
                non-local variables) wherever it is meaningful and accurate.
            </span>
            正確で有意義なときにはいつでも、API(関数の引数や非ローカル変数など)に(<code>const</code>を使うことを強く推奨します。
        </span>
        <span>
            <span class="src">
                This
                provides consistent, mostly compiler-verified documentation
                of what objects an operation can mutate.
            </span>
            これによって、どのオブジェクトが各操作によって変更されうるかという、一貫性があり、かつ、コンパイラによってほぼ検証済みのドキュメントが提供されることになります。
        </span>
        <span>
            <span class="src">
                Having
                a consistent and reliable way to distinguish reads from writes
                is critical to writing thread-safe code, and is useful in
                many other contexts as well.
            </span>
            一貫性と信頼性を持って、読み込みと書き込みを判別することは、スレッドセーフなコードを書く上では不可欠ですし、その他多くの場合にも有用です。
        </span>

        <span>
            <span class="src">
                In particular:
            </span>
            特に:
        </span>
    </p>

    <ul>
        <li>
            <span>
                <span class="src">
                    If a function guarantees that it will not modify an argument
                    passed by reference or by pointer, the corresponding function parameter
                    should be a reference-to-const (<code>const T&amp;</code>) or
                    pointer-to-const (<code>const T*</code>), respectively.
                </span>
                関数が、参照渡しあるいはポインタ渡しされる引数を変更しないことを保証する場合、その引数は、const参照(<code>const T&amp;</code>)かconstポインタ(<code>const T*</code>)でないといけません。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    For a function parameter passed by value, <code>const</code> has
                    no effect on the caller, thus is not recommended in function
                    declarations.
                </span>
                関数の引数を値渡しする場合、<code>const</code>は呼び出し側にとって、なんの意味もないため、関数宣言の中では推奨されません。
            </span>
            <span>
                <span class="src">
                    See
                    <a href="https://abseil.io/tips/109">TotW #109</a>.
                </span>
                <a href="https://abseil.io/tips/109">TotW #109</a>を読んでください。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    Declare methods to be <code>const</code> unless they
                    alter the logical state of the object (or enable the user to modify
                    that state, e.g., by returning a non-const reference, but that's
                    rare), or they can't safely be invoked concurrently.
                </span>
                メソッド宣言においては、そのメソッドがオブジェクトの論理状態を変更したり(あるいは、非const
                参照を返すなどして、ユーザーがその状態を変更できるようにする。ただし、これはまれなケースです)、複数スレッドから安全に同時に呼び出すことができない場合を除いて、<code>const</code>にしてください。
            </span>
        </li>
    </ul>

    <p>
        <span>
            <span class="src">
                Using <code>const</code> on local variables is neither encouraged
                nor discouraged.
            </span>
            ローカル変数に <code>const</code>を使うことは推奨でも非推奨でもありません。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                All of a class's <code>const</code> operations should be safe
                to invoke concurrently with each other.
            </span>
            クラスのすべての<code>const</code>な操作は、互いに同時に並行して実行できなければなりません。
        </span>
        <span>
            <span class="src">
                If that's not feasible, the class must
                be clearly documented as "thread-unsafe".
            </span>
            それができない場合、そのクラスは「スレッドセーフではない」とドキュメントに明記しなければなりません。
        </span>
    </p>

    <h4 class="stylepoint_subsection"><span title="Where to put the const">constをどこに置くか</span></h4>

    <p>
        <span>
            <span class="src">
                Some people favor the form <code>int const *foo</code>
                to <code>const int* foo</code>.
            </span>
            プログラマの中には、<code>const int* foo</code>という形より<code>int const *foo</code>という形を好む人もいます。
        </span>
        <span>
            <span class="src">
                They argue that this is
                more readable because it's more consistent: it keeps the
                rule that <code>const</code> always follows the object
                it's describing.
            </span>
            彼らの主張は「<code>const</code>は常にその特徴付けをするオブジェクトの後に続くというルールを一貫して保てるため、可読性が高い」というものです。
        </span>
        <span>
            <span class="src">
                However, this consistency argument
                doesn't apply in codebases with few deeply-nested pointer
                expressions since most <code>const</code> expressions
                have only one <code>const</code>, and it applies to the
                underlying value.
            </span>
            しかしながら、この一貫性に対する主張は、深くネストされたポインタの表現には適用されません。ほとんどの<code>const</code>表現は、1つの<code>const</code>のみが書かれ、それはポインタが指し示す値に対して適用されるからです。
        </span>
        <span>
            <span class="src">
                In such cases, there's no consistency
                to maintain.
            </span>
            このような場合、もはや一貫性は保たれません。
        </span>
        <span>
            <span class="src">
                Putting the <code>const</code> first is
                arguably more readable, since it follows English in
                putting the "adjective" (<code>const</code>) before the
                "noun" (<code>int</code>).
            </span>
            <code>const</code>を前置するほうが、おそらく可読性が高まります。これは、英語の文法の「形容詞(<code>const</code>)が名詞(<code>int</code>)の前にくる」と一致しているからです。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                That said, while we encourage putting
                <code>const</code> first, we do not require it.
            </span>
            以上より、我々は、<code>const</code>を先に書くのを推奨しますが、これを必須のルールとはしません。
        </span>
        <span>
            <span class="src">
                But be
                consistent with the code around you!
            </span>
            ただし、周囲のコードとの一貫性は保つようにしてください。
        </span>
    </p>

    <h3 id="Use_of_constexpr"><span title="Use of constexpr">constexprの使い方</span></h3>

    <p>
        <span>
            <span class="src">
                Use <code>constexpr</code> to define true
                constants or to ensure constant initialization.
            </span>
            真の定数を定義したいときや、定数初期化を保証したいときには、<code>constexpr</code>を使用してください。
        </span>
    </p>

    <p class="definition"></p>
    <p>
        <span>
            <span class="src">
                Some variables can be declared <code>constexpr</code>
                to indicate the variables are true constants, i.e., fixed at
                compilation/link time.
            </span>
            変数を<code>constexpr</code>として宣言することで、それが真の定数(コンパイル時かリンク時に決定)されることを示すことができます。
        </span>
        <span>
            <span class="src">
                Some functions and constructors
                can be declared <code>constexpr</code> which enables them
                to be used in defining a <code>constexpr</code>
                variable.
            </span>
            また、関数やコンストラクタを<code>constexpr</code>として宣言することで、それを<code>constexpr</code>変数の定義のために使えるようにすることができます。
        </span>
    </p>
    <p class="pros"></p>
    <p>
        <span>
            <span class="src">
                Use of <code>constexpr</code> enables definition of
                constants with floating-point expressions rather than
                just literals; definition of constants of user-defined
                types; and definition of constants with function
                calls.
            </span>
            <code>constexpr</code>を使うことで、ただのリテラルではない浮動小数点式を、定数として宣言できるようになります。また、<code>constexpr</code>によって、ユーザー定義の型を定数として宣言したり、関数呼び出しの結果を定数として定義したりすることができるようになります。
        </span>
    </p>
    <p class="cons"></p>
    <p>
        <span>
            <span class="src">
                Prematurely marking something as constexpr may cause
                migration problems if later on it has to be downgraded.
            </span>
            早まって何かをconstexprで宣言してしまうと、後でダウングレードする必要がでてきた場合、マイグレーション時の問題となるかもしれません。
        </span>
        <span>
            <span class="src">
                Current restrictions on what is allowed in constexpr
                functions and constructors may invite obscure workarounds
                in these definitions.
            </span>
            現時点では、関数やコンストラクタにconstexprをつけることが認められていますが、それによってそれらの定義に、まだあまり知られていない手法を引き込んでしまうかもしれません。
        </span>
    </p>
    <p class="decision"></p>
    <p>
        <span>
            <span class="src">
                <code>constexpr</code> definitions enable a more
                robust specification of the constant parts of an
                interface.
            </span>
            <code>constexpr</code>によって、インターフェースの定数に関する部分を、より堅牢なものにできます。
        </span>
        <span>
            <span class="src">
                Use <code>constexpr</code> to specify true
                constants and the functions that support their
                definitions.
            </span>
            真の定数を決めるときや、関数が真の定数の定義をサポートするときは、<code>constexpr</code>を使用してください。
        </span>
        <span>
            <span class="src">
                Avoid complexifying function definitions to
                enable their use with <code>constexpr</code>.
            </span>
            ただし、<code>constexpr</code>を使いたいがためだけに、関数定義を複雑化させるのは避けてください。
        </span>
        <span>
            <span class="src">
                Do not use
                <code>constexpr</code> to force inlining.
            </span>
            また、インライン化を強制する目的では<code>constexpr</code>を使用してはいけません。
        </span>
    </p>

    <h3 id="Integer_Types"><span title="Integer Types">整数型</span></h3>

    <p>
        <span>
            <span class="src">
                Of the built-in C++ integer types, the only one used
                is
                <code>int</code>.
            </span>
            C++における組み込みの整数型の中で、最も使われているのは<code>int</code>です。
        </span>
        <span>
            <span class="src">
                If a program needs a variable of a
                different size, use
                a precise-width integer type from
                <code>&lt;cstdint&gt;</code>, such as
                <code>int16_t</code>.
            </span>
            プログラムが異なるサイズの変数を必要とするときは、<code>&lt;cstdint&gt;</code>から、<code>int16_t</code>のような、サイズが決まった整数型を使うようにしてください。
        </span>
        <span>
            <span class="src">
                If your variable represents a
                value that could ever be greater than or equal to 2^31
                (2GiB), use a 64-bit type such as
                <code>int64_t</code>.
            </span>
            変数が、2^31 (2GiB)以上の値を示すかもしれない場合、<code>int64_t</code>のような64ビットの型を使ってください。
        </span>
        <span>
            <span class="src">
                Keep in mind that even if your value won't ever be too large
                for an <code>int</code>, it may be used in intermediate
                calculations which may require a larger type.
            </span>
            また、変数が<code>int</code>の範囲を超えることがないとわかっている場合でも、その中間の計算においては、より大きな型が必要とされることもあるため、そのことを常に念頭に置くようにしてください。
        </span>
        <span>
            <span class="src">
                When in doubt,
                choose a larger type.
            </span>
            迷ったときには大きな型を選びましょう。
        </span>
    </p>

    <p class="definition"></p>
    <p>
        <span>
            <span class="src">
                C++ does not precisely specify the sizes of integer types like <code>int</code>.
            </span>
            C++の仕様において、<code>int</code>のような整数型のサイズは厳密に決められていません。
        </span>
        <span>
            <span class="src">
                Typically people assume that <code>short</code> is 16 bits,
                <code>int</code> is 32 bits, <code>long</code> is 32 bits
                and <code>long long</code> is 64 bits.
            </span>
            多くの場合、<code>short</code>が16ビット、<code>int</code>が32ビット、<code>long</code>が32ビット、<code>long long</code>は64ビットであると仮定されています。
        </span>
    </p>
    <p class="pros"></p>
    <p>
        <span>
            <span class="src">
                Uniformity of declaration.
            </span>
            宣言が画一的です。
        </span>
    </p>
    <p class="cons"></p>
    <p>
        <span>
            <span class="src">
                The sizes of integral types in C++ can vary based on
                compiler and architecture.
            </span>
            C++における整数型のサイズは、そのコンパイラやアーキテクチャに基づいて異なります。
        </span>
    </p>
    <p class="decision"></p>

    <p>
        <span>
            <span class="src">
                The standard library header <code>&lt;cstdint&gt;</code> defines types
                like <code>int16_t</code>, <code>uint32_t</code>,
                <code>int64_t</code>, etc.
            </span>
            標準ライブラリの<code>&lt;cstdint&gt;</code>ヘッダーは、<code>int16_t</code>や<code>uint32_t</code>、<code>int64_t</code>などのような型を定義しています。
        </span>
        <span>
            <span class="src">
                You should always use
                those in preference to <code>short</code>, <code>unsigned
                long long</code> and the like, when you need a guarantee
                on the size of an integer.
            </span>
            整数型のサイズを保証する必要がある場合は、<code>short</code>や<code>unsigned long long</code>等ではなく、常に<code>int16_t</code>や<code>uint64_t</code>を優先して使ってください。
        </span>
        <span>
            <span class="src">
                Of the C integer types, only
                <code>int</code> should be used.
            </span>
            C言語の整数型は、<code>int</code>のみが使用できます。
        </span>
        <span>
            <span class="src">
                When appropriate, you
                are welcome to use standard types like
                <code>size_t</code> and <code>ptrdiff_t</code>.
            </span>
            また、それが適切な場合は、<code>size_t</code>や<code>ptrdiff_t</code>などの標準の型を使用してもかまいません。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                We use <code>int</code> very often, for integers we
                know are not going to be too big, e.g., loop counters.
            </span>
            たとえばループカウンタなど、そんなに大きくならないとわかっている整数について、<code>int</code>は非常によく使われます。
        </span>
        <span>
            <span class="src">
                Use plain old <code>int</code> for such things.
            </span>
            このような場合は、Plain Old な<code>int</code>を使ってください。
        </span>
        <span>
            <span class="src">
                You
                should assume that an <code>int</code> is

                at least 32 bits, but don't
                assume that it has more than 32 bits.
            </span>
            <code>int</code>は最低でも32ビットあると仮定して構いません。
            ただし、32ビットよりも大きいという仮定を行ってはいけません。
        </span>
        <span>
            <span class="src">
                If you need a 64-bit
                integer type, use <code>int64_t</code> or <code>uint64_t</code>.
            </span>
            もし64ビットの整数型を必要とする場合は、<code>int64_t</code>か<code>uint64_t</code>を使ってください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                For integers we know can be "big",
                use
                <code>int64_t</code>.
            </span>
            大きくなるかもしれないことがわかっている整数については、<code>int64_t</code>を使ってください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                You should not use the unsigned integer types such as
                <code>uint32_t</code>, unless there is a valid
                reason such as representing a bit pattern rather than a
                number, or you need defined overflow modulo 2^N.
            </span>
            <code>uint32_t</code>等のunsignedな整数型は、明確な理由がない限り使用すべきではありません。たとえば、変数が数値ではなくビットパターンを表している場合や、意図的にオーバーフローさせて2^Nによる剰余がほしい場合などに限って使用するようにします。
        </span>
        <span>
            <span class="src">
                In
                particular, do not use unsigned types to say a number
                will never be negative.
            </span>
            特に、整数が絶対に負にならないということを表す目的ではunsigned型を使ってはいけません。
        </span>
        <span>
            <span class="src">
                Instead, use
                assertions for this.
            </span>
            そのような目的には、アサーションを使用してください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                If your code is a container that returns a size, be
                sure to use a type that will accommodate any possible
                usage of your container.
            </span>
            もしあなたがコンテナを作っているところで、そのサイズを返そうとしている場合には、そのコンテナがどのように扱われても対応できるであろう型を選んでください。
        </span>
        <span>
            <span class="src">
                When in doubt, use a larger type
                rather than a smaller type.
            </span>
            迷ったら、小さな型よりも大きな型を使いましょう。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Use care when converting integer types.
            </span>
            整数型の変換には注意してください。
        </span>
        <span>
            <span class="src">
                Integer
                conversions and promotions can cause undefined behavior, leading to security bugs and
                other problems.
            </span>
            整数型の変換や拡張は、ときに未定義の動作を引き起こし、セキュリティに関するバグやその他の問題を引き起こします。
        </span>
    </p>
    <h4><span title="On Unsigned Integers">unsignedな整数</span></h4>

    <p>
        <span>
            <span class="src">
                Unsigned integers are good for representing bitfields and modular
                arithmetic.
            </span>
            unsignedな整数は、ビットフィールドを表したり、合同算術を行うときに有用です。
        </span>
        <span>
            <span class="src">
                Because of historical accident, the C++ standard also uses
                unsigned integers to represent the size of containers - many members
                of the standards body believe this to be a mistake, but it is
                effectively impossible to fix at this point.
            </span>
            歴史的な事情により、C++標準では、コンテナのサイズを表すために unsigned な整数が使用されています。
            (多くの標準化委員会のメンバーが、これは失敗だったと考えていますが、もはや修正できる段階にはありません。)
        </span>
        <span>
            <span class="src">
                The fact that unsigned
                arithmetic doesn't model the behavior of a simple integer, but is
                instead defined by the standard to model modular arithmetic (wrapping
                around on overflow/underflow), means that a significant class of bugs
                cannot be diagnosed by the compiler.
            </span>
            unsignedな整数の演算は、単純な整数の演算とは異なり、合同算術によって定義され(オーバーフロー・アンダーフロー時に周回する)ますが、
            このことがコンパイラに検出できない大きなバグのカテゴリを生み出しています。
        </span>
        <span>
            <span class="src">
                In other cases, the defined
                behavior impedes optimization.
            </span>
            また、他のケースにおいては、定義されている挙動が最適化を妨げることもあります。
        </span>
    </p>
    <p>
        <span>
            <span class="src">
                That said, mixing signedness of integer types is responsible for an
                equally large class of problems.
            </span>
            とはいえ、signedな整数型とunsignedな整数型を混ぜて使うことは、同じように大きなカテゴリの問題の原因となります。
        </span>
        <span>
            <span class="src">
                The best advice we can provide: try
                to use iterators and containers rather than pointers and sizes, try
                not to mix signedness, and try to avoid unsigned types (except for
                representing bitfields or modular arithmetic).
            </span>
            これについて我々にできる最善のアドバイスは、「コンテナについては、sizeとポインタではなく、イテレータを使うようにすること」「signed整数とunsigned整数を混ぜて使わないようにすること」「(ビットフィールドと合同算術を除いて)そもそも、unsigned整数型を使わないようにすること」です。
        </span>
        <span>
            <span class="src">
                Do not use an unsigned
                type merely to assert that a variable is non-negative.
            </span>
            たかだか、変数が非負であることを表すためだけにunsigned型を使ってはいけません。
        </span>
    </p>

    <h3 id="64-bit_Portability"><span title="64-bit Portability">64ビットへの移植性</span></h3>

    <p>
        <span>
            <span class="src">
                Code should be 64-bit and 32-bit friendly.
            </span>
            コードは64ビットと32ビットの両方にフレンドリーであるべきです。
        </span>
        <span>
            <span class="src">
                Bear in mind
                problems of printing, comparisons, and structure alignment.
            </span>
            printするときの問題、比較するときの問題、構造体のアラインメントの問題を常に心にとめておいてください。
        </span>
    </p>

    <ul>
        <li>
            <p>
                <span>
                    <span class="src">
                        Correct portable <code>printf()</code> conversion specifiers for
                        some integral typedefs rely on macro expansions that we find unpleasant to
                        use and impractical to require (the <code>PRI</code> macros from
                        <code>&lt;cinttypes&gt;</code>).
                    </span>
                    正しく移植性のある<code>printf()</code>の整数の変換指定子は、マクロ展開(<code>&lt;cinttypes&gt;</code>に含まれる<code>PRI</code>系マクロ群がそれです)に依存しており、些か不格好で、実用的でもありません。
                </span>
                <span>
                    <span class="src">
                        Unless there is no reasonable alternative
                        for your particular case, try to avoid or even upgrade APIs that rely on the
                        <code>printf</code> family.
                    </span>
                    あなたのプロジェクトで、理にかなった代用品が見つけられない場合、 <code>printf</code>に依存したAPIを使うのをやめるか、APIのアップグレードを試みましょう。
                </span>
                <span>
                    <span class="src">
                        Instead use a library supporting typesafe numeric
                        formatting, such as
                        <a href="https://github.com/abseil/abseil-cpp/blob/master/absl/strings/str_cat.h"><code>StrCat</code></a>
                        or
                        <a href="https://github.com/abseil/abseil-cpp/blob/master/absl/strings/substitute.h"><code>Substitute</code></a>
                        for fast simple conversions,

                        or <a href="#Streams"><code>std::ostream</code></a>.
                    </span>
                    かわりに、
                    <a
                        href="https://github.com/abseil/abseil-cpp/blob/master/absl/strings/str_cat.h"><code>StrCat</code></a>や、
                    高速でシンプルな変換には<a
                        href="https://github.com/abseil/abseil-cpp/blob/master/absl/strings/substitute.h"><code>Substitute</code></a>、
                    もしくは、<a href="#Streams"><code>std::ostream</code></a>などの、型安全な整数書式化のライブラリを使いましょう。

                </span>
            </p>

            <p>
                <span>
                    <span class="src">
                        Unfortunately, the <code>PRI</code> macros are the only portable way to
                        specify a conversion for the standard bitwidth typedefs (e.g.,
                        <code>int64_t</code>, <code>uint64_t</code>, <code>int32_t</code>,
                        <code>uint32_t</code>, etc).
                    </span>
                    ビット幅指定による整数型へのtypedefs(
                    <code>int64_t</code>, <code>uint64_t</code>, <code>int32_t</code>,
                    <code>uint32_t</code>, 等)の書式指定子については、
                    残念ながら、<code>PRI</code>系マクロ群のみが唯一移植性のある方法です。
                </span>
                <span>
                    <span class="src">
                        Where possible, avoid passing arguments of types specified by bitwidth
                        typedefs to <code>printf</code>-based APIs.
                    </span>
                    可能であれば、<code>printf</code>系のAPIに、このような、ビット幅によって決まる型の引数を渡すのは避けてください。
                </span>
                <span>
                    <span class="src">
                        Note that it is acceptable
                        to use typedefs for which printf has dedicated length modifiers, such as
                        <code>size_t</code> (<code>z</code>),
                        <code>ptrdiff_t</code> (<code>t</code>), and
                        <code>maxint_t</code> (<code>j</code>).
                    </span>
                    一方で、printfが長さ指定子を持っているような型(たとえば
                    <code>size_t</code> (<code>z</code>),
                    <code>ptrdiff_t</code> (<code>t</code>),
                    <code>maxint_t</code> (<code>j</code>)等)は問題なく扱えることも忘れないでください。
                </span>
            </p>
        </li>
        <li>
            <span>
                <span class="src">
                    Remember that <code>sizeof(void *)</code> !=
                    <code>sizeof(int)</code>.
                </span>
                <code>sizeof(void *)</code> != <code>sizeof(int)</code>であることを忘れないでください。
            </span>
            <span>
                <span class="src">
                    Use <code>intptr_t</code> if
                    you want a pointer-sized integer.
                </span>
                ポインタと同じサイズの整数が必要なときは、<code>intptr_t</code>を使ってください。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    You may need to be careful with structure
                    alignments, particularly for structures being stored on
                    disk.
                </span>
                構造体のアラインメントに注意を払う必要があります(特に、構造体がディスクに保存される場合)。
            </span>
            <span>
                <span class="src">
                    Any class/structure with a
                    <code>int64_t</code>/<code>uint64_t</code>
                    member will by default end up being 8-byte aligned on a
                    64-bit system.
                </span>
                64ビットシステムにおいては、<code>int64_t</code>か<code>uint64_t</code>を含むクラスや構造体は、デフォルトで8バイト境界にアラインメントされます。
            </span>
            <span>
                <span class="src">
                    If you have such structures being shared
                    on disk between 32-bit and 64-bit code, you will need
                    to ensure that they are packed the same on both
                    architectures.
                </span>
                もし、このような構造体をディスクに保存して32ビットのコードと64ビットのコードで共有する場合、両方のアーキテクチャで同じようにパックされることを保証する必要があるでしょう。
            </span>
            <span>
                <span class="src">
                    Most compilers offer a way to
                    alter structure alignment.
                </span>
                ほとんどのコンパイラは、構造体のアラインメントを変える手段を提供しています。
            </span>
            <span>
                <span class="src">
                    For gcc, you can use
                    <code>__attribute__((packed))</code>.
                </span>
                GCCでは、<code>__attribute__((packed))</code>が使えます。
            </span>
            <span>
                <span class="src">
                    MSVC offers
                    <code>#pragma pack()</code> and
                    <code>__declspec(align())</code>.
                </span>
                MSVCは<code>#pragma pack()</code>と<code>__declspec(align())</code>を提供しています。
            </span>
        </li>

        <li>
            <p>
                <span>
                    <span class="src">
                        Use <a href="#Casting">braced-initialization</a> as needed to create
                        64-bit constants. For example:
                    </span>
                    64ビット定数を作るためには、次の例のように、波括弧初期化を使いましょう。
                </span>
            </p>
            <pre>int64_t my_value{0x123456789};
uint64_t my_mask{uint64_t{3} &lt;&lt; 48};
</pre>
        </li>
    </ul>


    <h3 id="Preprocessor_Macros"><span title="Preprocessor Macros">プリプロセッサマクロ</span></h3>

    <p>
        <span>
            <span class="src">
                Avoid defining macros, especially in headers; prefer
                inline functions, enums, and <code>const</code> variables.
            </span>
            マクロを定義するのは避けましょう(特にヘッダーでは)。
            インライン関数や、列挙型、<code>const</code>変数を使いましょう。
        </span>
        <span>
            <span class="src">
                Name macros with a project-specific prefix.
            </span>
            マクロの名前にはプロジェクト固有の接頭辞をつけてください。
        </span>
        <span>
            <span class="src">
                Do not use
                macros to define pieces of a C++ API.
            </span>
            C++ APIを定義するために、マクロを使わないでください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Macros mean that the code you see is not the same as
                the code the compiler sees.
            </span>
            マクロによって、あなたが見ているコードとコンパイラから見たコードが同じではなくなります。
        </span>
        <span>
            <span class="src">
                This can introduce unexpected
                behavior, especially since macros have global scope.
            </span>
            これによって、特に、マクロがグローバルスコープのとき、意図しない挙動を引き起こすことがあります。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                The problems introduced by macros are especially severe
                when they are used to define pieces of a C++ API,
                and still more so for public APIs.
            </span>
            マクロによって引き起こされる問題は、特に、マクロがC++ APIとして、特にパブリックなAPIとして定義されたときに重大です。
        </span>
        <span>
            <span class="src">
                Every error message from
                the compiler when developers incorrectly use that interface
                now must explain how the macros formed the interface.
            </span>
            開発者がインターフェースの使い方を間違えたときのコンパイラからのエラーメッセージは、マクロがどのようにインターフェースを形成しているかを説明しなくてはなりません。
        </span>
        <span>
            <span class="src">
                Refactoring and analysis tools have a dramatically harder
                time updating the interface.
            </span>
            リファクタリングや解析のツールはインターフェースを更新するために劇的な時間が掛かるようになります。
        </span>
        <span>
            <span class="src">
                As a consequence, we
                specifically disallow using macros in this way.
            </span>
            以上のことより、我々は明確に、マクロをこの方法で使用することを禁止します。
        </span>
        <span>
            <span class="src">
                For example, avoid patterns like:
            </span>
            たとえば、避けるべきパターンは次の通りです。
        </span>
    </p>

    <pre class="badcode">class WOMBAT_TYPE(Foo) {
  // ...

 public:
  EXPAND_PUBLIC_WOMBAT_API(Foo)

  EXPAND_WOMBAT_COMPARISONS(Foo, ==, &lt;)
};
</pre>

    <p>
        <span>
            <span class="src">
                Luckily, macros are not nearly as necessary in C++ as
                they are in C.
            </span>
            幸いにも、C++はC言語ほどマクロを必要としません。
        </span>
        <span>
            <span class="src">
                Instead of using a macro to inline
                performance-critical code, use an inline function.
            </span>
            パフォーマンスクリティカルなコードをインライン化する時には、マクロではなくインライン関数を使ってください。
        </span>
        <span>
            <span class="src">
                Instead of using a macro to store a constant, use a
                <code>const</code> variable.
            </span>
            定数を保持するためには、マクロではなく<code>const</code>変数を使ってください。
        </span>
        <span>
            <span class="src">
                Instead of using a macro to
                "abbreviate" a long variable name, use a reference.
            </span>
            長い名前の変数の短縮形を作るためには、マクロではなく参照を使ってください。
        </span>
        <span>
            <span class="src">
                Instead of using a macro to conditionally compile code
                ... well, don't do that at all (except, of course, for
                the <code>#define</code> guards to prevent double
                inclusion of header files).
            </span>
            状況によってコンパイルされるコードを変えるためには、マクロではなく……いや、そもそもそんなことをしてはいけません(もちろん、多重インクルードを防ぐためのインクルードガードは例外です)。
        </span>
        <span>
            <span class="src">
                It makes testing much more
                difficult.
            </span>
            そのようなことをすると、テストが非常に難しくなります。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Macros can do things these other techniques cannot,
                and you do see them in the codebase, especially in the
                lower-level libraries.
            </span>
            マクロは他の方法ではできないことを実現できるため、既存のコードベースにおいて、特に低レベルなライブラリでそれらを見かけることがあるかもしれません。
        </span>
        <span>
            <span class="src">
                And some of their special features
                (like stringifying, concatenation, and so forth) are not
                available through the language proper.
            </span>
            さらに、マクロには、文字列化や連結など特別な機能があり、それらの機能は言語では提供されません。
        </span>
        <span>
            <span class="src">
                But before using a
                macro, consider carefully whether there's a non-macro way
                to achieve the same result.
            </span>
            ただし、マクロを使う前に、マクロではない方法で同じ結果を達成する方法がないかよく検討してください。
        </span>
        <span>
            <span class="src">
                If you need to use a macro to
                define an interface, contact
                your project leads to request
                a waiver of this rule.
            </span>
            もし、マクロを使ってインターフェースを定義する必要が生じた場合は、このルールを破棄するために、プロジェクトリーダーと相談してください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                The following usage pattern will avoid many problems
                with macros; if you use macros, follow it whenever
                possible:
            </span>
            以下に示すようなマクロの使い方をすれば、多くの問題を避けることができます。マクロを定義しようとするときは可能な限りこれらに従ってください。
        </span>
    </p>

    <ul>
        <li>
            <span>
                <span class="src">
                    Don't define macros in a <code>.h</code> file.
                </span>
                <code>.h</code>ファイルでは、マクロを定義してはいけません。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    <code>#define</code> macros right before you use
                    them, and <code>#undef</code> them right after.
                </span>
                マクロは使う直前に<code>#define</code>し、使い終わったらすぐに<code>#undef</code>してください。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Do not just <code>#undef</code> an existing macro
                    before replacing it with your own; instead, pick a name
                    that's likely to be unique.
                </span>
                既存のマクロを自分のものに置き換えるために、<code>#undef</code>してはいけません。
                かわりに、あなたのマクロにユニークとなる前をつけてください。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Try not to use macros that expand to unbalanced C++
                    constructs, or at least document that behavior
                    well.
                </span>
                C++の偏った構造を拡張するためにマクロを使おうとしないでください。あるいは、少なくとも、その挙動について十分なドキュメント化を行ってください。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Prefer not using <code>##</code> to generate
                    function/class/variable names.
                </span>
                関数名やクラス名、変数名を生成するために<code>##</code>を使うのはやめましょう。
            </span>
        </li>
    </ul>

    <p>
        <span>
            <span class="src">
                Exporting macros from headers (i.e., defining them in a header
                without <code>#undef</code>ing them before the end of the header)
                is extremely strongly discouraged.
            </span>
            ヘッダーからマクロをエクスポートする(言い換えると、ヘッダーでマクロを定義し、そのヘッダーの終わりまで<code>#undef</code>しない)ことは、非常に強く非推奨です。
        </span>
        <span>
            <span class="src">
                If you do export a macro from a
                header, it must have a globally unique name.
            </span>
            もし、そのようなマクロをヘッダーからエクスポートする場合は、グローバルにユニークな名前でなくてはなりません。
        </span>
        <span>
            <span class="src">
                To achieve this, it
                must be named with a prefix consisting of your project's namespace
                name (but upper case).
            </span>
            そのため、必ずプロジェクトのnamespaceの名前を(すべて大文字で)マクロ名の頭につけるようにしてください。
        </span>
    </p>
    <h3 id="0_and_nullptr/NULL"><span title="0 and nullptr/NULL">0とnullptrとNULL</span></h3>

    <p>
        <span>
            <span class="src">
                Use <code>nullptr</code> for pointers, and <code>'\0'</code> for chars (and
                not the <code>0</code> literal).
            </span>
            ポインタには<code>nullptr</code>、文字列には<code>'\0'</code>を使用し、<code>0</code>リテラルは使わないでください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                For pointers (address values), use <code>nullptr</code>, as this
                provides type-safety.
            </span>
            ポインタ(アドレス値)には、<code>nullptr</code>を使用します。型安全です。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Use <code>'\0'</code> for the null character.
            </span>
            ヌル文字には<code>'\0'</code>を使います。
        </span>
        <span>
            <span class="src">
                Using the correct type makes
                the code more readable.
            </span>
            正しい型を使うことで、コードの可読性が向上します。
        </span>
    </p>
    <h3 id="sizeof"><span title="sizeof">sizeof</span></h3>

    <p>
        <span>
            <span class="src">
                Prefer <code>sizeof(<var>varname</var>)</code> to
                <code>sizeof(<var>type</var>)</code>.
            </span>
            <code>sizeof(<var>型</var>)</code>よりも<code>sizeof(<var>変数名</var>)</code>を使いましょう。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Use <code>sizeof(<var>varname</var>)</code> when you
                take the size of a particular variable.
            </span>
            具体的な変数のサイズを知りたいときには<code>sizeof(<var>変数名</var>)</code>を使ってください。
        </span>
        <span>
            <span class="src">
                <code>sizeof(<var>varname</var>)</code> will update
                appropriately if someone changes the variable type either
                now or later.
            </span>
            <code>sizeof(<var>変数名</var>)</code>であれば、変数の型に変更があった場合でも適切に追従してくれます。
        </span>
        <span>
            <span class="src">
                You may use
                <code>sizeof(<var>type</var>)</code> for code unrelated
                to any particular variable, such as code that manages an
                external or internal data format where a variable of an
                appropriate C++ type is not convenient.
            </span>
            具体的な変数に結びつかない場合は<code>sizeof(<var>型</var>)</code>を使ってもかまいません。たとえば、外部や内部のデータのフォーマットを管理したい場合で、かつC++の型の仕組みが不十分な場合などです。
        </span>
    </p>
    <pre>MyStruct data;
memset(&amp;data, 0, sizeof(data));
</pre>

    <div>
        <div class="src">
            <pre class="badcode">memset(&amp;data, 0, sizeof(MyStruct));
</pre>
        </div>
        <pre class="badcode">memset(&amp;data, 0, sizeof(MyStruct));  // これは避ける
</pre>
    </div>

    <pre>if (raw_size &lt; sizeof(int)) {
  LOG(ERROR) &lt;&lt; "compressed record not big enough for count: " &lt;&lt; raw_size;
  return false;
}
</pre>

    <a id="auto"></a>
    <h3 id="Type_deduction"><span title="Type Deduction (including auto)">型推論(autoを含む)</span></h3>


    <p>
        <span>
            <span class="src">
                Use type deduction only if it makes the code clearer to readers who aren't
                familiar with the project, or if it makes the code safer.
            </span>
            型推論は、型推論を用いることでプロジェクトに慣れていない読者にとってコードを読みやすくできる場合や、型推論を用いることでコードをより安全にできる場合に限り使うようにしてください。
        </span>
        <span>
            <span class="src">
                Do not use it
                merely to avoid the inconvenience of writing an explicit type.
            </span>
            単に明示的に型を書くのが不便だからという理由では使わないでください。
        </span>
    </p>

    <p class="definition">
    </p>

    <p>
        <span>
            <span class="src">
                There are several contexts in which C++ allows (or even requires) types to
                be deduced by the compiler, rather than spelled out explicitly in the code:
            </span>
            C++ では、しばしば、コードで明示的に型を記述するのではなく、コンパイラによって型が推論されることを許可する (またはそれを必要とする) 状況があります。
        </span>
    </p>
    <dl>
        <dt>
            <span>
                <span class="src">
                    <a href="https://en.cppreference.com/w/cpp/language/template_argument_deduction">Function template argument deduction</a>
                </span>
                <a href="https://en.cppreference.com/w/cpp/language/template_argument_deduction">関数テンプレートの引数推論</a>
            </span>
        </dt>
        <dd>
            <span>
                <span class="src">
                    A function template can be invoked without explicit template arguments.
                </span>
                関数テンプレートは、明示的なテンプレート引数なしで呼び出すことができます。
            </span>
            <span>
                <span class="src">
                    The compiler deduces those arguments from the types of the function
                    arguments:
                </span>
                コンパイラは、関数の実引数の型からこれらの引数を推測します。
            </span>
            <pre class="neutralcode">template &lt;typename T&gt;
void f(T t);

f(0);  // Invokes f&lt;int&gt;(0)</pre>
        </dd>
        <dt>
            <span>
                <span class="src">
                    <a href="https://en.cppreference.com/w/cpp/language/auto"><code>auto</code> variable declarations</a>
                </span>
                <a href="https://en.cppreference.com/w/cpp/language/auto"><code>auto</code>変数宣言</a>
            </span>
        </dt>
        <dd>
            <span>
                <span class="src">
                    A variable declaration can use the <code>auto</code> keyword in place
                    of the type.
                </span>
                変数宣言では、型の代わりに<code>auto</code>キーワードを使用できます。
            </span>

            <span>
                <span class="src">
                    The compiler deduces the type from the variable's
                    initializer, following the same rules as function template argument
                    deduction with the same initializer (so long as you don't use curly braces
                    instead of parentheses).
                </span>
                コンパイラは変数の初期化子から、その初期化子を関数テンプレートでの引数推論に渡した場合と同じ規則に従って、変数の型を推論します (丸括弧のかわりに波括弧を使用しない限り)。
            </span>

            <pre class="neutralcode">auto a = 42;  // a is an int
auto&amp; b = a;  // b is an int&amp;
auto c = b;   // c is an int
auto d{42};   // d is an int, not a std::initializer_list&lt;int&gt;</pre>
            <span>
                <span class="src">
                    <code>auto</code> can be qualified with <code>const</code>, and can be
                    used as part of a pointer or reference type, but it can't be used as a
                    template argument.
                </span>
                <code>auto</code>は<code>const</code>で修飾でき、ポインタまたは参照型の一部として使用できますが、テンプレート引数として使用することはできません。
            </span>
            <span>
                <span class="src">
                    A rare variant of this syntax uses
                    <code>decltype(auto)</code> instead of <code>auto</code>, in which case
                    the deduced type is the result of applying
                    <a href="https://en.cppreference.com/w/cpp/language/decltype"><code>decltype</code></a>
                    to the initializer.
                </span>
                この構文のまれに現れる変種形として、<code>auto</code>のかわりに<code>decltype(auto)</code>というのもあり、その場合は、初期化子を<a href="https://en.cppreference.com/w/cpp/language/decltype"><code>decltype</code></a>に渡した結果の型が推論されます。
            </span>
        </dd>
        <dt>
            <span>
                <span class="src">
                    <a href="https://en.cppreference.com/w/cpp/language/function#Return_type_deduction">Function return type deduction</a>
                </span>
                <a href="https://en.cppreference.com/w/cpp/language/function#Return_type_deduction">関数の戻り値の型推論</a>
            </span>
        </dt>
        <dd>
            <span>
                <span class="src">
                    <code>auto</code> (and <code>decltype(auto)</code>) can also be used in
                    place of a function return type.
                </span>
                <code>auto</code> (と<code>decltype(auto)</code>)は、関数の戻り型のかわりに用いることもできます。
            </span>
            <span>
                <span class="src">
                    The compiler deduces the return type from
                    the <code>return</code> statements in the function body, following the same
                    rules as for variable declarations:
                </span>
                コンパイラは、関数本体の<code>return</code>文から、変数宣言のときと同じ規則に従って、戻り値の型を推論します。
            </span>
            <div>
                <div class="src">
                    <pre class="neutralcode">auto f() { return 0; }  // The return type of f is int</pre>
                </div>
                <pre class="neutralcode">auto f() { return 0; }  // f の戻り値の型は int</pre>
            </div>

            <span>
                <span class="src">
                    <a href="#Lambda_expressions">Lambda expression</a> return types can be
                    deduced in the same way, but this is triggered by omitting the return type,
                    rather than by an explicit <code>auto</code>.
                </span>
                <a href="#Lambda_expressions">ラムダ式</a>の戻り値の型も同じ方法で推論させることができますが、これは明示的な<code>auto</code>ではなく、戻り値の型を省略したときに行われます。
            </span>
            <span>
                <span class="src">
                    Confusingly,
                    <a href="#trailing_return">trailing return type</a> syntax for functions
                    also uses <code>auto</code> in the return-type position, but that doesn't
                    rely on type deduction; it's just an alternate syntax for an explicit
                    return type.
                </span>
                紛らわしいことに、関数の<a href="#trailing_return">末尾の戻り値の型</a>の構文でも、戻り値の型の位置に<code>auto</code>が使われますが、こちらは型推論には頼っているのではなく、明示的に戻り値の型を書く別の構文にすぎません。
            </span>
        </dd>
        <dt>
            <span>
                <span class="src">
                    <a href="https://isocpp.org/wiki/faq/cpp14-language#generic-lambdas">Generic lambdas</a>
                </span>
                <a href="https://isocpp.org/wiki/faq/cpp14-language#generic-lambdas">汎用ラムダ</a>
            </span>
        </dt>
        <dd>
            <span>
                <span class="src">
                    A lambda expression can use the <code>auto</code> keyword in place of
                    one or more of its parameter types.
                </span>
                ラムダ式では、1つ以上の仮引数の型のかわりに<code>auto</code>キーワードを用いることができます。
            </span>
            <span>
                <span class="src">
                    This causes the lambda's call operator
                    to be a function template instead of an ordinary function, with a separate
                    template parameter for each <code>auto</code> function parameter:
                </span>
                これにより、ラムダの呼び出し演算子が通常の関数ではなく関数テンプレートになり、各<code>auto</code>引数に個別のテンプレート引数が使用されます。
            </span>
            <div>
                <div class="src">
                    <pre class="neutralcode">// Sort `vec` in decreasing order
std::sort(vec.begin(), vec.end(), [](auto lhs, auto rhs) { return lhs &gt; rhs; });</pre>
                </div>
                <pre class="neutralcode">// `vec` を降順ソート
std::sort(vec.begin(), vec.end(), [](auto lhs, auto rhs) { return lhs &gt; rhs; });</pre>
            </div>

            
        </dd>
        <dt>
            <span>
                <span class="src">
                    <a href="https://isocpp.org/wiki/faq/cpp14-language#lambda-captures">Lambda init captures</a>
                </span>
                <a href="https://isocpp.org/wiki/faq/cpp14-language#lambda-captures">ラムダの初期化キャプチャ</a>
            </span>
        </dt>
        <dd>
            <span>
                <span class="src">
                    Lambda captures can have explicit initializers, which can be used to
                    declare wholly new variables rather than only capturing existing ones:
                </span>
                ラムダキャプチャでは、既存の変数をキャプチャするだけでなく、明示的に初期化子を持たせて、まったく新しい変数を宣言することもできます。
            </span>
            <div>
                <div class="src">
                    <pre class="neutralcode">[x = 42, y = "foo"] { ...
}  // x is an int, and y is a const char*</pre>
                </div>
                <pre class="neutralcode">[x = 42, y = "foo"] { ...
}  // x は int で、y は const char*</pre>
            </div>
            
            <span>
                <span class="src">
                    This syntax doesn't allow the type to be specified; instead, it's deduced
                    using the rules for <code>auto</code> variables.
                </span>
                この構文では、型を指定することはできず、かわりに、<code>auto</code>変数のルールを使用して型が推論されます。
            </span>
        </dd>
        <dt>
            <span>
                <span class="src">
                    <a href="https://en.cppreference.com/w/cpp/language/class_template_argument_deduction">Class template argument deduction</a>
                </span>
                <a href="https://en.cppreference.com/w/cpp/language/class_template_argument_deduction">クラス テンプレートの引数推論</a>
            </span>
        </dt>
        <dd>
            <span>
                <span class="src">
                    See <a href="#CTAD">below</a>.
                </span>
                <a href="#CTAD">後述します</a>。
            </span>
        </dd>
        <dt>
            <span>
                <span class="src">
                    <a href="https://en.cppreference.com/w/cpp/language/structured_binding">Structured bindings</a>
                </span>
                <a href="https://en.cppreference.com/w/cpp/language/structured_binding">構造化バインディング</a>
            </span>
        </dt>
        <dd>
            <span>
                <span class="src">
                    When declaring a tuple, struct, or array using <code>auto</code>, you can
                    specify names for the individual elements instead of a name for the whole
                    object; these names are called "structured bindings", and the whole
                    declaration is called a "structured binding declaration".
                </span>
                <code>auto</code>を使用してタプル、構造体、または配列を宣言する場合、オブジェクト全体の名前ではなく、個々の要素の名前を決めることができます。
                これらの名前は「構造化バインディング」と呼ばれ、その宣言全体は「構造化バインディング宣言」と呼ばれます。
            </span>
            <span>
                <span class="src">
                    This syntax
                    provides no way of specifying the type of either the enclosing object
                    or the individual names:
                </span>
                この構文では、囲んでいるオブジェクトまたは個々の名前の型を指定する方法はありません。
            </span>
            <pre class="neutralcode">auto [iter, success] = my_map.insert({key, value});
if (!success) {
    iter-&gt;second = value;
}</pre>
            <span>
                <span class="src">
                    The <code>auto</code> can also be qualified with <code>const</code>,
                    <code>&amp;</code>, and <code>&amp;&amp;</code>, but note that these qualifiers
                    technically apply to the anonymous tuple/struct/array, rather than the
                    individual bindings.
                </span>
                この<code>auto</code>は、<code>const</code>、<code>&amp;</code>、および <code>&amp;&amp;</code>で修飾することもできますが、これらの修飾子は、技術的には、個々のバインディング先ではなく、その宣言で作られる無名のタプル/構造体/配列に適用されることに注意してください。
            </span>
            <span>
                <span class="src">
                    The rules that determine the types of the bindings
                    are quite complex; the results tend to be unsurprising, except that
                    the binding types typically won't be references even if the declaration
                    declares a reference (but they will usually behave like references anyway).
                </span>
                それぞれのバインディングの型を決定するルールは非常に複雑です。
                結果として、大抵は、想像通りのものになるのですが、宣言が参照である場合には、各々のバインディングの型は通常は参照にはなりません。
                (ただしいずれにせよ、通常は参照のように動作します)。
            </span>
        </dd>
    </dl>

    <p>
        <span>
            <span class="src">
                (These summaries omit many details and caveats; see the links for further
                information.)
            </span>
            (これらの要約では、多くの詳細と警告を割愛しています。より詳細な情報を得るために、各リンク先を参照してください。)
        </span>
    </p>

    <p class="pros"></p>
    <ul>
        <li>
            <span>
                <span class="src">
                    C++ type names can be long and cumbersome, especially when they
                    involve templates or namespaces.
                </span>
                C++の型名は、特にテンプレートや名前空間を含んだ場合、長く面倒なものになりがちです。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    When a C++ type name is repeated within a single declaration or a
                    small code region, the repetition may not be aiding readability.
                </span>
                1つの宣言や小さなコードブロックの中で、C++の型名の繰り返されることは、可読性の助けにはなりません。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    It is sometimes safer to let the type be deduced, since that avoids
                    the possibility of unintended copies or type conversions.
                </span>
                また、意図しないコピーや型変換を避けるために、変数の型を推論させるほうがより安全な場合もあります。
            </span>
        </li>
    </ul>

    <p class="cons"></p>

    <p>
        <span>
            <span class="src">
                C++ code is usually clearer when types are explicit,
                especially when type deduction would depend on information from
                distant parts of the code.
            </span>
            通常、型が明示された方がC++コードがわかりやすくなります。特に、コードの離れた箇所の情報に型推論が依存している場合などです。
        </span>
        <span>
            <span class="src">
                In expressions
                like:
            </span>
            たとえば次のような式を考えてみます。
        </span>
    </p>

    <pre class="badcode">auto foo = x.add_foo();
auto i = y.Find(key);
</pre>

    <p>
        <span>
            <span class="src">
                it may not be obvious what the resulting types are if the type
                of <code>y</code> isn't very well known, or if <code>y</code> was
                declared many lines earlier.
            </span>
            この式において、<code>y</code>の型が十分に知られていなかったり、<code>y</code>がずっと前に宣言されていたりした場合、式の結果の型が明確であるとはいえないでしょう。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Programmers have to understand when type deduction will or won't
                produce a reference type, or they'll get copies when they didn't
                mean to.
            </span>
            プログラマは型推論がどの場合に参照を返し、どの場合に返さないか、を理解していなければなりません。さもなくば、意図せずオブジェクトのコピーを得ることになってしまうかもしれません。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                If a deduced type is used as part of an
                interface, then a
                programmer might change its type while only intending to
                change its value, leading to a more radical API change
                than intended.
            </span>
            推論された型が、インターフェースの一部として使われていた場合、プログラマはその値を変えるだけのつもりで、型も変えてしまうかもしれません。これによって意図した変更よりも根本的なAPIの変更を招いてしまうかもしれません。
        </span>
    </p>

    <p class="decision">
    </p>

    <p>
        <span>
            <span class="src">
                The fundamental rule is: use type deduction only to make the code
                clearer or safer, and do not use it merely to avoid the
                inconvenience of writing an explicit type.
            </span>
            基本的なルールとして、型推論はコードをより明確または安全にする目的でのみ使い、明示的な型を記述する不便さを回避する目的では使わないようにしてください。
        </span>
        <span>
            <span class="src">
                When judging whether the
                code is clearer, keep in mind that your readers are not necessarily
                on your team, or familiar with your project, so types that you and
                your reviewer experience as unnecessary clutter will very often
                provide useful information to others.
            </span>
            コードがより明確かどうかを判断するときは、読者が必ずしもあなたのチームに所属しているわけでも、あなたのプロジェクトに精通しているわけでもないということを念頭においてください。
            あなた自身やあなたのレビュアーが、それを不要なゴミだと感じたとしても、他人にとっては非常に有益な情報を与えている、ということは、実際によくあることなのです。
        </span>
        <span>
            <span class="src">
                For example, you can assume that
                the return type of <code>make_unique&lt;Foo&gt;()</code> is obvious,
                but the return type of <code>MyWidgetFactory()</code> probably isn't.
            </span>
            たとえば、<code>make_unique&lt;Foo&gt;()</code> の戻り値の型は自明であると見なせますが、<code>MyWidgetFactory()</code> の戻り値の型はおそらくそうではないと想定できます。
        </span>
    </p>
    <p>
        <span>
            <span class="src">
                These principles apply to all forms of type deduction, but the
                details vary, as described in the following sections.
            </span>
            これらの原則はすべての形式の型推論に適用されのですがが、より細かいところでは異なってきます。それについて次以降のセクションで説明していきます。
        </span>
    </p>

    <h4 title="Function template argument deduction">関数テンプレートの引数推論</h4>
    <p>
        <span>
            <span class="src">
                Function template argument deduction is almost always OK.
            </span>
            関数テンプレートの引数推論は、ほとんどの場合問題ありません。
        </span>
        <span>
            <span class="src">
                Type deduction
                is the expected default way of interacting with function templates,
                because it allows function templates to act like infinite sets of ordinary
                function overloads.
            </span>
            型推論は、関数テンプレートを用いる際のデフォルトの方法として想定されています。型推論を用いることによって、関数テンプレートが通常関数のオーバーロードの無限集合のように振る舞えるようになるためです。
        </span>
        <span>
            <span class="src">
                Consequently, function templates are almost always
                designed so that template argument deduction is clear and safe, or
                doesn't compile.
            </span>
            したがって、関数テンプレートは、ほとんど常に、テンプレート引数の推論が明確かつ安全に行われるか、さもなくばコンパイルエラーになるように設計されています。
        </span>
    </p>

    <h4 title="Local variable type deduction">ローカル変数の型推論</h4>
    <p>
        <span>
            <span class="src">
                For local variables, you can use type deduction to make the code clearer
                by eliminating type information that is obvious or irrelevant, so that
                the reader can focus on the meaningful parts of the code:
            </span>
            ローカル変数において、型推論によって、明白または無関係な型情報を削除し、コードをわかりやすくすることができます。
            これにより、読者はコードの本質的な部分に集中できます。
        </span>
    </p>
    <pre class="neutralcode">std::unique_ptr&lt;WidgetWithBellsAndWhistles&gt; widget_ptr =
    std::make_unique&lt;WidgetWithBellsAndWhistles&gt;(arg1, arg2);
absl::flat_hash_map&lt;std::string,
                    std::unique_ptr&lt;WidgetWithBellsAndWhistles&gt;&gt;::const_iterator
    it = my_map_.find(key);
std::array&lt;int, 6&gt; numbers = {4, 8, 15, 16, 23, 42};</pre>

    <pre class="goodcode">auto widget_ptr = std::make_unique&lt;WidgetWithBellsAndWhistles&gt;(arg1, arg2);
auto it = my_map_.find(key);
std::array numbers = {4, 8, 15, 16, 23, 42};</pre>

    <p>
        <span>
            <span class="src">
                Types sometimes contain a mixture of useful information and boilerplate,
                such as <code>it</code> in the example above: it's obvious that the
                type is an iterator, and in many contexts the container type and even the
                key type aren't relevant, but the type of the values is probably useful.
            </span>
            型には、上記例の<code>it</code>のように、有用な情報と、ただの定型文とが混在していることがあります。
            <code>it</code>について、型がイテレータであることは明らかであり、多くの文脈において、コンテナの型やキーの型でさえ関係ありませんが、値の型はおそらく役に立ちます。
        </span>
        <span>
            <span class="src">
                In such situations, it's often possible to define local variables with
                explicit types that convey the relevant information:
            </span>
            このような状況では、型を明示したローカル変数を定義することによって、関連する情報を伝えられることがままあります。
        </span>
    </p>
                <div>
                <div class="src">
                    <pre class="goodcode">if (auto it = my_map_.find(key); it != my_map_.end()) {
    WidgetWithBellsAndWhistles&amp; widget = *it-&gt;second;
    // Do stuff with `widget`
}</pre>
                </div>
                <pre class="goodcode">if (auto it = my_map_.find(key); it != my_map_.end()) {
    WidgetWithBellsAndWhistles&amp; widget = *it-&gt;second;
    // `widget`に関する操作を行う
}</pre>
            </div>
    
    <p>
        <span>
            <span class="src">
                If the type is a template instance, and the parameters are
                boilerplate but the template itself is informative, you can use
                class template argument deduction to suppress the boilerplate.
            </span>
            型がテンプレートインスタンスで、そのパラメータは定型文だが、テンプレート自体は有用な情報を含む場合、クラステンプレートの引数推論を使用して定型文を抑制することができます。
        </span>
        <span>
            <span class="src">
                However,
                cases where this actually provides a meaningful benefit are quite rare.
            </span>
            ただし、これが実際に意味のある利益をもたらすケースは非常にまれです。
        </span>
        <span>
            <span class="src">
                Note that class template argument deduction is also subject to a
                <a href="#CTAD">separate style rule</a>.
            </span>
            そして、クラステンプレートの引数推論は、<a href="#CTAD">別のスタイルルール</a>に従うことにも注意してください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Do not use <code>decltype(auto)</code> if a simpler option will work,
                because it's a fairly obscure feature, so it has a high cost in code
                clarity.
            </span>
            より単純な手段で十分な場合には、 <code>decltype(auto)</code>を使用しないでください。
            <code>decltype(auto)</code>は、かなりわかりにくい機能であるため、コードの明確性の面で大きなコストになります。
        </span>
    </p>

    <h4 title="Return type deduction">戻り値の型推論</h4>

    <p>
        <span>
            <span class="src">
                Use return type deduction (for both functions and lambdas) only if the
                function body has a very small number of <code>return</code> statements,
                and very little other code, because otherwise the reader may not be able
                to tell at a glance what the return type is.
            </span>
            関数とラムダどちらの場合でも、関数本体に含まれる<code>return</code>ステートメントの数が非常に少なく、かつ、その他のコードがほとんどない場合にのみ、戻り値の型推論を使用するようにしてください。
            そうしないと、読者が戻り値の型を一目で知ることができなくなります。
        </span>
        <span>
            <span class="src">
                Furthermore, use it only
                if the function or lambda has a very narrow scope, because functions with
                deduced return types don't define abstraction boundaries: the implementation
                <em>is</em> the interface.
            </span>
            もっと言えば、その関数やラムダが非常に狭いスコープを持つ場合にのみ使用するようにしてください。戻り値の型を推論に委ねる関数は、抽象化の境界を定義せず、その実装<em>が</em>そのままそのインターフェイスとなるためです。
        </span>
        <span>
            <span class="src">
                In particular, public functions in header files
                should almost never have deduced return types.
            </span>
            特に、ヘッダーファイル内のパブリックな関数では、戻り値の型推論を含むことはほとんどまったくないでしょう。
        </span>
    </p>

    <h4 title="Parameter type deduction">引数の型推論</h4>

    <p>
        <span>
            <span class="src">
                <code>auto</code> parameter types for lambdas should be used with caution,
                because the actual type is determined by the code that calls the lambda,
                rather than by the definition of the lambda.
            </span>
            ラムダの<code>auto</code>引数の実際の型は、ラムダの定義ではなく、ラムダを呼び出すコードによって決定されるため、注意して使用する必要があります。
        </span>
        <span>
            <span class="src">
                Consequently, an explicit
                type will almost always be clearer unless the lambda is explicitly called
                very close to where it's defined (so that the reader can easily see both),
                or the lambda is passed to an interface so well-known that it's
                obvious what arguments it will eventually be called with (e.g.,
                the <code>std::sort</code> example above).
            </span>
            したがって、ラムダが定義のすぐ近くで明示的に呼び出されていて読者がその両方を容易に読めるか、ラムダが非常によく知られたインターフェイスに渡されており、最終的にどの引数で呼び出されるかが明らか(例えば上記例の<code>std::sort</code>)な場合を除けば、ほとんどの場合、明示的な型の方がより明確になるでしょう。
        </span>
    </p>

    <h4 title="Lambda init captures">ラムダ初期化キャプチャ</h4>

    <p>
        <span>
            <span class="src">
                Init captures are covered by a <a href="#Lambda_expressions">more specific
                  style rule</a>, which largely supersedes the general rules for
                type deduction.
            </span>
            初期化キャプチャは、<a href="#Lambda_expressions">より具体的なスタイルルール</a>によってカバーされます。これは、型推論の一般的なルールに大きく取って代わります。
        </span>
    </p>

    <h4 title="Structured bindings">構造化バインディング</h4>

    <p>
        <span>
            <span class="src">
                Unlike other forms of type deduction, structured bindings can actually
                give the reader additional information, by giving meaningful names to the
                elements of a larger object.
            </span>
            他の形式の型推論とは異なり、構造化バインディングは、大きなオブジェクトの各要素に意味のある名前を付けられるので、実際に読者へ追加情報を提供できます。
        </span>
        <span>
            <span class="src">
                This means that a structured binding declaration
                may provide a net readability improvement over an explicit type, even in cases
                where <code>auto</code> would not.
            </span>
            これは、型を明示的に書くよりも、構造化バインディング宣言を用いる方が、全体としての可読性の向上につながるかもしれないことを意味します(<code>auto</code>が可読性の向上に貢献しなかったとしてもです)。
        </span>
        <span>
            <span class="src">
                Structured bindings are especially
                beneficial when the object is a pair or tuple (as in the <code>insert</code>
                example above), because they don't have meaningful field names to begin with,
                but note that you generally <a href="#Structs_vs._Tuples">shouldn't use
                    pairs or tuples</a> unless a pre-existing API like <code>insert</code>
                forces you to.
            </span>
            構造化バインディングが特に有益なのは、上記例の<code>insert</code>のように、対象のオブジェクトが、もともと意味のあるフィールド名を持っていない値ペアやタプル等である場合です。
            とはいえ、<code>insert</code> などの既存の API によって強制されない限り、通常は、<a href="#Structs_vs._Tuples">そもそも値ペアやタプルは使うべきではありません</a>。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                If the object being bound is a struct, it may sometimes be helpful to
                provide names that are more specific to your usage, but keep in mind that
                this may also mean the names are less recognizable to your reader than the
                field names.
            </span>
            バインド対象のオブジェクトが構造体である場合、その場でのフィールドの使い方に特化した名前をつけることが有用な場合もあります。
            ただし、コード読者にとっては、その名前が、元のフィールド名よりもわかりにくくなるかもしれないということも念頭においてください。
        </span>
        <span>
            <span class="src">
                We recommend using a comment to indicate the name of the
                underlying field, if it doesn't match the name of the binding, using the
                same syntax as for function parameter comments:
            </span>
            バインディングの名前とフィールド名とが一致しない場合、関数引数のコメントと同じ構文で、コメントで、もとになるフィールドの名前を記述することをお勧めします。
        </span>
    </p>
    <pre>auto [/*field_name1=*/bound_name1, /*field_name2=*/bound_name2] = ...</pre>
    <p>
        <span>
            <span class="src">
                As with function parameter comments, this can enable tools to detect if
                you get the order of the fields wrong.
            </span>
            関数引数のコメントと同様に、これによって、フィールドの順序が間違っていないかどうかを、ツールに検出してもらうことができるようになるでしょう。
        </span>
    </p>

    <h3 id="CTAD"><span title="Class Template Argument Deduction">クラステンプレートの引数推論</span></h3>

    <p>
        <span>
            <span class="src">
                Use class template argument deduction only with templates that have
                explicitly opted into supporting it.
            </span>
            クラステンプレートの引数推論は、それをサポートすることを明示(オプトイン)しているテンプレートでのみ使用するようにしてください。
        </span>
    </p>

    <p class="definition">
    </p>
    <p>
        <span>
            <span class="src">
                <a href="https://en.cppreference.com/w/cpp/language/class_template_argument_deduction">Class
                    template argument deduction</a> (often abbreviated "CTAD") occurs when
                a variable is declared with a type that names a template, and the template
                argument list is not provided (not even empty angle brackets):
            </span>
            <a href="https://en.cppreference.com/w/cpp/language/class_template_argument_deduction">クラステンプレートの引数推論</a>(しばしば "CTAD" と略される)は、変数がテンプレート型名で宣言され、かつ、その宣言でテンプレートの引数リストが提供されていない(空の山括弧もない)場合に発生します。
        </span>
    </p>
    <pre class="neutralcode">std::array a = {1, 2, 3};  // `a` is a std::array&lt;int, 3&gt;</pre>
    <p>
        <span>
            <span class="src">
                The compiler deduces the arguments from the initializer using the
                template's "deduction guides", which can be explicit or implicit.
            </span>
            コンパイラは、明示的または暗黙的な、そのテンプレートの「推論ガイド」を使用して、初期化子からテンプレート引数を推論します。
        </span>
    </p>
    <p>
        <span>
            <span class="src">
                Explicit deduction guides look like function declarations with trailing
                return types, except that there's no leading <code>auto</code>, and the
                function name is the name of the template.
            </span>
            明示的な推論ガイドは、戻り値の型が末尾にある関数宣言のような形をしていますが、先頭に<code>auto</code>がなく、関数名がテンプレートの名前になっています。
        </span>
        <span>
            <span class="src">
                For example, the above example
                relies on this deduction guide for <code>std::array</code>:
            </span>
            たとえば、上記の例は、<code>std::array</code>の次の推論ガイドに依存しています。
        </span>
    </p>
    <pre class="neutralcode">namespace std {
    template &lt;class T, class...
    U&gt;
    array(T, U...) -&gt; std::array&lt;T, 1 + sizeof...(U)&gt;;
    }</pre>
    <p>
        <span>
            <span class="src">
                Constructors in a primary template (as opposed to a template specialization)
                also implicitly define deduction guides.
            </span>
            (テンプレートの特殊化とは異なり)プライマリテンプレートのコンストラクタも、推論ガイドを暗黙的に定義します。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                When you declare a variable that relies on CTAD, the compiler selects
                a deduction guide using the rules of constructor overload resolution,
                and that guide's return type becomes the type of the variable.
            </span>
            CTAD に依存する変数を宣言すると、コンパイラはコンストラクタのオーバーロード解決の規則を使用して推論ガイドを選択し、そのガイドの戻り値の型が変数の型になります。
        </span>
    </p>

    <p class="pros">
    </p>
    <p>
        <span>
            <span class="src">
                CTAD can sometimes allow you to omit boilerplate from your code.
            </span>
            CTAD では、コードから定型文を省略できる場合があります。
        </span>
    </p>

    <p class="cons">
    </p>
    <p>
        <span>
            <span class="src">
                The implicit deduction guides that are generated from constructors
                may have undesirable behavior, or be outright incorrect.
            </span>
            コンストラクタから生成された暗黙的な推論ガイドは、望ましくない動作をしたり、まったく正しくない場合があります。
        </span>
        <span>
            <span class="src">
                This is
                particularly problematic for constructors written before CTAD was
                introduced in C++17, because the authors of those constructors had no
                way of knowing about (much less fixing) any problems that their
                constructors would cause for CTAD.
            </span>
            これは、特に、C++17でCTADが導入される前に作成されたコンストラクタで問題になりがちです。
            これらのコンストラクタの作成者は、それらのコンストラクタがCTADによって引き起こす何らかの問題について知る手段がなかったためです。
        </span>
        <span>
            <span class="src">
                Furthermore, adding explicit deduction
                guides to fix those problems might break any existing code that relies on
                the implicit deduction guides.
            </span>
            さらに、これらの問題を修正するために明示的な推論ガイドを追加しようとすると、今度は、それまでの暗黙的な推論ガイドに依存している既存のコードが壊れる可能性があります。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                CTAD also suffers from many of the same drawbacks as <code>auto</code>,
                because they are both mechanisms for deducing all or part of a variable's
                type from its initializer.
            </span>
            CTAD にも<code>auto</code>と同じ欠点が数多くあります。
            これは、どちらも初期化子から変数の型のすべてまたは一部を推測するためのメカニズムであるためです。
        </span>
        <span>
            <span class="src">
                CTAD does give the reader more information
                than <code>auto</code>, but it also doesn't give the reader an obvious
                cue that information has been omitted.
            </span>
            CTAD は <code>auto</code>よりも多くの情報を読者に提供しますが、情報の省略について明確な手掛かりを与える訳ではありません。
        </span>
    </p>

    <p class="decision">
    </p>
    <p>
        <span>
            <span class="src">
                Do not use CTAD with a given template unless the template's maintainers
                have opted into supporting use of CTAD by providing at least one explicit
                deduction guide (all templates in the <code>std</code> namespace are
                also presumed to have opted in).
            </span>
            あるテンプレートにおいて、そのテンプレートのメンテナーによって少なくとも1つの明示的な推論ガイドが提供され、そのテンプレートでCTADをサポートすることを明示(オプトイン)されていない限り、そのテンプレートでは CTAD を使用しないでください。なお、<code>std</code>名前空間のすべてのテンプレートは、すでにCTADをサポートしているものと見なしてかまいません。
        </span>
        <span>
            <span class="src">
                This should be enforced with a compiler
                warning if available.
            </span>
            これは、可能ならばコンパイラの警告で強制されるべきです。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Uses of CTAD must also follow the general rules on
                <a href="#Type_deduction">Type deduction</a>.
            </span>
            CTAD の使用は、<a href="#Type_deduction">型推論</a>に関する一般規則にも従う必要があります。
        </span>
    </p>

    <h3 id="Designated_initializers" title="Designated Initializers">指示付き初期化子</h3>

    <p>
        <span>
            <span class="src">
                Use designated initializers only in their C++20-compliant form.
            </span>
            指示付き初期化子は、C++20 準拠の形式でのみ使用してください。
        </span>
    </p>

    <p class="definition">
    </p>
    <p>
        <span>
            <span class="src">
                <a href="https://en.cppreference.com/w/cpp/language/aggregate_initialization#Designated_initializers">
                    Designated initializers</a> are a syntax that allows for initializing an
                aggregate ("plain old struct") by naming its fields explicitly:
            </span>
            <a href="https://en.cppreference.com/w/cpp/language/aggregate_initialization#Designated_initializers">指示付き初期化子</a>は、フィールドに明示的に名前を付けることで集約型(aggregate) ("plain old struct") を初期化できる構文です。
        </span>
    </p>
    <pre class="neutralcode">  struct Point {
        float x = 0.0;
        float y = 0.0;
        float z = 0.0;
      };
    
      Point p = {
        .x = 1.0,
        .y = 2.0,
        // z will be 0.0
      };</pre>
    <p>
        <span>
            <span class="src">
                The explicitly listed fields will be initialized as specified, and others
                will be initialized in the same way they would be in a traditional aggregate
                initialization expression like <code>Point{1.0, 2.0}</code>.
            </span>
            明示的にリストされたフィールドは指定どおりに初期化され、その他のフィールドは <code>Point{1.0, 2.0}</code> などの従来の集約初期化式と同じ方法で初期化されます。
        </span>
    </p>

    <p class="pros">
    </p>
    <p>
        <span>
            <span class="src">
                Designated initializers can make for convenient and highly readable
                aggregate expressions, especially for structs with less straightforward
                ordering of fields than the <code>Point</code> example above.
            </span>
            指示付き初期化子は、特に上記の <code>Point</code> の例よりもフィールドの順序付けが単純でない構造体の場合に、便利で読みやすい集計式(aggregate expressions)を作成できます。
        </span>
    </p>

    <p class="cons">
    </p>
    <p>
        <span>
            <span class="src">
                While designated initializers have long been part of the C standard and
                supported by C++ compilers as an extension, only recently have they made it
                into the C++ standard, being added as part of C++20.
            </span>
            指示付き初期化子は、長い間、標準C言語の一部であり、C++ コンパイラによって拡張機能としてサポートされていましたが、最近、 C++20 の一部として、C++ 標準に組み込まれました。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                The rules in the C++ standard are stricter than in C and compiler extensions,
                requiring that the designated initializers appear in the same order as the
                fields appear in the struct definition.
            </span>
            C++標準における規則は、標準Cやコンパイラの拡張機能のものよりも厳しく、指示付き初期化子が、構造体の定義におけるフィールドと同じ順序で現れることを要求しています。
        </span>
        <span>
            <span class="src">
                So in the example above, it is legal
                according to C++20 to initialize <code>x</code> and then <code>z</code>, but not
                <code>y</code> and then <code>x</code>.
            </span>
            したがって、C++20 において、前述の例では、<code>x</code> のあとに <code>z</code> を初期化することは正当ですが、<code>y</code> のあとに <code>x</code> をおくことはできません。
        </span>
    </p>

    <p class="decision">
    </p>
    <p>
        <span>
            <span class="src">
                Use designated initializers only in the form that is compatible with the
                C++20 standard: with initializers in the same order as the corresponding fields
                appear in the struct definition.
            </span>
            指示付き初期化子は、C++20 標準と互換性のある形式でのみ使用してください。対応するフィールドが構造体定義に現れるのと同じ順序で初期化子を使用します。
        </span>
    </p>

    <h3 id="Lambda_expressions"><span title="Lambda expressions">ラムダ式</span></h3>

    <p>
        <span>
            <span class="src">
                Use lambda expressions where appropriate.
            </span>
            ラムダ式は、それが適切な場合に、使用してください。
        </span>
        <span>
            <span class="src">
                Prefer explicit captures
                when the lambda will escape the current scope.
            </span>
            ラムダ式が現在のスコープの外に出て行くときは、明示的な変数のキャプチャを行いましょう。
        </span>
    </p>

    <p class="definition"></p>

    <p>
        <span>
            <span class="src">
                Lambda expressions are a concise way of creating anonymous
                function objects.
            </span>
            ラムダ式は、匿名関数オブジェクトを作るための簡潔な方法です。
        </span>
        <span>
            <span class="src">
                They're often useful when passing
                functions as arguments. For example:
            </span>
            関数の引数として渡す場合にも便利です。例を見てみましょう。
        </span>
    </p>

    <pre>std::sort(v.begin(), v.end(), [](int x, int y) {
  return Weight(x) &lt; Weight(y);
});
</pre>

    <p>
        <span>
            <span class="src">
                They further allow capturing variables from the enclosing scope either
                explicitly by name, or implicitly using a default capture.
            </span>
            さらに、ラムダ式は、自身を囲むスコープから変数をキャプチャすることができます。変数をキャプチャは、明示的に名前を指定するか、暗黙的なデフォルトのキャプチャを使うかのどちらかによって行われます。
        </span>
        <span>
            <span class="src">
                Explicit captures
                require each variable to be listed, as
                either a value or reference capture:
            </span>
            明示的なキャプチャのためには、次のように、各変数を、値とするか参照とするかを指定しつつリストに並べます。
        </span>
    </p>
    <div>
        <div class="src">
            <pre>int weight = 3;
int sum = 0;
// Captures `weight` by value and `sum` by reference.
std::for_each(v.begin(), v.end(), [weight, &amp;sum](int x) {
  sum += weight * x;
});
</pre>
        </div>
        <pre>int weight = 3;
int sum = 0;
// weigthは値として、sumは参照としてキャプチャします。
std::for_each(v.begin(), v.end(), [weight, &amp;sum](int x) {
  sum += weight * x;
});
</pre>
    </div>
    <p>
        <span>
            <span class="src">
                Default captures implicitly capture any variable referenced in the
                lambda body, including <code>this</code> if any members are used:
            </span>
            デフォルトのキャプチャは暗黙的にラムダ式の本体で参照されたすべての変数をキャプチャします。何らかのメンバが使われている場合は<code>this</code>もキャプチャされます。
        </span>
    </p>
    <div>
        <div class="src">
            <pre>const std::vector&lt;int&gt; lookup_table = ...;
std::vector&lt;int&gt; indices = ...;
// Captures `lookup_table` by reference, sorts `indices` by the value
// of the associated element in `lookup_table`.
std::sort(indices.begin(), indices.end(), [&amp;](int a, int b) {
  return lookup_table[a] &lt; lookup_table[b];
});
</pre>
        </div>
        <pre>const std::vector&lt;int&gt; lookup_table = ...;
std::vector&lt;int&gt; indices = ...;
// lookup_tableを参照としてキャプチャし、
// lookup_tableの要素に関連づけられたindicesの値をソートしています。
std::sort(indices.begin(), indices.end(), [&amp;](int a, int b) {
  return lookup_table[a] &lt; lookup_table[b];
});
</pre>
</div>
        <p>
            <span>
                <span class="src">
                    A variable capture can also have an explicit initializer, which can
                    be used for capturing move-only variables by value, or for other situations
                    not handled by ordinary reference or value captures:
                </span>
                変数キャプチャには、明示的な初期化子を含めることもできます。これは、ムーブ専用の変数を値でキャプチャしたい場合や、通常の参照キャプチャや値キャプチャでは処理されないその他の状況に対応できます。
            </span>
        </p>
        <pre>std::unique_ptr&lt;Foo&gt; foo = ...;
        [foo = std::move(foo)] () {
          ...
        }</pre>
        <p>
            <span>
                <span class="src">
                    Such captures (often called "init captures" or "generalized lambda captures")
                    need not actually "capture" anything from the enclosing scope, or even have
                    a name from the enclosing scope; this syntax is a fully general way to define
                    members of a lambda object:
                </span>
                このようなキャプチャ (「初期化キャプチャ」または「一般化されたラムダキャプチャ」と呼ばれることが多い)は、実際には、囲んでいるスコープから何かを「キャプチャする」必要はなく、囲んでいるスコープ内に名前を持っている必要さえありません。
                この構文は、ラムダオブジェクトのメンバ変数を定義するための完全に一般的な方法です。
            </span>
        </p>
        <pre class="neutralcode">[foo = std::vector&lt;int&gt;({1, 2, 3})] () {
          ...
        }</pre>
        <p>
            <span>
                <span class="src">
                    The type of a capture with an initializer is deduced using the same rules
                    as <code>auto</code>.
                </span>
                初期化子を使用したキャプチャの型は、<code>auto</code>と同じ規則を使用して推論されます。
            </span>
        </p>

        <p class="pros"></p>
        <ul>
            <li>
                <span>
                    <span class="src">
                        Lambdas are much more concise than other ways of
                        defining function objects to be passed to STL
                        algorithms, which can be a readability
                        improvement.
                    </span>
                    ラムダ式は、STLのアルゴリズムに渡すためには、関数オブジェクトを作るよりも遙かに簡潔な方法であり、可読性も向上させます。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        Appropriate use of default captures can remove
                        redundancy and highlight important exceptions from
                        the default.
                    </span>
                    適切にデフォルトキャプチャを用いることで、余分な記述を減らせます。また、デフォルトとは異なる重要な例外を目立たせることもできます。
                </span>
            </li>

            <li>
                <span>
                    <span class="src">
                        Lambdas, <code>std::function</code>, and
                        <code>std::bind</code> can be used in combination as a
                        general purpose callback mechanism; they make it easy
                        to write functions that take bound functions as
                        arguments.
                    </span>
                    ラムダ式や<code>std::function</code>、<code>std::bind</code>は、一般的なコールバックのメカニズムとして、それらを組み合わせて使用することができ、引数に関数をとるような関数が書きやすくなります。
                </span>
            </li>
        </ul>

    <p class="cons"></p>
    <ul>
        <li>
            <span>
                <span class="src">
                    Variable capture in lambdas can be a source of dangling-pointer
                    bugs, particularly if a lambda escapes the current scope.
                </span>
                ラムダ式の変数のキャプチャは、ダングリングポインタバグの元になる危険があり、特にラムダ式がそのスコープの外に出ていくときは注意が必要です。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Default captures by value can be misleading because they do not prevent
                    dangling-pointer bugs.
                </span>
                デフォルトでは値によるキャプチャが行われますが、これらがダングリングポインタのバグを防ぐことはないため、ミスリードも起こしやすいです。
            </span>
            <span>
                <span class="src">
                    Capturing a pointer by value doesn't cause a deep
                    copy, so it often has the same lifetime issues as capture by reference.
                </span>
                ポインタを値でキャプチャしてもそれが自動的にディープコピーされることはありません。このため、参照でキャプチャした場合と同様に、オブジェクトの寿命に関する問題を内包しています。
            </span>
            <span>
                <span class="src">
                    This is especially confusing when capturing 'this' by value, since the use
                    of 'this' is often implicit.
                </span>
                特に、thisポインタを値でキャプチャした場合には混乱の元になりやすいです。thisは暗黙的に使用されることが多いからです。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    Captures actually declare new variables (whether or not the captures have
                    initializers), but they look nothing like any other variable declaration
                    syntax in C++.
                </span>
                キャプチャは(キャプチャに初期化子があるかどうかに関係なく)実際に新しい変数を宣言しますが、C++ の他の変数宣言構文とはまったく異なる見た目をしています。
            </span>
            <span>
                <span class="src">
                    In particular, there's no place for the variable's type,
                    or even an <code>auto</code> placeholder (although init captures can
                    indicate it indirectly, e.g., with a cast).
                </span>
                特に、変数の型や<code>auto</code>プレースホルダーの場所はありません (ただし、初期化キャプチャは、キャストなどを使用して間接的にキャプチャの型を示すことができます)。
            </span>
            <span>
                <span class="src">
                    This can make it difficult to
                    even recognize them as declarations.
                </span>
                これにより、それらが宣言であると認識することさえ困難になる可能性があります。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Init captures inherently rely on <a href="#Type_deduction">type
                        deduction</a>, and suffer from many of the same drawbacks as
                    <code>auto</code>, with the additional problem that the syntax doesn't
                    even cue the reader that deduction is taking place.
                </span>
                初期化キャプチャは本質的に<a href="#Type_deduction">型推論</a>に依存しており、<code>auto</code>と同様の欠点の多くに悩まされることになります。さらに、その、構文上、そこで型推論が行われることを読者に知らせることもできないという追加の問題があります。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    It's possible for use of lambdas to get out of
                    hand; very long nested anonymous functions can make
                    code harder to understand.
                </span>
                ラムダ式は、手に余るような扱い方もできてしまいます。たとえば、非常に長い匿名の関数がネストされていたとしたら、そのコードを理解するのは難しくなるでしょう。
            </span>
        </li>

    </ul>

    <p class="decision"></p>
    <ul>
        <li>
            <span>
                <span class="src">
                    Use lambda expressions where appropriate, with formatting as
                    described <a href="#Formatting_Lambda_Expressions">below</a>.
                </span>
                ラムダ式は、適切な場合に限り、使用してください。その際の書式は<a href="#Formatting_Lambda_Expressions">ラムダ式の書式</a>に従ってください。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    Prefer explicit captures if the lambda may escape the current scope.
                </span>
                ラムダ式が現在のスコープの外に出て行く場合は、明示的なキャプチャを使いましょう。
            </span>
            <span>
                <span class="src">
                    For example, instead of:
                </span>
                以下に例を示します。悪い例:
            </span>
            <div>
                <div class="src">
                    <pre class="badcode">{
  Foo foo;
  ...
  executor-&gt;Schedule([&amp;] { Frobnicate(foo); })
  ...
}
// BAD! The fact that the lambda makes use of a reference to `foo` and
// possibly `this` (if `Frobnicate` is a member function) may not be
// apparent on a cursory inspection. If the lambda is invoked after
// the function returns, that would be bad, because both `foo`
// and the enclosing object could have been destroyed.
</pre>
                </div>
                <pre class="badcode">{
  Foo foo;
  ...
  executor-&gt;Schedule([&amp;] { Frobnicate(foo); })
  ...
}
// これはダメ！
// ラムダ式において、`foo`と`this`(`Frobnicate`がメンバ関数である場合)が
// 使用されていますが、それは大まかにみるだけでは明らかとは言えません。
// もし、Schedule関数から処理が戻った後に、ラムダ式が呼ばれることがあると、
// よくないことが起こるかもしれません。ラムダ式が呼び出されたとき、
// `foo`も、このラムダを取り囲んでいたオブジェクトも
// すでに存在していないかもしれないからです。
</pre>
            </div>
            <span>
                <span class="src">
                    prefer to write:
                </span>
                良い例:
            </span>
            <div>
                <div class="src">
                    <pre>{
  Foo foo;
  ...
  executor-&gt;Schedule([&amp;foo] { Frobnicate(foo); })
  ...
}
// BETTER - The compile will fail if `Frobnicate` is a member
// function, and it's clearer that `foo` is dangerously captured by
// reference.
</pre>
                </div>
                <pre>{
  Foo foo;
  ...
  executor-&gt;Schedule([&amp;foo] { Frobnicate(foo); })
  ...
}
// この方がマシ。
// Frobnicateがメンバ関数である場合、コンパイルに失敗します。
// また、fooが危険なキャプチャをされていることがより明確になります。
</pre>
            </div>
        </li>
        <li>
            <span>
                <span class="src">
                    Use default capture by reference ([&amp;]) only when the
                    lifetime of the lambda is obviously shorter than any potential
                    captures.
                </span>
                参照のデフォルトキャプチャ(<code>[&amp;]</code>)は、ラムダ式の寿命が、その潜在的なキャプチャのすべてよりも明らかに短いときにのみ使用してください。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    Use default capture by value ([=]) only as a means of binding a
                    few variables for a short lambda, where the set of captured
                    variables is obvious at a glance, and which does not result in
                    capturing <code>this</code> implicitly.
                </span>
                値のデフォルトキャプチャ(<code>[=]</code>)は、短いラムダ式において1～2個の変数がキャプチャされる場合で、かつ、一目見ただけでどの変数がキャプチャされているかがわかり、暗黙的な<code>this</code>のキャプチャが行われない場合にのみ使用してください。
            </span>
            <span>
                <span class="src">
                    (That means that a lambda that
                    appears in a non-static class member function and refers to non-static
                    class members in its body must capture <code>this</code> explicitly or
                    via <code>[&amp;]</code>.)
                </span>
                (つまり、クラスの非staticなメンバ関数内にあって、かつ、何らかの非staticなメンバを内部で参照するラムダ式は必ず<code>this</code>を明示的にキャプチャするか、<code>[&amp;]</code>を使用してください。)
            </span>
            <span>
                <span class="src">
                    Prefer not to write long or
                    complex lambdas with default capture by value.
                </span>
                長いラムダ式や複雑なラムダ式には、値のデフォルトキャプチャは使わないでください。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    Use captures only to actually capture variables from the enclosing scope.
                </span>
                キャプチャは自身を囲むスコープから実際に変数をキャプチャするためだけに使用してください。
            </span>
            <span>
                <span class="src">
                    Do not use captures with initializers to introduce new names, or
                    to substantially change the meaning of an existing name.
                </span>
                新しい名前を導入する目的、あるいは、既存の名前の意味を実質的に変える目的で、初期化子つきキャプチャを使わないでください。
            </span>
            <span>
                <span class="src">
                    Instead,
                    declare a new variable in the conventional way and then capture it,
                    or avoid the lambda shorthand and define a function object explicitly.
                </span>
                そのかわり、従来の方法で新しいローカル変数を宣言しそれをキャプチャするか、ラムダ式による短縮表現をやめて関数オブジェクトを明示的に定義してください。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    See the section on <a href="#Type_deduction">type deduction</a>
                    for guidance on specifying the parameter and return types.
                </span>
                引数や戻り値型の指定に関するガイドとして<a href="#Type_deduction">型推論</a>のセクションも参照してください。
            </span>
        </li>
    </ul>

    <h3 id="Template_metaprogramming"><span title="Template metaprogramming">テンプレートメタプログラミング</span></h3>

    <p>
        <span>
            <span class="src">
                Avoid complicated template programming.
            </span>
            複雑なテンプレートプログラミングは避けましょう。
        </span>
    </p>

    <p class="definition"></p>
    <p>
        <span>
            <span class="src">
                Template metaprogramming refers to a family of techniques that
                exploit the fact that the C++ template instantiation mechanism is
                Turing complete and can be used to perform arbitrary compile-time
                computation in the type domain.
            </span>
            テンプレートメタプログラミングとは、C++のテンプレート実体化の仕組みがチューリング完全であり、コンパイル時に型の世界で任意の計算を行うために使用できるという事実を利用した一連のテクニックを指します。
        </span>
    </p>
    <p class="pros"></p>
    <p>
        <span>
            <span class="src">
                Template metaprogramming allows extremely flexible interfaces that
                are type safe and high performance.
            </span>
            テンプレートメタプログラミングによって、型安全かつ高性能で、非常に柔軟なインターフェースを提供することが可能になります。
        </span>
        <span>
            <span class="src">
                Facilities like

                <a href="https://github.com/google/googletest">GoogleTest</a>,
                <code>std::tuple</code>, <code>std::function</code>, and
                Boost.Spirit would be impossible without it.
            </span>
            <a href="https://github.com/google/googletest">GoogleTest</a>
            や<code>std::tuple</code>、<code>std::function</code>、Boost.Spiritのような仕組みは、テンプレートメタプログラミングがなければ実現できません。
        </span>
    </p>
    <p class="cons"></p>
    <p>
        <span>
            <span class="src">
                The techniques used in template metaprogramming are often obscure
                to anyone but language experts.
            </span>
            テンプレートメタプログラミングにおいて使われるテクニックは、言語に精通していない人には、わかりにくいものです。
        </span>
        <span>
            <span class="src">
                Code that uses templates in
                complicated ways is often unreadable, and is hard to debug or
                maintain.
            </span>
            複雑な方法でテンプレートを使っているコードは、可読性が低く、デバッグやメンテナンスが難しいものばかりです。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Template metaprogramming often leads to extremely poor compile
                time error messages: even if an interface is simple, the complicated
                implementation details become visible when the user does something
                wrong.
            </span>
            また、テンプレートメタプログラミングを使っていると、コンパイル時のエラーメッセージが非常に貧弱なものになることがあります。たとえ、インターフェースが単純なものであっても、ユーザーが何かを間違えたときに、その複雑な実装の詳細が見えるようになってしまうことがあります。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Template metaprogramming interferes with large scale refactoring by
                making the job of refactoring tools harder.
            </span>
            テンプレートメタプログラミングは、リファクタリングツールの仕事を困難にし、大規模なリファクタリングを阻害します。
        </span>
        <span>
            <span class="src">
                First, the template code
                is expanded in multiple contexts, and it's hard to verify that the
                transformation makes sense in all of them.
            </span>
            第一に、テンプレートコードは様々な文脈で展開されますが、展開されたそれらのすべてが正しいか否かを確かめることは難しいです。
        </span>
        <span>
            <span class="src">
                Second, some refactoring
                tools work with an AST that only represents the structure of the code
                after template expansion.
            </span>
            第二に、リファクタリングツールの中には、テンプレートを展開した後のコードの構造のみを含むASTを用いて動作するものが存在します。
        </span>
        <span>
            <span class="src">
                It can be difficult to automatically work
                back to the original source construct that needs to be
                rewritten.
            </span>
            それらのツールが、書き換えの対象となる元のソースコードの構造を自動的に復元することは困難でしょう。
        </span>
    </p>
    <p class="decision"></p>
    <p>
        <span>
            <span class="src">
                Template metaprogramming sometimes allows cleaner and easier-to-use
                interfaces than would be possible without it, but it's also often a
                temptation to be overly clever.
            </span>
            ときに、テンプレートメタプログラミングによって、きれいで、使いやすいインターフェースを提供することができます。しかし、同時に、必要以上にうまい実装をしようと感じさせられてしまう魅力も持ち合わせています。
        </span>
        <span>
            <span class="src">
                It's best used in a small number of
                low level components where the extra maintenance burden is spread out
                over a large number of uses.
            </span>
            テンプレートは低レベルで少数のコンポーネントに使われることがベストであり、さもなくば、多くのコードに過剰なメンテナンスのための負荷が広がってしまうことになるかもしれません。

        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Think twice before using template metaprogramming or other
                complicated template techniques; think about whether the average
                member of your team will be able to understand your code well enough
                to maintain it after you switch to another project, or whether a
                non-C++ programmer or someone casually browsing the code base will be
                able to understand the error messages or trace the flow of a function
                they want to call.
            </span>
            テンプレートメタプログラミングやその他の複雑なテンプレートのテクニックを使おうとする前に、もう一度よく考えてください。あなたのプロジェクトチームの平均的なメンバーは、あなたがチームを抜けた後でも、そのコードを十分に理解してメンテナンスすることができるでしょうか。あるいは、C++プログラマでない人や他の誰かがカジュアルにコードベースを見たときに、エラーメッセージを理解したり、呼ぼうとする関数のフローを追いかけることができるでしょうか。
        </span>
        <span>
            <span class="src">
                If you're using recursive template instantiations
                or type lists or metafunctions or expression templates, or relying on
                SFINAE or on the <code>sizeof</code> trick for detecting function
                overload resolution, then there's a good chance you've gone too
                far.
            </span>
            もし、あなたがテンプレートのインスタンス化や型リストやメタ関数や式テンプレートを再帰的に使おうとしていたり、あるいは、SFINAEや<code>sizeof</code>トリックに基づいて関数のオーバーロードを解決しようとしているとしたら、それらは、大抵、あなたがあまりにも遠くに来てしまったことを意味しています。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                If you use template metaprogramming, you should expect to put
                considerable effort into minimizing and isolating the complexity.
            </span>
            テンプレートメタプログラミングを使うのであれば、その複雑さを最小化、分離することに対する相応の努力を払わなくてはなりません。
        </span>
        <span>
            <span class="src">
                You
                should hide metaprogramming as an implementation detail whenever
                possible, so that user-facing headers are readable, and you should
                make sure that tricky code is especially well commented.
            </span>
            可能であれば、メタプログラミングは実装の詳細として隠されるべきでしょう。そうすることで、あなたのユーザーが目にするヘッダーは可読性が高くなります。また、トリッキーなコードには特にしっかり確実にコメントを残すようにしてください。
        </span>
        <span>
            <span class="src">
                You should
                carefully document how the code is used, and you should say something
                about what the "generated" code looks like.
            </span>
            コードを使い方については、注意してドキュメント化してください。その際、「生成されるコード」の外観についても何かしら言及しておいてください。
        </span>
        <span>
            <span class="src">
                Pay extra attention to the
                error messages that the compiler emits when users make mistakes.
            </span>
            ユーザーがミスを犯した場合にコンパイラが生成するであろうエラーメッセージにも特別の注意を払ってください。
        </span>
        <span>
            <span class="src">
                The
                error messages are part of your user interface, and your code should
                be tweaked as necessary so that the error messages are understandable
                and actionable from a user point of view.
            </span>
            このエラーメッセージはあなたが提供するユーザーインターフェースの一部なのです。ユーザーが何かを間違えたときに、ユーザーにとって理解可能であり、どうすればよいかわかるようなエラーメッセージが生成されるよう、コードは調整されていなければなりません。
        </span>
    </p>

    <h3 id="Boost"><span title="Boost">boost</span></h3>

    <p>
        <span>
            <span class="src">
                Use only approved libraries from the Boost library
                collection.
            </span>
            boostのうち、あらかじめ認められたライブラリのみを使用することができます。
        </span>
    </p>

    <p class="definition"></p>
    <p>
        <span>
            <span class="src">
                The
                <a href="https://www.boost.org/">
                    Boost library collection
                </a> is a popular collection of
                peer-reviewed, free, open-source C++ libraries.
            </span>
            <a href="https://www.boost.org/">boostライブラリコレクション</a>は、ピアレビュー済み、フリー、オープンソースのC++ライブラリの有名なコレクションです。
        </span>
    </p>
    <p class="pros"></p>
    <p>
        <span>
            <span class="src">
                Boost code is generally very high-quality, is widely
                portable, and fills many important gaps in the C++
                standard library, such as type traits and better binders.
            </span>
            一般に、boostのコードはとても品質が良く、広い移植性を持ち、型traitsやよりよいバインダなどを持つように、C++の標準ライブラリの隙間を埋めてくれます。
        </span>
    </p>
    <p class="cons"></p>
    <p>
        <span>
            <span class="src">
                Some Boost libraries encourage coding practices which can
                hamper readability, such as metaprogramming and other
                advanced template techniques, and an excessively
                "functional" style of programming.
            </span>
            boostライブラリの中には、メタプログラミングやその他の先進的なテンプレートテクニックを取り入れたり、過度に「機能本意(functional)」なプログラミングスタイルを採用したりと、コードの可読性を妨げるコーディング手法を推奨しているものもあります。
        </span>
    </p>
    <p class="decision"></p>

    <p>
        <span>
            <span class="src">
                In order to maintain a high level of readability for
                all contributors who might read and maintain code, we
                only allow an approved subset of Boost features.
            </span>
            コードを読みメンテナンスを行うすべてのコントリビュータのために、コードは高い可読性が保たれていなければなりません。
            可読性を維持するため、あらかじめ許可されたboostのサブセットのみが使用を認められています。
        </span>
        <span>
            <span class="src">
                Currently, the following libraries are permitted:
            </span>
            現在のところ使用が認められてるライブラリは下記のとおりです。
        </span>
    </p>

    <ul>
        <li>
            <span>
                <span class="src">
                    <a href="https://www.boost.org/libs/utility/call_traits.htm">
                        Call Traits
                    </a> from <code>boost/call_traits.hpp</code>
                </span>
                <a href="https://www.boost.org/libs/utility/call_traits.htm">Call Traits</a>
                (<code>boost/call_traits.hpp</code>)
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    <a href="https://www.boost.org/libs/utility/compressed_pair.htm">
                        Compressed Pair
                    </a> from <code>boost/compressed_pair.hpp</code>
                </span>
                <a href="https://www.boost.org/libs/utility/compressed_pair.htm">Compressed Pair</a>
                (<code>boost/compressed_pair.hpp</code>)
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    <a href="https://www.boost.org/libs/graph/">
                        The Boost Graph Library (BGL)
                    </a> from <code>boost/graph</code>,
                    except serialization (<code>adj_list_serialize.hpp</code>) and
                    parallel/distributed algorithms and data structures
                    (<code>boost/graph/parallel/*</code> and
                    <code>boost/graph/distributed/*</code>).
                </span>
                <a href="https://www.boost.org/libs/graph/">The Boost Graph Library (BGL)</a>
                (<code>boost/graph</code>) ただし、serialization (<code>adj_list_serialize.hpp</code>)と、
                parallel/distributed algorithms and data structures
                (<code>boost/graph/parallel/*</code>, <code>boost/graph/distributed/*</code>)を除く
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    <a href="https://www.boost.org/libs/property_map/">
                        Property Map
                    </a> from <code>boost/property_map</code>, except
                    parallel/distributed property maps (<code>boost/property_map/parallel/*</code>).
                </span>
                <a href="https://www.boost.org/libs/property_map/">Property
                    Map</a>(<code>boost/property_map</code>) ただし、parallel/distributed property maps
                (<code>boost/property_map/parallel/*</code>) を除く
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    <a href="https://www.boost.org/libs/iterator/">
                        Iterator
                    </a> from <code>boost/iterator</code>
                </span>
                <a href="https://www.boost.org/libs/iterator/">
                    Iterator
                </a> (<code>boost/iterator</code>)
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    The part of <a href="https://www.boost.org/libs/polygon/">
                        Polygon
                    </a> that deals with Voronoi diagram
                    construction and doesn't depend on the rest of
                    Polygon:
                    <code>boost/polygon/voronoi_builder.hpp</code>,
                    <code>boost/polygon/voronoi_diagram.hpp</code>, and
                    <code>boost/polygon/voronoi_geometry_type.hpp</code>
                </span>
                <a href="https://www.boost.org/libs/polygon/">Polygon</a>のうち、Voronoi diagram
                constructionを扱い、かつ残りのPolygonに依存していない部分
                (<code>boost/polygon/voronoi_builder.hpp</code>,
                <code>boost/polygon/voronoi_diagram.hpp</code>,
                <code>boost/polygon/voronoi_geometry_type.hpp</code>)
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    <a href="https://www.boost.org/libs/bimap/">
                        Bimap
                    </a> from <code>boost/bimap</code>
                </span>
                <a href="https://www.boost.org/libs/bimap/">
                    Bimap
                </a> (<code>boost/bimap</code>)
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    <a href="https://www.boost.org/libs/math/doc/html/dist.html">
                        Statistical Distributions and Functions
                    </a> from
                    <code>boost/math/distributions</code>
                </span>
                <a href="https://www.boost.org/libs/math/doc/html/dist.html">
                    Statistical Distributions and Functions
                </a> (<code>boost/math/distributions</code>)
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    <a href="https://www.boost.org/libs/math/doc/html/special.html">
                        Special Functions
                    </a> from <code>boost/math/special_functions</code>
                </span>
                <a href="https://www.boost.org/libs/math/doc/html/special.html">
                    Special Functions
                </a> (<code>boost/math/special_functions</code>)
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    <a href="https://www.boost.org/libs/multi_index/">
                        Multi-index
                    </a> from <code>boost/multi_index</code>
                </span>
                <a href="https://www.boost.org/libs/multi_index/">
                    Multi-index
                </a> (<code>boost/multi_index</code>)
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    <a href="https://www.boost.org/libs/heap/">
                        Heap
                    </a> from <code>boost/heap</code>
                </span>
                <a href="https://www.boost.org/libs/heap/">
                    Heap
                </a> (<code>boost/heap</code>)
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    The flat containers from
                    <a href="https://www.boost.org/libs/container/">Container</a>:
                    <code>boost/container/flat_map</code>, and
                    <code>boost/container/flat_set</code>
                </span>
                <a href="https://www.boost.org/libs/container/">Container</a>のThe flat containers
                (<code>boost/container/flat_map</code>, <code>boost/container/flat_set</code>)
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    <a href="https://www.boost.org/libs/intrusive/">Intrusive</a>
                    from <code>boost/intrusive</code>.
                </span>
                <a href="https://www.boost.org/libs/intrusive/">Intrusive</a> (<code>boost/intrusive</code>)
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    <a href="https://www.boost.org/libs/sort/">
                        The
                        <code>boost/sort</code> library
                    </a>.
                </span>
                <a href="https://www.boost.org/libs/sort/">
                    The
                    <code>boost/sort</code> library
                </a>
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    <a href="https://www.boost.org/libs/preprocessor/">Preprocessor</a>
                    from <code>boost/preprocessor</code>.
                </span>
                <a href="https://www.boost.org/libs/preprocessor/">Preprocessor</a>
                (<code>boost/preprocessor</code>)
            </span>
        </li>
    </ul>

    <p>
        <span>
            <span class="src">
                We are actively considering adding other Boost
                features to the list, so this list may be expanded in
                the future.
            </span>
            boostの他の機能については、随時リストへの追加が検討されています。今後、このリストは拡張されることがあります。
        </span>
    </p>


    <a id="C++11"></a>
    <h3 id="Other_Features"><span title="Other C++ Features">その他のC++機能</span></h3>

    <p>
        <span>
            <span class="src">
                As with <a href="#Boost">Boost</a>, some modern C++
                extensions encourage coding practices that hamper
                readability&#8212;for example by removing
                checked redundancy (such as type names) that may be
                helpful to readers, or by encouraging template
                metaprogramming.
            </span>
            <a
                href="#Boost">boost</a>を使う場合のように、いくつかのモダンなC++拡張は、可読性を低下させるようなコーディングプラクティスを奨励します。たとえば、型名などの読者の助けになるはずの冗長性を省いてしまったり、テンプレートメタプログラミングを奨励したりします。
        </span>
        <span>
            <span class="src">
                Other extensions duplicate functionality
                available through existing mechanisms, which may lead to confusion
                and conversion costs.
            </span>
            他の拡張は、既存のメカニズムを通してすでに機能的に実現可能であったことを再発明しており、それらは混乱や対話のためのコストを招き入れるかもしれません。
        </span>
    </p>
    <p class="decision"></p>

    <p>
        <span>
            <span class="src">
                In addition to what's described in the rest of the style
                guide, the following C++ features may not be used:
            </span>
            本ガイドの他の部分で説明している事柄に加えて、以下に示すC++の機能は使ってはいけません。
        </span>
    </p>

    <ul>

        <li>
            <span>
                <span class="src">
                    Compile-time rational numbers
                    (<code>&lt;ratio&gt;</code>), because of concerns that
                    it's tied to a more template-heavy interface
                    style.
                </span>
                コンパイル時有理数(<code>&lt;ratio&gt;</code>)。より重いテンプレートを使ったインターフェースのスタイルと紐付いている懸念があるため。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    The <code>&lt;cfenv&gt;</code> and
                    <code>&lt;fenv.h&gt;</code> headers, because many
                    compilers do not support those features reliably.
                </span>
                <code>&lt;cfenv&gt;</code>と<code>&lt;fenv.h&gt;</code>ヘッダー。多くのコンパイラにおいて、これらの機能に対する信頼性がないため。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    The <code>&lt;filesystem&gt;</code> header, which

                    does not have sufficient support for testing, and suffers
                    from inherent security vulnerabilities.
                </span>
                <code>&lt;filesystem&gt;</code>ヘッダー。テストへのサポートが十分でなく、性質上セキュリティ脆弱性を抱えやすいため。
            </span>

        </li>
    </ul>

    <h3 id="Nonstandard_Extensions"><span title="Nonstandard Extensions">非標準の拡張</span></h3>

    <p>
        <span>
            <span class="src">
                Nonstandard extensions to C++ may not be used unless otherwise specified.
            </span>
            C++に対する非標準の拡張は、あらかじめ決められているものを除いて使用してはいけません。
        </span>
    </p>
    <p class="definition"></p>
    <p>
        <span>
            <span class="src">
                Compilers support various extensions that are not part of standard C++.
            </span>
            コンパイラは、C++の標準にはない、様々な拡張を提供しています。
        </span>
        <span>
            <span class="src">
                Such
                extensions include GCC's <code>__attribute__</code>, intrinsic functions such
                as <code>__builtin_prefetch</code>, inline assembly, <code>__COUNTER__</code>,
                <code>__PRETTY_FUNCTION__</code>, compound statement expressions (e.g.,
                <code>foo = ({ int x; Bar(&amp;x); x })</code>, variable-length arrays and
                <code>alloca()</code>, and the "<a href="https://en.wikipedia.org/wiki/Elvis_operator">Elvis Operator</a>"
                <code>a?:b</code>.
            </span>
            たとえば、GCCの<code>__attribute__</code>や、<code>__builtin_prefetch</code>のようなintrinsic関数、インラインアセンブリ、<code>__COUNTER__</code>、<code>__PRETTY_FUNCTION__</code>、<code>foo = ({ int x; Bar(&amp;x); x })</code>のようなcompound statement expression、可変長配列と<code>alloca()</code>、「<a href="https://ja.wikipedia.org/wiki/%E3%82%A8%E3%83%AB%E3%83%93%E3%82%B9%E6%BC%94%E7%AE%97%E5%AD%90">エルビス演算子</a>」<code>a?:b</code>などです。
        </span>
    </p>
    <p class="pros"></p>
    <ul>
        <li>
            <span>
                <span class="src">
                    Nonstandard extensions may provide useful features that do not exist
                    in standard C++.
                </span>
                非標準の拡張は、標準C++にない便利な機能を提供してくれます。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    Important performance guidance to the compiler can only be specified
                    using extensions.
                </span>
                パフォーマンスに関する重要なガイドをコンパイラに伝えるためには、このような拡張機能を使うしかありません。
            </span>
        </li>
    </ul>

    <p class="cons"></p>
    <ul>
        <li>
            <span>
                <span class="src">
                    Nonstandard extensions do not work in all compilers.
                </span>
                非標準の拡張はすべてのコンパイラで動くわけではありません。
            </span>
            <span>
                <span class="src">
                    Use of nonstandard
                    extensions reduces portability of code.
                </span>
                これらを使用するとコードの移植性が低下します。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    Even if they are supported in all targeted compilers, the extensions
                    are often not well-specified, and there may be subtle behavior differences
                    between compilers.
                </span>
                ターゲットとしているすべてのコンパイラでサポートされている機能であっても、このような拡張は十分に仕様が決められていない場合があり、コンパイラ間で微妙に異なる動作をすることもあります。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    Nonstandard extensions add to the language features that a reader must
                    know to understand the code.
                </span>
                非標準の拡張によって、コードの読者がコードを理解するために必要とする知識の量が増えます。
            </span>
        </li>
    </ul>

    <p class="decision"></p>
    <p>
        <span>
            <span class="src">
                Do not use nonstandard extensions.
            </span>
            非標準の拡張を使ってはいけません。
        </span>
        <span>
            <span class="src">
                You may use portability wrappers that
                are implemented using nonstandard extensions, so long as those wrappers

                are provided by a designated project-wide
                portability header.
            </span>
            ただし、プロジェクトにおいて、そのプロジェクト内全体で使用するように設計されたヘッダーとして、非標準の拡張機能に関する移植性を保つためのラッパーが提供されている場合は、それらを通してのみ非標準の機能を使用してもかまいません。
        </span>
    </p>

    <h3 id="Aliases"><span title="Aliases">エイリアス</span></h3>

    <p>
        <span>
            <span class="src">
                Public aliases are for the benefit of an API's user, and should be clearly documented.
            </span>
            パブリックなエイリアスはAPIのユーザーにとって有用なものです。それらは、明確にドキュメント化されていなければなりません。
        </span>
    </p>
    <p class="definition"></p>
    <p>
        <span>
            <span class="src">
                There are several ways to create names that are aliases of other entities:
            </span>
            他のエンティティのエイリアスとして名前をつけるためには、以下に例を示すとおり、いくつかの方法があります。
        </span>
    </p>
    <pre>typedef Foo Bar;
using Bar = Foo;
using other_namespace::Foo;
</pre>

    <p>
        <span>
            <span class="src">
                In new code, <code>using</code> is preferable to <code>typedef</code>,
                because it provides a more consistent syntax with the rest of C++ and works
                with templates.
            </span>
            新しいコードにおいては、<code>typedef</code>よりも<code>using</code>を使う方がよいでしょう。
            <code>using</code>は、C++の他の部分との一貫性がよく、またテンプレートにおいても機能します。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Like other declarations, aliases declared in a header file are part of that
                header's public API unless they're in a function definition, in the private portion of a class,
                or in an explicitly-marked internal namespace.
            </span>
            エイリアスは、関数の定義内やクラスのprivateな部分、あるいは内部用と明示された名前空間の中で宣言されている場合を除いて、他の宣言と同様に、ヘッダーファイルにおいて、そのヘッダーの持つパブリックなAPIの一部として宣言されます。

        </span>
        <span>
            <span class="src">
                Aliases in such areas or in .cc files are
                implementation details (because client code can't refer to them), and are not restricted by this
                rule.
            </span>
            一方で、先に述べたような場所や、.ccファイルにあるエイリアスは、クライアントのコードが参照できない実装の詳細の一部であるため、このルールによる制限は受けません。
        </span>
    </p>
    <p class="pros"></p>
    <ul>
        <li>
            <span>
                <span class="src">
                    Aliases can improve readability by simplifying a long or complicated name.
                </span>
                エイリアスは、長い複雑な名前を単純化するため、可読性を高めます。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    Aliases can reduce duplication by naming in one place a type used repeatedly in an API,
                    which <em>might</em> make it easier to change the type later.
                </span>
                エイリアスは、APIにおいて型名が繰り返し使われる場合に、型に名前をつけることで、その重複を減らします。こうすることで、後で型を変更するのが容易になる<em>かも</em>しれません。
            </span>
        </li>
    </ul>

    <p class="cons"></p>
    <ul>
        <li>
            <span>
                <span class="src">
                    When placed in a header where client code can refer to them, aliases increase the
                    number of entities in that header's API, increasing its complexity.
                </span>
                クライアントコードが参照できるヘッダーでエイリアスが宣言されるとき、それらはそのヘッダーのAPIが提供するエンティティの数を増やすため、複雑性が増します。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    Clients can easily rely on unintended details of public aliases, making
                    changes difficult.
                </span>
                意図しないパプリックなエイリアスがあると、クライアントは簡単にそれに依存してしまうことができ、それによって後の変更が難しくなります。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    It can be tempting to create a public alias that is only intended for use
                    in the implementation, without considering its impact on the API, or on maintainability.
                </span>
                エイリアスを認めることは、APIやそのメンテナンス性に対する影響をよく考えず、実装で使用するだけの目的でパプリックなエイリアスを作ってしまうことへの誘惑となりえます。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    Aliases can create risk of name collisions
                </span>
                エイリアスは名前が衝突するリスクを生み出します。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    Aliases can reduce readability by giving a familiar construct an unfamiliar name
                </span>
                馴染みのある構造に馴染みのない名前のエイリアスをつけてしまうと可読性が低下します。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    Type aliases can create an unclear API contract:
                    it is unclear whether the alias is guaranteed to be identical to the type it aliases,
                    to have the same API, or only to be usable in specified narrow ways
                </span>
                型のエイリアスは、APIの規約を不明瞭にする場合があります。それは、エイリアスが常に同一の型へのエイリアスであり同じAPIを持っていることが保証されているのか、はたまた、指定されている狭い方法でしか使用できないのかがわからない場合などです。
            </span>
        </li>
    </ul>

    <p class="decision"></p>
    <p>
        <span>
            <span class="src">
                Don't put an alias in your public API just to save typing in the implementation;
                do so only if you intend it to be used by your clients.
            </span>
            実装においてタイピングする文字の数を減らすためにパプリックなAPIとしてエイリアスを配置してはいけません。クライアントに使ってもらうことを目的としている場合に限り、エイリアスをパプリックにしてください。
        </span>
    </p>
    <p>
        <span>
            <span class="src">
                When defining a public alias, document the intent of
                the new name, including whether it is guaranteed to always be the same as the type
                it's currently aliased to, or whether a more limited compatibility is
                intended.
            </span>
            パプリックなエイリアスを定義するとき、その新しい名前の意図をドキュメント化してください。また、ドキュメントには、その名前がその時点で指していた型と常に同一の型を指し続けることが保証されているか、あるいはより限られた互換性が目的とされているのかということも含めてください。
        </span>
        <span>
            <span class="src">
                This lets the user know whether they can treat the types as
                substitutable or whether more specific rules must be followed, and can help the
                implementation retain some degree of freedom to change the alias.
            </span>
            これによって、ユーザーはその型を単に置き換えていいのか、もっと細かいルールに従う必要があるのかを判断できます。また、これによって、エイリアスの変更に対するある程度の自由度を確保することができるため、実装もしやすくなるでしょう。
        </span>
    </p>
    <p>
        <span>
            <span class="src">
                Don't put namespace aliases in your public API. (See also <a href="#Namespaces">Namespaces</a>).
            </span>
            namespaceへのエイリアスをパプリックなAPIの中においてはいけません(<a href="#Namespaces">名前空間</a>を参照)。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                For example, these aliases document how they are intended to be used in client code:
            </span>
            たとえば、以下の例を見てください。これらのエイリアスは、クライアントコードにおいてそれらがどう扱われることを意図しているかドキュメント化しています。
        </span>
    </p>
    <div>
        <div class="src">
            <pre>namespace mynamespace {
// Used to store field measurements. DataPoint may change from Bar* to some internal type.
// Client code should treat it as an opaque pointer.
using DataPoint = ::foo::Bar*;

// A set of measurements. Just an alias for user convenience.
using TimeSeries = std::unordered_set&lt;DataPoint, std::hash&lt;DataPoint&gt;, DataPointComparator&gt;;
}  // namespace mynamespace
</pre>
        </div>
        <pre>namespace mynamespace {
// フィールドの測定値を保存するために使用されます。
// DataPoint は Bar* から他の内部型に変更されるかもしれません。
// クライアントコードにおいては、これを透過的なポインタとして扱ってください。
using DataPoint = ::foo::Bar*;

// 測定のセットです。
// これはユーザーの利便性のために定義されています。
using TimeSeries = std::unordered_set&lt;DataPoint, std::hash&lt;DataPoint&gt;, DataPointComparator&gt;;
}  // namespace mynamespace
</pre>
    </div>
    <p>
        <span>
            <span class="src">
                These aliases don't document intended use, and half of them aren't meant for client use:
            </span>
            一方、次の例のエイリアスは、意図に関するドキュメントがなく、さらにその半分はクライアントで使用する目的ですらありません。
        </span>
    </p>
    <div>
        <div class="src">
            <pre class="badcode">namespace mynamespace {
// Bad: none of these say how they should be used.
using DataPoint = ::foo::Bar*;
using ::std::unordered_set;  // Bad: just for local convenience
using ::std::hash;           // Bad: just for local convenience
typedef unordered_set&lt;DataPoint, hash&lt;DataPoint&gt;, DataPointComparator&gt; TimeSeries;
}  // namespace mynamespace
</pre>
        </div>
        <pre class="badcode">namespace mynamespace {
// ダメ: どのように扱われるべきかが書かれていない。
using DataPoint = ::foo::Bar*;
using ::std::unordered_set;  // ダメ: 自分の利便性のため
using ::std::hash;           // ダメ: 自分の利便性のため
typedef unordered_set&lt;DataPoint, hash&lt;DataPoint&gt;, DataPointComparator&gt; TimeSeries;
}  // namespace mynamespace
</pre>
</div>
    <p>
        <span>
            <span class="src">
                However, local convenience aliases are fine in function definitions, private sections of
                classes, explicitly marked internal namespaces, and in .cc files:
            </span>
            しかし、自分の利便性のためのエイリアスは、関数定義の中で定義する分には問題ありません。クラスのprivateセクションや、明示的に内部使用するとマークされている名前空間の中や、.ccファイル内での定義も同様に問題ありません。
        </span>
    </p>

    <div>
        <div class="src">
            <pre>// In a .cc file
using ::foo::Bar;
</pre>
        </div>
        <pre>// .ccファイルの中
using ::foo::Bar;
</pre>
    </div>

    <h2 id="Inclusive_Language"><span title="Inclusive Language">インクルーシブ・ランゲージ</span></h2>

    <p>
        <span>
            <span class="src">
                In all code, including naming and comments, use inclusive language
                and avoid terms that other programmers might find disrespectful or offensive
                (such as "master" and "slave", "blacklist" and "whitelist", or "redline"),
                even if the terms also have an ostensibly neutral meaning.
            </span>
            命名やコメントを含むすべてのコードで「インクルーシブ・ランゲージ」を使用し、他のプログラマーが無礼または不快に感じる可能性のある用語 (「マスター」と「スレーブ」、「ブラックリスト」と「ホワイトリスト」、または「レッドライン」など) は、その用語に表面上は中立的な意味があったとしても、使用を避けてください。
        </span>
        <span>
            <span class="src">
                Similarly, use gender-neutral language unless you're referring
                to a specific person (and using their pronouns).
            </span>
            同様に、特定の人(およびその人の代名詞)に言及している場合を除き、性別に中立な言葉を使用してください。
        </span>
        <span>
            <span class="src">
                For example,
                use "they"/"them"/"their" for people of unspecified gender
                (<a href="https://apastyle.apa.org/style-grammar-guidelines/grammar/singular-they">even
                    when singular</a>), and "it"/"its" for software, computers, and other
                things that aren't people.
            </span>
            たとえば、 "they" / "them" / "their" は、性別が特定されていない人
            (<a href="https://apastyle.apa.org/style-grammar-guidelines/grammar/singular-they">単数の場合でも</a>)
            に使用し、"it" / "its" は、ソフトウェア、コンピューター、およびその他の人ではないものに使用します。
        </span>
    </p>

    <h2 id="Naming"><span title="Naming">命名規則</span></h2>

    <p>
        <span>
            <span class="src">
                The most important consistency rules are those that govern
                naming.
            </span>
            一貫性を保つためのもっとも重要ルールは、名前の付け方を決めることです。
        </span>
        <span>
            <span class="src">
                The style of a name immediately informs us what sort of
                thing the named entity is: a type, a variable, a function, a
                constant, a macro, etc., without requiring us to search for the
                declaration of that entity.
            </span>
            名前のスタイルのおかげで、名前のついたそれが何であるか、型なのか、変数なのか、関数なのか、定数なのか、マクロなのか、その宣言を探しに行かなくとも、すぐにわかるのです。

        </span>
        <span>
            <span class="src">
                The pattern-matching engine in our
                brains relies a great deal on these naming rules.
            </span>
            我々の脳内パターンマッチングエンジンは、これらの名前付けのルールに大きく依存しています。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Naming rules are pretty arbitrary, but
                we feel that
                consistency is more important than individual preferences in this
                area, so regardless of whether you find them sensible or not,
                the rules are the rules.
            </span>
            命名規則はかなり恣意的なものですが、我々は個人の好みよりも全体の一貫性をより重要視します。そのため、あなたがわかりやすいかと感じるかどうかに関わらず、ルールはルールと考えてください。
        </span>
    </p>

    <h3 id="General_Naming_Rules"><span title="General Naming Rules">全般的な命名規則</span></h3>

    <p>
        <span>
            <span class="src">
                Optimize for readability using names that would be clear
                even to people on a different team.
            </span>
            他のチームのメンバーから見てもわかりやすい命名を行うことによって、可読性を最適化するようにしてください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Use names that describe the purpose or intent of the object.
            </span>
            オブジェクトには、目的や意図がわかるような名前をつけてください。
        </span>
        <span>
            <span class="src">
                Do not worry about saving horizontal space as it is far
                more important to make your code immediately
                understandable by a new reader.
            </span>
            画面の横幅を気にする必要はありません。そんなことよりも、あなたのコードが新しい読者にとってすぐに理解できるようにすることの方がはるかに重要です。
        </span>
        <span>
            <span class="src">
                Minimize the use of
                abbreviations that would likely be unknown to someone outside
                your project (especially acronyms and initialisms).
            </span>
            プロジェクト外のコード読者に意味が通じないかもしれない省略形の使用は最小限にとどめてください。
        </span>
        <span>
            <span class="src">
                Do not
                abbreviate by deleting letters within a word.
            </span>
            語句の中の文字を削る方法による省略も行わないでください。
        </span>
        <span>
            <span class="src">
                As a rule of thumb, an abbreviation is probably OK if it's listed in
                Wikipedia.
            </span>
            ルールを平たく言えば、Wikipediaに書いてあるような省略語はOKというところでしょうか。
        </span>
        <span>
            <span class="src">
                Generally speaking, descriptiveness should be
                proportional to the name's scope of visibility.
            </span>
            一般的には、その記述性は、その名前が見えるスコープに比例すべきです。
        </span>
        <span>
            <span class="src">
                For example,
                <code>n</code> may be a fine name within a 5-line function,
                but within the scope of a class, it's likely too vague.
            </span>
            例えば<code>n</code>は5行しかない関数内では問題ないかもしれませんが、クラススコープ内にあったとしたら曖昧すぎるでしょう。
        </span>

    </p>
    <div>
        <div class="src">
            <pre>class MyClass {
 public:
  int CountFooErrors(const std::vector&lt;Foo&gt;&amp; foos) {
    int n = 0;  // Clear meaning given limited scope and context
    for (const auto&amp; foo : foos) {
      ...
      ++n;
    }
    return n;
  }
  void DoSomethingImportant() {
    std::string fqdn = ...;  // Well-known abbreviation for Fully Qualified Domain Name
  }
 private:
  const int kMaxAllowedConnections = ...;  // Clear meaning within context
};
</pre>
        </div>
        <pre>class MyClass {
 public:
  int CountFooErrors(const std::vector&lt;Foo&gt;&amp; foos) {
    int n = 0;  // 限られたスコープと文脈において、十分明確
    for (const auto&amp; foo : foos) {
      ...
      ++n;
    }
    return n;
  }
  void DoSomethingImportant() {
    std::string fqdn = ...;  // Fully Qualified Domain Name のよく知られた略語
  }
 private:
  const int kMaxAllowedConnections = ...;  // 文脈から意味が明確
}; </pre>
    </div>

    <div>
        <div class="src">
            <pre class="badcode">class MyClass {
 public:
  int CountFooErrors(const std::vector&lt;Foo&gt;&amp; foos) {
    int total_number_of_foo_errors = 0;  // Overly verbose given limited scope and context
    for (int foo_index = 0; foo_index &lt; foos.size(); ++foo_index) {  // Use idiomatic `i`
      ...
      ++total_number_of_foo_errors;
    }
    return total_number_of_foo_errors;
  }
  void DoSomethingImportant() {
    int cstmr_id = ...;  // Deletes internal letters
  }
 private:
  const int kNum = ...;  // Unclear meaning within broad scope
};
</pre>
        </div>
        <pre class="badcode">class MyClass {
 public:
  int CountFooErrors(const std::vector&lt;Foo&gt;&amp; foos) {
    int total_number_of_foo_errors = 0;  // スコープと文脈に対して冗長すぎる
    for (int foo_index = 0; foo_index &lt; foos.size(); ++foo_index) {  // 慣用的な `i` を使うべき
      ...
      ++total_number_of_foo_errors;
    }
    return total_number_of_foo_errors;
  }
  void DoSomethingImportant() {
    int cstmr_id = ...;  // 単語の途中の文字を消している
  }
 private:
  const int kNum = ...;  // 広いスコープに対して意味が不明瞭
};
</pre>
    </div>

    <p>
        <span>
            <span class="src">
                Note that certain universally-known abbreviations are OK, such as
                <code>i</code> for an iteration variable and <code>T</code> for a
                template parameter.
            </span>
            一般に広く知られている省略形を使うことはOKであることに注意してください。たとえば、イテレータ変数の<code>i</code>や、テンプレート引数の<code>T</code>などは問題ありません。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                For the purposes of the naming rules below, a "word" is anything that you
                would write in English without internal spaces.
            </span>
            以下の命名規則では、「単語」とはスペースを含まない英単語を指します。
        </span>
        <span>
            <span class="src">
                This includes abbreviations,
                such as acronyms and initialisms.
            </span>
            これには頭字語(acronymやinitialism)などの略語も含まれます。
        </span>
        <span>
            <span class="src">
                For names written in mixed case (also
                sometimes referred to as
                "<a href="https://en.wikipedia.org/wiki/Camel_case">camel case</a>" or
                "<a href="https://en.wiktionary.org/wiki/Pascal_case">Pascal case</a>"), in
                which the first letter of each word is capitalized, prefer to capitalize
                abbreviations as single words, e.g., <code>StartRpc()</code> rather than
                <code>StartRPC()</code>.
            </span>
            各単語の頭文字を大文字とした、大文字と小文字を混在させた名前（「<a href="https://en.wikipedia.org/wiki/Camel_case">キャメルケース</a>」または「<a                 href="https://en.wiktionary.org/wiki/Pascal_case">パスカルケース</a>」と呼ばれるもの）においては、            略語は単一の単語であるかのように表記しましょう（例えば <code>StartRPC()</code>ではなく<code>StartRpc()</code>）。
        </span>
    </p>
    <p>
        <span>
            <span class="src">
                Template parameters should follow the naming style for their
                category: type template parameters should follow the rules for
                <a href="#Type_Names">type names</a>, and non-type template
                parameters should follow the rules for <a href="#Variable_Names">
                variable names</a>.
            </span>
            テンプレート引数の命名規則は、引数が型ならば<a href="#Type_Names">型名</a>に従い、そうでない場合は<a href="#Variable_Names">変数名</a>に従ってください。
        </span>

    </p>
    <h3 id="File_Names"><span title="File Names">ファイル名</span></h3>

    <p>
        <span>
            <span class="src">
                Filenames should be all lowercase and can include
                underscores (<code>_</code>) or dashes (<code>-</code>).
            </span>
            ファイル名はすべて小文字で、アンダースコア(<code>_</code>)とダッシュ(<code>-</code>)を含むことができます。
        </span>
        <span>
            <span class="src">
                Follow the convention that your

                project uses.
            </span>
            プロジェクトが使用するルールに従ってください。
        </span>
        <span>
            <span class="src">
                If there is no consistent
                local pattern to follow, prefer "_".
            </span>
            もし、プロジェクトでの独自の定めがない場合、アンダースコアを使用しましょう。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Examples of acceptable file names:
            </span>
            問題のないファイル名の例
        </span>
    </p>

    <ul>
        <li>
            <code>my_useful_class.cc</code>
        </li>
        <li>
            <code>my-useful-class.cc</code>
        </li>
        <li>
            <code>myusefulclass.cc</code>
        </li>
        <li>
            <span>
                <span class="src">
                    <code>myusefulclass_test.cc // _unittest and _regtest are deprecated.</code>
                </span>
                <code>myusefulclass_test.cc // _unittest や _regtest は廃止</code>
            </span>
        </li>
    </ul>

    <p>
        <span>
            <span class="src">
                C++ files should end in
                <code>.cc</code> and header files should end in
                <code>.h</code>.
            </span>
            C++のファイルは<code>.cc</code>で終わり、ヘッダーは<code>.h</code>で終わります。
        </span>
        <span>
            <span class="src">
                Files that rely on being textually included at specific points
                should end in
                <code>.inc</code> (see also the section on
                <a href="#Self_contained_Headers">self-contained headers</a>).
            </span>
            特定の場所にそのままインクルードされることが目的のファイルは<code>.inc</code>で終わります(<a href="#Self_contained_Headers">自己完結型ヘッダー</a>のセクションも参照してください)。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Do not use filenames that already exist in
                <code>/usr/include</code>, such as
                <code>db.h</code>.
            </span>
            既に<code>/usr/include</code>に存在するファイル名をつけてはいけません(たとえば<code>db.h</code>)。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                In general, make your filenames very specific.
            </span>
            通常、ファイル名は非常に明確なものをつけてください。
        </span>
        <span>
            <span class="src">
                For
                example, use <code>http_server_logs.h</code> rather than
                <code>logs.h</code>.
            </span>
            たとえば、<code>logs.h</code>よりも<code>http_server_logs.h</code>としてください。
        </span>
        <span>
            <span class="src">
                A very common case is to have a pair
                of files called, e.g.,
                <code>foo_bar.h</code> and
                <code>foo_bar.cc</code>, defining a class called
                <code>FooBar</code>.
            </span>
            非常に良くあるパターンは、ファイルをペアにして、たとえば<code>foo_bar.h</code>と<code>foo_bar.cc</code>で、クラス<code>FooBar</code>を定義するようなやり方です。
        </span>
    </p>
    <h3 id="Type_Names"><span title="Type Names">型名</span></h3>

    <p>
        <span>
            <span class="src">
                Type names start with a capital letter and have a capital
                letter for each new word, with no underscores:
                <code>MyExcitingClass</code>,
                <code>MyExcitingEnum</code>.
            </span>
            型の名前は大文字で始まり、単語の区切りごとに大文字にします。アンダースコアは使いません。たとえば、<code>MyExcitingClass</code>、<code>MyExcitingEnum</code>とします。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                The names of all types — classes, structs, type aliases,
                enums, and type template parameters — have the same naming convention.
            </span>
            型(クラス、構造体、型のエイリアス、列挙型、テンプレート引数)の名前はすべて同じ命名規則に従います。
        </span>
        <span>
            <span class="src">
                Type names should start with a capital letter and have a capital letter
                for each new word.
            </span>
            型の名前は大文字で始めて、単語の境目ごとに大文字にします。
        </span>
        <span>
            <span class="src">
                No underscores.
            </span>
            アンダースコアは使いません。
        </span>
        <span>
            <span class="src">
                For example:
            </span>
            以下に例を示します。
        </span>
    </p>
    <div>
        <div class="src">
            <pre>// classes and structs
class UrlTable { ...
class UrlTableTester { ...
struct UrlTableProperties { ...

// typedefs
typedef hash_map&lt;UrlTableProperties *, std::string&gt; PropertiesMap;

// using aliases
using PropertiesMap = hash_map&lt;UrlTableProperties *, std::string&gt;;

// enums
enum class UrlTableError { ...
</pre>
        </div>
        <pre>// クラスと構造体
class UrlTable { ...
class UrlTableTester { ...
struct UrlTableProperties { ...

// typedef
typedef hash_map&lt;UrlTableProperties *, std::string&gt; PropertiesMap;

// using
using PropertiesMap = hash_map&lt;UrlTableProperties *, std::string&gt;;

// 列挙型
enum class UrlTableError { ...
</pre>
    </div>

    <h3 id="Variable_Names"><span title="Variable Names">変数名</span></h3>

    <p>
        <span>
            <span class="src">
                The names of variables (including function parameters) and data members are
                all lowercase, with underscores between words.
            </span>
            変数名(関数の引数も含む)や、データメンバ名は、小文字で始め単語の間にアンダースコアを使います。
        </span>
        <span>
            <span class="src">
                Data members of classes (but not
                structs) additionally have trailing underscores.
            </span>
            クラス(構造体は含まず)のデータメンバは、末尾にアンダースコアをつけます。
        </span>
        <span>
            <span class="src">
                For instance:
                <code>a_local_variable</code>,
                <code>a_struct_data_member</code>,
                <code>a_class_data_member_</code>.
            </span>
            たとえば、<code>a_local_variable</code>、<code>a_struct_data_member</code>、<code>a_class_data_member_</code>といった感じです。
        </span>
    </p>

    <h4 class="stylepoint_subsection"><span title="Common Variable names">一般的な変数名</span></h4>

    <p>
        <span>
            <span class="src">
                For example:
            </span>
            以下に例を示します。
        </span>
    </p>
    <div>
        <div class="src">
            <pre>std::string table_name;  // OK - lowercase with underscore.
</pre>
        </div>
        <pre>std::string table_name;  // OK - 小文字でアンダースコアを使っている。
</pre>
    </div>
    <div>
        <div class="src">
            <pre class="badcode">std::string tableName;   // Bad - mixed case.
</pre>
        </div>
        <pre class="badcode">std::string tableName;   // ダメ - 大文字小文字が混ざっている。
</pre>
    </div>
    <h4 class="stylepoint_subsection"><span title="Class Data Members">クラスのデータメンバ</span></h4>

    <p>
        <span>
            <span class="src">
                Data members of classes, both static and non-static, are
                named like ordinary nonmember variables, but with a
                trailing underscore.
            </span>
            クラスのデータメンバは、staticであるなしに関わらず、基本的にはメンバでない変数名と同様ですが、末尾にアンダースコアをつけます。
        </span>
    </p>
    <div>
        <div class="src">
            <pre>class TableInfo {
  ...
 private:
  std::string table_name_;  // OK - underscore at end.
  static Pool&lt;TableInfo&gt;* pool_;  // OK.
};
</pre>
        </div>
        <pre>class TableInfo {
  ...
 private:
  std::string table_name_;  // OK - 末尾にアンダースコアがついている。
  static Pool&lt;TableInfo&gt;* pool_;  // OK.
};
</pre>
    </div>
    <h4 class="stylepoint_subsection"><span title="Struct Data Members">構造体のデータメンバ</span></h4>

    <p>
        <span>
            <span class="src">
                Data members of structs, both static and non-static,
                are named like ordinary nonmember variables.
            </span>
            構造体のデータメンバは、staticであるなしに関わらず、通常の変数と同じように名前を付けます。
        </span>
        <span>
            <span class="src">
                They do not have
                the trailing underscores that data members in classes have.
            </span>
            クラスのデータメンバと違い、末尾にアンダースコアはつけません。
        </span>
    </p>

    <pre>struct UrlTableProperties {
  std::string name;
  int num_entries;
  static Pool&lt;UrlTableProperties&gt;* pool;
};
</pre>

    <p>
        <span>
            <span class="src">
                See
                <a href="#Structs_vs._Classes">
                    Structs vs.
                    Classes
                </a> for a discussion of when to use a struct
                versus a class.
            </span>
            いつ構造体を使っていつクラスを使うかに関する議論は<a href="#Structs_vs._Classes">構造体かクラスか</a>を参照してください。
        </span>
    </p>
    <h3 id="Constant_Names"><span title="Constant Names">定数名</span></h3>

    <p>
        <span>
            <span class="src">
                Variables declared constexpr or const, and whose value is fixed for
                the duration of the program, are named with a leading "k" followed
                by mixed case.
            </span>
            constexprあるいはconstとして宣言され、プログラムの始めから終わりまで値が変わらない変数は、頭に「k」を付けて、大文字小文字を織り交ぜて宣言します。
        </span>
        <span>
            <span class="src">
                Underscores can be used as separators in the rare cases
                where capitalization cannot be used for separation.
            </span>
            大文字化できない一部のケースにおいては、アンダースコアを用いることができます。
        </span>
        <span>
            <span class="src">
                For example:
            </span>
            以下に例を示します。
        </span>
    </p>
    <pre>const int kDaysInAWeek = 7;
const int kAndroid8_0_0 = 24;  // Android 8.0.0</pre>
    <p>
        <span>
            <span class="src">
                All such variables with static storage duration (i.e., statics and globals,
                see
                <a href="http://en.cppreference.com/w/cpp/language/storage_duration#Storage_duration">
                    Storage Duration
                </a> for details) should be named this way.
            </span>
            このようなすべての、静的記憶域期間を持つ変数(つまり、静的変数やグローバル変数。詳細は<a
                href="http://en.cppreference.com/w/cpp/language/storage_duration#Storage_duration">Storage
                Duration</a>を参照)は、この方法で命名します。
        </span>
        <span>
            <span class="src">
                This
                convention is optional for variables of other storage classes, e.g., automatic
                variables, otherwise the usual variable naming rules apply.
            </span>
            他の記憶域期間に分類される変数(自動変数など)に関してはこのルールの適用は任意とし、このルールを適用しない場合は、通常の変数名の規則に従うものとします。
        </span>
    </p>
    <p>

    </p>
    <h3 id="Function_Names"><span title="Function Names">関数名</span></h3>

    <p>
        <span>
            <span class="src">
                Regular functions have mixed case; accessors and mutators may be named
                like variables.
            </span>
            通常の関数は、大文字小文字を混ぜて命名します。getter(accessor)やsetter(mutator)は、変数名の命名ルールを用いることもあります。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Ordinarily, functions should start with a capital letter and have a
                capital letter for each new word.
            </span>
            通常、関数名は大文字で始まり、新しい単語が現れるごとに大文字を使用します。
        </span>
    </p>

    <pre>AddTableEntry()
DeleteUrl()
OpenFileOrDie()
</pre>
    <p>
        <span>
            <span class="src">
                (The same naming rule applies to class- and namespace-scope
                constants that are exposed as part of an API and that are intended to look
                like functions, because the fact that they're objects rather than functions
                is an unimportant implementation detail.)
            </span>
            (クラススコープや名前空間スコープにおいて定数がAPIとして公開され、かつ、それらが関数のように振る舞う場合は、この命名規則を適用します。それらが実際には関数ではなくオブジェクトであるという事実は、実装の詳細でありさほど重要ではありません。)
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Accessors and mutators (get and set functions) may be named like
                variables.
            </span>
            getter(accessor)やsetter(mutator)は、変数名のように名前を付けてもかまいません。
        </span>
        <span>
            <span class="src">
                These often correspond to actual member variables, but this is
                not required.
            </span>
            これらは、実際のメンバ変数と紐づけられますが、必須ではありません。
        </span>
        <span>
            <span class="src">
                For example, <code>int count()</code> and <code>void
                set_count(int count)</code>.
            </span>
            たとえば、<code>int count()</code>と<code>void set_count(int count)</code>です。
        </span>
    </p>
    <h3 id="Namespace_Names"><span title="Namespace Names">名前空間の名前</span></h3>

    <p>
        <span>
            <span class="src">
                Namespace names are all lower-case, with words separated by underscores.
            </span>
            名前空間名はすべて小文字にし、単語同士をアンダースコアで区切ります。
        </span>
        <span>
            <span class="src">
                Top-level namespace names are
                based on the project name
            </span>
            トップレベルの名前空間は、プロジェクト名に基づいたものにします。
        </span>
        <span>
            <span class="src">
                Avoid collisions
                between nested namespaces and well-known top-level namespaces.
            </span>
            ネストされた名前空間であっても、よく知られたトップレベルの名前空間との衝突は避けてください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                The name of a top-level namespace should usually be the
                name of the project or team whose code is contained in that
                namespace.
            </span>
            トップレベルの名前空間の名前は、通常はプロジェクト名か、そのコードが格納されるチームの名前をつけます。
        </span>
        <span>
            <span class="src">
                The code in that namespace should usually be in
                a directory whose basename matches the namespace name (or in
                subdirectories thereof).
            </span>
            名前空間に含まれるコードは、通常、その名前空間の名前と一致するディレクトリ(かそのサブディレクトリ)の中に置かれます。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Keep in mind that the <a href="#General_Naming_Rules">rule
                against abbreviated names</a> applies to namespaces just as much
                as variable names.
            </span>
            変数名と同様の<a href="#General_Naming_Rules">省略に関するルール</a>が名前空間にも適用されることに留意してください。
        </span>
        <span>
            <span class="src">
                Code inside the namespace seldom needs to
                mention the namespace name, so there's usually no particular need
                for abbreviation anyway.
            </span>
            名前空間の内側のコードが、その名前空間の名前を必要とすることはめったにありません。
            このため、いずれにせよ、通常は、何らかの省略形が必要になることはないでしょう。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Avoid nested namespaces that match well-known top-level
                namespaces.
            </span>
            ネストされた名前空間の名前を、よく知られたトップレベルの名前空間と一致させることは避けてください。
        </span>
        <span>
            <span class="src">
                Collisions between namespace names can lead to surprising
                build breaks because of name lookup rules.
            </span>
            このような名前空間名の衝突があると、名前検索のルールによって、想定外のビルドエラーを招きかねません。
        </span>
        <span>
            <span class="src">
                In particular, do not
                create any nested <code>std</code> namespaces.
            </span>
            特に、<code>std</code>という名前の名前空間は、いかなるネストの階層にも作らないでください。
        </span>
        <span>
            <span class="src">
                Prefer unique project
                identifiers
                (<code>websearch::index</code>, <code>websearch::index_util</code>)
                over collision-prone names like <code>websearch::util</code>.
            </span>
            <code>websearch::util</code>のような衝突の起こりやすい名前は避け、プロジェクト内でユニークな識別子をつけましょう(<code>websearch::index</code>, <code>websearch::index_util</code>)。
        </span>
        <span>
            <span class="src">
                Also avoid overly deep nesting
                namespaces (<a href="https://abseil.io/tips/130">TotW #130</a>).
            </span>
            また、深すぎる名前空間のネスト、も避けてください(<a href="https://abseil.io/tips/130">TotW #130</a>)。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                For <code>internal</code> namespaces, be wary of other code being
                added to the same <code>internal</code> namespace causing a collision
                (internal helpers within a team tend to be related and may lead to
                collisions).
            </span>
            <code>internal</code>のような名前空間は、同じ<code>internal</code>名前空間に追加されている他のコードと衝突しないように特に注意が必要です(チーム内での内部用のヘルパ同士が、関係を持ってしまう傾向があり、それによって衝突を引き起こすかもしれません)。
        </span>
        <span>
            <span class="src">
                In such a situation, using the filename to make a unique
                internal name is helpful
                (<code>websearch::index::frobber_internal</code> for use
                in <code>frobber.h</code>)
            </span>
            このような場合は、ファイル名を使ってユニークな内部名を作る方法が役立ちます(<code>frobber.h</code>では、<code>websearch::index::frobber_internal</code>を使います)。
        </span>
    </p>

    <h3 id="Enumerator_Names"><span title="Enumerator Names">列挙型の名前</span></h3>

    <p>
        <span>
            <span class="src">
                Enumerators (for both scoped and unscoped enums) should be named like
                <a href="#Constant_Names">constants</a>, not like
                <a href="#Macro_Names">macros</a>.
                That is, use <code>kEnumName</code> not
                <code>ENUM_NAME</code>.
            </span>
            列挙型(スコープ付き、スコープなしともに)は、<a href="#Macro_Names">マクロの命名規則</a>(<code>ENUM_NAME</code>)ではなく、<a href="#Constant_Names">定数の命名規則</a>(<code>kEnumName</code>)に従います。
        </span>
    </p>

    <pre>enum class UrlTableError {
  kOk = 0,
  kOutOfMemory,
  kMalformedInput,
};
</pre>
    <pre class="badcode">enum class AlternateUrlTableError {
  OK = 0,
  OUT_OF_MEMORY = 1,
  MALFORMED_INPUT = 2,
};
</pre>

    <p>
        <span>
            <span class="src">
                Until January 2009, the style was to name enum values
                like
                <a href="#Macro_Names">macros</a>.
            </span>
            2009年1月までは、列挙値は<a href="#Macro_Names">マクロ</a>の命名規則に従っていました。
        </span>
        <span>
            <span class="src">
                This caused
                problems with name collisions between enum values and
                macros.
            </span>
            しかし、これによって列挙値とマクロとの間で名前が衝突する問題が起きました。
        </span>
        <span>
            <span class="src">
                Hence, the change to prefer constant-style naming
                was put in place.
            </span>
            それゆえに、定数と同じ命名規則に従うようルールを変更しました。
        </span>
        <span>
            <span class="src">
                New code should use constant-style
                naming.
            </span>
            新しいコードでは定数と同様の命名規則を使ってください。
        </span>
    </p>

    <h3 id="Macro_Names"><span title="Macro Names">マクロ名</span></h3>

    <p>
        <span>
            <span class="src">
                You're not really going to <a href="#Preprocessor_Macros">
                efine a macro</a>, are you? If you do, they're like this:
                <code>MY_MACRO_THAT_SCARES_SMALL_CHILDREN_AND_ADULTS_ALIKE</code>.
            </span>
            本当は<a href="#Preprocessor_Macros">マクロを定義</a>しようだなんて思ってないですよね？　
            マクロを定義する場合は、<code>MY_MACRO_THAT_SCARES_SMALL_CHILDREN_AND_ADULTS_ALIKE</code> のようにします。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Please see the <a href="#Preprocessor_Macros">description
                of macros</a>; in general macros should <em>not</em> be used.
            </span>
            まず、<a href="#Preprocessor_Macros">マクロの詳細</a>を参照してください。通常、マクロは使用されるべきでは<em>ありません</em>。
        </span>
        <span>
            <span class="src">
                However, if they are absolutely needed, then they should be
                named with all capitals and underscores.
            </span>
            しかし、どうしてもマクロが必要な場合は、すべて大文字にし、アンダースコアを使って名前をつけます。
        </span>
    </p>

    <pre>#define ROUND(x) ...
#define PI_ROUNDED 3.0
</pre>

    <h3 id="Exceptions_to_Naming_Rules"><span title="Exceptions to Naming Rules">命名規則の例外</span></h3>

    <p>
        <span>
            <span class="src">
                If you are naming something that is analogous to an
                existing C or C++ entity then you can follow the existing
                naming convention scheme.
            </span>
            既存のCやC++のエンティティと類似したものに名前を付ける場合、既存の命名規則に従ってもかまいません。
        </span>
    </p>

    <dl>
        <dt><code>bigopen()</code></dt>
        <dd>
            <span>
                <span class="src">
                    function name, follows form of <code>open()</code>
                </span>
                <code>open()</code>の形に従った関数名。
            </span>
        </dd>

        <dt><code>uint</code></dt>
        <dd><code>typedef</code></dd>

        <dt><code>bigpos</code></dt>
        <dd>
            <span>
                <span class="src">
                    <code>struct</code> or <code>class</code>, follows
                    form of <code>pos</code>
                </span>
                <code>pos</code>の形に従った<code>struct</code>や<code>class</code>。
            </span>
        </dd>

        <dt><code>sparse_hash_map</code></dt>
        <dd>
            <span>
                <span class="src">
                    STL-like entity; follows STL naming conventions
                </span>
                STLの命名規則に従った、STLライクなエンティティ。
            </span>
        </dd>

        <dt><code>LONGLONG_MAX</code></dt>
        <dd>
            <span>
                <span class="src">
                    a constant, as in <code>INT_MAX</code>
                </span>
                <code>INT_MAX</code>のような定数。
            </span>
        </dd>
    </dl>

    <h2 id="Comments"><span title="Comments">コメント</span></h2>

    <p>
        <span>
            <span class="src">
                Comments are absolutely vital to keeping our code readable.
            </span>
            コードの可読性を保つために、コメントはなくてはならないものです。
        </span>
        <span>
            <span class="src">
                The following rules describe what
                you should comment and where.
            </span>
            このルールでは、どこにどのようなコメントを残すべきかを説明します。
        </span>
        <span>
            <span class="src">
                But remember: while comments are very important, the best code is
                self-documenting.
            </span>
            ひとつ忘れないでほしいことは、確かにコメントは非常に重要なものですが、それよりもコード自身がドキュメントの役割をしている状態がベストだということです。
        </span>
        <span>
            <span class="src">
                Giving sensible names to types and variables is much better than using obscure
                names that you must then explain through comments.
            </span>
            型や変数に、曖昧な名前をつけてコメントするよりも、コメント不要の適切な名前をつけるほうが、はるかに優れています。
        </span>
    </p>
    <p>
        <span>
            <span class="src">
                When writing your comments, write for your audience: the
                next
                contributor who will need to
                understand your code.
            </span>
            コメントを書くときは、読者を意識してください。
            次にコードを担当する人が、あなたが書いたコードを理解できるようにコメントを記述してください。
        </span>
        <span>
            <span class="src">
                Be generous — the next
                one may be you!
            </span>
            あるいは、次の担当者は自分かもしれません。惜しみなくコメントを書きましょう。
        </span>
    </p>

    <p>訳者注: 本日本語版ガイドではコード例中のコメントも日本語に訳していますが、ガイドの内容自体は英語によるコメントを対象としたままのものを記載しています。</p>

    <h3 id="Comment_Style"><span title="Comment Style">コメントのスタイル</span></h3>

    <p>
        <span>
            <span class="src">
                Use either the <code>//</code> or <code>/* */</code>
                syntax, as long as you are consistent.
            </span>
            コメントには、一貫性が保たれている限り、<code>//</code>か<code>/* */</code>のどちらを使ってもかまいません。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                You can use either the <code>//</code> or the <code>/*
                */</code> syntax; however, <code>//</code> is
                <em>much</em> more common.
            </span>
            コメントには、<code>//</code>と<code>/* */</code>のどちらの文法を使ってもかまいません。しかし、<code>//</code>の方が<em>はるかに</em>一般的です。
        </span>
        <span>
            <span class="src">
                Be consistent with how you
                comment and what style you use where.
            </span>
            どのスタイルでどこにどのようにコメントをつけるかは、一貫性を保ってください。
        </span>
    </p>

    <h3 id="File_Comments"><span title="File Comments">ファイルに対するコメント</span></h3>

    <p>
        <span>
            <span class="src">
                Start each file with license boilerplate.
            </span>
            各ファイルは、ライセンスに関する定型文で始めてください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                File comments describe the contents of a file.
            </span>
            ファイル全体に掛かるコメントでは、そのファイルに含まれる内容を説明します。
        </span>
        <span>
            <span class="src">
                If a file declares,
                implements, or tests exactly one abstraction that is documented by a comment
                at the point of declaration, file comments are not required.
            </span>
            そのファイルにおいてただ1つの概念だけを宣言または実装、テストしていて、かつ、それに関するコメントが宣言のすぐ近くにある場合は、ファイル全体を説明するコメントは必須というわけではありません。
        </span>
        <span>
            <span class="src">
                All other files
                must have file comments.
            </span>
            しかし、それ以外の場合は、各ファイルにはファイル全体に掛かる説明のコメントを書かなくてはなりません。
        </span>
    </p>

    <h4 class="stylepoint_subsection"><span title="Legal Notice and Author Line">法的な注意事項と著者に関する行</span></h4>

    <p>
        <span>
            <span class="src">
                Every file should contain license
                boilerplate.
            </span>
            すべてのファイルに、ライセンスに関する定型文を含めてください。
        </span>
        <span>
            <span class="src">
                Choose the appropriate boilerplate for the
                license used by the project (for example, Apache 2.0,
                BSD, LGPL, GPL).
            </span>
            定型文は、そのプロジェクトが採用しているライセンスに沿った適切なものを選択してください(たとえば、Apache 2.0, BSD, LGPL, GPL)。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                If you make significant changes to a file with an
                author line, consider deleting the author line.
            </span>
            著者に関するの行を含め、ファイルに対して大きな変更を加えた場合は、著者に関する行を削除することを検討してください。
        </span>
        <span>
            <span class="src">
                New files should usually not contain copyright notice or
                author line.
            </span>
            新しいファイルについては、通常、著作権表記や著者の行は含めません。
        </span>
    </p>

    <h4 class="stylepoint_subsection"><span title="File Contents">ファイルの内容に関するコメント</span></h4>

    <p>
        <span>
            <span class="src">
                If a
                <code>.h</code> declares multiple abstractions, the file-level comment
                should broadly describe the contents of the file, and how the abstractions are
                related.
            </span>
            <code>.h</code>ファイルが複数の概念を宣言している場合、ファイルレベルのコメントは、広くファイルの内容を説明するものにします。そして、それらの概念がどのように関係しているかを説明します。
        </span>
        <span>
            <span class="src">
                A 1 or 2 sentence file-level comment may be sufficient.
            </span>
            ファイル全体に掛かるコメントは、1つか2つの文で十分でしょう。
        </span>
        <span>
            <span class="src">
                The detailed
                documentation about individual abstractions belongs with those abstractions,
                not at the file level.
            </span>
            個々の概念に関する詳細なドキュメントは、ファイル全体に向けたコメントではなく、それぞれの概念に属すべきです。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Do not duplicate comments in both the
                <code>.h</code> and the
                <code>.cc</code>.
            </span>
            <code>.h</code>と<code>.cc</code>の両方にコメントを重複させてはいけません。
        </span>
        <span>
            <span class="src">
                Duplicated comments diverge.
            </span>
            重複したコメントは、いずれ分岐してしまいます。
        </span>
    </p>
    <h3 id="Class_Comments"><span title="Class Comments">クラスに対するコメント</span></h3>

    <p>
        <span>
            <span class="src">
                Every non-obvious class or struct declaration should have an accompanying
                comment that describes what it is for and how it should be used.
            </span>
            各クラスや構造体の宣言には、一目見ただけでわかるような場合を除いて、そのクラスの目的と使用方法についてのコメントが必要です。
        </span>
    </p>

    <div>
        <div class="src">
            <pre>// Iterates over the contents of a GargantuanTable.
// Example:
//    std::unique_ptr&lt;GargantuanTableIterator&gt; iter = table-&gt;NewIterator();
//    for (iter-&gt;Seek("foo"); !iter-&gt;done(); iter-&gt;Next()) {
//      process(iter-&gt;key(), iter-&gt;value());
//    }
class GargantuanTableIterator {
  ...
};
</pre>
        </div>
        <pre>// GargantuanTable全体をイテレートします
// 使用例:
//    std::unique_ptr&lt;GargantuanTableIterator&gt; iter = table-&gt;NewIterator();
//    for (iter-&gt;Seek("foo"); !iter-&gt;done(); iter-&gt;Next()) {
//      process(iter-&gt;key(), iter-&gt;value());
//    }
class GargantuanTableIterator {
  ...
};
</pre>
    </div>

    <p>
        <span>
            <span class="src">
                The class comment should provide the reader with enough information to know
                how and when to use the class, as well as any additional considerations
                necessary to correctly use the class.
            </span>
            クラスのコメントは、コードの読者がそのクラスをいつどのように使えばよいのかわかるように記述します。また、クラスを正しく扱うために必要な付加情報があればそれらも記述します。
        </span>
        <span>
            <span class="src">
                Document the synchronization assumptions
                the class makes, if any.
            </span>
            また、クラスにスレッド間等の同期に関する前提条件が存在する場合は、それらも記述します。
        </span>
        <span>
            <span class="src">
                If an instance of the class can be accessed by
                multiple threads, take extra care to document the rules and invariants
                surrounding multithreaded use.
            </span>
            クラスのインスタンスが複数のスレッドからアクセスされる場合は、そのクラスをマルチスレッド下で扱う場合のルールや不変条件に関しても、細心の注意を払って記述します。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                The class comment is often a good place for a small example code snippet
                demonstrating a simple and focused usage of the class.
            </span>
            クラスコメントは、そのクラスの使用例などの小さなコードスニペットを記載するためにも都合の良い場所です。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                When sufficiently separated (e.g.,
                <code>.h</code> and
                <code>.cc</code>
                files), comments describing the use of the class should go together with its
                interface definition; comments about the class operation and implementation
                should accompany the implementation of the class's methods.
            </span>
            コードが<code>.h</code>と<code>.cc</code>ファイルとに十分に分離されているとき、そのクラスの扱い方に関するコメントはインターフェースの定義のそばにおきます。その一方で、クラスの操作や実装に関するコメントは、クラスメソッドの実装のそばに置きます。
        </span>
    </p>
    <h3 id="Function_Comments"><span title="Function Comments">関数に対するコメント</span></h3>

    <p>
        <span>
            <span class="src">
                Declaration comments describe use of the function (when it is
                non-obvious); comments at the definition of a function describe
                operation.
            </span>
            関数を宣言するときのコメントでは、その関数の使い方(が明らかでない場合)について説明するようにします。一方で、関数を定義するときのコメントでは、その関数が行う操作について説明するようにします。
        </span>
    </p>

    <h4 class="stylepoint_subsection"><span title="Function Declarations">関数宣言時のコメント</span></h4>

    <p>
        <span>
            <span class="src">
                Almost every function declaration should have comments immediately
                preceding it that describe what the function does and how to use
                it.
            </span>
            ほぼすべての関数宣言において、その宣言の直前に、関数の目的と使用方法に関するコメントが必要です。
        </span>
        <span>
            <span class="src">
                These comments may be omitted only if the function is simple and
                obvious (e.g., simple accessors for obvious properties of the class).
            </span>
            関数が非常に単純で一目で何をするのかがわかる場合は、コメントを省略してもかまいません(たとえば、クラスプロパティへのアクセッサである場合など)。
        </span>
        <span>
            <span class="src">
                Private methods and functions declared in `.cc` files are not exempt.
            </span>
            `.cc`ファイル内で宣言されたprivateなメソッドや関数についても免除されません。
        </span>
        <span>
            <span class="src">
                Function comments should be written with an implied subject of
                <i>This function</i> and should start with the verb phrase; for example,
                "Opens the file", rather than "Open the file".
            </span>
            関数のコメントは、(英語で書くならば)<i>This function</i>を暗黙的な主語として、動詞句から始めます。
            例えば "Open the file" ではなく、"Opens the file"です。
        </span>
        <span>
            <span class="src">
                In general, these comments do not
                describe how the function performs its task.
            </span>
            一般的に、これら関数宣言のコメントでは、その関数が「どのように」処理を行うかについては触れません。
        </span>
        <span>
            <span class="src">
                Instead, that should be
                left to comments in the function definition.
            </span>
            そのような内容は、ここではなく、関数定義のコメントに譲るようにしてください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Types of things to mention in comments at the function
                declaration:
            </span>
            関数の宣言のコメントで言及すべきことは以下のような内容です。
        </span>
    </p>

    <ul>
        <li>
            <span>
                <span class="src">
                    What the inputs and outputs are.
                </span>
                関数の入力と出力は何か。
            </span>
            <span>
                <span class="src">
                    If function argument names
                    are provided in `backticks`, then code-indexing
                    tools may be able to present the documentation better.
                </span>
                関数の引数名は<code>`backticks`</code>のようにバッククオートで囲んで記述すると、コードインデックスツールによってドキュメント化した場合の表示がよくなるかもしれません。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    For class member functions: whether the object remembers
                    reference or pointer arguments beyond the duration of the method
                    call.
                </span>
                クラスメンバ関数について、関数に渡した参照やポインタの引数について、関数から処理が戻った後もオブジェクトがそれらを記憶し続けるか否か。
            </span>
            <span>
                <span class="src">
                    This is quite common for pointer/reference arguments to
                    constructors.
                </span>
                これはコンストラクタへのポインタ引数や参照引数でとても一般的です。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    For each pointer argument, whether it is allowed to be null and what happens
                    if it is.
                </span>
                各ポインタ引数について、その引数がnullでもよいか否か、また、nullの場合何が起きるか。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    For each output or input/output argument, what happens to any state that argument
                    is in. (E.g. is the state appended to or overwritten?).
                </span>
                各出力引数や入出力引数において、その引数の各状態に対して引数の状態がどうなるか。
                （例えば、新たに状態が追加されるのか、上書きされるのか）
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    If there are any performance implications of how a
                    function is used.
                </span>
                関数の使い方に関するパフォーマンス上の注意事項がある場合はその情報。
            </span>
        </li>
    </ul>

    <p>
        <span>
            <span class="src">
                Here is an example:
            </span>
            以下に例を示します。
        </span>
    </p>
<div>
                    <div class="src">
<pre>// Returns an iterator for this table, positioned at the first entry
// lexically greater than or equal to `start_word`. If there is no
// such entry, returns a null pointer. The client must not use the
// iterator after the underlying GargantuanTable has been destroyed.
//
// This method is equivalent to:
//    std::unique_ptr&lt;Iterator&gt; iter = table-&gt;NewIterator();
//    iter-&gt;Seek(start_word);
//    return iter;
std::unique_ptr&lt;Iterator&gt; GetIterator(absl::string_view start_word) const;
</pre>
                    </div>
<pre>// テーブル内で`start_word`に等しいか辞書的に次に大きい最初の要素を指す
// イテレータを返します。そのような要素がない場合、nullptrが返ります。
// 対象のGargantuanTableが破壊された後は、この関数から戻ったイテレータを
// 使用してはいけません。
//
// このメソッドは次の呼び出しと等価です:
//    std::unique_ptr&lt;Iterator&gt; iter = table-&gt;NewIterator();
//    iter-&gt;Seek(start_word);
//    return iter;
std::unique_ptr&lt;Iterator&gt; GetIterator(absl::string_view start_word) const;
</pre>
</div>
    
    <p>
        <span>
            <span class="src">
                However, do not be unnecessarily verbose or state the
                completely obvious.
            </span>
            ただし、コメントを不必要に冗長にしたり、完全に明らかなことをわざわざ主張したりはしないでください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                When documenting function overrides, focus on the
                specifics of the override itself, rather than repeating
                the comment from the overridden function.
            </span>
            オーバーライドした関数にドキュメントを書くときは、オーバーライドする前の関数に関するコメントを繰り返すよりも、オーバーライド自体の仕様にフォーカスしたコメントを記述してください。
        </span>
        <span>
            <span class="src">
                In many of these
                cases, the override needs no additional documentation and
                thus no comment is required.
            </span>
            ただし、これらの多くの場合において、オーバーライドされた関数は追加の情報を必要としないため、その場合はコメントは不要です。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                When commenting constructors and destructors, remember
                that the person reading your code knows what constructors
                and destructors are for, so comments that just say
                something like "destroys this object" are not useful.
            </span>
            コンストラクタやデストラクタにコメントを書くときの注意点は、コードの読者は、コンストラクタとは何か、デストラクタとは何か既に知っているということです。単に「オブジェクトを破壊します」のようなコメントは役に立ちません。
        </span>
        <span>
            <span class="src">
                Document what constructors do with their arguments (for
                example, if they take ownership of pointers), and what
                cleanup the destructor does.
            </span>
            コンストラクタのコメントには、コンストラクタがその引数で何をするか(たとえば、ポインタの所有権を引き取るか否か)を記述し、デストラクタのコメントには、デストラクタが何をクリーンアップするかを記述してください。
        </span>
        <span>
            <span class="src">
                If this is trivial, just
                skip the comment.
            </span>
            記述するまでもない、という場合には、コメントは省略してください。
        </span>
        <span>
            <span class="src">
                It is quite common for destructors not
                to have a header comment.
            </span>
            実際、大多数のデストラクタにおいて、ヘッダーでのコメントはありません。
        </span>
    </p>

    <h4 class="stylepoint_subsection"><span title="Function Definitions">関数定義時のコメント</span></h4>

    <p>
        <span>
            <span class="src">
                If there is anything tricky about how a function does
                its job, the function definition should have an
                explanatory comment.
            </span>
            関数がその処理において何かしらトリッキーなことをしている場合、関数を定義するときにそれを説明するコメントが必要です。
        </span>
        <span>
            <span class="src">
                For example, in the definition
                comment you might describe any coding tricks you use,
                give an overview of the steps you go through, or explain
                why you chose to implement the function in the way you
                did rather than using a viable alternative.
            </span>
            このコメントでは、たとえば、使用されているコーディングトリックを説明したり、その関数の処理手順の概要を示したり、あるいは、様々な実現方法の中から、なぜこの実装方法を選んだのかという理由を説明したりすることができます。
        </span>
        <span>
            <span class="src">
                For instance,
                you might mention why it must acquire a lock for the
                first half of the function but why it is not needed for
                the second half.
            </span>
            たとえば、関数の前半ではロックの取得を必要とするが、後半では必要としない理由について言及することもできるでしょう。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Note you should
                <em>not</em> just repeat the comments
                given with the function declaration, in the
                <code>.h</code> file or wherever.
            </span>
            <code>.h</code>等で行った関数宣言のコメントの内容を繰り返すだけのコメントは避けてください。
        </span>
        <span>
            <span class="src">
                It's okay to
                recapitulate briefly what the function does, but the
                focus of the comments should be on how it does it.
            </span>
            関数が何をするのかを軽く繰り返す程度はかまいませんが、どちらかというと、どのようにそれを実現しているかにフォーカスしたコメントを記述するようにしてください。
        </span>
    </p>

    <h3 id="Variable_Comments"><span title="Variable Comments">変数に対するコメント</span></h3>

    <p>
        <span>
            <span class="src">
                In general the actual name of the variable should be
                descriptive enough to give a good idea of what the variable
                is used for.
            </span>
            通常、変数名には、その変数の目的がわかるような、十分記述的な名前をつけるようにします。
        </span>
        <span>
            <span class="src">
                In certain cases, more comments are required.
            </span>
            それでも、さらにコメントが必要とされる場合があります。
        </span>
    </p>

    <h4 class="stylepoint_subsection"><span title="Class Data Members">クラスデータメンバに対するコメント</span></h4>

    <p>
        <span>
            <span class="src">
                The purpose of each class data member (also called an instance
                variable or member variable) must be clear.
            </span>
            各クラスのデータメンバ(インスタンス変数、メンバ変数とも呼ばれる)の目的は明確になっていなければなりません。
        </span>
        <span>
            <span class="src">
                If there are any
                invariants (special values, relationships between members, lifetime
                requirements) not clearly expressed by the type and name, they must be
                commented.
            </span>
            変数の型や変数名だけでは明確に説明できない不変の事柄がある場合(たとえば、特殊な意味を持つ値、メンバ間の関連性、寿命に関する要件など)、それらはコメントとして書かれていなければなりません。
        </span>
        <span>
            <span class="src">
                However, if the type and name suffice (<code>int
                num_events_;</code>), no comment is needed.
            </span>
            一方で、型と名前だけで十分ならば(<code>int num_events_;</code>)は、コメントは不要です。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                In particular, add comments to describe the existence and meaning
                of sentinel values, such as nullptr or -1, when they are not
                obvious.
            </span>
            特に、<code>nullptr</code>や<code>-1</code>のような値に、番兵などの特殊な意味を持たせて使っていて、かつ、それがわかりにくいときは、そのような値の存在や意味について、説明のためのコメントを付け足してください。
        </span>
        <span>
            <span class="src">
                For example:
            </span>
            以下に例を示します。
        </span>
    </p>

    <div>
        <div class="src">
            <pre>private:
 // Used to bounds-check table accesses. -1 means
 // that we don't yet know how many entries the table has.
 int num_total_entries_;
</pre>
        </div>
        <pre>private:
 // テーブルアクセスの境界値チェックに使います。
 // -1 は、まだテーブルにいくつの要素があるかわからないことを意味します。
 int num_total_entries_;
</pre>
    </div>

    <h4 class="stylepoint_subsection"><span title="Global Variables">グローバル変数に対するコメント</span></h4>

    <p>
        <span>
            <span class="src">
                All global variables should have a comment describing what they
                are, what they are used for, and (if unclear) why they need to be
                global.
            </span>
            すべてのグローバル変数は、その変数が何を表していて、何のために使われ、そしてなぜグローバルである必要があるのか(明確でない場合)を説明するコメントが必要です。
        </span>
        <span>
            <span class="src">
                For example:
            </span>
            以下に例を示します。
        </span>
    </p>
    <div>
        <div class="src">

            <pre>// The total number of test cases that we run through in this regression test.
const int kNumTestCases = 6;
</pre>
        </div>
        <pre>// この回帰テストにおけるテストケースの総数
const int kNumTestCases = 6;
</pre>
    </div>

    <h3 id="Implementation_Comments"><span title="Implementation Comments">実装に対するコメント</span></h3>

    <p>
        <span>
            <span class="src">
                In your implementation you should have comments in tricky,
                non-obvious, interesting, or important parts of your code.
            </span>
            実装コードにおいてトリッキーな部分や、明らかでない部分、興味深い部分、重要な部分について、コメントを記述してください。
        </span>
    </p>

    <h4 class="stylepoint_subsection"><span title="Explanatory Comments">解説のコメント</span></h4>

    <p>
        <span>
            <span class="src">
                Tricky or complicated code blocks should have comments
                before them.
            </span>
            トリッキーあるいは複雑なコードブロックの前には、コメントを記述してください。
        </span>
    </p>

    <h4 class="stylepoint_subsection" id="Function_Argument_Comments"><span
            title="Function Argument Comments">関数引数のコメント</span></h4>

    <p>
        <span>
            <span class="src">
                When the meaning of a function argument is nonobvious, consider
                one of the following remedies:
            </span>
            関数の引数の意味がわかりにくい場合、次に述べる対策のいずれかを検討してください。
        </span>
    </p>

    <ul>
        <li>
            <span>
                <span class="src">
                    If the argument is a literal constant, and the same constant is
                    used in multiple function calls in a way that tacitly assumes they're
                    the same, you should use a named constant to make that constraint
                    explicit, and to guarantee that it holds.
                </span>
                引数が定数リテラルであり、かつ、同じ値を複数の関数で使用していて、しかも、それが暗黙的に同じであると仮定されているような場合は、その制限を明示し、かつ、同じ値となることを保証するため、名前つきの定数を使ってください。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Consider changing the function signature to replace a
                    <code>bool</code>
                    argument with an
                    <code>enum</code> argument.
                </span>
                <code>bool</code>の代わりに<code>enum</code>を使ってください。
            </span>
            <span>
                <span class="src">
                    This will make the argument
                    values self-describing.
                </span>
                これによって、引数の値が自分自身を説明するようにできます。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    For functions that have several configuration options, consider
                    defining a single class or struct to hold all the options
                    ,
                    and pass an instance of that.
                </span>
                関数がいくつかの設定オプションを持つような場合、すべてのオプションを保持するような1つのクラスか構造体を定義し、そのインスタンスを関数に渡すようにしてください。
            </span>
            <span>
                <span class="src">

                    This approach has several advantages.
                </span>
                この方法はいくつか利点があります。
            </span>
            <span>
                <span class="src">
                    Options are referenced by name
                    at the call site, which clarifies their meaning.
                </span>
                まず、呼び出し元において、オプションが名前によって参照されるため、意味が明確になります。
            </span>
            <span>
                <span class="src">
                    It also reduces
                    function argument count, which makes function calls easier to read and
                    write.
                </span>
                また、関数の引数の数が減るため、関数呼び出し自体を読みやすく書きやすくなります。
            </span>
            <span>
                <span class="src">
                    As an added benefit, you don't have to change call sites when
                    you add another option.
                </span>
                さらに、将来オプションを追加するときに、呼び出し元のコードを書き換える必要がなくなります。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Replace large or complex nested expressions with named variables.
                </span>
                長くて複雑なネストを含む式は、名前付きの変数によって分割してください。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    As a last resort, use comments to clarify argument meanings at the
                    call site.
                </span>
                最後の手段として、引数の意味を明確にするためのコメントを使用してください。
            </span>
        </li>
    </ul>
    <span>
        <span class="src">
            Consider the following example:
        </span>
        次の例を考えてみましょう。
    </span>
    <div>
        <div class="src">
            <pre class="badcode">// What are these arguments?
const DecimalNumber product = CalculateProduct(values, 7, false, nullptr);
</pre>
        </div>
        <pre class="badcode">// これらの引数の意味は？
const DecimalNumber product = CalculateProduct(values, 7, false, nullptr);
</pre>
    </div>

    <p>
        <span>
            <span class="src">
                versus:
            </span>
            これに対して……
        </span>
    </p>
    <div>
        <div class="src">
            <pre>ProductOptions options;
options.set_precision_decimals(7);
options.set_use_cache(ProductOptions::kDontUseCache);
const DecimalNumber product =
    CalculateProduct(values, options, /*completion_callback=*/nullptr);
</pre>
        </div>
        <pre>ProductOptions options;
options.set_precision_decimals(7);
options.set_use_cache(ProductOptions::kDontUseCache);
const DecimalNumber product =
    CalculateProduct(values, options, /*completion_callback=*/nullptr);
</pre>
    </div>

    <h4 id="Implementation_Comment_Donts"><span title="Don'ts">してはならないこと</span></h4>

    <p>
        <span>
            <span class="src">
                Do not state the obvious.
            </span>
            明らかなことをわざわざ主張してはなりません。
        </span>
        <span>
            <span class="src">
                In particular, don't literally describe what
                code does, unless the behavior is nonobvious to a reader who understands
                C++ well.
            </span>
            特に、通常は、コードがしていることをただ説明してはいけません(C++を十分理解している読者が見て明らかでない場合は除きます)。
        </span>
        <span>
            <span class="src">
                Instead, provide higher level comments that describe
                <i>why</i>
                the code does what it does, or make the code self describing.
            </span>
            そのようなコメントを書くかわりに、それよりも高い次元の、たとえばそのコードが<em>なぜ</em>それをしているのかをコメントとして記述するか、あるいはコード自身でそれを説明するようにしてください。
        </span>
    </p>

    <span>
        <span class="src">
            Compare this:
        </span>
        以下のコードを比べてみましょう。
    </span>
    <div>
        <div class="src">
            <pre class="badcode">// Find the element in the vector.
&lt;-- Bad: obvious!
if (std::find(v.begin(), v.end(), element) != v.end()) {
    Process(element);
}
</pre>
        </div>
        <pre class="badcode">// vectorの中から要素を検索する。  &lt;-- ダメ。そんなことはコードを見れば明らか。
    if (std::find(v.begin(), v.end(), element) != v.end()) {
        Process(element);
}
</pre>
    </div>

    <span>
        <span class="src">
            To this:
        </span>
        と、
    </span>
    <div>
        <div class="src">
            <pre>// Process "element" unless it was already processed.
if (std::find(v.begin(), v.end(), element) != v.end()) {
  Process(element);
}
</pre>
        </div>
        <pre>// まだ処理していない要素があれば処理する。
auto iter = std::find(v.begin(), v.end(), element);
if (iter != v.end()) {
  Process(element);
}
</pre>
    </div>

    <span>
        <span class="src">
            Self-describing code doesn't need a comment.
        </span>
        さらに、コードが説明的になっていると、コメントを必要とすらしません。
    </span>
    <span>
        <span class="src">
            The comment from
            the example above would be obvious:
        </span>
        上の例におけるコメントは、以下のようにすると、より明確です。
    </span>
    <pre>if (!IsAlreadyProcessed(element)) {
  Process(element);
}
</pre>

    <h3 id="Punctuation,_Spelling_and_Grammar"><span title="Punctuation, Spelling and Grammar">句読点と綴りと文法</span></h3>

    <p>
        <span>
            <span class="src">
                Pay attention to punctuation, spelling, and grammar; it is
                easier to read well-written comments than badly written
                ones.
            </span>
            句読点や綴りや文法に注意してください。きちんとしたコメントは、それだけで読みやすいものです。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Comments should be as readable as narrative text, with
                proper capitalization and punctuation.
            </span>
            コメントは、大文字や句読点を適切に用いてふつうの文章として読めるように記述します。
        </span>
        <span>
            <span class="src">
                In many cases,
                complete sentences are more readable than sentence
                fragments.
            </span>
            多くの場合、文の断片だけの場合よりも、完全な文にするほうが読みやすいです。
        </span>
        <span>
            <span class="src">
                Shorter comments, such as comments at the end
                of a line of code, can sometimes be less formal, but you
                should be consistent with your style.
            </span>
            特に行末コメントなどの短いコメントでは形式を崩しがちですが、スタイルには一貫性を持つべきです。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Although it can be frustrating to have a code reviewer
                point out that you are using a comma when you should be
                using a semicolon, it is very important that source code
                maintain a high level of clarity and readability.
            </span>
            コードレビュアーからの「セミコロンを使うべきところでカンマを使っている」といった指摘にはうんざりするかもしれませんが、ソースコードの明瞭性や可読性を高く保つことは、本当に重要なことなのです。
        </span>
        <span>
            <span class="src">
                Proper
                punctuation, spelling, and grammar help with that
                goal.
            </span>
            適切な句読点、正しい綴り、正しい文法は、このゴールに向かうための手助けをしてくれるでしょう。
        </span>
    </p>
    <h3 id="TODO_Comments"><span title="TODO Comments">TODOコメント</span></h3>

    <p>
        <span>
            <span class="src">
                Use
                <code>TODO</code> comments for code that is temporary,
                a short-term solution, or good-enough but not perfect.
            </span>
            <code>TODO</code>コメントは、一時的なもの、暫定対応、あるいは完璧ではないが現状十分である、といったコードに対して使用してください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                <code>TODO</code>s should include the string
                <code>TODO</code> in all caps, followed by the

                name, e-mail address, bug ID, or other
                identifier
                of the person or issue with the best context
                about the problem referenced by the
                <code>TODO</code>.
            </span>
            <code>TODO</code>は、すべて大文字で<code>TODO</code>と書き、続けて、その<code>TODO</code>に関する問題についてもっともよく知る人の名前やメールアドレス、バグ管理番号、その他の識別子であったり、もっとも関連するissueへの参照を含めるようにします。
        </span>
        <span>
            <span class="src">
                The
                main purpose is to have a consistent
                <code>TODO</code> that
                can be searched to find out how to get more details upon
                request.
            </span>
            このルールの主な目的は、<code>TODO</code>に一貫性を持たせ、その件についてより詳しく知るためにはどうしたらよいか、わかるようにすることです。
        </span>
        <span>
            <span class="src">
                A <code>TODO</code> is not a commitment that the
                person referenced will fix the problem.
            </span>
            <code>TODO</code>は「名前の書かれている人がその問題を直します」という約束ではありません。
        </span>
        <span>
            <span class="src">
                Thus when you create
                a <code>TODO</code> with a name, it is almost always your
                name that is given.
            </span>
            したがって、あなたが<code>TODO</code>を作るときは、ほとんど常にあなたの名前で作ることになります。
        </span>
    </p>

    <div>
        <div class="src">
            <pre>// TODO(kl@gmail.com): Use a "*" here for concatenation operator.
// TODO(Zeke) change this to use relations.
// TODO(bug 12345): remove the "Last visitors" feature.
</pre>
            </div>
            <pre>// TODO(kl@gmail.com): 結合のために*演算子を使うほうがいいのだが……
// TODO(Zeke) 関係を使うように直さねば……
// TODO(bug 12345): Last visitors機能は削除せねば……
</pre>
</div>

    <p>
        <span>
            <span class="src">
                If your <code>TODO</code> is of the form "At a future
                date do something" make sure that you either include a
                very specific date ("Fix by November 2005") or a very
                specific event ("Remove this code when all clients can
                handle XML responses.").
            </span>
            もし、<code>TODO</code>が「未来のいつ、なにをする」という形式になる場合は、必ず、具体的な日付(例:「2005年11月までに直す」)や、具体的なイベント(例:「すべてのクライアントがXMLレスポンスを扱えるようになったらこのコードは消す」)を含めるようにしてください。
        </span>
    </p>

    <h2 id="Formatting">
        <span title="Formatting">コードのフォーマット</span>
    </h2>

    <p>
        <span>
            <span class="src">
                Coding style and formatting are pretty arbitrary, but a
                project is much easier to follow
                if everyone uses the same style.
            </span>
            コーディングスタイルとフォーマットは非常に好みによるところが大きいものですが、全員で同じスタイルを使えば、プロジェクトがそれに沿うのは簡単です。
        </span>
        <span>
            <span class="src">
                Individuals may not agree with every
                aspect of the formatting rules, and some of the rules may take
                some getting used to, but it is important that all
                project contributors follow the
                style rules so that
                they can all read and understand
                everyone's code easily.
            </span>
            各個人にとっては、各フォーマットルールの中には、賛同できないものもあれば、馴染み深いものもあるでしょう。
            しかし、重要なことはプロジェクト内のすべてのメンバーが1つのスタイルルールに統一することであり、それによって誰もがコードを読みやすく理解しやすい状態にできるのです。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                To help you format code correctly, we've created a
                <a href="https://raw.githubusercontent.com/google/styleguide/gh-pages/google-c-style.el">
                settings file for emacs</a>.
            </span>
            正しくコードをフォーマットするために、<a href="https://raw.githubusercontent.com/google/styleguide/gh-pages/google-c-style.el">emacsの設定ファイル</a>を用意しています。
        </span>
    </p>

    <h3 id="Line_Length"><span title="Line Length">行の長さ</span></h3>

    <p>
        <span>
            <span class="src">
                Each line of text in your code should be at most 80
                characters long.
            </span>
            コードの各行の長さは、長くとも80文字までにしてください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                We recognize that this rule is
                controversial, but so much existing code already adheres
                to it, and we feel that consistency is important.
            </span>
            このルールには議論の余地があることは認識しています。しかし、既存の多くのコードがこのルールに沿っており、そして、我々は一貫性を重要視しています。
        </span>
    </p>

    <p class="pros"></p>
    <p>
        <span>
            <span class="src">
                Those who favor this rule
                argue that it is rude to force them to resize
                their windows and there is no need for anything longer.
            </span>
            このルールを推す人の主張は、相手にウィンドウサイズを変えさせるのは失礼であり、またコードをそれ以上長くする必要もないというものです。
        </span>
        <span>
            <span class="src">
                Some folks are used to having several code windows
                side-by-side, and thus don't have room to widen their
                windows in any case.
            </span>
            複数のコードウィンドウを横に並べて使っていて、これ以上ウィンドウの幅を広げるスペースはないという人もいます。
        </span>
        <span>
            <span class="src">
                People set up their work environment
                assuming a particular maximum window width, and 80
                columns has been the traditional standard.
            </span>
            多くの人が、最大ウィンドウサイズを仮定した仕事環境を準備しており、それらは伝統的に80文字が標準とされてきました。
        </span>
        <span>
            <span class="src">
                Why change
                it?
            </span>
            変える理由がありますか？
        </span>
    </p>
    <p class="cons"></p>
    <p>
        <span>
            <span class="src">
                Proponents of change argue that a wider line can make
                code more readable.
            </span>
            このルールを変えたがっている人の主張は、もっと長い行を使える方がコードが読みやすくなるはずだというものです。
        </span>
        <span>
            <span class="src">
                The 80-column limit is an hidebound
                throwback to 1960s mainframes; modern equipment has wide screens that
                can easily show longer lines.
            </span>
            80文字という制限は1960年代のメインフレームを思い起こさせますが、現代の機器は、長い行も簡単に表示できる広いスクリーンを備えています。
        </span>
    </p>
    <p class="decision"></p>
    <p>
        <span>
            <span class="src">
                80 characters is the maximum.
            </span>
            最大80文字とします。
        </span>
    </p>

    <p class="exception"></p>
    <p>
        <span>
            <span class="src">
                A line may exceed 80 characters if it is
            </span>
            次の場合、80文字を超えても構いません。
        </span>
    </p>
    <ul>
        <li>
            <span>
                <span class="src">
                    a comment line which is not feasible to split without harming
                    readability, ease of cut and paste or auto-linking -- e.g., if a line
                    contains an example command or a literal URL longer than 80 characters.
                </span>
                コメントのための行について、行を分割することによって、可読性やコピーペーストの利便性、リンクがクリックできなくなるなどの利便性を妨げる場合。
                たとえば、80文字よりも長いコマンド例やURLなどが当てはまります。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    a string literal that cannot easily be wrapped at 80 columns.
                </span>
                80文字で簡単に折り返すことができない文字列リテラル。
            </span>
            <span>
                <span class="src">
                    This may be because it contains URIs or other semantically-critical pieces,
                    or because the literal contains an embedded language, or a multiline
                    literal whose newlines are significant like help messages.
                </span>
                これには、URIやその他の意味的に重要な部分が含まれていたり、リテラルが組み込みの言語を含んでいたり、ヘルプメッセージのような改行が重要な役割を占める複数行のリテラルなどが含まれます。
            </span>
            <span>
                <span class="src">
                    In these cases, breaking up the literal would
                    reduce readability, searchability, ability to click links, etc.
                </span>
                このような場合、リテラルを分割すると、可読性、検索性、リンクのクリックしやすさなどが低下します。
            </span>
            <span>
                <span class="src">
                    Except for
                    test code, such literals should appear at namespace scope near the top of a
                    file.
                </span>
                テストコードを除いて、このようなリテラルはファイルの先頭付近の名前空間スコープにおかれるべきです。
            </span>
            <span>
                <span class="src">
                    If a tool like Clang-Format doesn't recognize the unsplittable content,
                    <a href="https://clang.llvm.org/docs/ClangFormatStyleOptions.html#disabling-formatting-on-a-piece-of-code">
                        disable the tool</a> around the content as necessary.
                </span>
                Clang-Formatのようなツールが分割不可のコンテンツを認識しない場合、必要に応じてコンテンツ周辺で<a href="https://clang.llvm.org/docs/ClangFormatStyleOptions.html#disabling-formatting-on-a-piece-of-code">ツールを無効</a>にしてください。
            </span>

            <br><br>
            <span>
                <span class="src">
                    (We must balance between usability/searchability of such literals and the
                    readability of the code around them.)
                </span>
                (このようなリテラルの使い勝手や検索性と、その周辺のコードの読みやすさとの間でバランスを取らなければなりません。)
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    an include statement.
                </span>
                <code>#include</code>文。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    a <a href="#The__define_Guard">header guard</a>
                </span>
                <a href="#The__define_Guard">ヘッダーガード</a>。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    a using-declaration
                </span>
                using宣言。
            </span>
        </li>
    </ul>

    <h3 id="Non-ASCII_Characters"><span title="Non-ASCII Characters">非アスキー文字</span></h3>

    <p>
        <span>
            <span class="src">
                Non-ASCII characters should be rare, and must use UTF-8
                formatting.
            </span>
            非アスキー文字は滅多に使いません。もし使う場合は必ずUTF-8フォーマットでなければなりません。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                You shouldn't hard-code user-facing text in source,
                even English, so use of non-ASCII characters should be
                rare.
            </span>
            まず前提として、ユーザーが目にする文字列をソースにハードコーディングしてはいけません。たとえ英語であってもです。このため、非アスキー文字がコード中に出てくることは滅多にありません。
        </span>
        <span>
            <span class="src">
                However, in certain cases it is appropriate to
                include such words in your code.
            </span>
            しかし、場合によっては、このような単語をコードに含めることが適切であることもあります。
        </span>
        <span>
            <span class="src">
                For example, if your
                code parses data files from foreign sources, it may be
                appropriate to hard-code the non-ASCII string(s) used in
                those data files as delimiters.
            </span>
            たとえば、あなたのコードが海外のデータファイルを解析するのであれば、非アスキーの文字列をデータの区切り文字としてソースに埋め込むのが適切かもしれません。
        </span>
        <span>
            <span class="src">
                More commonly, unittest
                code (which does not need to be localized) might
                contain non-ASCII strings.
            </span>
            より一般的な例として、(ローカライズの必要がない)ユニットテストのためのコードは非アスキー文字を含んでいることがあります。
        </span>
        <span>
            <span class="src">
                In such cases, you should use
                UTF-8, since that is an encoding
                understood by most tools able to handle more than just
                ASCII.
            </span>
            こういった場合には、UTF-8を使います。UTF-8は、ASCII以外に対応するほとんどのツールによって解釈できるエンコーディングです。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Hex encoding is also OK, and encouraged where it
                enhances readability &#8212; for example,
                <code>"\xEF\xBB\xBF"</code>, or, even more simply,
                <code>u8"\uFEFF"</code>, is the Unicode zero-width
                no-break space character, which would be invisible if
                included in the source as straight UTF-8.
            </span>
            16進数によるエンコーディングを使うこともできます。特に、そうすることで可読性が高まる場合はそちらのほうが推奨されます。たとえば、<code>"\xEF\xBB\xBF"</code>、あるいは単に<code>u8"\uFEFF"</code>は、Unicodeにおいて、ゼロ幅で非改行の空白文字を表します。もし、これが、ふつうのUTF-8文字としてソースコードに含められていたら、それを目で見ることはできないでしょう。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Use the
                <code>u8</code> prefix
                to guarantee that a string literal containing
                <code>\uXXXX</code> escape sequences is encoded as UTF-8.
            </span>
            <code>\uXXXX</code>エスケープシーケンスを含む文字列リテラルがUTF-8にエンコードされることを保証するため、<code>u8</code>接頭辞を使用してください。
        </span>
        <span>
            <span class="src">
                Do not use it for strings containing non-ASCII characters
                encoded as UTF-8, because that will produce incorrect
                output if the compiler does not interpret the source file
                as UTF-8.
            </span>
            ただし、ふつうのUTF-8エンコードによる非アスキー文字を含む文字列には、これを使用しないでください。コンパイラがソースファイルをUTF-8として解釈しなかった場合に、不正な出力を生成してしまいます。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                You shouldn't use the C++11
                <code>char16_t</code> and
                <code>char32_t</code> character types, since they're for
                non-UTF-8 text.
            </span>
            C++11の文字型<code>char16_t</code>と<code>char32_t</code>は、UTF-8以外のエンコードのためのものであるため、使用しないでください。
        </span>
        <span>
            <span class="src">
                For similar reasons you also shouldn't
                use
                <code>wchar_t</code> (unless you're writing code that
                interacts with the Windows API, which uses
                <code>wchar_t</code> extensively).
            </span>
            また、同様の理由で、<code>wchar_t</code>も使用しないでください(ただし、<code>wchar_t</code>を使用するWindows APIとやりとりするコードを書いている場合は除きます)。
        </span>
    </p>
    <h3 id="Spaces_vs._Tabs"><span title="Spaces vs. Tabs">スペースか、タブか</span></h3>

    <p>
        <span>
            <span class="src">
                Use only spaces, and indent 2 spaces at a time.
            </span>
            スペースのみを使用してください。インデント1つにつき、スペースは2つです。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                We use spaces for indentation.
            </span>
            インデントにはスペースを使います。
        </span>
        <span>
            <span class="src">
                Do not use tabs in your
                code.
            </span>
            コードにタブを使わないでください。
        </span>
        <span>
            <span class="src">
                You should set your editor to emit spaces when you
                hit the tab key.
            </span>
            タブキーを押したときにスペースが入力されるようにエディタを設定してください。
        </span>
    </p>
    <h3 id="Function_Declarations_and_Definitions"><span title="Function Declarations and Definitions">関数宣言と関数定義</span>
    </h3>

    <p>
        <span>
            <span class="src">
                Return type on the same line as function name, parameters
                on the same line if they fit.
            </span>
            関数の戻り値の型は関数名と同じ行に記述します。
            関数の引数は1行に収まるのであれば同じ行に記述します。
        </span>
        <span>
            <span class="src">
                Wrap parameter lists which do
                not fit on a single line as you would wrap arguments in a
                <a href="#Function_Calls">function call</a>.
            </span>
            引数リストが1行に収まらない場合は、<a href="#Function_Calls">関数呼び出し</a>と同様のやり方で、行を分割してください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Functions look like this:
            </span>
            関数は以下のようにします。
        </span>
    </p>

    <pre>ReturnType ClassName::FunctionName(Type par_name1, Type par_name2) {
  DoSomething();
  ...
}
</pre>

    <p>
        <span>
            <span class="src">
                If you have too much text to fit on one line:
            </span>
            1行が収まらないときは、以下のようにします。
        </span>
    </p>

    <pre>ReturnType ClassName::ReallyLongFunctionName(Type par_name1, Type par_name2,
                                             Type par_name3) {
  DoSomething();
  ...
}
</pre>

    <p>
        <span>
            <span class="src">
                or if you cannot fit even the first parameter:
            </span>
            最初の引数からして1行に収まらないときは、以下のようにします。
        </span>
    </p>
    <div>
        <div class="src">
            <pre>ReturnType LongClassName::ReallyReallyReallyLongFunctionName(
    Type par_name1,  // 4 space indent
    Type par_name2,
    Type par_name3) {
  DoSomething();  // 2 space indent
  ...
}
</pre>
        </div>
        <pre>ReturnType LongClassName::ReallyReallyReallyLongFunctionName(
    Type par_name1,  // インデントはスペース 4個
    Type par_name2,
    Type par_name3) {
  DoSomething();  // インデントはスペース 2個
  ...
}
</pre>
    </div>

    <p>
        <span>
            <span class="src">
                Some points to note:
            </span>
            注意すべき点がいくつかあります。
        </span>
    </p>

    <ul>
        <li>
            <span>
                <span class="src">
                    Choose good parameter names.
                </span>
                引数の名前をよく考えて決めてください。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    A parameter name may be omitted only if the parameter is not used in the
                    function's definition.
                </span>
                関数の定義において引数が使われない場合に限り、その引数の名前を省略してもかまいません。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    If you cannot fit the return type and the function
                    name on a single line, break between them.
                </span>
                戻り値の型と関数名とが同じ行に収まらない場合は、その間で行を分割してください。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    If you break after the return type of a function
                    declaration or definition, do not indent.
                </span>
                戻り値の型の後で改行する場合であっても、インデントはしないでください。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    The open parenthesis is always on the same line as
                    the function name.
                </span>
                開き丸括弧は常に関数名と同じ行に書きます。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    There is never a space between the function name
                    and the open parenthesis.
                </span>
                関数名と開き丸括弧の間にはスペースを入れてはいけません。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    There is never a space between the parentheses and
                    the parameters.
                </span>
                開き丸括弧と引数の間にはスペースを入れてはいけません。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    The open curly brace is always on the end of the last line of the function
                    declaration, not the start of the next line.
                </span>
                開き波括弧は常に関数宣言の最後の行に書きます。次の行の頭ではありません。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    The close curly brace is either on the last line by
                    itself or on the same line as the open curly brace.
                </span>
                閉じ波括弧は、それ自身で最後の行とするか、開き波括弧と同じ行に書くかのいずれかです。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    There should be a space between the close
                    parenthesis and the open curly brace.
                </span>
                閉じ丸括弧と開き波括弧の間にはスペースを1つ入れます。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    All parameters should be aligned if possible.
                </span>
                可能な限り、すべての引数を整列させます。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Default indentation is 2 spaces.
                </span>
                デフォルトのインデントはスペース2つです。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Wrapped parameters have a 4 space indent.
                </span>
                引数リストにおいて行を分割した場合は、インデントはスペース4つです。
            </span>
        </li>
    </ul>

    <p>
        <span>
            <span class="src">
                Unused parameters that are obvious from context may be omitted:
            </span>
            以下の例のように、引数が使われない、かつ、その意味が文脈から明らかな場合は、引数を省略できます。
        </span>
    </p>

    <pre>class Foo {
 public:
  Foo(const Foo&amp;) = delete;
  Foo&amp; operator=(const Foo&amp;) = delete;
};
</pre>

    <p>
        <span>
            <span class="src">
                Unused parameters that might not be obvious should comment out the variable
                name in the function definition:
            </span>
            使われない引数でも、意味が明らかでない場合は、関数定義の引数名をコメントアウトして残します。
        </span>
    </p>

    <pre>class Shape {
 public:
  virtual void Rotate(double radians) = 0;
};

class Circle : public Shape {
 public:
  void Rotate(double radians) override;
};

void Circle::Rotate(double /*radians*/) {}
</pre>

    <div>
        <div class="src">
            <pre class="badcode">// Bad - if someone wants to implement later, it's not clear what the
// variable means.
void Circle::Rotate(double) {}
</pre>
        </div>
        <pre class="badcode">// ダメ。後で誰かが実装しようとしても、引数の名前が何であったのかわからない。
void Circle::Rotate(double) {}
</pre>
    </div>

    <p>
        <span>
            <span class="src">
                Attributes, and macros that expand to attributes, appear at the very
                beginning of the function declaration or definition, before the
                return type:
            </span>
            属性や、属性に展開されるマクロは、関数宣言や関数定義の一番最初(戻り値の型の前)に書きます。
        </span>
    </p>
    <pre>  ABSL_ATTRIBUTE_NOINLINE void ExpensiveFunction();
  [[nodiscard]] bool IsOk();
</pre>

    <h3 id="Formatting_Lambda_Expressions"><span title="Lambda Expressions">ラムダ式</span></h3>

    <p>
        <span>
            <span class="src">
                Format parameters and bodies as for any other function, and capture
                lists like other comma-separated lists.
            </span>
            引数リストと関数の定義のフォーマットは他の関数と同様とします。キャプチャリストのフォーマットは他のカンマ区切りリストと同様とします。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                For by-reference captures, do not leave a space between the
                ampersand (&amp;) and the variable name.
            </span>
            参照キャプチャのアンパサンド(&amp;)と変数名との間には、スペースを入れません。
        </span>
    </p>
    <pre>int x = 0;
auto x_plus_n = [&amp;x](int n) -&gt; int { return x + n; }
</pre>
    <p>
        <span>
            <span class="src">
                Short lambdas may be written inline as function arguments.
            </span>
            短いラムダ式は、関数の引数としてインラインで書いてもかまいません。
        </span>
    </p>
    <pre>std::set&lt;int&gt; to_remove = {7, 8, 9};
std::vector&lt;int&gt; digits = {3, 9, 1, 8, 4, 7, 1};
digits.erase(std::remove_if(digits.begin(), digits.end(), [&amp;to_remove](int i) {
               return to_remove.find(i) != to_remove.end();
             }),
             digits.end());
</pre>

    <h3 id="Floating_Literals"><span title="Floating-point Literals">浮動小数点リテラル</span></h3>

    <p>
        <span>
            <span class="src">
                Floating-point literals should always have a radix point, with digits on both
                sides, even if they use exponential notation.
            </span>
            浮動小数点リテラルには、指数表記を使用する場合であっても、常に小数点を書き、小数点の両側に数字を置きます。
        </span>
        <span>
            <span class="src">
                Readability is improved if all
                floating-point literals take this familiar form, as this helps ensure that they
                are not mistaken for integer literals, and that the
                <code>E</code>/<code>e</code> of the exponential notation is not mistaken for a
                hexadecimal digit.
            </span>
            すべての浮動小数点リテラルがこの使い慣れた形式を取ることで、浮動小数点リテラルが整数リテラルと間違われたり、指数表記の<code>E</code>や<code>e</code>が 16 進数と間違われたりすることがなくなり、可読性が向上します。
        </span>
        <span>
            <span class="src">
            </span>
        </span>
        <span>
            <span class="src">
                It is fine to initialize a floating-point variable with an
                integer literal (assuming the variable type can exactly represent that integer),
                but note that a number in exponential notation is never an integer literal.
            </span>
            浮動小数点変数を整数リテラルで初期化することは問題ありません(変数の型がその整数を正確に表すことができる場合)が、指数表記の数値は決して整数リテラルではないことに注意してください。
        </span>
    </p>

    <pre class="badcode">float f = 1.f;
long double ld = -.5L;
double d = 1248e6;
</pre>

    <pre class="goodcode">float f = 1.0f;
float f2 = 1;   // Also OK
long double ld = -0.5L;
double d = 1248.0e6;
</pre>

    <h3 id="Function_Calls"><span title="Function Calls">関数呼び出し</span></h3>

    <p>
        <span>
            <span class="src">
                Either write the call all on a single line, wrap the
                arguments at the parenthesis, or start the arguments on a new
                line indented by four spaces and continue at that 4 space
                indent.
            </span>
            関数呼び出しは1行で書くか、引数を丸括弧のところに揃えるように改行するか、スペース4つでインデントした新しい行に引数リストを書くかのいずれかとします。
        </span>
        <span>
            <span class="src">
                In the absence of other considerations, use the
                minimum number of lines, including placing multiple arguments
                on each line where appropriate.
            </span>
            他に考慮すべきことがない場合は、1行に複数の引数を含めて、可能な限り少ない行数で記述してください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Function calls have the following format:
            </span>
            関数呼び出しは以下のォーマットに従ってください。
        </span>
    </p>
    <pre>bool result = DoSomething(argument1, argument2, argument3);
</pre>

    <p>
        <span>
            <span class="src">
                If the arguments do not all fit on one line, they
                should be broken up onto multiple lines, with each
                subsequent line aligned with the first argument.
            </span>
            もし、引数が1行に収まらない場合、それらを複数の行に分割してください。その際、後続の行は最初の引数に揃えてください。
        </span>
        <span>
            <span class="src">
                Do not
                add spaces after the open paren or before the close
                paren:
            </span>
            開き丸括弧の後や、閉じ丸括弧の前にスペースを入れてはいけません。
        </span>
    </p>
    <pre>bool result = DoSomething(averyveryveryverylongargument1,
                          argument2, argument3);
</pre>

    <p>
        <span>
            <span class="src">
                Arguments may optionally all be placed on subsequent
                lines with a four space indent:
            </span>
            引数は、スペース4つでインデントされた後続行に記述することもできます。
        </span>
    </p>
    <div>
        <div class="src">
            <pre>if (...) {
  ...
  ...
  if (...) {
    bool result = DoSomething(
        argument1, argument2,  // 4 space indent
        argument3, argument4);
    ...
  }
</pre>
        </div>
        <pre>if (...) {
  ...
  ...
  if (...) {
    bool result = DoSomething(
        argument1, argument2,  // スペース4つでインデント
        argument3, argument4);
    ...
  }
</pre>
    </div>

    <p>
        <span>
            <span class="src">
                Put multiple arguments on a single line to reduce the
                number of lines necessary for calling a function unless
                there is a specific readability problem.
            </span>
            関数呼び出しに必要な行数を減らすため、可読性に関する特別な事情がない限り、1行に複数の引数を配置してください。
        </span>

        <span>
            <span class="src">
                Some find that
                formatting with strictly one argument on each line is
                more readable and simplifies editing of the arguments.
            </span>
            人によっては、各行に1つずつ引数をおくフォーマットのほうが読みやすく、より編集しやすくなると考えるかもしれません。
        </span>

        <span>
            <span class="src">
                However, we prioritize for the reader over the ease of
                editing arguments, and most readability problems are
                better addressed with the following techniques.
            </span>
            しかし、我々は、編集のしやすさよりも読者のことを優先しており、可読性に関する問題は次のような方法で改善することができます。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                If having multiple arguments in a single line decreases
                readability due to the complexity or confusing nature of the
                expressions that make up some arguments, try creating
                variables that capture those arguments in a descriptive name:
            </span>
            複雑な式で引数が構成され、1行に複数の引数をおくと可読性が低下してしまうという場合には、一時変数を作り、それらの引数に記述的な名前を与えてください。
        </span>
    </p>
    <pre>int my_heuristic = scores[x] * y + bases[x];
bool result = DoSomething(my_heuristic, x, y, z);
</pre>

    <p>
        <span>
            <span class="src">
                Or put the confusing argument on its own line with
                an explanatory comment:
            </span>
            あるいは、意味のわかりにくい引数を、説明的なコメントともに、個別の行に配置してください。
        </span>
    </p>
    <div>
        <div class="src">
            <pre>bool result = DoSomething(scores[x] * y + bases[x],  // Score heuristic.
                          x, y, z);
</pre>
        </div>
        <pre>bool result = DoSomething(scores[x] * y + bases[x],  // ヒューリスティックなスコア
                          x, y, z);
</pre>
    </div>

    <p>
        <span>
            <span class="src">
                If there is still a case where one argument is
                significantly more readable on its own line, then put it on
                its own line.
            </span>
            それでもまだ、1つの引数を固有の行に書く方がはるかに読みやすいという場合には、そのようにしてください。
        </span>
        <span>
            <span class="src">
                The decision should be specific to the argument
                which is made more readable rather than a general policy.
            </span>
            全体的なポリシーよりも、引数がより読みやすくなる方法を選びましょう。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Sometimes arguments form a structure that is important
                for readability.
            </span>
            ときには、引数が可読性の面で重要な構造を持つことがあります。
        </span>
        <span>
            <span class="src">
                In those cases, feel free to format the
                arguments according to that structure:
            </span>
            このような場合は、それらの引数をその構造に沿って自由に配置するようにしてください。
        </span>
    </p>
    <div>
        <div class="src">
            <pre>// Transform the widget by a 3x3 matrix.
my_widget.Transform(x1, x2, x3,
                    y1, y2, y3,
                    z1, z2, z3);
</pre>
        </div>
        <pre>// ウィジェットを3x3行列で変形する
my_widget.Transform(x1, x2, x3,
                    y1, y2, y3,
                    z1, z2, z3);
</pre>
    </div>


    <h3 id="Braced_Initializer_List_Format"><span title="Braced Initializer List Format">波括弧による初期化子リスト</span></h3>

    <p>
        <span>
            <span class="src">
                Format a braced initializer list exactly like you would format a function
                call in its place.
            </span>
            波括弧による初期化子リストは、関数呼び出しと同じようにフォーマットします。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                If the braced list follows a name (e.g., a type or
                variable name), format as if the
                <code>{}</code> were the
                parentheses of a function call with that name.
            </span>
            波括弧のリストが型名や変数名のすぐ後に続く場合は、<code>{}</code>を関数呼び出しにおける丸括弧と同等と見なして扱います。
        </span>
        <span>
            <span class="src">
                If there
                is no name, assume a zero-length name.
            </span>
            名前がない場合は、0文字の名前があると見なしてフォーマットします。
        </span>
    </p>
    <div>
        <div class="src">
            <pre>// Examples of braced init list on a single line.
return {foo, bar};
functioncall({foo, bar});
std::pair&lt;int, int&gt; p{foo, bar};

// When you have to wrap.
SomeFunction(
    {"assume a zero-length name before {"},
    some_other_function_parameter);
SomeType variable{
    some, other, values,
    {"assume a zero-length name before {"},
    SomeOtherType{
        "Very long string requiring the surrounding breaks.",
        some, other, values},
    SomeOtherType{"Slightly shorter string",
                  some, other, values}};
SomeType variable{
    "This is too long to fit all in one line"};
MyType m = {  // Here, you could also break before {.
    superlongvariablename1,
    superlongvariablename2,
    {short, interior, list},
    {interiorwrappinglist,
     interiorwrappinglist2}};
</pre>
        </div>
        <pre>// 波括弧初期化子リストを1行に配置する場合の例
return {foo, bar};
functioncall({foo, bar});
std::pair&lt;int, int&gt; p{foo, bar};

// 複数行にする場合
SomeFunction(
    {"assume a zero-length name before {"},
    some_other_function_parameter);
SomeType variable{
    some, other, values,
    {"assume a zero-length name before {"},
    SomeOtherType{
        "Very long string requiring the surrounding breaks.",
        some, other, values},
    SomeOtherType{"Slightly shorter string",
                  some, other, values}};
SomeType variable{
    "This is too long to fit all in one line"};
MyType m = {  // {の前で改行してもかまいません
    superlongvariablename1,
    superlongvariablename2,
    {short, interior, list},
    {interiorwrappinglist,
     interiorwrappinglist2}};
</pre>
    </div>


    <h3 id="Conditionals"><span title="Conditionals">条件文</span></h3>

    <p>
        <span>
            <span class="src">
                In an <code>if</code> statement, including its optional <code>else if</code>
                and <code>else</code> clauses, put one space between the <code>if</code> and the
                opening parenthesis, and between the closing parenthesis and the curly brace (if
                any), but no spaces between the parentheses and the condition or initializer.
            </span>
            <code>if</code>ステートメント及び<code>else if</code>句や<code>else</code>句では、<code>if</code>と開き丸括弧の間、および閉じ丸括弧と開き波括弧 (存在する場合) の間にスペースを1つ入れます。
            しかし、丸括弧と条件または初期化子の間にはスペースを入れません。
        </span>
        <span>
            <span class="src">
                If
                the optional initializer is present, put a space or newline after the semicolon,
                but not before.
            </span>
            オプションの初期化子が存在する場合、スペースまたは改行をセミコロンの後に1つ入れます。しかし、セミコロンの前には入れません。
        </span>
    </p>

    <div>
        <div class="src">
            <pre class="badcode">if(condition) {              // Bad - space missing after IF
if ( condition ) {           // Bad - space between the parentheses and the condition
if (condition){              // Bad - space missing before {
if(condition){               // Doubly bad

if (int a = f();a == 10) {   // Bad - space missing after the semicolon
            </pre>
        </div>
        <pre class="badcode">if(condition) {              // ダメ。ifの後にスペースがない。
if ( condition ) {           // ダメ。括弧と条件の間にスペースがある。
if (condition){              // ダメ。{の前にスペースがない。
if(condition){               // ダメダメ。

if (int a = f();a == 10) {   // ダメ。セミコロンの後にスペースがない。</pre>
    </div>

    <p>
        <span>
            <span class="src">
                Use curly braces for the controlled statements following
                <code>if</code>, <code>else if</code> and <code>else</code>.
            </span>
            <code>if</code>、<code>else if</code>、<code>else</code>に続く本文には波括弧を使用します。
        </span>
        <span>
            <span class="src">
                Break the line
                immediately after the opening brace, and immediately before the closing brace.
            </span>
            開き波括弧の直後と閉じ波括弧の直前で改行します。
        </span>
        <span>
            <span class="src">
                A
                subsequent <code>else</code>, if any, appears on the same line as the preceding
                closing brace, separated by a space.
            </span>
            後続の<code>else</code>がある場合は、前の閉じ波括弧と同じ行にスペースで区切って表示されます。
        </span>
    </p>

    <div>
        <div class="src">
            <pre>
if (condition) {                   // no spaces inside parentheses, space before brace
    DoOneThing();                   // two space indent
    DoAnotherThing();
} else if (int a = f(); a != 3) {  // closing brace on new line, else on same line
    DoAThirdThing(a);
} else {
    DoNothing();
}</pre>
        </div>
        <pre>
if (condition) {                   // 丸括弧の中にスペースなし、波括弧の前にスペース1つ
    DoOneThing();                   // スペース2つでインデント
    DoAnotherThing();
} else if (int a = f(); a != 3) {  // 閉じ波括弧は新しい行に。elseは同じ行に。
    DoAThirdThing(a);
} else {
    DoNothing();
}</pre>
    </div>
    <p>
        <span>
            <span class="src">
                For historical reasons, we allow one exception to the above rules: if an
                <code>if</code> statement has no <code>else</code> or <code>else if</code>
                clauses, then the curly braces for the controlled statement or the line breaks
                inside the curly braces may be omitted if as a result the entire <code>if</code>
                statement appears on either a single line (in which case there is a space
                between the closing parenthesis and the controlled statement) or on two lines
                (in which case there is a line break after the closing parenthesis and there are
                no braces).
            </span>
            歴史的な理由から、上記のルールには 1 つの例外を認めています。
            <code>if</code>ステートメントに<code>else</code>または<code>else if</code>句がなく、<code>if</code>ステートメント全体が1 行 (閉じ括弧と被制御ステートメントの間にスペースがある場合)または 2 行 (閉じ括弧の後に改行があり、波括弧がない場合) の形になる場合、続く文の波括弧または波括弧内の改行は省略できます。
        </span>
        <span>
            <span class="src">
                For example, the following forms are allowed under this
                exception.
            </span>
            たとえば、次の形はこの例外の下で許可されます。
        </span>
    </p>

    <pre>if (x == kFoo) return new Foo();

if (x == kBar)
  return new Bar(arg1, arg2, arg3);

if (x == kQuz) { return new Quz(1, 2, 3); }
</pre>

    <p>
        <span>
            <span class="src">
                Use this style only when the statement is brief, and consider that
                conditional statements with complex conditions or controlled statements may be
                more readable with curly braces.
            </span>
            このスタイルは、文が短い場合にのみ使用してください。
            複雑な条件を含む条件付きステートメントや文は、波括弧を使用することで読みやすくなる可能性があることを考慮してください。
        </span>
        <span>
            <span class="src">
                Some
                projects
                require curly braces always.
            </span>
            一部のプロジェクトでは常に波括弧が必要であると定めています。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Finally, these are not permitted:
            </span>
            最後に、次のようにしてはいけません。
        </span>
    </p>
    <div>
        <div class="src">
            <pre class="badcode">// Bad - IF statement with ELSE is missing braces
if (x) DoThis();
else DoThat();

// Bad - IF statement with ELSE does not have braces everywhere
if (condition)
    foo;
else {
    bar;
}

// Bad - IF statement is too long to omit braces
if (condition)
    // Comment
    DoSomething();

// Bad - IF statement is too long to omit braces
if (condition1 &amp;&amp;
    condition2)
    DoSomething();</pre>
        </div>
        <pre class="badcode">// ダメ - elseのあるif文で波括弧がない
if (x) DoThis();
else DoThat();

// ダメ - elseのあるif文で波括弧がない
if (condition)
    foo;
else {
    bar;
}

// ダメ -  if文で波括弧を省略するには長すぎる
if (condition)
    // Comment
    DoSomething();

// ダメ - if文で波括弧を省略するには長すぎる
if (condition1 &amp;&amp;
    condition2)
    DoSomething();</pre>
    </div>
    

    <h3 id="Loops_and_Switch_Statements"><span title="Loops and Switch Statements">ループとswitch文</span></h3>

    <p>
        <span>
            <span class="src">
                Switch statements may use braces for blocks.
            </span>
            switch文でブロックを作るために波括弧を使用できます。
        </span>
        <span>
            <span class="src">
                Annotate
                non-trivial fall-through between cases.
            </span>
            case間をフォールスルーする時には、自明な場合を除いて、注釈をつけてください。
        </span>
        <span>
            <span class="src">
                Braces are optional for single-statement loops.
            </span>
            ループの本体が1つの文からなる場合、波括弧はつけてもつけなくてもかまいません。
        </span>
        <span>
            <span class="src">
                Empty loop bodies should use either empty braces or <code>continue</code>.
            </span>
            空のループには、波括弧による空のブロックか、<code>continue</code>文を使用してください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                <code>case</code> blocks in <code>switch</code>
                statements can have curly braces or not, depending on
                your preference.
            </span>
            <code>switch</code>中の<code>case</code>ブロックでは、波括弧を使っても使わなくてもかまいません。
        </span>
        <span>
            <span class="src">
                If you do include curly braces they
                should be placed as shown below.
            </span>
            波括弧を使う場合は、下記の例のように配置します。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                If not conditional on an enumerated value, switch
                statements should always have a
                <code>default</code> case
                (in the case of an enumerated value, the compiler will
                warn you if any values are not handled).
            </span>
            switch文の条件値が列挙型でない場合は、必ず<code>default</code>ブロックが必要です(列挙型の値によるswitch文は、caseが漏れてもコンパイラが警告してくれるでしょう)。
        </span>
        <span>
            <span class="src">
                If the default
                case should never execute, treat this as an error.
                For example:
            </span>
            defaultブロックが絶対に実行されない場合、次の例のように、エラーとして扱ってください。
        </span>
    </p>

    <div>
        <div class="src">
            <pre>switch (var) {
  case 0: {  // 2 space indent
    ...      // 4 space indent
    break;
  }
  case 1: {
    ...
    break;
  }
  default: {
    assert(false);
  }
}
</pre>
        </div>
        <pre>switch (var) {
  case 0: {  // スペース2つでインデント
    ...      // スペース4つでインデント
    break;
  }
  case 1: {
    ...
    break;
  }
  default: {
    assert(false);
  }
}
</pre>
    </div>

    <p>
        <span>
            <span class="src">
                Fall-through from one case label to
                another must be annotated using the
                <code>[[fallthrough]];</code> attribute.
            </span>
            あるケースラベルから別のラベルへのフォールスルーは、<code>[[fallthrough]];</code>属性での注釈が必要です。
        </span>
        <span>
            <span class="src">
                <code>[[fallthrough]];</code> should be placed at a
                point of execution where a fall-through to the next case
                label occurs.
            </span>
            <code>[[fallthrough]];</code>は次のケースラベルへのフォールスルーが起きる実行箇所に置くべきです。
        </span>
        <span>
            <span class="src">
                A common exception is consecutive case
                labels without intervening code, in which case no
                annotation is needed.
            </span>
            よくある例外は間にコードを持たない連続したラベルで、このときは注釈不要です。
        </span>
    </p>

    <pre>switch (x) {
    case 41:  // No annotation needed here.
    case 43:
    if (dont_be_picky) {
        // Use this instead of or along with annotations in comments.
        [[fallthrough]];
    } else {
        CloseButNoCigar();
        break;
    }
    case 42:
    DoSomethingSpecial();
    [[fallthrough]];
    default:
    DoSomethingGeneric();
    break;
} </pre>

    <p>
        <span>
            <span class="src">
                Braces are optional for single-statement loops.
            </span>
            ひとつの文からなるループにおいて、波括弧はつけてもつけなくてもかまいません。
        </span>
    </p>

    <pre>for (int i = 0; i &lt; kSomeNumber; ++i)
  printf("I love you\n");

for (int i = 0; i &lt; kSomeNumber; ++i) {
  printf("I take it back\n");
}
</pre>

    <p>
        <span>
            <span class="src">
                Empty loop bodies should use either an empty pair of braces or
                <code>continue</code> with no braces, rather than a single semicolon.
            </span>
            ループ本体が空になる場合は、波括弧による空のブロックとするか、波括弧なしの<code>continue</code>を使います。セミコロンだけを書いてはいけません。
        </span>
    </p>
    <div>
        <div class="src">
            <pre>while (condition) {
  // Repeat test until it returns false.
}
for (int i = 0; i &lt; kSomeNumber; ++i) {}  // Good - one newline is also OK.
while (condition) continue;  // Good - continue indicates no logic.
</pre>
            </div>
            <pre>while (condition) {
  // falseが返るまでテストを続ける。
}
for (int i = 0; i &lt; kSomeNumber; ++i) {}  // OK。新しい1行でもOK。
while (condition) continue;  // OK。continueで、ロジックがないことを示す。
</pre>
        </div>
        <div>
            <div class="src">
                <pre class="badcode">while (condition);  // Bad - looks like part of do/while loop.
</pre>
            </div>
            <pre class="badcode">while (condition);  // ダメ。do-whileループの一部に見える。
</pre>
        </div>


    <h3 id="Pointer_and_Reference_Expressions"><span title="Pointer and Reference Expressions">ポインタと参照の表現</span></h3>

    <p>
        <span>
            <span class="src">
                No spaces around period or arrow.
            </span>
            ピリオドやアロー演算子の周りにスペースは使いません。
        </span>
        <span>
            <span class="src">
                Pointer operators do not
                have trailing spaces.
            </span>
            ポインタ演算子の後にはスペースを使いません。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                The following are examples of correctly-formatted
                pointer and reference expressions:
            </span>
            正しくフォーマットされたポインタおよび参照の例を以下に示します。
        </span>
    </p>

    <pre>x = *p;
p = &amp;x;
x = r.y;
x = r-&gt;y;
</pre>
    <p>
        <span>
            <span class="src">
                Note that:
            </span>
            以下のことに注意してください。
        </span>
    </p>

    <ul>
        <li>
            <span>
                <span class="src">
                    There are no spaces around the period or arrow when
                    accessing a member.
                </span>
                メンバにアクセスするためのピリオドやアロー演算子の周りにはスペースを使いません。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Pointer operators have no space after the
                    <code>*</code> or
                    <code>&amp;</code>.
                </span>
                ポインタ演算子(<code>*</code>や<code>&amp;</code>)の後にはスペースを使いません。
            </span>
        </li>
    </ul>

    <p>
        <span>
            <span class="src">
                When referring to a pointer or reference (variable declarations or definitions, arguments,
                return types, template parameters, etc), you may place the space before or after the
                asterisk/ampersand.
            </span>
            ポインタや参照を参照する(変数宣言や定義、引数、戻り値型、テンプレート引数など)ときは、アスタリスクやアンパサンドを型名か変数名かのどちらにつけてもかまいません。
        </span>
        <span>
            <span class="src">
                In the trailing-space style, the space is elided in some cases (template
                parameters, etc).
            </span>
            後ろにスペースを置くスタイルの場合、スペースは省略されることがあります(テンプレート引数など)。
        </span>
    </p>

    <div>
        <div class="src">
            <pre>// These are fine, space preceding.
char *c;
const std::string &amp;str;
int *GetPointer();
std::vector&lt;char *&gt;

// These are fine, space following (or elided).
char* c;
const std::string&amp; str;
int* GetPointer();
std::vector&lt;char*&gt;  // Note no space between '*' and '&gt;'
</pre>
        </div>
        <pre>// これらはどちらもOK。スペースが先。
char *c;
const std::string &amp;str;
int *GetPointer();
std::vector&lt;char *&gt;

// これらもどちらもOK。スペースが先。
char* c;
const std::string&amp; str;
int* GetPointer();
std::vector&lt;char*&gt;  // '*' と '&gt;'の間にスペースがない点に注意
</pre>
    </div>

    <p>
        <span>
            <span class="src">
                You should do this consistently within a single
                file.
                When modifying an existing file, use the style in
                that file.
            </span>
            ファイル内の一貫性を保つようにしてください。既存のファイルを変更する場合は、そのファイルのスタイルにあわせてください。
        </span>
    </p>

    <span>
        <span class="src">
            It is allowed (if unusual) to declare multiple variables in the same
            declaration, but it is disallowed if any of those have pointer or
            reference decorations.
        </span>
        複数の変数をまとめて宣言してもかまいません。しかし、それらの中に1つでもポインタや参照が含まれる場合は、同時に宣言してはいけません。
    </span>
    <span>
        <span class="src">
            Such declarations are easily misread.
        </span>
        そのような宣言は簡単に読み違えてしまうからです。
    </span>
    <div>
        <div class="src">
            <pre>// Fine if helpful for readability.
int x, y;
</pre>
        </div>
        <pre>// 可読性が高まる場合はOK。
int x, y;
</pre>
    </div>

    <div>
        <div class="src">
            <pre class="badcode">int x, *y;  // Disallowed - no &amp; or * in multiple declaration
char * c;  // Bad - spaces on both sides of *
const std::string &amp; str;  // Bad - spaces on both sides of &amp;
</pre>
        </div>
        <pre class="badcode">int x, *y;  // 禁止。&amp;や*が複数宣言の中に含められている。
char * c;  // ダメ。*の前後両方にスペースがある。
const std::string &amp; str;  // ダメ。&amp;の前後両方にスペースがある。
</pre>
    </div>

    <h3 id="Boolean_Expressions"><span title="Boolean Expressions">ブーリアンの表現</span></h3>

    <p>
        <span>
            <span class="src">
                When you have a boolean expression that is longer than the
                <a href="#Line_Length">standard line length</a>, be
                consistent in how you break up the lines.
            </span>
            ブーリアンの式が<a href="#Line_Length">標準の行の長さ</a>を超えるような場合、行の区切り方に一貫性を持たせてください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                In this example, the logical AND operator is always at
                the end of the lines:
            </span>
            以下の例では、論理積演算子を常に行末においています。
        </span>
    </p>

    <div>
        <div class="src">
            <pre>if (this_one_thing &gt; this_other_thing &amp;&amp;
    a_third_thing == a_fourth_thing &amp;&amp;
    yet_another &amp;&amp; last_one) {
  ...
}
</pre>
        </div>
        <pre>if (this_one_thing &gt; this_other_thing &amp;&amp;
    a_third_thing == a_fourth_thing &amp;&amp;
    yet_another &amp;&amp; last_one) {
  ...
}
</pre>
    </div>

    <p>
        <span>
            <span class="src">
                Note that when the code wraps in this example, both of
                the
                <code>&amp;&amp;</code> logical AND operators are at
                the end of the line.
            </span>
            この例において、2つの<code>&amp;&amp;</code>論理積演算子が、いずれも行末に来ていることに注目してください。
        </span>
        <span>
            <span class="src">
                This is more common in Google code,
                though wrapping all operators at the beginning of the
                line is also allowed.
            </span>
            演算子は次の行の頭に書いてもかまいませんが、Googleのコードにおいてよく見るのはこのような行末に置く形です。
        </span>
        <span>
            <span class="src">
                Feel free to insert extra
                parentheses judiciously because they can be very helpful
                in increasing readability when used
                appropriately, but be careful about overuse.
            </span>
            また、丸括弧を適切に扱うことで式の可読性が向上するため、丸括弧は自由に挿入して構いませんが、使いすぎには注意してください。
        </span>
        <span>
            <span class="src">
                Also note that you should always use
                the punctuation operators, such as
                <code>&amp;&amp;</code> and <code>~</code>, rather than
                the word operators, such as <code>and</code> and
                <code>compl</code>.
            </span>
            演算子には<code>and</code>や<code>compl</code>のようなワードによる演算子ではなく、常に<code>&amp;&amp;</code>や<code>~</code>のような記号による演算子を使用してください。
        </span>
    </p>
    <h3 id="Return_Values"><span title="Return Values">戻り値</span></h3>

    <p>
        <span>
            <span class="src">
                Do not needlessly surround the <code>return</code>
                expression with parentheses.
            </span>
            <code>return</code>文の式を不必要に丸括弧で囲んではいけません。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Use parentheses in
                <code>return expr;</code> only
                where you would use them in
                <code>x = expr;</code>.
            </span>
            <code>return expr;</code>に丸括弧を使うのは、式が<code>x = expr;</code>の形をしている場合のみです。
        </span>
    </p>

    <div>
        <div class="src">
            <pre>return result;                  // No parentheses in the simple case.
// Parentheses OK to make a complex expression more readable.
return (some_long_condition &amp;&amp;
        another_condition);
</pre>
        </div>
        <pre>return result;                  // シンプルなときは丸括弧は使わない。

// これはOK。複雑な式を読みやすくするために、丸括弧を使っている。
return (some_long_condition &amp;&amp;
        another_condition);
</pre>
    </div>
    <div>
        <div class="src">
            <pre class="badcode">return (value);                // You wouldn't write var = (value);
return(result);                // return is not a function!
</pre>
        </div>
        <pre class="badcode">return (value);                // var = (value);とは書かないでしょう。
return(result);                // returnは関数ではない！
</pre>
    </div>

    <h3 id="Variable_and_Array_Initialization"><span title="Variable and Array Initialization">変数と配列の初期化</span></h3>

    <p>
        <span>
            <span class="src">
                You may choose between
                <code>=</code>,
                <code>()</code>, and
                <code>{}</code>; the following are
                all correct:
            </span>
            <code>=</code>か<code>()</code>、<code>{}</code>のいずれかから選んで使用できます。次の例はすべてOKです。
        </span>
    </p>

    <div>
        <div class="src">
            <pre>int x = 3;
int x(3);
int x{3};
std::string name = "Some Name";
std::string name("Some Name");
std::string name{"Some Name"};
</pre>
        </div>
        <pre>int x = 3;
int x(3);
int x{3};
std::string name = "Some Name";
std::string name("Some Name");
std::string name{"Some Name"};
</pre>
    </div>

    <p>
        <span>
            <span class="src">
                Be careful when using a braced initialization list
                <code>{...}</code>
                on a type with an
                <code>std::initializer_list</code> constructor.
            </span>
            型が<code>std::initializer_list</code>を引数にとるコンストラクタを持つ場合、波括弧による初期化子リストを使う場合は注意が必要です。
        </span>
        <span>
            <span class="src">
                A nonempty
                <i>braced-init-list</i> prefers the
                <code>std::initializer_list</code> constructor whenever
                possible.
            </span>
            型に<code>std::initializer_list</code>を引数にとるコンストラクタがあると、空でない波括弧初期化リストは可能な限りこれを呼び出そうとします。
        </span>
        <span>
            <span class="src">
                Note that empty braces <code>{}</code> are special, and
                will call a default constructor if available.
            </span>
            ただし、リストが空<code>{}</code>のときは特殊で、デフォルトコンストラクタ(あれば)が呼ばれます。
        </span>
        <span>
            <span class="src">
                To force the
                non-<code>std::initializer_list</code> constructor, use parentheses
                instead of braces.
            </span>
            強制的に<code>std::initializer_list</code>ではないコンストラクタを呼びたい場合は、波括弧ではなく丸括弧を使ってください。
        </span>
    </p>

    <div>
        <div class="src">
            <pre>std::vector&lt;int&gt; v(100, 1);  // A vector containing 100 items: All 1s.
std::vector&lt;int&gt; v{100, 1};  // A vector containing 2 items: 100 and 1.
</pre>
        </div>
        <pre>std::vector&lt;int&gt; v(100, 1);  // 中身は「1」が100個。
std::vector&lt;int&gt; v{100, 1};  // 中身は「100」と「1」の2個。
</pre>
    </div>

    <p>
        <span>
            <span class="src">
                Also, the brace form prevents narrowing of integral
                types.
            </span>
            また、整数型に波括弧による初期化子の形を用いると、小さい型への変換を防ぐことができます。
        </span>
        <span>
            <span class="src">
                This can prevent some types of programming
                errors.
            </span>
            これによって、プログラミング上のミスを防げる場合もあります。
        </span>
    </p>

    <div>
        <div class="src">
            <pre>int pi(3.14);  // OK -- pi == 3.
int pi{3.14};  // Compile error: narrowing conversion.
</pre>
        </div>
        <pre>int pi(3.14);  // OK。 pi == 3 だけど。
int pi{3.14};  // コンパイルエラー: より小さい型への変換
</pre>
    </div>

    <h3 id="Preprocessor_Directives"><span title="Preprocessor Directives">プリプロセッサディレクティブ</span></h3>

    <p>
        <span>
            <span class="src">
                The hash mark that starts a preprocessor directive should
                always be at the beginning of the line.
            </span>
            プリプロセッサディレクティブに使われる<code>#</code>は、常に行の先頭になくてはなりません。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Even when preprocessor directives are within the body
                of indented code, the directives should start at the
                beginning of the line.
            </span>
            たとえプリプロセッサディレクティブをインデントされているコードの中に書く場合であっても、ディレクティブは行頭に記述します。
        </span>
    </p>

    <div>
        <div class="src">
            <pre>// Good - directives at beginning of line
  if (lopsided_score) {
#if DISASTER_PENDING      // Correct -- Starts at beginning of line
    DropEverything();
# if NOTIFY               // OK but not required -- Spaces after #
    NotifyClient();
# endif
#endif
    BackToNormal();
  }
</pre>
        </div>
        <pre>// OK。プリプロセッサが行の頭にある。
  if (lopsided_score) {
#if DISASTER_PENDING      // 正しい。行頭から始める。
    DropEverything();
# if NOTIFY               // #の後ろにスペースがあってもOK(必須ではない)。
    NotifyClient();
# endif
#endif
    BackToNormal();
  }
</pre>
    </div>
    <div>
        <div class="src">
            <pre class="badcode">// Bad - indented directives
  if (lopsided_score) {
    #if DISASTER_PENDING  // Wrong!  The "#if" should be at beginning of line
    DropEverything();
    #endif                // Wrong!  Do not indent "#endif"
    BackToNormal();
  }
</pre>
        </div>
        <pre class="badcode">// ダメ。ディレクティブがインデントされている。
  if (lopsided_score) {
    #if DISASTER_PENDING  // 間違い！ "#if"は行頭になくてはならない。
    DropEverything();
    #endif                // 間違い！ #endifをインデントしてはダメ。
    BackToNormal();
  }
</pre>
    </div>

    <h3 id="Class_Format"><span title="Class Format">クラスのフォーマット</span></h3>

    <p>
        <span>
            <span class="src">
                Sections in <code>public</code>, <code>protected</code> and
                <code>private</code> order, each indented one space.
            </span>
            クラス内のセクションは<code>public</code>、<code>protected</code>、<code>private</code>の順で並べ、それぞれスペース1文字でインデントします。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                The basic format for a class definition (lacking the
                comments, see<a href="#Class_Comments">Class
                Comments</a> for a discussion of what comments are
                needed) is:
            </span>
            基本的なクラス定義のフォーマットを以下に示します(コメントは省略しています。コメントについては、<a href="#Class_Comments">クラスのコメント</a>で議論しています)
        </span>
    </p>

    <div>
        <div class="src">
            <pre>class MyClass : public OtherClass {
 public:      // Note the 1 space indent!
  MyClass();  // Regular 2 space indent.
  explicit MyClass(int var);
  ~MyClass() {}

  void SomeFunction();
  void SomeFunctionThatDoesNothing() {
  }

  void set_some_var(int var) { some_var_ = var; }
  int some_var() const { return some_var_; }

 private:
  bool SomeInternalFunction();

  int some_var_;
  int some_other_var_;
};
</pre>
        </div>
        <pre>class MyClass : public OtherClass {
 public:      // スペース1つでインデント！
  MyClass();  // スペース2つでインデント(いつもの)
  explicit MyClass(int var);
  ~MyClass() {}

  void SomeFunction();
  void SomeFunctionThatDoesNothing() {
  }

  void set_some_var(int var) { some_var_ = var; }
  int some_var() const { return some_var_; }

 private:
  bool SomeInternalFunction();

  int some_var_;
  int some_other_var_;
};
</pre>
    </div>

    <p>
        <span>
            <span class="src">
                Things to note:
            </span>
            次の点に注意してください。
        </span>
    </p>

    <ul>
        <li>
            <span>
                <span class="src">
                    Any base class name should be on the same line as
                    the subclass name, subject to the 80-column limit.
                </span>
                基底クラスの名前は派生クラスの名前と同じ行に配置されるべきです。行の長さの制限にも従ってください。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    The <code>public:</code>,<code>protected:</code>,
                    and <code>private:</code> keywords should be indented
                    one space.
                </span>
                <code>public:</code>と<code>protected:</code>と<code>private:</code>キーワードは、スペース1つでインデントします。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Except for the first instance, these keywords
                    should be preceded by a blank line.
                </span>
                最初のキーワードを除いて、それらの前には空行を挟みます。
            </span>
            <span>
                <span class="src">
                    This rule is
                    optional in small classes.
                </span>
                小さなクラスにおいては、このルールに従わなくてもかまいません。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Do not leave a blank line after these
                    keywords.
                </span>
                これらのキーワードの後には空行を入れてはいけません。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    The <code>public</code> section should be first,
                    followed by the <code>protected</code> and finally the
                    <code>private</code> section.
                </span>
                <code>public</code>セクションが最初、次に<code>protected</code>、最後に<code>private</code>の順番にします。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    See<a href="#Declaration_Order">Declaration
                    Order</a> for rules on ordering declarations within
                    each of these sections.
                </span>
                各セクション内における宣言の順序に関するルールについては<a href="#Declaration_Order">宣言の順序</a>を参照してください。
            </span>
        </li>
    </ul>

    <h3 id="Constructor_Initializer_Lists"><span title="Constructor Initializer Lists">コンストラクタの初期化子リスト</span></h3>

    <p>
        <span>
            <span class="src">
                Constructor initializer lists can be all on one line or
                with subsequent lines indented four spaces.
            </span>
            コンストラクタの初期化子リストは、すべて同じ行に納めるか、行を分けて2行目以降をスペース4つでインデントして書きます。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                The acceptable formats for initializer lists are:
            </span>
            初期化子リストの正しい例は次の通りです。
        </span>
    </p>

    <div>
        <div class="src">
            <pre>// When everything fits on one line:
MyClass::MyClass(int var) : some_var_(var) {
  DoSomething();
}

// If the signature and initializer list are not all on one line,
// you must wrap before the colon and indent 4 spaces:
MyClass::MyClass(int var)
    : some_var_(var), some_other_var_(var + 1) {
  DoSomething();
}

// When the list spans multiple lines, put each member on its own line
// and align them:
MyClass::MyClass(int var)
    : some_var_(var),             // 4 space indent
      some_other_var_(var + 1) {  // lined up
  DoSomething();
}

// As with any other code block, the close curly can be on the same
// line as the open curly, if it fits.
MyClass::MyClass(int var)
    : some_var_(var) {}
</pre>
        </div>
        <pre>// 1行にすべて収まるとき
MyClass::MyClass(int var) : some_var_(var) {
  DoSomething();
}

// 1行に収まらない場合は、コロンの手前で行を区切り、
// スペース4つでインデントしなくてはならない。
MyClass::MyClass(int var)
    : some_var_(var), some_other_var_(var + 1) {
  DoSomething();
}

// 初期化子リストが複数に分かれる場合は、
// 各変数ごとに1行を使うようにし、それらを整列させる。
MyClass::MyClass(int var)
    : some_var_(var),             // スペース4つでインデント。
      some_other_var_(var + 1) {  // 行頭は揃える。
  DoSomething();
}

// 他のコードブロックと同様に、1行に収まる場合は
// 閉じ波括弧と開き波括弧とを同じ行においてもよい。
MyClass::MyClass(int var)
    : some_var_(var) {}
</pre>
    </div>

    <h3 id="Namespace_Formatting"><span title="Namespace Formatting">名前空間のフォーマット</span></h3>

    <p>
        <span>
            <span class="src">
                The contents of namespaces are not indented.
            </span>
            名前空間内の内容はインデントしません。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                <a href="#Namespaces">Namespaces</a> do not add an
                extra level of indentation.
            </span>
            <a href="#Namespaces">名前空間</a>ではインデントを足しません。
        </span>

        <span>
            <span class="src">
                For example, use:
            </span>
            たとえば、次のように使用します。
        </span>
    </p>

    <div>
        <div class="src">
            <pre>namespace {

void foo() {  // Correct.  No extra indentation within namespace.
  ...
}

}  // namespace
</pre>
        </div>
        <pre>namespace {

void foo() {  // 正しい。名前空間ではインデントしない。
  ...
}

}  // namespace
</pre>
    </div>

    <p>
        <span>
            <span class="src">
                Do not indent within a namespace:
            </span>
            名前空間の中ではインデントしてはいけません。
        </span>
    </p>

    <div>
        <div class="src">
            <pre class="badcode">namespace {

  // Wrong!  Indented when it should not be.
  void foo() {
    ...
  }

}  // namespace
</pre>
        </div>
        <pre class="badcode">namespace {

  // 間違い！　インデントしてはだめ。
  void foo() {
    ...
  }

}  // namespace
</pre>
    </div>

    <p>
        <span>
            <span class="src">
                When declaring nested namespaces, put each namespace
                on its own line.
            </span>
            ネストされた名前空間を宣言するときは、各名前空間ごとに別の行にわけます。
        </span>
    </p>

    <div>
        <div class="src">
            <pre>namespace foo {
namespace bar {
</pre>
        </div>
        <pre>namespace foo {
namespace bar {
</pre>
    </div>

    <h3 id="Horizontal_Whitespace"><span title="Horizontal Whitespace">水平方向の空白</span></h3>

    <p>
        <span>
            <span class="src">
                Use of horizontal whitespace depends on location.
            </span>
            水平方向の空白は場所に応じて使いわけます。
        </span>
        <span>
            <span class="src">
                Never put
                trailing whitespace at the end of a line.
            </span>
            行末に空白をおいてはいけません。
        </span>
    </p>

    <h4 class="stylepoint_subsection"><span title="General">全般</span></h4>

    <div>
        <div class="src">
            <pre>int i = 0;  // Two spaces before end-of-line comments.

void f(bool b) {  // Open braces should always have a space before them.
  ...
int i = 0;  // Semicolons usually have no space before them.
// Spaces inside braces for braced-init-list are optional.  If you use them,
// put them on both sides!
int x[] = { 0 };
int x[] = {0};

// Spaces around the colon in inheritance and initializer lists.
class Foo : public Bar {
 public:
  // For inline function implementations, put spaces between the braces
  // and the implementation itself.
  Foo(int b) : Bar(), baz_(b) {}  // No spaces inside empty braces.
  void Reset() { baz_ = 0; }  // Spaces separating braces from implementation.
  ...
</pre>
        </div>
        <pre>int i = 0;  // 行末コメントの前にはスペース2つ。

void f(bool b) {  // 開き波括弧の前には常にスペースをおく。
  ...

int i = 0;  // セミコロンの前にスペースはおかない。

// 波括弧初期化子リストの内側はスペースはおいてもおかなくてもよい。
// ただし、スペースをいれる場合は必ず左右の両方におく。
int x[] = { 0 };
int x[] = {0};

// 継承や初期化子のコロンの前後にはスペースをおく。
class Foo : public Bar {
 public:
  // インライン関数の実装において、波括弧と実装の間にはスペースをおく。
  Foo(int b) : Bar(), baz_(b) {}  // 空の実装にはスペースをおかない。
  void Reset() { baz_ = 0; }  // 波括弧と実装との間にはスペースをおく。
  ...
</pre>
    </div>

    <p>
        <span>
            <span class="src">
                Adding trailing whitespace can cause extra work for
                others editing the same file, when they merge, as can
                removing existing trailing whitespace.
            </span>
            行末のスペースは、同じファイルを編集する他の人がマージするときに、行末スペースの削除という余計な仕事を発生させる場合があります。
        </span>
        <span>
            <span class="src">
                So: Don't
                introduce trailing whitespace.
            </span>
            このため、行末にスペースを入れてはいけません。
        </span>
        <span>
            <span class="src">
                Remove it if you're
                already changing that line, or do it in a separate
                clean-up
                operation (preferably when no-one
                else is working on the file).
            </span>
            もし行末のスペースがある行を編集したときは、そのタイミングで取り除いてください。あるいは、別途コード整理のタイミングで取り除いてください(その場合は、誰もそのファイルを編集していないときがいいでしょう)。
        </span>
    </p>

    <h4 class="stylepoint_subsection"><span title="Loops and Conditionals">ループと条件式</span></h4>

    <div>
        <div class="src">
            <pre>if (b) {          // Space after the keyword in conditions and loops.
} else {          // Spaces around else.
}
while (test) {}   // There is usually no space inside parentheses.
switch (i) {
for (int i = 0; i &lt; 5; ++i) {
// Loops and conditions may have spaces inside parentheses, but this
// is rare.  Be consistent.
switch ( i ) {
if ( test ) {
for ( int i = 0; i &lt; 5; ++i ) {
// For loops always have a space after the semicolon.  They may have a space
// before the semicolon, but this is rare.
for ( ; i &lt; 5 ; ++i) {
  ...

// Range-based for loops always have a space before and after the colon.
for (auto x : counts) {
  ...
}
switch (i) {
  case 1:         // No space before colon in a switch case.
    ...
  case 2: break;  // Use a space after a colon if there's code after it.
</pre>
        </div>
        <pre>if (b) {          // 条件文やループキーワードの後ろにはスペースをおく。
} else {          // elseの前後にはスペースをおく。
}
while (test) {}   // 丸括弧の内側には通常はスペースをおかない。
switch (i) {
for (int i = 0; i &lt; 5; ++i) {

// ループ文と条件式の丸括弧の内側には、スペースをおいてもかまわないが、
// そのようなケースはほとんどない。周りとの一貫性を保つこと。
switch ( i ) {
if ( test ) {
for ( int i = 0; i &lt; 5; ++i ) {

// ループでは、常にセミコロンの後にスペースをおく。
// セミコロンの前にもスペースをおいてもかまわないが、
// そのようなケースもまたほとんどない。
for ( ; i &lt; 5 ; ++i) {
  ...

// レンジベースのループでは、常にコロンの前後にスペースをおく。
for (auto x : counts) {
  ...
}
switch (i) {
  case 1:         // caseのコロンの前にはスペースをおかない。
    ...
  case 2: break;  // コロンの後ろにコードがある場合はスペースをおく。
</pre>
    </div>

    <h4 class="stylepoint_subsection"><span title="Operators">演算子</span></h4>

    <div>
        <div class="src">
            <pre>// Assignment operators always have spaces around them.
x = 0;

// Other binary operators usually have spaces around them, but it's
// OK to remove spaces around factors.  Parentheses should have no
// internal padding.
v = w * x + y / z;
v = w*x + y/z;
v = w * (x + z);

// No spaces separating unary operators and their arguments.
x = -5;
++x;
if (x &amp;&amp; !y)
  ...
</pre>
        </div>
        <pre>// 代入演算子の前後には常にスペースをおく。
x = 0;

// その他の二項演算子の前後には、通常はスペースをおくが、
// 項の前後のスペースは、適宜削除してもかまわない。
// 丸括弧を使う場合は、その内側にはスペースをおくべきでない。
v = w * x + y / z;
v = w*x + y/z;
v = w * (x + z);

// 単項演算子においては、その引数との間にスペースはおかない。
x = -5;
++x;
if (x &amp;&amp; !y)
  ...
</pre>
    </div>

    <h4 class="stylepoint_subsection"><span title="Templates and Casts">テンプレートとキャスト</span></h4>

    <div>
        <div class="src">
            <pre>// No spaces inside the angle brackets (&lt; and &gt;), before
// &lt;, or between &gt;( in a cast
std::vector&lt;std::string&gt; x;
y = static_cast&lt;char*&gt;(x);

// Spaces between type and pointer are OK, but be consistent.
std::vector&lt;char *&gt; x;
</pre>
        </div>
        <pre>// 山括弧の内側(<code>&lt;</code> and <code>&gt;</code>)にはスペースをおかない。
// キャストにおける<code>&lt;</code>の前や、<code>&gt;</code>と<code>(</code>との間にもスペースをおかない。
std::vector&lt;std::string&gt; x;
y = static_cast&lt;char*&gt;(x);

// ポインタと型名の間のスペースはOK。ただし、周囲との一貫性を保つこと。
std::vector&lt;char *&gt; x;
</pre>
    </div>

    <h3 id="Vertical_Whitespace"><span title="Vertical Whitespace">垂直方向の空白</span></h3>

    <p>
        <span>
            <span class="src">
                Minimize use of vertical whitespace.
            </span>
            垂直方向の空白は最低限にしてください。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                This is more a principle than a rule: don't use blank lines when
                you don't have to.
            </span>
            これはルールというよりも原則です。不必要な場合は空行を使ってはいけません。
        </span>
        <span>
            <span class="src">
                In particular, don't put more than one or two blank
                lines between functions, resist starting functions with a blank line,
                don't end functions with a blank line, and be sparing with your use of
                blank lines.
            </span>
            特に、関数と関数との間の空行は1行か2行とし、関数を空行で始めることは控え、関数を空行で終わらせず、関数の中の空行は節約しましょう。
        </span>
        <span>
            <span class="src">
                A blank line within a block of code serves like a
                paragraph break in prose: visually separating two thoughts.
            </span>
            コードブロックの中の空行は、散文において段落を区切るような、2つの考えを視覚的に分離する効果があります。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                The basic principle is: The more code that fits on one screen, the
                easier it is to follow and understand the control flow of the
                program.
            </span>
            基本的な原則は「より多くのコードが1画面内に収まるようにすれば、プログラムのコントロールフローが追いかけやすく理解しやすくなる」というものです。
        </span>
        <span>
            <span class="src">
                Use whitespace purposefully to provide separation in that
                flow.
            </span>
            空白は、フローの分離を与える目的をもって使いましょう。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                Some rules of thumb to help when blank lines may be
                useful:
            </span>
            空行の使い方に関する経験則として、次のようなルールが有用かもしれません。
        </span>
    </p>

    <ul>
        <li>
            <span>
                <span class="src">
                    Blank lines at the beginning or end of a function
                    do not help readability.
                </span>
                関数の最初と最後の空行を入れても、コードが読みやすくなることはありません。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Blank lines inside a chain of if-else blocks may
                    well help readability.
                </span>
                if-elseブロックの連鎖の中に空行を入れると、読みやすくなることがあります。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    A blank line before a comment line usually helps
                    readability — the introduction of a new comment suggests
                    the start of a new thought, and the blank line makes it clear
                    that the comment goes with the following thing instead of the
                    preceding.
                </span>
                コメント行の前の空白はたいていの場合は可読性を高めます。
                新しいコメントの導入は新しい思考の始まりを促します。
                そして、空行が挟まることで、コメントがその後に続く何かに関わっていることを明確にします。
            </span>
        </li>
        <li>
            <span>
                <span class="src">
                    Blank lines immediately inside a declaration of a namespace or block of
                    namespaces may help readability by visually separating the load-bearing
                    content from the (largely non-semantic) organizational wrapper.
                </span>
                名前空間または名前空間のブロックの宣言のすぐ内側にある空白行は、(ほとんど意味を持たない) 組織のラッパーから負荷を伴うコンテンツを視覚的に分離することによって、読みやすさを向上させる場合があります。
            </span>
            <span>
                <span class="src">
                    Especially
                    when the first declaration inside the namespace(s) is preceded by a comment,
                    this becomes a special case of the previous rule, helping the comment to
                    "attach" to the subsequent declaration.
                </span>
                特に、名前空間内の最初の宣言の前にコメントがある場合、これは前のルールの特殊なケースになり、コメントが後続の宣言に「くっついている」ことを示すのに役立ちます。
            </span>
        </li>
    </ul>

    <h2 id="Exceptions_to_the_Rules"><span title="Exceptions to the Rules">ルールの例外</span></h2>

    <p>
        <span>
            <span class="src">
                The coding conventions described above are mandatory.
            </span>
            ここまでに説明したコーディング規約はどれも必須とされるものです。
        </span>
        <span>
            <span class="src">
                However, like all good rules, these sometimes have exceptions,
                which we discuss here.
            </span>
            しかし、すべての良いルールがそうであるように、これらのルールにはいくつかの例外事項があります。ここで、それらについて議論します。
        </span>
    </p>

    <h3 id="Existing_Non-conformant_Code"><span title="Existing Non-conformant Code">ルールに沿わない既存のコード</span></h3>

    <p>
        <span>
            <span class="src">
                You may diverge from the rules when dealing with code that
                does not conform to this style guide.
            </span>
            このスタイルガイドのルールに従っていない既存のコードを取り扱うときには、このガイドのルールからは外れてもかまいません。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                If you find yourself modifying code that was written
                to specifications other than those presented by this
                guide, you may have to diverge from these rules in order
                to stay consistent with the local conventions in that
                code.
            </span>
            コードを編集しているとき、元のコードが、本ガイドのルールではなく、別のルールに従っていると気づくことがあるかもしれません。そのような場合には、そのコードの規約との一貫性を保つために、本ガイドのルールからは外れなくてはならないでしょう。
        </span>
        <span>
            <span class="src">
                If you are in doubt about how to do this, ask the
                original author or the person currently responsible for
                the code.
            </span>
            どうしていいか迷った場合、コードの原作者や現在の責任者に確認してください。
        </span>
        <span>
            <span class="src">
                Remember that <em>consistency</em> includes
                local consistency, too.
            </span>
            「<em>一貫性</em>」には、こういった局所的な一貫性も含まれているということを忘れないでください。
        </span>
    </p>


    <h3 id="Windows_Code"><span title="Windows Code">Windowsのコード</span></h3>

    <p>
        <span>
            <span class="src">
                Windows
                programmers have developed their own set of coding
                conventions, mainly derived from the conventions in Windows
                headers and other Microsoft code.
            </span>
            Windowsプログラマの間では、独自のコーディング規約が開発されてきました。それらは、主にWindowsのヘッダーや、その他のMicrosoftのコードのコーディング規約から派生してきたものです。
        </span>
        <span>
            <span class="src">
                We want to make it easy
                for anyone to understand your code, so we have a single set
                of guidelines for everyone writing C++ on any platform.
            </span>
            我々は、あなたのコードが誰にでも簡単に理解されるようにすることを望んでおり、そのために、プラットフォームに依存しない、すべてのC++を書く人に向けた、ただ1つのガイドラインを用意しています。
        </span>
    </p>

    <p>
        <span>
            <span class="src">
                It is worth reiterating a few of the guidelines that
                you might forget if you are used to the prevalent Windows
                style:
            </span>
            あなたが広く普及しているWindowsルールに馴染んでいるようであれば、よく忘れられがちな以下のガイドラインをおさらいしておきましょう。
        </span>
    </p>

    <ul>
        <li>
            <span>
                <span class="src">
                    Do not use Hungarian notation (for example, naming
                    an integer
                    <code>iNum</code>).
                </span>
                ハンガリアン記法(たとえば、整数型に<code>iNum</code>と名付ける)は使わないでください。
            </span>
            <span>
                <span class="src">
                    Use the Google naming
                    conventions, including the <code>.cc</code> extension
                    for source files.
                </span>
                ソースコードの拡張子が<code>.cc</code>であることも含め、Googleの命名規則に従ってください。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Windows defines many of its own synonyms for
                    primitive types, such as <code>DWORD</code>,
                    <code>HANDLE</code>, etc.
                </span>
                Windowsは組み込み型に対する独自のシノニム(同義語)を定義しています(たとえば、<code>DWORD</code>や<code>HANDLE</code>など)。
            </span>
            <span>
                <span class="src">
                    It is perfectly acceptable,
                    and encouraged, that you use these types when calling
                    Windows API functions.
                </span>
                Windows APIを呼び出すときにこれらの型を使用することはまったく問題なく、むしろ推奨されることです。
            </span>
            <span>
                <span class="src">
                    Even so, keep as close as you
                    can to the underlying C++ types.
                </span>
                ただし、その場合であっても、極力、基本的なC++の型から離れないようにしてください。
            </span>
            <span>
                <span class="src">
                    For example, use
                    <code>const TCHAR *</code> instead of
                    <code>LPCTSTR</code>.
                </span>
                たとえば、<code>LPCTSTR</code>ではなく<code>const TCHAR *</code>を使用してください。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    When compiling with Microsoft Visual C++, set the
                    compiler to warning level 3 or higher, and treat all
                    warnings as errors.
                </span>
                コンパイラにMicrosoft Visual C++を使う場合は、コンパイラの警告レベルを3以上に設定し、すべての警告をエラーとして扱うように設定してください。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Do not use <code>#pragma once</code>; instead use
                    the standard Google include guards.
                </span>
                <code>#pragma once</code>は使用してはいけません。そのかわりに、Google標準のインクルードガードを使用してください。
            </span>
            <span>
                <span class="src">
                    The path in the
                    include guards should be relative to the top of your
                    project tree.
                </span>
                インクルードガードのパスは、プロジェクトツリーのルートからの相対パスを使用します。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    In fact, do not use any nonstandard extensions,
                    like <code>#pragma</code> and <code>__declspec</code>,
                    unless you absolutely must.
                </span>
                <code>#pragma</code>や<code>__declspec</code>のような、非標準の拡張は、どうしても必要な場合を除いて使わないでください。
            </span>
            <span>
                <span class="src">
                    Using
                    <code>__declspec(dllimport)</code> and
                    <code>__declspec(dllexport)</code> is allowed; however,
                    you must use them through macros such as
                    <code>DLLIMPORT</code> and <code>DLLEXPORT</code>, so
                    that someone can easily disable the extensions if they
                    share the code.
                </span>
                <code>__declspec(dllimport)</code>と<code>__declspec(dllexport)</code>は使ってもよいのですが、しかし、その場合であっても必ず、<code>DLLIMPORT</code>や<code>DLLEXPORT</code>のようなマクロを通して使わなければいけません。そうしておくことで、コードが共有されたときに、他の人が簡単にそのような拡張を無効化することができるようになります。
            </span>
        </li>
    </ul>

    <p>
        <span>
            <span class="src">
                However, there are just a few rules that we
                occasionally need to break on Windows:
            </span>
            Windowsにおいては、場合によってルールを曲げざるをえないときもあります。
        </span>
    </p>

    <ul>
        <li>
            <span>
                <span class="src">
                    Normally we <a href="#Multiple_Inheritance">strongly discourage
                    the use of multiple implementation inheritance</a>;
                    however, it is required when using COM and some ATL/WTL
                    classes.
                </span>
                通常、<a href="#Multiple_Inheritance">実装の多重継承は強く非推奨です</a>が、COMやATL/WTLクラスを使おうとすると、それが必要になってきます。
            </span>
            <span>
                <span class="src">
                    You may use multiple implementation
                    inheritance to implement COM or ATL/WTL classes and
                    interfaces.
                </span>
                COMやATL/WTLクラスやインターフェースを実装するためであれば、実装の多重継承を使用してもかまいません。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Although you should not use exceptions in your own
                    code, they are used extensively in the ATL and some
                    STLs, including the one that comes with Visual C++.
                </span>
                例外は、自分のコードに使うべきではありませんが、ATLやSTLやその他Visual C++からくるコードにおいて広く使われています。
            </span>
            <span>
                <span class="src">
                    When using the ATL, you should define
                    <code>_ATL_NO_EXCEPTIONS</code> to disable exceptions.
                </span>
                ATLを使う場合には、<code>_ATL_NO_EXCEPTIONS</code>を定義して、例外を無効にしてください。
            </span>
            <span>
                <span class="src">
                    You should investigate whether you can also disable
                    exceptions in your STL, but if not, it is OK to turn on
                    exceptions in the compiler.
                </span>
                STLを使う場合は、使用するSTLで例外を無効にできるかどうかを確認し、それができない場合は、例外が使えるようにコンパイラの設定を変更してもかまいません。
            </span>
            <span>
                <span class="src">
                    (Note that this is only to
                    get the STL to compile.
                </span>
                (しかし、例外はSTLをコンパイルするためだけに使用するということに注意してください。
            </span>
            <span>
                <span class="src">
                    You should still not write
                    exception handling code yourself.)
                </span>
                この場合でも、例外を処理するコードを自分で書くべきではありません。)
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    The usual way of working with precompiled headers
                    is to include a header file at the top of each source
                    file, typically with a name like
                    <code>StdAfx.h</code> or <code>precompile.h</code>.
                </span>
                プリコンパイル済みヘッダーを使ったよくある仕事のやり方は、各ソースファイルの最も先頭で、典型的には<code>StdAfx.h</code>や<code>precompile.h</code>という名前を持つヘッダーファイルをインクルードするというものです。
            </span>
            <span>
                <span class="src">
                    To make your code easier
                    to share with other projects, avoid including this file
                    explicitly (except in
                    <code>precompile.cc</code>), and
                    use the
                    <code>/FI</code> compiler option to include the
                    file automatically.
                </span>
                他のプロジェクトとコードを共有しやすくするため、明示的にこれらのファイルをインクルードするようなことは避け(<code>precompile.cc</code>は例外とします)、コンパイラオプション<code>/FI</code>を使用して自動的にインクルードされるようにしてください。
            </span>
        </li>

        <li>
            <span>
                <span class="src">
                    Resource headers, which are usually named
                    <code>resource.h</code> and contain only macros, do not
                    need to conform to these style guidelines.
                </span>
                リソースヘッダー(通常は<code>resource.h</code>という名前を持ち、マクロのみを含んでいるファイル)はこのルールに従う必要はありません。
            </span>
        </li>
    </ul>
</div>

</body>

</html>