Add a "code consistency" chapter

[rstegg]

Code consistency is crucial for readability and maintainability:

• What is consistency? (is it the look of the code? is it the structure?)
• What isn't consistency? (e.g. does using class and function declarations cause inconsistency?)
• Why consistency matters
• How consistency can bring about better development practices

Consistency patterns:

• revealing module pattern
• more describe here

[bebraw]

Yeah, good idea. I wonder if a part of this belongs to the linting chapter.

[rstegg]

I think linting is one way to attempt to solve consistency, but linting can't solve your whole codebase.

[bebraw]

Yup, that's true. This needs more fodder to show examples which cannot be captured by linting.

[rstegg]

I can think of two consistency types ATM:

• "Style" consistency - linting
• "Completeness" consistency - e.g. every class with a getter should also have a setter

[bebraw]

Ok, http://eslint.org/docs/rules/accessor-pairs covers latter. 😄

[rstegg]

Oops! I didn't know. Perhaps there isn't a need for this extra section then? 😄

[bebraw]

Yeah, let's leave this open for a while to gather ideas.

[dcarral]

As food for thought, there are a bunch of inconsistencies which can't be handled by means of static analysis. Naming consistencies are the first ones I can think of, e.g.:

• Entity/abstraction named ThingThatLoadsFoo vs another one named BarLoader. We can use one pattern or the other (in case of this stupid example, perhaps we might wanna use the latter), but mixing both of them in the same project would be inconsistent.

[bebraw]

@dcarral Great point. Maybe this is where custom linting rules could come in? Naming tends to be more project specific than other rules. Pushing towards automation and showing how to do that might work here.