You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First five chapters of the book which covers:
- Installation and setup of C++ tools
- Simple beginner project
- Common concepts like functions, variables, types and control flow
- Making and using structs
Any and all contributions are always very much appreciated. However, to make sure the process of accepting patches goes for everyone (especially for the maintainer), you should try to follow these few simple guidelines when you contribute:
4
+
Any and all contributions are always very much appreciated. However, to make sure the
5
+
process of accepting patches goes for everyone (especially for the maintainer), you
6
+
should try to follow these few simple guidelines when you contribute:
5
7
6
8
## Prerequisites
7
9
@@ -12,76 +14,89 @@ Any and all contributions are always very much appreciated. However, to make sur
12
14
13
15
1. Fork the repository.
14
16
2. Create a new branch based on the `dev` branch (`git checkout -b <your_branch> dev`).
15
-
If your contribution is a bug fix, you should name your branch `bugfix/xxx`;
16
-
for a feature, it should be `feature/xxx` etc. Otherwise, just use your good
17
-
judgment. Consistent naming of branches is appreciated since it makes the
18
-
output of `git branch` easier to understand with a single glance.
17
+
If your contribution is a bug fix, you should name your branch `bugfix/xxx`;
18
+
for a feature, it should be `feature/xxx` etc. Otherwise, just use your good
19
+
judgment. Consistent naming of branches is appreciated since it makes the
20
+
output of `git branch` easier to understand with a single glance.
19
21
3. Do your modifications on that branch.
20
-
4. Make sure your modifications did not break anything by building and verifying the output using:
22
+
4. Make sure your modifications did not break anything by building and verifying the
23
+
output using:
21
24
22
-
```sh
23
-
mdbook serve --open
24
-
```
25
+
```sh
26
+
mdbook serve --open
27
+
```
25
28
26
29
5. Commit your changes. Your commit message should start with a one line
27
-
short description of the modifications, with the details and explanations
28
-
of your modifications following in subsequent paragraphs or bullet points. If you address an issue, create a subtitle with the issues number and title followed by the changes involved in resolving the issue.
29
-
Please limit your lines to about 78 characters in commit messages, since
30
-
it makes the output easier to read in `git log`. Also, starting your commit
31
-
message with a tag describing the nature of the commit is nice, since it
32
-
makes the commit history easier to skim through. For commits that do not
33
-
change any functionality (e.g. refactoring or fixing typos), the `[NFC]`
34
-
tag (No Functionality Change) can be used. Here's an example of an
35
-
acceptable commit message:
36
-
37
-
```txt
38
-
[TAG] Refactor the interface
39
-
40
-
- Rename elem to contains
41
-
- Rename subset to is_subset, and make is_subset applicable in infix notation
42
-
43
-
Issue (#12) - Add an at `at_key` method:
44
-
- Added the `at_key` method
45
-
- operator[] is now bound to at_key instead of find
46
-
```
47
-
48
-
When applicable, please squash adjacent _wip_ commits into a single _logical_ commit.
49
-
If your contribution has several logical commits, it's fine.
30
+
short description of the modifications, with the details and explanations of your
31
+
modifications following in subsequent paragraphs or bullet points. If you address an
32
+
issue, create a subtitle with the issues number and title followed by the changes
33
+
involved in resolving the issue. Please limit your lines to about 78 characters in commit
34
+
messages, since it makes the output easier to read in `git log`. Also, starting your
35
+
commit message with a tag describing the nature of the commit is nice, since it makes the
36
+
commit history easier to skim through. For commits that do not change any functionality
37
+
(e.g. refactoring or fixing typos), the `[NFC]`tag (No Functionality Change) can be
38
+
used. Here's an example of an acceptable commit message:
39
+
40
+
```txt
41
+
[TAG] Refactor the interface
42
+
43
+
- Rename elem to contains
44
+
- Rename subset to is_subset, and make is_subset applicable in infix notation
45
+
46
+
Issue (#12) - Add an at `at_key` method:
47
+
- Added the `at_key` method
48
+
- operator[] is now bound to at_key instead of find
49
+
```
50
+
51
+
When applicable, please squash adjacent _wip_ commits into a single _logical_ commit. If
52
+
your contribution has several logical commits, it's fine.
50
53
6. Push the changes to your fork (`git push origin <your_branch>`).
51
54
7. Open a pull request against the package's `dev` branch (not against `main`).
52
55
53
-
I will do my best to respond in a timely manner. I might discuss your patch and suggest some modifications, or I might amend your patch myself and ask you for feedback.
54
-
You will always be given proper credit.
56
+
I will do my best to respond in a timely manner. I might discuss your patch and suggest
57
+
some modifications, or I might amend your patch myself and ask you for feedback. You will
58
+
always be given proper credit.
55
59
56
60
## Style guide
57
61
58
-
Markdown uses the CommonMark style guide for the most part however, certain exceptions are allowed for customizing the style. It is a guide for a reason.
62
+
Markdown uses the CommonMark style guide for the most part however, certain exceptions
63
+
are allowed for customizing the style. It is a guide for a reason.
59
64
60
-
- Any code example should have a corresponding example link that is either a full file/project or a link to an external compiler (eg. Godbolt).
61
-
- Any free standing or example links that are related should be put in a bullet-list and separate unrelated links by a empty line.
62
-
- Reserve the use of quote blocks (lines beginning with `>` in Markdown) for side notes relating to content or examples
65
+
- Any code example should have a corresponding example link that is either a full
66
+
file/project or a link to an external compiler (eg. Godbolt).
67
+
- Any free standing or example links that are related should be put in a bullet-list and
68
+
separate unrelated links by a empty line.
69
+
- Reserve the use of quote blocks (lines beginning with `>` in Markdown) for side notes
70
+
relating to content or examples
63
71
64
72
For C++ content such as examples:
65
73
66
74
- Indent using 4 spaces.
67
75
- Do not leave trailing white spaces at the end of lines, and no more than a
68
-
single newline at the end of a source file.
69
-
- A definition blocks' initial brace should start on a newline, not trail off the declaration.
70
-
- Prefer direct initialisation (`{}` over `=`) over assignment initialisation, especially for primitive types.
76
+
single newline at the end of a source file.
77
+
- A definition blocks' initial brace should start on a newline, not trail off the
78
+
declaration.
79
+
- Prefer direct initialisation (`{}` over `=`) over assignment initialisation, especially
80
+
for primitive types.
71
81
- Prefer brace-based initialisation for invoking a types constructor.
72
82
- Use spaces on either side of constructor arguments when using braces (eg. `int{ _ }`).
73
-
- Use `auto` as variable introducer and declare type explicitly in the brace initialiser or on right-hand-side of the assignment.
83
+
- Use `auto` as variable introducer and declare type explicitly in the brace initialiser
84
+
or on right-hand-side of the assignment.
74
85
- Prefer trailing return types on functions over prefixed notation.
75
-
- Prefer to separate functions declarations (eg. `constexpr auto`), signature, constant and reference qualifiers (classes), `noexcept` specification and return type on separate lines if function declaration gets too long. Indent the constant and references qualifiers, `noexcept` specification and return type if they are on a newline.
86
+
- Prefer to separate functions declarations (eg. `constexpr auto`), signature, constant
87
+
and reference qualifiers (classes), `noexcept` specification and return type on separate
88
+
lines if function declaration gets too long. Indent the constant and references
89
+
qualifiers, `noexcept` specification and return type if they are on a newline.
Copy file name to clipboardExpand all lines: README.md
-5
Original file line number
Diff line number
Diff line change
@@ -31,8 +31,3 @@ $ mdbook serve --open
31
31
32
32
Refer to the [Code of Conduct](/CODE_OF_CONDUCT.md) and the [License](/LICENSE) for this repository for the expected behavior of contributors and users of the repository. If you have any concerns reach out to me (Tyler Swann) on Teams or follow standard M procedures for issues you are having within the team, branch or MDN. If you wish to contribute, follow the [contributing guide](/CONTRIBUTING.md).
33
33
34
-
## TODO
35
-
36
-
-[ ] Only cover basic structs (no constructors) in chapter 5.
0 commit comments