<commit_before>= Code Conventions

In general we are following the conventions outlined in the
link:https://google-styleguide.googlecode.com/svn/trunk/cppguide.html[Google C++ style guide].
We have some modifications with respect to naming and a few rules to be outlined
below.

== Naming
=== Namespaces

In general everything should be in the wn namespace. Furthermore every set of
functionality, generally library, should be in it's own sub-namespace.

Internal-only functionality should be in a further namespace called internal.

At the end of every namespace a comment should be included describing the
namespace that was closed. Anonymous namespaces should be closed with the
comment `// anonymous namespace`.

[source,cpp]
----
namespace wn {
namespace containers {
namespace internal {

class deque_iterator {};

}  // namespace internal

class deque {};

}  // namespace containers
}  // namespace wn

namespace {
}  // anonymous namespace
----

=== Classes

Class names should be all lower-case with word separation done with underscores.
They are already expected to be in a `wn::<library>::namespace` so the name
should not repeat this information.

[source,cpp]
----
class my_foo;
struct my_bar;
----

=== Functions and Class Methods

Free functions follow the same naming conventions as classes. Their names should
be descriptive of the operation they perform, and longer names should be
preferred over potentially unclear abbreviations.

=== Arguments

Function arguments should follow the same rules as functions and methods, but
must be prefixed with an `_` denoting they are an input/output to/from this
method.

[source,cpp]
----
int foo(int _bar, int* _baz);
----

=== Local Variables

Local variables should be the same as arguments but should omit the underscore.

[source,cpp]
----
int foo() {
    int bar = 4;
}
----

=== Member Variables

Member variables should be prefixed with `m_` so that they can be readily
identified.

=== Static Variables

Private static member variables should be prefixed with `s_` in order to
identify them.

Public static member variables can omit the `s_`.

Static variables of any type are generally discouraged, and should only be used
with careful thought.

=== Template Parameters

Template parameters should be in sentence case. One exception is if the usage is
very localized and clear, an abbreviated form can be used.

[source,cpp]
----
template <typename MyType>
class fooClass {
  ...
};

template <typename T>
operator=(const T& _other) {
  ...
}
----

=== Header Guards

Header guards follow the same structure as the namespace and class name for the
main class in the file. This should also be the file name. The closing of the
header guard should also contain a comment describing what has been closed.

[source,cpp]
----
#ifdef __WN_CONTAINERS_DEQUE_H__
#define __WN_CONTAINERS_DEQUE_H__
#endif  // __WN_CONTAINERS_DEQUE_H__
----

=== Macros

Macros should be avoided if possible, but sometimes it is required. Other than
header guards preprocessor directives should be ALL_CAPS separated by "_"
characters. In conditional preprocessor sections, at the end of the directive a
comment should be included describing the section that was closed.

[source,cpp]
----
#define MY_FOO
#define MY_FOO(bar)
#ifdef FOO
#endif  // FOO
----

== Formatting
Our formatting is based off of the Google C++ style guide with some
modifications. We use clang-format extensively, and it should handle all
formatting. See .clang-format for further details.
<commit_msg>Updated the style-guide with some new information that was missing.<commit_after>= Code Conventions

In general we are following the conventions outlined in the
link:https://google-styleguide.googlecode.com/svn/trunk/cppguide.html[Google C++ style guide].
We have some modifications with respect to naming and a few rules to be outlined
below.

== Naming
=== Namespaces

In general everything should be in the wn namespace. Furthermore every set of
functionality, generally library, should be in it's own sub-namespace.

Internal-only functionality should be in a further namespace called internal.

At the end of every namespace a comment should be included describing the
namespace that was closed. Anonymous namespaces should be closed with the
comment `// anonymous namespace`.

[source,cpp]
----
namespace wn {
namespace containers {
namespace internal {

class deque_iterator {};

}  // namespace internal

class deque {};

}  // namespace containers
}  // namespace wn

namespace {
}  // anonymous namespace
----

=== Classes

Class names should be all lower-case with word separation done with underscores.
They are already expected to be in a `wn::<library>::namespace` so the name
should not repeat this information.

[source,cpp]
----
class my_foo;
struct my_bar;
----

=== Functions and Class Methods

Free functions follow the same naming conventions as classes. Their names should
be descriptive of the operation they perform, and longer names should be
preferred over potentially unclear abbreviations.

=== Arguments

Function arguments should follow the same rules as functions and methods, but
must be prefixed with an `_` denoting they are an input/output to/from this
method.

[source,cpp]
----
int foo(int _bar, int* _baz);
----

=== Local Variables

Local variables should be the same as arguments but should omit the underscore.

[source,cpp]
----
int foo() {
    int bar = 4;
}
----

=== Member Variables

Member variables should be prefixed with `m_` so that they can be readily
identified.

=== Static Variables

Private static member variables should be prefixed with `s_` in order to
identify them.

Public static member variables can omit the `s_`.

Static variables of any type are generally discouraged, and should only be used
with careful thought.

=== Global Constants

Global constants should be used in place of Macros wherever possible.
They should named as other variables, but prefixed with `k_`.

=== Template Parameters

Template parameters should be in sentence case. One exception is if the usage is
very localized and clear, an abbreviated form can be used.

[source,cpp]
----
template <typename MyType>
class fooClass {
  ...
};

template <typename T>
operator=(const T& _other) {
  ...
}
----

=== Header Guards

Header guards follow the same structure as the namespace and class name for the
main class in the file. This should also be the file name. The closing of the
header guard should also contain a comment describing what has been closed.

[source,cpp]
----
#ifdef __WN_CONTAINERS_DEQUE_H__
#define __WN_CONTAINERS_DEQUE_H__
#endif  // __WN_CONTAINERS_DEQUE_H__
----

=== Macros

Macros should be avoided if possible, but sometimes it is required. Other than
header guards preprocessor directives should be ALL_CAPS separated by "_"
characters. In conditional preprocessor sections, at the end of the directive a
comment should be included describing the section that was closed.

[source,cpp]
----
#define MY_FOO
#define MY_FOO(bar)
#ifdef FOO
#endif  // FOO
----

=== Numeric Types
As a rule, the numeric types specified in `<cstdint>` should be used
instead of the more traditional `int` `long int` types. This ensures
clarity of width, and more control over data types than otherwise.

=== System Specific Code
When writing system-specific code, Win32 for example, any variables, functions
that interact with system-specific APIs should use the types expected
by the API documentation, rather than their equivalent types from this document.
[source, cpp]
----
GetModuleHandle(NULL); // << This is ok
GetModuleHandle(nullptr); // << This is discouraged
----

== Formatting
Our formatting is based off of the Google C++ style guide with some
modifications. We use clang-format extensively, and it should handle all
formatting. See .clang-format for further details.

{'fraction_non_alphanumeric': 0.07577497129735936, 'fraction_numerical': 0.0005102691669855849, 'mean_word_length': 4.117493472584856, 'pattern_counts': {'":': 0, '<': 14, '<?xml version=': 0, '>': 10, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2324932', 'n_tokens_mistral': 2111, 'n_tokens_neox': 2028, 'n_words': 1041}