forked from google/styleguide
-
Notifications
You must be signed in to change notification settings - Fork 7
/
Copy pathcppguide.ja.html
16725 lines (15688 loc) · 814 KB
/
cppguide.ja.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<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.7.1/jquery.min.js"></script>
<style>
/* 翻訳ポップアップ */
#tip_popup {
position: absolute;
max-width: 70%;
padding: 8px;
z-index: 100;
left: -99999px;
}
span:hover { background: linear-gradient(0deg, #FFA 50%, transparent 50%); }
#tip_popup { background: linear-gradient(0deg, #EFF, #FFF); border: 1px solid black; }
@media (prefers-color-scheme: dark) {
span:hover { background: linear-gradient(0deg, #26A 50%, transparent 50%); }
#tip_popup { background: linear-gradient(0deg, #111, #135); border: 1px solid white;}
}
span.src,
div.src {
display: none;
}
</style>
<script>
// 翻訳ポップアップ
$(() => {
var tip = $('<div id="tip_popup"></div>');
$("body").append(tip);
$("span,div").each(function () {
const src = $(this).attr("data-src") || $(this).children(".src").html() || null;
if (src) {
const on = m => tip.html(src).css({ left: "min(28vw, " + (m.pageX + 20) + "px)", top: (m.pageY + 20) + "px" });
const off = m => tip.css({ left: "-99999px" });
$(this).mouseover(on).mousemove(on).mouseout(off);
}
});
});
</script>
<link rel="shortcut icon" href="https://www.google.com/favicon.ico" />
<script async defer src="https://buttons.github.io/buttons.js"></script>
</head>
<body onload="initStyleGuide();">
<div id="content">
<h1>
<span data-src="Google C++ Style Guide">Google C++ スタイルガイド</span> 日本語全訳
</h1>
<h2 class="ignoreLink">訳者前書き</h2>
<ul>
<li>本ドキュメントは<a href="https://github.com/google/styleguide/">https://github.com/google/styleguide/</a> にて公開されているGoogle C++ Style Guideを日本語に訳したものです。</li>
<li>オリジナルの最新版は <a href="https://google.github.io/styleguide/cppguide.html">https://google.github.io/styleguide/cppguide.html</a>で読むことができます。</li>
<li>commit <a href="https://github.com/google/styleguide/blob/8c4da230fc15e01e0ba3545c8a6ff55bc3da4649/cppguide.html">8c4da23 (Sep 6, 2024 (JST))</a> 時点のものを底本としています。</li>
<li>オリジナルと同様<a href="https://creativecommons.org/licenses/by/3.0/">CC-By 3.0 License</a>で頒布します。</li>
<li>誤訳を含んでいる恐れがあります。訳文にマウスを重ねると原文が表示されますので、そちらもあわせて参照してください。</li>
<li>訳者はGoogleと無関係です。</li>
<li>誤訳の指摘・改善案は GitHub の <a href="https://github.com/ttsuki/styleguide/issues">Issues</a> か <a href="https://github.com/ttsuki/styleguide/pulls">Pull Requests</a> からお願いします。</li>
<li>☆をつけてもらえると励みになります;) <a class="github-button" href="https://github.com/ttsuki/styleguide" data-color-scheme="no-preference: light; light: light; dark: dark;" data-icon="octicon-star" data-show-count="true" aria-label="Star ttsuki/styleguide on GitHub">Star:</a></li>
</ul>
<div class="horizontal_toc" id="tocDiv"></div>
<h2 id="Background" class="ignoreLink"><span data-src="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++のコードを書くときにすべきこと・すべきでないことを詳しく説明し、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>」という語は、一般には可読性(readability/リーダビリティ)としても知られていますが、このガイドにおける<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 data-src="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>
それらは、このガイドで説明されるすべての個別のルールの根底にある、基礎的な「<strong>なぜそのようにするのか</strong>」の集合です。
</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’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’t discuss it.
</span>
この原則は、むしろ、このスタイルガイドで取り扱わないルールについて説明していると言えます。
たとえば、このガイドでは<code>goto</code>の濫用に関するルールを取り扱っていません。<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: 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>
また、一貫性を保つと、ツールによる自動化も進めやすくなります。たとえば、コード整形ツールや<code>#include</code>を整理するツールは、コードがツールの期待と一貫しているときにのみ、その力を発揮することでしょう。
</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";
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>
このことは、私たちのコードベースでは特に重要です。なぜなら、コードの担当者やチームのメンバーは時とともに変化していくからです。たとえ今この瞬間に、チームメンバー全員が全てのコードを理解できていたとしても、数年後も同じである保証はどこにもありません。
</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億行以上のコードがあり、何千人ものエンジニアが働くコードベースにおいては、ある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 data-src="C++ Version">C++のバージョン</span>
</h2>
<p>
<span>
<span class="src">
Currently, code should target C++20, i.e., should not use C++23
features.
</span>
現時点において、コードはC++20をターゲットとします。C++23の機能は使ってはいけません。
</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++17 and C++20 in your project.
</span>
C++17やC++20から導入された比較的新しい機能については、それらを使う前に、他の環境への移植性について考慮してください。
</span>
</p>
<h2 id="Header_Files">
<span data-src="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 data-src="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>
ヘッダーファイル以外で<code>#include</code>されることを意図したファイルには<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>
ヘッダーファイルの利用者やリファクタリングツールに対して、そのヘッダーを<code>#include</code>する際の事前条件を何ら課さないようにしてください。
</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>を書き、そのヘッダーが必要とする他のヘッダーをすべて<code>#include</code>してください。
</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>
あるヘッダーファイルにおいて、利用者に向けたインライン関数やテンプレートを宣言するときは、それらの定義も、同一のヘッダーファイル内か、同一ヘッダーファイルから<code>#include</code>するファイルの中に含めてください。
</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>#include</code>されるヘッダーファイル (<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>
また、あるテンプレートのインスタンス化が特定の単一の<code>.cc</code>ファイル内でのみ行われる場合には、そのテンプレートの定義を<code>.cc</code>ファイルの中に保持してもかまいません。これは、たとえば<a href="https://en.cppreference.com/w/cpp/language/class_template#Explicit_instantiation">明示的なテンプレートのインスタンス化</a>を行う場合や、あるいは、テンプレートの定義へのアクセスをその<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>
レアケースながら、<code>#include</code>されることを目的としつつも、自己完結でないファイルも存在します。
</span>
<span>
<span class="src">
These are typically intended to be included at unusual
locations, such as the middle of another file.
</span>
これらのファイルは、典型的には、別のファイルの中ほどなどの特殊な場所で<code>#include</code>されることを意図して作られており、
</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>を持っていなかったり、そのヘッダーが必要とする他のファイルを<code>#include</code>していなかったりします。
</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 data-src="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>によるガード)を持たせます。
</span>
<span>
<span class="src">
The format of the symbol name
should be
<code><i><PROJECT></i>_<i><PATH></i>_<i><FILE></i>_H_</code>.
</span>
ガードのシンボル名は<code><i><PROJECT></i>_<i><PATH></i>_<i><FILE></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 data-src="Include What You Use">必要なものを<code>#include</code>する</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>
ソースファイル上やヘッダーファイル上において、何らか他の場所で定義されたシンボルを参照したいときは、そのシンボルの宣言・定義の提供を意図されたヘッダーファイルを直接<code>#include</code>します。
</span>
<span>
<span class="src">
It should not
include header files for any other reason.
</span>
そして、それ以外の理由では<code>#include</code>してはいけません。
</span>
</p>
<p>
<span>
<span class="src">
Do not rely on transitive inclusions.
</span>
推移的な<code>#include</code>に頼ってはいけません。
</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>が禁止されているのであればこそ、ヘッダーファイルの著者は、ユーザーのコードを破壊することなく、安心して、不要となった<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>.cc</code>に対応するヘッダー」にも適用されます。
<code>foo.cc</code>で<code>bar.h</code>のシンボルを使うのであれば、たとえ既に<code>foo.h</code>で<code>#include "bar.h"</code>していたとしても、改めて<code>foo.cc</code>でも<code>#include "bar.h"</code>してください。
</span>
</p>
<h3 id="Forward_Declarations">
<span data-src="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">必要なヘッダーを<code>#include</code></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>
<div><div class="src">
<pre>// In a C++ source file:
class B;
void FuncInB();
extern int variable_in_b;
ABSL_DECLARE_FLAG(flag_in_b);
</pre></div><pre>// C++ソース内:
class B;
void FuncInB();
extern int variable_in_b;
ABSL_DECLARE_FLAG(flag_in_b);
</pre></div>
<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 <code>#include</code> 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>を単純に前方宣言に置き換えたとすると、コードの意味が変わってしまいます。