*Eckel* justifies the decisions about the coding styles in the text[fn:eckel-2000]:
#+begin_quote
All the decisions about coding style in this book have been deliberately considered and made, sometimes over a period of years.
#+end_quote
** General
The coding style as described by *Eckel* is one that he came to after years of practice, and originates from Bjarne Stroustrup's style, the Author of =C++=[fn:eckel-2000]:
#+begin_quote
I use a particular coding style for the examples in this book. It was developed over a number of years, and was partially inspired by Bjarne Stroustrup's style in his original The C++ Programming Language.
#+end_quote
*Eckel* goes on to declare that it's more important to keep a consistent style, than to try to determine which is superior[fn:eckel-2000]:
#+begin_quote
Because C++ is a free-form programming language, you can continue to use whatever style you're comfortable with. That said, I will note that it is important to have a consistent formatting style within a project.
#+end_quote
** File names
*Eckel* describes the history of the naming conventions for =C/C++= files[fn:eckel-2000]:
#+begin_quote
In C, it has been traditional to name header files (containing declarations) with an extension of .h and implementation files (that cause storage to be allocated and code to be generated) with an extension of .c.
#+end_quote
Depending on the type of operating system, some files had different extensions as well[fn:eckel-2000]:
#+begin_quote
DOS C++ vendors used extensions of hxx and cxx for header files and implementation files, respectively, or hpp and cpp. Later, someone figured out that the only reason you needed a different extension for a file was so the compiler could determine whether to compile it as a C or C++ file
| Implementation | .c | Implementation file for C |
| Implementation | .cpp | Implementaiton file for C++ |
** Begin and end comment tags
Most of the code examples in the text book have comment tags at the beginning and end, which is part of a system used by *Eckel* to verify all of the code examples[fn:eckel-2000]:
#+begin_quote
A very important issue with this book is that all code that you see in the book must be verified to be correct (with at least one compiler).
#+end_quote
*Eckel* further elaborates how each example has a custom ~makefile~ and some program information included in the tags[fn:eckel-2000]:
#+begin_quote
Because ExtractCode.cpp also creates a makefile for each subdirectory, information about how a program is made and the command-line used to test it is also incorporated into the listings.
#+end_quote
** Parentheses, braces, and indentation
The section begins with, what is in my opinion, an accurate statement by *Eckel*, although not without irony[fn:eckel-2000]:
#+begin_quote
Of course, everyone thinks their own style is the most rational. However, the style used here has a simple logic behind it, which will be presented here mixed in with ideas on why some of the other styles developed.
#+end_quote
On addressing indentation[fn:eckel-2000]:
#+begin_quote
Everyone seems to agree that code inside braces should be indented.
#+end_quote
*Eckel* addresses braces in his coding style[fn:eckel-2000]:
#+begin_quote
... the opening brace should always go on the same line as the "precursor" (by which I mean "whatever the body is about: a class, function, object definition, if statement, etc."). This is a single, consistent rule I apply to all of the code I write, and it makes formatting much simpler.
#+end_quote
** Identifier names
*Eckel* explains the naming conventions of identifiers[fn:eckel-2000]:
#+begin_quote
Those familiar with Java will notice that I have switched to using the standard Java style for all identifier names. However, I cannot be completely consistent here because identifiers in the Standard C and C++ libraries do not follow this style
#+end_quote
| Type | Style |
|---------------------+-------------|
| Class | Pascal Case |
| Function / Variable | Camel Case |
| Const / Definition | Snake Case |
#+begin_src cpp
class FrenchVanilla : public IceCream { }
#+end_src
#+begin_src cpp
const MAX_SCOOPS = 3;
#+end_src
#+begin_src cpp
FrenchVanilla myIceCreamCone(MAX_SCOOPS);
#+end_src
** Order of header inclusion
*Eckel* broadly defines the order of inclusion[fn:eckel-2000]:
#+begin_quote
Headers are included in order from "the most specific to the most general." That is, any header files in the local directory are included first, then any of my own "tool" headers, such as require.h, then any third-party library headers, then the Standard C++ Library headers, and finally the C library headers.
#+end_quote
#+begin_src cpp
#include <myheader.h> // Local directory headers.
#include <mytools> // Personal tool headers.
#include <thirdparty> // Third party library headers.
