forked from google/styleguide
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathcppguide_de.html
More file actions
6753 lines (5442 loc) · 245 KB
/
cppguide_de.html
File metadata and controls
6753 lines (5442 loc) · 245 KB
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>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>C++ Stil Vorgabe basierend auf Google C++ Style Guide</title>
<link rel="stylesheet" type="text/css" href="include/styleguide.css">
<link rel="stylesheet" type="text/css" href="include/styleguide_de.css">
<script language="javascript" src="include/styleguide.js"></script>
<script language="javascript" src="include/styleguide_de.js"></script>
<!--link rel="shortcut icon" type="image/x-icon" href="https://www.google.com/favicon.ico" /-->
</head>
<body onload="initStyleGuide();">
<div id="content">
<h1>C++ Stil Vorgabe basierend auf <a href="cppguide.html">Google C++ Style Guide</a></h1>
<div class="horizontal_toc" id="tocDiv"></div>
<div class="main_body">
toggle languages:
<a href="#" onclick="toggle_lang('en');">en</a>
<a href="#" onclick="toggle_lang('de');">de</a>
<a href="#" onclick="toggle_lang('fr');">fr</a>
<h2 lang⁼"de" class="ignoreLink" id="Background">Hintergrund</h2>
<p lang="en">C++ is one of the main development languages used by
many of Google's open-source projects. 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.</p>
<p lang="de">C++ ist eine der Hauptentwicklungssprachen, die von
vielen quelloffenen Google Projekten benutzt wird. Wie jeder C++-
Programmierer weiss, hat diese Computersprache mächtige Eigenschaften,
aber bringt auch eine grosse Komplexität mit sich, die den Code fehleranfällig
macht, schwierig zu lesen und weiter zu pflegen.</p>
<p lang="en">The goal of this guide is to manage this complexity by
describing in detail the dos and don'ts of writing C++ code.
These rules exist to
keep the code base manageable while still allowing
coders to use C++ language features productively.</p>
<p lang="de">Das Ziel dieser Anleitung ist, diese Komplexität zu meistern,
indem detailliert auf Aspekte der C++-Programmierung eingegangen wird, wie
man es machen oder lassen sollte. Diese Regeln bestehen, um die Codebasis
handhabbar zu belassen, und doch dem Programmierer zu erlauben, die
Eigenschaften von C++ produktiv einzusetzen.</p>
<p lang="en"><em>Style</em>, also known as readability, is what we call
the conventions that govern our C++ code. The term Style is a
bit of a misnomer, since these conventions cover far more than
just source file formatting.</p>
<p lang="de">Diese Konvention, auch als <em>Stil</em> oder Lesbarkeit bezeichnet,
überwacht unseren C++ Code. Der Ausdruck Stil ist etwas zu schwach ausgefallen,
denn diese Konvention geht weit mehr als nur bis zur Sourcecode-Formatierung. </p>
<p lang="en">
Most open-source projects developed by
Google conform to the requirements in this guide.</p>
<p lang="de">
Die meisten quelloffenen Projekte, welche durch Google entwickelt werden,
halten sich an die Vorgaben dieser Anleitung.</p>
<p lang="en">Note that this guide is not a C++ tutorial: we assume that
the reader is familiar with the language. </p>
<p lang="de">Beachte, dass diese Anleitung keine Unterweisung in der Programmierung mit C++ ist.
Wir gehen davon aus, dass der Leser, die Leserin mit dieser Computersprache
bekannt ist.</p>
<h3 lang="de" id="Goals">Ziele dieser Stilanleitung</h3>
<div class="stylebody">
<p lang="en">Why do we have this document?</p>
<p lang="de">Weshalb haben wir dieses Dokument?</p>
<p lang="en">There are a few core goals that we believe this guide should
serve. These are the fundamental <b>why</b>s that
underlie all of the individual rules. 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. 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.</p>
<p lang="de">Wir denken, dass diese Anleitung einige zentrale Anliegen aufzeigen sollte.
Das sind die fundamentalen <b>Warum</b>, die allen Regeln zugrunde liegen.
Um Diskussionen eine gute Basis zu geben und um der weiteren Kommune/Umgebung aufzuzeigen,
warum bestimmte Regeln in Kraft sind und warum wir einzelne Entscheidungen gefällt haben,
begründen wir im Folgenden unsere Ideen. Wenn man versteht, welche Ziele eine
jede Regel verfolgt, dann sollte es auch für alle klarer sein, wann eine Regel
übergangen werden kann, und welche Argumente oder Alternativen für eine Änderung
der Regeln in dieser Anleitung sprechen.
<p lang="en">The goals of the style guide as we currently see them are as follows:</p>
<p lang="de">Die Ziele dieser Stilanleitung, wie wir sie im Moment sehen, sind wie folgt:</p>
<dl>
<dt lang="en">Style rules should pull their weight</dt>
<dt lang="de">Stileregeln sollten schon Gewicht haben</dt>
<dd lang="en">The benefit of a style rule
must be large enough to justify asking all of our engineers to
remember it. 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. 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.</dd>
<dd lang="de">Der Vorteil einer Stilregel sollte gross genug sein, um zu rechtfertigen,
dass alle Google Ingenieure sie beachten. Der Vorteil wird relativ gemessen gegenüber
einer Codebasis, die wir erhalten würden, wenn die Regel nicht in Kraft wäre.
Eine Regel gegen eine üble Angewohnheit, hätte nur einen kleinen Effekt, wenn
diese Vergehen von den Leuten eh selten begangen würden. Dieses Prinzip erklärt,
warum wir viele Regeln ausser Acht lassen: z.B. <code>goto</code> verstösst
schon gegen eine Anzahl von Prinzipien in dieser Anleitung, ist aber ausserordentlich
rar geworden, weshalb es hier auch nicht weiter diskutiert wird.</dd>
<dt lang="en">Optimize for the reader, not the writer</dt>
<dt lang="de">Optimiere für den Leser, nicht den Author</dt>
<dd lang="en">Our codebase (and most individual components submitted to it) is
expected to continue for quite some time. As a result, more time will
be spent reading most of our code than writing it. 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. "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). </dd>
<dd lang="de">Von der Codebasis, und den meisten einzelnen hinzugefügten Komponenten darin,
wird erwartet, dass sie noch lange Zeit währt. Daraus folgt, dass mehr Zeit mit
dem Lesen des Codes verbracht wird, als mit dem Schreiben. Explizit nehmen
wir Bezug auf einen Durchschnittsprogrammierer bei Google, der Code liest, unterhält und
testet in der Codebasis, anstelle das Schreiben solchen Codes zu vereinfachen.
"Hinterlasse dem Leser eine Spur" könnte dieses Prinzip untermalen: wenn etwas
überraschendes oder unübliches in einem Codeschnipsel passiert (z.B. das
Ändern des Besitzers eines Pointers), dann ist es wertvoll, wenn dem Leser an
dieser Stelle ein helfender Kommentar hinterlassen wird. (<code>std::unique_ptr</code>
zeigt schon den Übertrag des Besitzes unmissverständlich auf.)</dd>
<dt lang="en">Be consistent with existing code</dt>
<dt lang="de">Beachte die Übereinstimmung mit existierendem Code</dt>
<dd lang="en">Using one style consistently through our codebase lets us focus on
other (more important) issues. 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. 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. </dd>
<dd lang="en">Einen Programmierstil konsistent auf die Codebasis anzuwenden gibt
einem die Möglichkeit, sich auf eventuell wichtigere Angelegenheiten zu
konzentrieren. Durch Konsistenz kann auch Automatisierung erreicht werden:
nur wer sich an die Vorgaben der Tools hält, kann diese auch einsetzen (z.B. das
automatische Formatieren des Codes oder die Anpassung der <code>#include</code>
Anweisungen). Einige Fälle, in denen Regeln als "Sei konsistent" bezeichnet
sind, reduzieren sich auf "Nimm einfach eine und lass es gut sein". Die
möglichen Diskussion darüber welche zu wählen ist, überwiegt den Nutzen
bei weitem.</dd>
<dt lang="en">Be consistent with the broader C++ community when appropriate</dt>
<dt lang="de">Beachte die weitere C++ Kommune, wenn zuträglich</dt>
<dd lang="en">Consistency with the way other organizations use C++ has value for
the same reasons as consistency within our code base. 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. However, sometimes
standard features and idioms are flawed, or were just designed without
our codebase's needs in mind. In those cases (as described below) it's
appropriate to constrain or ban standard features. 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.</dd>
<dd lang="de">Die gleichen Überlegungen liegen dem Beachten der Benutzung
von C++ in anderen Organisationen als auch in der eigenen Codebasis zugrunde.
Gibt es im C++ Standard eine Eigenschaft, die ein Problem löst, oder wird
ein akzeptiertes Idiom weitherum eingesetzt, dann ist das schon ein Argument
um es zu benutzen. Nur manchmal sind eben solche Standards oder Idiome
nicht zu gebrauchen oder wurden nicht im Hinblick auf eine bestimmte
Codebasis geschaffen. In solchen Fällen (wie weiter unten beschrieben) ist
es angezeigt, von Standardeigenschaften Abstand zu nehmen oder sie sogar
zu meiden. In einzelnen Fällen bevorzugt Google eine hausgemachte Lösung
oder Bibliotheken von Drittparteien gegenüber dem Standard, aus gefühlter
Überlegenheit oder mangels Nutzen aus der Portierung der Codebasis auf
den Standard.</dd>
<dt lang="en">Avoid surprising or dangerous constructs</dt>
<dt lang="de">Vermeide überraschende und gefährliche Konstrukte</dt>
<dd lang="en">C++ has features that are more surprising or dangerous than one
might think at a glance. Some style guide restrictions are in place to
prevent falling into these pitfalls. There is a high bar for style
guide waivers on such restrictions, because waiving such rules often
directly risks compromising program correctness.
</dd>
<dd lang="de">C++ hat überraschendere oder gefährlichere Merkmale, als man
zuerst denkt. Einige Einschränkungen in dieser Stilanleitung sind nur
dazu da, um nicht in diese Löcher zu tapsen. Bei solchen Regeln ist für das Auslassen
ihrer Beachtung eine höherer Massstab angesetzt, weil daraus meist Fehler
in den Programmen folgen.</dd>
<dt lang="en">Avoid constructs that our average C++ programmer would find tricky
or hard to maintain</dt>
<dt lang="de">Vermeide Konstrukte, die ein durchschnittlicher C++-Programmierer
schwierig findet oder schwer zu unterhalten</dt>
<dd lang="en">C++ has features that may not be generally appropriate because of
the complexity they introduce to the code. 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. When in doubt, waivers to rules of this type
can be sought by asking
your project leads. 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.</dd>
<dd lang="de">C++ kennt Eigenheiten, deren Gebrauch nicht den Zuwachs an
Komplexität rechtfertigen, um sie weiträumig einzusetzen. In viel benutztem
Code können sie eingesetzt werden, da eine umständlichere Umschreibung multipliziert
mit der Nutzung zu aufwändig wären. Bei Zweifeln kann um eine Befreiung von
der Beachtung solcher Regeln angefragt werden. Dies ist sicherlich angebracht,
da Code-Verantwortung und Teammitgliedschaft mit der Zeit ändern. Auch wenn
jeder, der heute mit dem Code arbeitet, ihn auch versteht, ist das kein
Garant dafür, dass es in mehreren Jahren auch so sein wird.</dd>
<dt lang="en">Be mindful of our scale</dt>
<dt lang="de">Achte auf die Ausmasse</dt>
<dd lang="en">With a codebase of 100+ million lines and thousands of engineers,
some mistakes and simplifications for one engineer can become costly
for many. 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.</dd>
<dd lang="de">In einer Codebasis, die mehr als 100 Millionen Zeilen Code zählt und
tausende Ingenieure daran arbeiten, kann eine Fehler oder Vereinfachung eines
einzelnen sehr kostspielig werden für alle. Zum Beispiel ist es speziell
wichtig, den Namensraum nicht zu verunreinigen: Namenskollisionen über
die Codebasis hinweg sind schwer zu verhindern wenn jeder einfach Sachen in
den globalen Namensraum stellt.</dd>
<dt lang="en">Concede to optimization when necessary</dt>
<dt lang="de">Mache Optimierungen wenn nötig</dt>
<dd lang="en">Performance optimizations can sometimes be necessary and
appropriate, even when they conflict with the other principles of this
document.</dd>
<dd lang="de">Manchmal kann es notwendig sein eine Geschwindigkeitsoptimierung
vorzunehmen, auch wenn diese im Konflikt mit anderen Prinzipien dieses Dokuments
stehen.
</dl>
<p lang="en">The intent of this document is to provide maximal guidance with
reasonable restriction. As always, common sense and good taste should
prevail. 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. 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. Use your judgment, and if you are
unsure, please don't hesitate to ask your project leads to get additional
input.</p>
<p lang="de">Die Absicht hinter diesem Dokument ist die Unterstützung mit
Leitlinien unter angemessenen Einschränkungen. Gesunder Menschenverstand
und ein gutes Gespür sollten Vorrang haben. Dafür verweisen wir ausdrücklich
auf die etablierten Konventionen in der Google C++ Kommune, nicht nur jedermanns
persönliche oder die im Team. Sei weiterhin vorsichtig und zurückhaltend
in der Benutzung von schlauen aber unüblichen Konstrukten. Das Nichtvorhandensein
eines Verbots ist nicht gleichzusetzen mit einer Erlaubnis weiter zu gehen.
Wäge selber ab, oder frag einen Erhöhten um zusätzliche Information.</p>
</div>
<h2 id="Header_Files">Header Dateien</h2>
<p lang="en">In general, every <code>.cc</code> file should have an
associated <code>.h</code> file. There are some common
exceptions, such as unittests and
small <code>.cc</code> files containing just a
<code>main()</code> function.</p>
<p lang="de">Zu jeder <code>.cc</code> Datei gehört eine
<code>.h</code> Datei. Es gibt ein paar wenige Ausnahmen,
wie Unittest und kleine <code>.cc</code> Dateien, die gerade mal
eine <code>main()</code> Funktion enthalten.</p>
<p lang="en">Correct use of header files can make a huge difference to
the readability, size and performance of your code.</p>
<p lang="de">Der korrekte Einsatz von Header Dateien kann einen grossen
Einfluss auf die Lesbarkeit, die Grösse und die Leistung deines Codes haben.</p>
<p lang="en">The following rules will guide you through the various
pitfalls of using header files.</p>
<p lang="de">Die folgenden Regeln leiten dich um die Schlaglöcher der Benutzung
von Header Dateien.</p>
<a id="The_-inl.h_Files"></a>
<h3 id="Self_contained_Headers">In sich abgeschlossene Header</h3>
<div class="summary">
<p lang="en">Header files should be self-contained (compile on their own) and
end in <code>.h</code>. Non-header files that are meant for inclusion
should end in <code>.inc</code> and be used sparingly.</p>
<p lang="de">Header Dateien sollten in sich abgeschlossen sein (kompilierbar sein) und
mit der Endung <code>.h</code> im Namen versehen sein. Nicht-Header Dateien, die nur
für die Inklusion in anderen gedacht sind, sollten mit der Endung <code>.inc</code>
versehen sein und nur selten eingesetzt werden.</p>
</div>
<div class="stylebody">
<p lang="en">All header files should be self-contained. Users and refactoring
tools should not have to adhere to special conditions to include the
header. Specifically, a header should
have <a href="#The__define_Guard">header guards</a> and include all
other headers it needs.</p>
<p lang="de">Alle Header Dateien sollten selbst-genügsam sein. Benutzer und
Refaktorisierungswerkzeuge sollten sich nicht verbiegen um ihn einzubinden.
Speziell sollte der Header einen
<p lang="en">Prefer placing the definitions for template and inline functions in
the same file as their declarations. The definitions of these
constructs must be included into every <code>.cc</code> file that uses
them, or the program may fail to link in some build configurations. If
declarations and definitions are in different files, including the
former should transitively include the latter. Do not move these
definitions to separately included header files (<code>-inl.h</code>);
this practice was common in the past, but is no longer allowed.</p>
<p lang="de">Die Definition von template und inline Funktionen geschieht
am Besten in der gleichen Datei wie ihre Deklaration. Deren Definition
muss in jeder <code>.cc</code> Datei erfolgen, die sie benutzt, sonst
kann es vorkommen, dass das Linken missratet. Sind Deklaration und
Definition in verschiedenen Dateien, dann sollte das Einbinden des
ersteren das zweite miteinbinden. Es ist nicht mehr erlaubt, wie in
der Vergangenheit üblich, diese Definitionen in eigene Header Dateien mit
Endung <code>-inl.h</code> auszulagern.</p>
<p lang="en">As an exception, a template that is explicitly instantiated for
all relevant sets of template arguments, or that is a private
implementation detail of a class, is allowed to be defined in the one
and only <code>.cc</code> file that instantiates the template.</p>
<p lang="de">Als Ausnahme kann ein Template, welches explizit instantiiert
wird für alle Template-Argumente, oder welches ein privates Implementationsdetail
einer Klasse ist, in der <code>.cc</code> Datei stehen, in welcher es auch
verwendet wird.</p>
<p lang="en">There are rare cases where a file designed to be included is not
self-contained. These are typically intended to be included at unusual
locations, such as the middle of another file. They might not
use <a href="#The__define_Guard">header guards</a>, and might not include
their prerequisites. Name such files with the <code>.inc</code>
extension. Use sparingly, and prefer self-contained headers when
possible.</p>
<p lang="de">Es gibt seltene Fälle, in welchen eine Header-Datei nicht
in sich abgeschlossen ist. Diese werden typischerweise inmitten einer
anderen Datei inkludiert. Solche Dateien sollten die Endung <code>.inc</code>
besitzen und keinen <a href="#The__define_Guard">Header-Schutz</a> benutzen.
Verwende diese nur äusserst selten und bevorzuge in sich abgeschlossene
Header-Dateien.</p>
</div>
<h3 id="The__define_Guard">Der #define Schutz</h3>
<div class="summary">
<p lang="en">All header files should have <code>#define</code> guards to
prevent multiple inclusion. The format of the symbol name
should be
<code><i><PROJECT></i>_<i><PATH></i>_<i><FILE></i>_H_</code>.</p>
<p lang="de">Alle Header-Dateien sollten einen <code>#define</code> Schutz haben,
um bei mehrfacher Einbindung keine Neudeklarationen nach sich zu ziehen.
Das definierte Symbol sollte folgendem Schema folgen:
<code><i><PROJEKT></i>_<i><PFAD></i>_<i><DATEINAME></i>_H_</code>.</p>
</div>
<div class="stylebody">
<p lang="en">To guarantee uniqueness, they should
be based on the full path in a project's source tree. For
example, the file <code>foo/src/bar/baz.h</code> in
project <code>foo</code> should have the following
guard:</p>
<p lang="de">Um Einmaligkeit zu garantieren, sollte dieses Symbol
den ganzen Pfad vom Ursprung des Projekts beinhalten. Als Beispiel
sollte die Datei <code>foo/src/bar/baz.h</code> im Projekt <code>foo</code>
den folgenden Header-Schutz definiert bekommen:
<pre>#ifndef FOO_BAR_BAZ_H_
#define FOO_BAR_BAZ_H_
...
#endif // FOO_BAR_BAZ_H_
</pre>
</div>
<h3 id="Forward_Declarations">Vorwärtsdeklarationen</h3>
<div class="summary">
<p lang="en">Avoid using forward declarations where possible.
Just <code>#include</code> the headers you need.</p>
<p lang="de">Vermeide möglichst Vorwärtsdeklarationen.
Einfach <code>#include</code> die Header-Dateien, die du brauchst.</p>
</div>
<div class="stylebody">
<div class="definition">
<p lang="en">A "forward declaration" is a declaration of a class,
function, or template without an associated definition.</p>
<p lang="de">Eine Vorwärtsdeklaration ist eine Deklaration einer
Klasse, Funktion oder einem Template ohne dazugehörende Definition.</p>
</div>
<div class="pros">
<ul>
<li lang="en">Forward declarations can save compile time, as
<code>#include</code>s force the compiler to open
more files and process more input.</li>
<li lang="de">Vorwärtsdeklaration können Kompilierzeit einsparen,
weil <code>#include</code> den Compiler zwingen eine Datei
zu öffnen und sie zu prozessieren.</li>
<li lang="en">Forward declarations can save on unnecessary
recompilation. <code>#include</code>s can force
your code to be recompiled more often, due to unrelated
changes in the header.</li>
<li lang="de">Vorwärtsdeklaration können auch unnötige Neuübersetzungen
unterdrücken, verursacht durch nebensächliche Änderungen in den
<code>#include</code> Header.</li>
</ul>
</div>
<div class="cons">
<ul>
<li lang="en">Forward declarations can hide a dependency, allowing
user code to skip necessary recompilation when headers
change.</li>
<li lang="de">Vorwärtsdeklaration können Abhängigkeiten verstecken
und überspringen die Neuübersetzung von Benutzercode wenn
Header geändert worden sind.</li>
<li lang="en">A forward declaration may be broken by subsequent
changes to the library. 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.</li>
<li lang="de">Eine Vorwärtsdeklaration kann ungültig werden nach
Änderungen in einer Bibliothek. Vorwärtsdeklarationen von
Funktionen und Templaten können verhindern, dass Header-Eigner
sonst gültige Änderungen an ihrem API vornehmen können. Wie da sind:
Typausweitung, Hinzufügen eines Template-Parameters mit einem
Defaultwert oder das Migrieren in einen anderen Namensraum.</li>
<li lang="en">Forward declaring symbols from namespace
<code>std::</code> yields undefined behavior.</li>
<li lang="de">Die Vorwärtsdeklaration eines Symbols im Namensraum
<code>std::</code> zieht undefiniertes Verhalten nach sich.</li>
<li lang="en">It can be difficult to determine whether a forward
declaration or a full <code>#include</code> is needed.
Replacing an <code>#include</code> with a forward
declaration can silently change the meaning of
code:
<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>
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>.
</li>
<li lang="de">Es kann schwer sein abzuklären, ob eine
Vorwärtsdeklaration oder ein vollständiges <code>#include</code>
notwendig sind.
Das Ersetzen von <code>#include</code> mit einer Vorwärtsdeklaration
kann still und heimlich den Sinn von Code ändern:
<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>
Sofern das <code>#include</code> durch eine Vorwärtsdeklaration
für <code>B</code> und <code>D</code> ersetzt wurde,
täte <code>test()</code> die Funktion <code>f(void*)</code>
aufrufen.
</li>
<li lang="en">Forward declaring multiple symbols from a header
can be more verbose than simply
<code>#include</code>ing the header.</li>
<li lang="de">Mehrere Symbole aus einer Headerdatei vowärts zu deklarieren
kann aufwändiger sein als bloss ein <code>#include</code>.</li>
<li lang="en">Structuring code to enable forward declarations
(e.g. using pointer members instead of object members)
can make the code slower and more complex.</li>
<li lang="de">Den Code hinsichtlich Vorwärtsdeklarationen umzubauen
(z.B. Zeigermethoden anstelle Objektmethoden), kann ihn
langsamer und komplexer machen.</li>
</ul>
</div>
<div class="decision">
<ul>
<li lang="en">Try to avoid forward declarations of entities
defined in another project.</li>
<li lang="de">Versuche Vorwärtsdeklarationen von Sachen, die in
anderen Projekten definiert sind, zu vermeiden.</li>
<li lang="en">When using a function declared in a header file,
always <code>#include</code> that header.</li>
<li lang="de">Sobald eine Funktion benutzt wird, die in einer Headerdatei
deklariert wurde, dann <code>#include</code> diese Datei.</li>
<li lang="en">When using a class template, prefer to
<code>#include</code> its header file.</li>
<li lang="de">Bei Benutzung eines Klassentemplat, bevorzuge ihre
Headerdatei zu <code>#include</code>.</li>
</ul>
<p lang="en">Please see <a href="#Names_and_Order_of_Includes">Names and Order
of Includes</a> for rules about when to #include a header.</p>
<p lang="de">Bite sehe auch in <a href="#Names_and_Order_of_Includes">Namen und Reihenfolge von Include</a> nach für Regeln über das Inkludieren von Headerdateien.</p>
</div>
</div>
<h3 id="Inline_Functions">Inline Funktionen</h3>
<div class="summary">
<p lang="en">Define functions inline only when they are small, say, 10
lines or fewer.</p>
<p lang="de">Definiere Funktionen als <code>inline</code> nur,
wenn sie klein sind, also etwa 10 Zeilen oder weniger zählen.</p>
</div>
<div class="stylebody">
<div class="definition">
<p lang="en">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.</p>
<p lang="de">Du kannst Funktionen auf eine Art deklarieren, damit der Compiler
sie inline kopieren kann, anstelle sie über den normalen Funktionsaufrufmechanismus
aufzurufen.</p>
</div>
<div class="pros">
<p lang="en">Inlining a function can generate more efficient object
code, as long as the inlined function is small. Feel free
to inline accessors and mutators, and other short,
performance-critical functions.</p>
<p lang="de">Eine Funktion <code>inline</code> zu deklarieren kann
effizienteren Code generieren, sofern diese Funktion klein ist.
Auslesemethoden, Mutationsmethoden, und andere Geschwindigkeitskritische,
kleine Funktionen, können ruhig <code>inline</code> deklariert werden.</p>
</div>
<div class="cons">
<p lang="en">Overuse of inlining can actually make programs slower.
Depending on a function's size, inlining it can cause the
code size to increase or decrease. Inlining a very small
accessor function will usually decrease code size while
inlining a very large function can dramatically increase
code size. On modern processors smaller code usually runs
faster due to better use of the instruction cache.</p>
<p lang="de">Die Übernutzung von <code>inline</code> kann
Programme sogar langsamer machen. Abhängig von der Grösse
einer Funktion, kann dies die Programmgrösse vergrössern
oder verkleinern. Eine sehr kleine Auslesemethode zu
<code>inline</code> wird normalerweise den Code verkleinern.
Aber eine sehr grosse Funktion zu <code>inline</code> wird
die Programmgrösse dramatisch vergrössern. Auf modernen
Prozessoren läuft kleinerer Code häufig schneller aufgrund
der besseren Nutzung des Befehlscache.</p>
</div>
<div class="decision">
<p lang="en">A decent rule of thumb is to not inline a function if
it is more than 10 lines long. Beware of destructors,
which are often longer than they appear because of
implicit member- and base-destructor calls!</p>
<p lang="de">Eine gängige Daumenregel besagt, keine Funktion zu
<code>inline</code>n wenn sie mehr als 10 Zeilen lang ist.
Nimm dich in Acht vor den Abräumern, da diese oft länger sind
als man denkt, aufgrund der impliziten Aufrufe von zugehörigen
Methoden und Basisklassenabräumern!</p>
<p lang="en">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).</p>
<p lang="de">Eine weitere nützliche Daumenregel:
es ist nicht kosteneffizient eine Funktion zu <code>inline</code>n,
wenn diese Schleifen oder Verzweigungen enthält (ausser,
diese Befehle werden im allgemeinen Fall gar nie ausgeführt).</p>
<p lang="en">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.
Usually recursive functions should not be inline. 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.</p>
<p lang="de">Es ist wichtig zu wissen, dass Funktionen
nicht immer ge<code>inline</code> werden, auch wenn sie
als solche deklariert wurden. Darunter fallen z.B.
virtuelle und rekursive Funktionen. Normalerweise sollten
rekursive Funktionen nicht als <code>inline</code>
deklariert werden. Der Hauptgrund warum eine virtuelle
Funktione <code>inline</code> deklariert wird, ist ihre
Definition in der abgeleiteten Klasse zu platzieren,
einerseits wegen Bequemlichkeit, aber auch um ihre
Verhaltensweise zu dokumentieren, z.B. Auslese-
oder Mutationsmethoden.</p>
</div>
</div>
<h3 id="Names_and_Order_of_Includes">Namen und Reihenfolge der Includes</h3>
<div class="summary">
<p lang="en">Use standard order for readability and to avoid hidden
dependencies: Related header, C library, C++ library, other libraries'
<code>.h</code>, your project's <code>.h</code>.</p>
<p lang="de">Benutze die allgemeine Reihenfolge für verbesserte Lesbarkeit und
um versteckte Abhängigkeiten zu verhindern: Verwandte Headerdateien, C Bibliotheken,
C++ Bibliotheken, <code>.h</code> anderer Bibliotheken, dann dem Projekt seine
<code>.h</code>.</p>
</div>
<div class="stylebody">
<p lang="en">
All of a project's header files should be
listed as descendants of the project's source
directory without use of UNIX directory shortcuts
<code>.</code> (the current directory) or <code>..</code>
(the parent directory). For example,
<code>google-awesome-project/src/base/logging.h</code>
should be included as:</p>
<p lang="de">
Alle Headerdateien des Projekts sollten startend mit dem
Quelldateien Verzeichnis aufgeführt werden, ohne die UNIX
Verzeichnisse <code>.</code> (das aktuelle Verzeichnis) oder
<code>..</code> (das übergeordnete Verzeichnis) einzuschliessen.
Beispiel:
<code>google-awesome-project/src/base/logging.h</code>
sollte eingebunden werden als:</p>
<pre>#include "base/logging.h"
</pre>
<p lang="en">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:</p>
<p lang="de">In <code><var>dir/foo</var>.cc</code> oder
<code><var>dir/foo_test</var>.cc</code>, wessen Hauptverwendung
die Implementation und der Test von Definitionen in
<code><var>dir2/foo2</var>.h</code> ist, ordne die Includes
folgendermassen:</p>
<ol>
<li lang="en"><code><var>dir2/foo2</var>.h</code>.</li>
<li lang="de"><code><var>dir2/foo2</var>.h</code>.</li>
<li lang="en">C system files.</li>
<li lang="de">C Systemdateien.</li>
<li lang="en">C++ system files.</li>
<li lang="de">C++ Systemdateien.</li>
<li lang="en">Other libraries' <code>.h</code>
files.</li>
<li lang="de">Anderer Bibliotheken <code>.h</code>
Dateien.</li>
<li lang="en">Your project's <code>.h</code> files.</li>
<li lang="de"><code>.h</code> Dateien deines Projekts.</li>
</ol>
<p lang="en">With the preferred ordering, if
<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.
Thus, this rule ensures that build breaks show up first
for the people working on these files, not for innocent
people in other packages.</p>
<p lang="de">Mit dieser kanonischen Reihenfolge, wenn
<code><var>dir2/foo2</var>.h</code> einen Include
auslässt, wird das Erstellen von <code><var>dir/foo</var>.cc</code>
oder <code><var>dir/foo</var>_test.cc</code> nicht funktionieren.
Deshalb führt diese Regel dazu, dass das Kompilieren abbricht
bei denen, die an diesen Dateien arbeiten, und nicht bei den
Unschuldigen, die in anderen Paketen stecken.</p>
<p lang="en"><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.</p>
<p lang="de"><code><var>dir/foo</var>.cc</code> und
<code><var>dir2/foo2</var>.h</code> sind oft im selben
Verzeichnis anzutreffen (z.B. <code>base/basictypes_test.cc</code> and
<code>base/basictypes.h</code>), können aber auch in ganz unterschiedlichen
zu liegen kommen.</p>
<p lang="en">Within each section the includes should be ordered
alphabetically. Note that older code might not conform to
this rule and should be fixed when convenient.</p>
<p lang="de">In jedem Abschnitt sollten die Includes alphabethisch
sortiert sein. Beachte, dass älterer Code dieser Regel nicht immer
folgt und deshalb praktischerweise angepasst werden sollte.</p>
<p lang="en">You should include all the headers that define the symbols you rely
upon, except in the unusual case of <a href="#Forward_Declarations">forward
declaration</a>. If you rely on symbols from <code>bar.h</code>,
don't count on the fact that you included <code>foo.h</code> which
(currently) includes <code>bar.h</code>: include <code>bar.h</code>
yourself, unless <code>foo.h</code> explicitly demonstrates its intent
to provide you the symbols of <code>bar.h</code>. However, any
includes present in the related header do not need to be included
again in the related <code>cc</code> (i.e., <code>foo.cc</code> can
rely on <code>foo.h</code>'s includes).</p>
<p lang="de">Du solltest alle Header inkludieren, welche die Symbole definieren,
von denen du abhängst, ausgenommen den unüblichen Fall von
<a href="#Forward_Declarations">Vorwärtsdeklaration</a>. Benötigst du ein
Symbol aus <code>bar.h</code>, zähle nicht darauf, dass du <code>foo.h</code>
einbindest, und dieses <code>bar.h</code> inkludiert, sondern inkludiere <code>bar.h</code>
direkt. Eine Ausnahme wäre, wenn <code>foo.h</code> ausdrücklich dafür gedacht ist,
die Symbole von <code>bar.h</code> auch zur Vefügung zu stellen. Andererseits müssen
keine Header noch einmal in den <code>cc</code> Dateien eingebunden werden, wenn
die Header dies schon erledigen.
<p lang="en">For example, the includes in
<code>google-awesome-project/src/foo/internal/fooserver.cc</code>
might look like this:</p>
<p lang="de">Zum Beispiel sieht die Einbindung der Header in der Datei
<code>google-awesome-project/src/foo/internal/fooserver.cc</code>
so aus:</p>
<pre>#include "foo/server/fooserver.h"
#include <sys/types.h>
#include <unistd.h>
#include <hash_map>
#include <vector>
#include "base/basictypes.h"
#include "base/commandlineflags.h"
#include "foo/server/bar.h"
</pre>
<p lang="en" class="exception">Sometimes, system-specific code needs
conditional includes. Such code can put conditional
includes after other includes. Of course, keep your
system-specific code small and localized. Example:</p>
<p lang="de" class="exception">Manchmal benötigt systemnaher Code
eine konditionale Einbindung. Eine solche sollte nach den anderen
Einbindungen stehen und natürlich klein ausfallen wie in
folgendem Beispiel:</p>
<pre>#include "foo/public/fooserver.h"
#include "base/port.h" // For LANG_CXX11.
#ifdef LANG_CXX11
#include <initializer_list>
#endif // LANG_CXX11
</pre>
</div>
<h2 id="Scoping">Gültigkeitsbereich</h2>
<h3 id="Namespaces">Namensbereich</h3>
<div class="summary">
<p lang="en">With few exceptions, place code in a namespace. Namespaces
should have unique names based on the project name, and possibly
its path. Do not use <i>using-directives</i> (e.g.
<code>using namespace foo</code>). Do not use
inline namespaces. For unnamed namespaces, see
<a href="#Unnamed_Namespaces_and_Static_Variables">Unnamed Namespaces and
Static Variables</a>.</p>
<p lang="de">Abgesehen von wenigen Ausnahmen, setzt man seinen Code in einen
Namensbereich. Dieser sollte einen eindeutigen Namen im Projekt aufweisen und
möglicherweise aus einem Dateipfad bestehen. Es sollte keine <i>using</i>-Direktive
verwendet werden (z.B. <code>using namespace foo</code>) und auch
keine <i>inline</i>-Namensbereiche. Für unbenannte Namensbereiche siehe <a href="#Unnamed_Namespaces_and_Static_Variables">unbenannte Namensbereiche und
statische Variablen</a>.</p>
</div>
<div class="stylebody">
<div class="definition">
<p lang="en">Namespaces subdivide the global scope
into distinct, named scopes, and so are useful for preventing
name collisions in the global scope.</p>
<p lang="de">Namensbereiche unterteilen den globalen Namensbereich in
einzelne Gültigkeitsbereiche und helfen so Namenskonflikte zu verhindern.</p>
</div>
<div class="pros">
<p lang="en">Namespaces provide a method for preventing name conflicts
in large programs while allowing most code to use reasonably
short names.</p>
<p lang="de">Namensbereiche sind die Methode der Wahl, um in grossen
Programmen Namenskonflikte zu verhindern und ermöglichen dennoch die
Verwendung von relativ kurzen Namen.</p>
<p lang="en">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. 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.</p>
<p lang="de">Eine Klasse <code>Foo</code>, definiert im globalen Namensraum
zweier verschiedener Projekte, kann zu Kompilierzeit oder auch zu
Laufzeit einen Namenskonflikt verursachen. Wenn jedes Projekt seinen
Code in einen eigenen Namensbereich setzen würde (z.B.
<code>project1::Foo</code> and <code>project2::Foo</code>), dann
wären dies zwei unterschiedliche Symbole, die nicht kollidieren können.
Und Code in den jeweiligen Projekten kann weiterhin auf <code>Foo</code>
referenzieren; ohne das Prefix.</p>
<p lang="en">Inline namespaces automatically place their names in
the enclosing scope. Consider the following snippet, for
example:</p>
<p lang="de">Inline-Namensbereiche setzen ihre Symbole in den umgebenden
Namensbereich. Betrachte den folgenden Codeausschnitt als Beispiel: </p>
<pre>namespace X {
inline namespace Y {
void foo();
} // namespace Y
} // namespace X
</pre>
<p lang="en">The expressions <code>X::Y::foo()</code> and
<code>X::foo()</code> are interchangeable. Inline
namespaces are primarily intended for ABI compatibility
across versions.</p>
<p lang="de">Der Ausdruck <code>X::Y::foo()</code> und
<code>X::foo()</code> sind austauschbar. Inline-Namensbereiche
werden vorwiegend für ABI-Kompatibilität über verschiedene
Versionen verwendet.</p>
</div>
<div class="cons">
<p lang="en">Namespaces can be confusing, because they complicate
the mechanics of figuring out what definition a name refers
to.</p>
<p lang="de">Namensbereiche können verstörend wirken, weil sie
das Auffinden der Definition anhand eines Namens komplizieren.</p>
<p lang="en">Inline namespaces, in particular, can be confusing
because names aren't actually restricted to the namespace
where they are declared. They are only useful as part of
some larger versioning policy.</p>
<p lang="de">Inline-Namensbereiche sind nicht auf
den Ort ihrer Deklaration beschränkt. Diese sind nur nötig
als Teil einer grösseren Versionspolitik.</p>
<p lang="en">In some contexts, it's necessary to repeatedly refer to
symbols by their fully-qualified names. For deeply-nested
namespaces, this can add a lot of clutter.</p>
<p lang="de">In einzelnen Umgebungen ist es nötig, dass
Symbole nur voll qualifiziert verwendet werden. Bei tief verschachtelten
Namensbereichen kann dies einigen Balast nach sich ziehen.</p>
</div>
<div class="decision">
<p lang="en">Namespaces should be used as follows:</p>
<p lang="de">Namensbereiche sollten folgendermassen verwendet werden:</p>
<ul>
<li lang="en">Follow the rules on <a href="#Namespace_Names">Namespace Names</a>.</li>
<li lang="de">Folge den Regeln von <a href="#Namespace_Names">Namen in Namensbereichen</a>.</li>
<li lang="en">Terminate namespaces with comments as shown in the given examples.</li>
<li lang="en">Beende einen Namensbereich mit einem Kommentar, wie im folgenden Beispiel aufgezeigt.</li>
<li>
<p lang="en">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.</p>
<p lang="de">Namensbereiche umschliessen die ganze Quelldatei nach
den Includes, <a href="https://gflags.github.io/gflags/">
gflags</a> Definitionen/Deklarationen
und Vorwärtsdeklarationen von Klassen aus anderen Namensbereichen.</p>
<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>
<pre>// In the .cc file
namespace mynamespace {
// Definition of functions is within scope of the namespace.
void MyClass::Foo() {
...
}
} // namespace mynamespace
</pre>
<p lang="en">More complex <code>.cc</code> files might have additional details,
like flags or using-declarations.</p>
<pre>#include "a.h"
DEFINE_FLAG(bool, someflag, false, "dummy flag");
namespace a {
using ::foo::bar;
...code for a... // Code goes against the left margin.
} // namespace a
</pre>
</li>
<li lang="en">Do not declare anything in namespace
<code>std</code>, including forward declarations of
standard library classes. Declaring entities in
namespace <code>std</code> is undefined behavior, i.e.,
not portable. To declare entities from the standard
library, include the appropriate header file.</li>
<li lang="en"><p lang="en">You may not use a <i>using-directive</i>
to make all names from a namespace available.</p>
<pre class="badcode">// Forbidden -- This pollutes the namespace.
using namespace foo;
</pre>
</li>
<li lang="en"><p lang="en">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.</p>