Merge release-v2.8.4 into master

CHANGELOG.md

@@ -1,3 +1,6 @@
+## v2.8.4 (October 31, 2017)
+- Add support to copyright tooling for TypeScript files (.ts, .tsx) [#164](https://github.com/mobify/mobify-code-style/pull/164)
+
 ## v2.8.3 (May 31, 2017)
 - Set sass linting rules to un-ignore base styles
 

copyright/headers/copyright-header.ts

@@ -0,0 +1,3 @@
+/* * *  *  * *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  * */
+/* Copyright (c) year Mobify Research & Development Inc. All rights reserved. */
+/* * *  *  * *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  * */

copyright/headers/copyright-header.tsx

@@ -0,0 +1,3 @@
+/* * *  *  * *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  * */
+/* Copyright (c) year Mobify Research & Development Inc. All rights reserved. */
+/* * *  *  * *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  * */

es6/README.md

@@ -51,6 +51,71 @@ globals:
 The boolean value indicates whether the global is to be treated as
 read-only (`false`) or read-write (`true`).
 
+## Naming
+
+Classes and constructor functions should be `TitleCased`
+
+```javascript
+// GOOD
+class DatePicker { }
+
+var LinkLabel = function() { }
+
+// BAD
+class linkLabel { }
+```
+
+Constant values that appear outside of a method scope and truly represent "data"
+that is constant (ie. it isn't something that is expected to be mutated during
+the app lifecycle), should be in `ALL_CAPS`. This means that things like global
+functions would still be `camelCased`. See examples below.
+
+```javascript
+// GOOD: constant data
+export const DEFAULT_NAME = 'Element'
+
+const STATE_CALLBACKS = {
+    pending: sendPendingResponse,
+    completed: sendCompletedResponse,
+    archived: sendArchivedResponse
+}
+
+// BAD: constant data should be ALL_CAPS
+export const defaultName = 'Element'
+
+class DatePicker {
+    render() {
+        // BAD: constant is within a method and should be camelCased
+        const DEFAULT_VALUE = 0
+    }
+}
+```
+
+All other symbols (methods, variables, and constants within a method) should be `camelCased`!
+
+```javascript
+// BAD - functions aren't "data" or a "class" and so shouldn't be TitleCase
+export const ReceiveProductData = createAction('Receive Product Data')
+
+// GOOD - exporting a function with camelCase name
+export const receiveProductData = createAction('Receive Product Data')
+
+
+// BAD - `const` outside of a method should be ALL_CAPS
+const defaultName = 'Element'
+
+// BAD - Not a constructor function and so should be camelCase
+const AddToCart = () => { console.log('Adding to cart') }
+
+// GOOD - local constants within class or function
+class MyClass {
+    const name = 'Button'
+    render() {
+        const button = <Button name={name} />
+    }
+}
+```
+
 ## Overriding Lint Rules
 
 Some of the lint rules disallow uncommon but valid behaviour that is easily confused with/typoed from much more common behaviour. If you need to use the disallowed behaviour on purpose, use an explicit lint override in the source.

es6/mobify-es6.yml

@@ -76,6 +76,12 @@ rules:
   func-style:
     - error
     - expression
+  new-cap:
+    - error
+    - 
+      newIsCap: true
+      capIsNew: true
+      properties: false
   new-parens: error
   no-alert: error
   no-labels: error

package.json

@@ -1,6 +1,6 @@
 {
   "name": "mobify-code-style",
-  "version": "2.8.3",
+  "version": "2.8.4",
   "description": "Code style guide and linting tools for Mobify",
   "repository": {
     "type": "git",

python/README.md

@@ -148,3 +148,14 @@ Message codes can be found [here](http://pylint-messages.wikidot.com/all-codes).
 Disable works for the block in which they are found, so include it at the module
 level to disable a message for a module or file.
 
+## Docstrings
+
+We don't have a company-wide standard for Docstrings, but if you're
+starting a new project, a good choice is the [Google style](https://google.github.io/styleguide/pyguide.html#Comments).
+The official Google documentation isn't always easy to follow, but there
+is an example file in [`example_google.py`](./example_google.py), in this repository.
+
+Using correct `Args` and `Returns` descriptions in your code will make it
+easier for you (or others) to work with many IDEs and code-aware editors
+that can infer the types of parameters and return values for you.
+