search

Bilue / swift-style-guide

Style guide & coding conventions for Swift projects
Creative Commons Zero v1.0 Universal
14 stars 3 forks source link

Prefer immutability #7

Open rhysforyou opened 8 years ago

rhysforyou commented 8 years ago

This comes out of some discussion that maybe "Prefer let-bindings over var-bindings wherever possible" doesn't make sense as a guideline when the compiler already generates warnings for that as of Swift 2. After talking it over with @sboddeus we decided that it's still probably valuable as a guideline if it's rephrased as something along the lines of "prefer immutability over mutability wherever possible".

rhysforyou commented 8 years ago

Does this get to close to being an architectural guideline vs simply a style guideline?

edwardaux commented 8 years ago

I would leave it in. Sure, the compiler will generate a warning, but the style guide provides narrative as to why we think this practice is meaningful.

Re: architecture vs style - my take is that the most valuable advice a "style" guide can give is the bigger picture stuff.

Nitpicking over whether we use 2 or 4 spaces, or K&R braces, or whatever adds only marginal value. These things can be enforced using a code formatter.

From my perspective, the true value of a style guide is in providing developers with a common set of terminology and patterns to use throughout the app, with a reasoned argument as to why each is better than the alternative.

sboddeus commented 8 years ago

I would move towards leaving this in with the wording / emphasis change.

In regards to style vs. architecture, the intent of this guide is very much style in support of "readability, consistency and removing debate about aesthetics". This guide should be enforceable with a linter or ClangFormat (when it supports Swift). We have been having seperate discussions about Architecture and the best way to present those discussions.