commit db9634a913267312cc943d74958ced6f72455aa6
parent 5beabb2d6211eceeb7741c450006e5fb88ab395b
Author: finwo <finwo@pm.me>
Date: Thu, 16 Aug 2018 14:30:58 +0200
Section 6 was indented too much
Diffstat:
| M | spec/spec0001.txt | | | 86 | ++++++++++++++++++++++++++++++++++++++++--------------------------------------- |
1 file changed, 44 insertions(+), 42 deletions(-)
diff --git a/spec/spec0001.txt b/spec/spec0001.txt
@@ -124,7 +124,7 @@ Table of contents
6.3.1. Reformatting existing code
6.3.2. Newly added code
6.4. Local style rules
-
+ 6.5. Generated code
1. Introduction
@@ -667,61 +667,63 @@ Table of contents
Objects MUST NOT specify template parameters when used as a
hierarchy instead of a map-like structure.
- 6. Policies
+// TODO: fix paragraph width
- 6.1. Unspecified styling
+6. Policies
- For any style question that isn't settled definitively by this
- specification, one SHOULD follow the code style of the rest of
- the file. If that doesn't resolve the question, consider
- emulating the other files in the same package. If that still
- does not resolve the question, follow the rules set by
- standardjs.
+ 6.1. Unspecified styling
- As a rule of thumb: be consistent throughout the package.
+ For any style question that isn't settled definitively by this
+ specification, one SHOULD follow the code style of the rest of
+ the file. If that doesn't resolve the question, consider
+ emulating the other files in the same package. If that still
+ does not resolve the question, follow the rules set by
+ standardjs.
- 6.2. Deprecation
+ As a rule of thumb: be consistent throughout the package.
- Mark deprecated methods, classes, inferfaces or functions with
- @deprecated annotations. A deprecation comment MUST include
- simple, clear directions for people to fix their call sites.
+ 6.2. Deprecation
- 6.3. Code not in TrackThis Style
+ Mark deprecated methods, classes, inferfaces or functions with
+ @deprecated annotations. A deprecation comment MUST include
+ simple, clear directions for people to fix their call sites.
- You will occasionally encounter files in your codebase that
- are not in proper TrackThis Style. These may have come from an
- acquisition, or may have been written before TrackThis Style
- took a position on some issue, or may be in non-TrackThis
- Style for any other reason.
+ 6.3. Code not in TrackThis Style
- 6.3.1. Reformatting existing code
+ You will occasionally encounter files in your codebase that
+ are not in proper TrackThis Style. These may have come from an
+ acquisition, or may have been written before TrackThis Style
+ took a position on some issue, or may be in non-TrackThis
+ Style for any other reason.
- When working on the file, only reformat the functions
- and/or methods you change instead of the whole file. If
- significant changes are being made to a file, it is
- expected that the file will be in TrackThis Style.
+ 6.3.1. Reformatting existing code
- 6.3.2. Newly added code
+ When working on the file, only reformat the functions
+ and/or methods you change instead of the whole file. If
+ significant changes are being made to a file, it is
+ expected that the file will be in TrackThis Style.
- Brand new files MUST use TrackThis style, regardless of
- style choices of other files in the same package. When
- adding new code to a file that is not in TrackThis Style,
- reformatting the existing code first is recommended,
- subject ti the advice in section 8.3.1.
+ 6.3.2. Newly added code
- If this reformatting is not done, the new code should be as
- consistent as possible with existing code in the same file,
- but MUST not break any rules of this specification.
+ Brand new files MUST use TrackThis style, regardless of
+ style choices of other files in the same package. When
+ adding new code to a file that is not in TrackThis Style,
+ reformatting the existing code first is recommended,
+ subject ti the advice in section 8.3.1.
- 6.4. Local style rules
+ If this reformatting is not done, the new code should be as
+ consistent as possible with existing code in the same file,
+ but MUST not break any rules of this specification.
+
+ 6.4. Local style rules
- Teams and projects may adopt additional style rules beyond
- those in this document, but must accept that cleanup changes
- may not abide by these additional rules, and must not block
- such cleanup changes due to violating any additional rules.
- Beware of excessive rules which serve no purpose. The style
- guide does not seek to define style in every possible scenario
- and neither should you.
+ Teams and projects may adopt additional style rules beyond
+ those in this document, but must accept that cleanup changes
+ may not abide by these additional rules, and must not block
+ such cleanup changes due to violating any additional rules.
+ Beware of excessive rules which serve no purpose. The style
+ guide does not seek to define style in every possible scenario
+ and neither should you.
N. Informative resources
