specifications

commit c7bb092fa2b1732ebebc07fe26addeab86e2a412
parent 402ff972649ed631cc9f8f002deab18050462ae2
Author: finwo <finwo@pm.me>
Date:   Thu, 16 Aug 2018 14:52:46 +0200

Added guidelines for third-party code

Diffstat:
M
spec/spec0001.txt
 | 
22
+++++++++++++++++++++-

1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/spec/spec0001.txt b/spec/spec0001.txt
@@ -125,6 +125,7 @@ Table of contents
          6.3.2. Newly added code
       6.4. Local style rules
       6.5. Generated code
+      6.6. Third-party code
 
 1. Introduction
 
@@ -681,7 +682,7 @@ Table of contents
 
    6.2. Deprecation
 
-      Mark deprecated methods, classes, inferfaces or functions with
+      Mark deprecated methods, classes, interfaces or functions with
       @deprecated annotations. A deprecation comment MUST include
       simple, clear directions for people to fix their call sites.
 
@@ -722,6 +723,25 @@ Table of contents
       seek to define style in every possible scenario and neither
       should you.
 
+   6.5. Generated code
+
+      Source code generate by any build process is not required to be
+      in TrackThis Style. However, any generated identifiers that will
+      by referenced from hand-written code must follow the naming
+      requirements. As a special exception, such identifiers are
+      allowed to contain underscores, which may help to avoid conflicts
+      with hand-written identifiers.
+
+   6.6. Third-party code
+
+      This style specification does not apply to third-party code used
+      within the package. When working on third-party code embedded in
+      the package, section 6.3 applies.
+
+      When working on third-party code which is not embedded in the
+      package, you MUST follow the style guide supplied by that project
+      if available.
+
 N. Informative resources
 
    [JSGUIDE]     Google JavaScript Style Guide