From a5a368f2cc0e74927eca19ed5297baade5e36c24 Mon Sep 17 00:00:00 2001 From: joshaber Date: Thu, 27 Sep 2012 08:57:47 -0400 Subject: [PATCH 1/3] no space between a cast and the variable --- README.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 10caf2a..2632488 100644 --- a/README.md +++ b/README.md @@ -10,7 +10,7 @@ * Comments should be [Tomdoc](http://tomdoc.org/)-style. * Use `#pragma mark`s to categorize methods and protocol implementations. -## Properties and Instance Variables +## Properties, Instance Variables, and Declarations * Never declare an ivar unless you need to change its type from its declared property. * Prefer exposing an immutable type for a property if it being mutable is an implementation detail. This is a valid reason to declare an ivar for a property. @@ -20,6 +20,12 @@ * Declare properties `readonly` if they are only set once in `-init`. * Don't use `@synthesize` unless the compiler requires it. * Instance variables should be prefixed with an underscore (just like when implicitly synthesized). + * There shouldn't be a space between a cast and the variable being cast. + +``` objc +NewType a = (OldType)b; +``` + ## Control Structures From c53180c1111e5f14c6b65427ed3cdca9a72c269e Mon Sep 17 00:00:00 2001 From: joshaber Date: Thu, 27 Sep 2012 08:58:00 -0400 Subject: [PATCH 2/3] use object literals and all that good stuff --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 2632488..d8fe24a 100644 --- a/README.md +++ b/README.md @@ -74,6 +74,8 @@ NSArray *theShit = @[ @1, @2, @3 ]; NSDictionary *keyedShit = @{ GHDidCreateStyleGuide: @YES }; ``` +* Use object literals, boxed expressions, and subscripting over the older, grosser alternatives. + ## Categories * Categories should be named for the sort of functionality they provide. Don't create umbrella categories. From 576eae2ea8d3ce19fc3e4dba41c9f0744bc49939 Mon Sep 17 00:00:00 2001 From: joshaber Date: Thu, 27 Sep 2012 16:03:07 -0400 Subject: [PATCH 3/3] split out an Expressions section --- README.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index d8fe24a..ca95235 100644 --- a/README.md +++ b/README.md @@ -10,7 +10,7 @@ * Comments should be [Tomdoc](http://tomdoc.org/)-style. * Use `#pragma mark`s to categorize methods and protocol implementations. -## Properties, Instance Variables, and Declarations +## Properties and Instance Variables * Never declare an ivar unless you need to change its type from its declared property. * Prefer exposing an immutable type for a property if it being mutable is an implementation detail. This is a valid reason to declare an ivar for a property. @@ -20,17 +20,20 @@ * Declare properties `readonly` if they are only set once in `-init`. * Don't use `@synthesize` unless the compiler requires it. * Instance variables should be prefixed with an underscore (just like when implicitly synthesized). - * There shouldn't be a space between a cast and the variable being cast. + +## Expressions + + * Use object literals, boxed expressions, and subscripting over the older, grosser alternatives. + * Comparisons should be explicit for everything except `BOOL`s. + * Prefer positive comparisons to negative. + * There shouldn't be a space between a cast and the variable being cast. ``` objc NewType a = (OldType)b; ``` - ## Control Structures - * Comparisons should be explicit for everything except `BOOL`s. - * Prefer positive comparisons to negative. * Always surround `if` bodies with curly braces if there is an `else`. Single-line `if` bodies without an `else` should be on the same line as the `if`. * All curly braces should begin on the same line as their associated statement. They should end on a new line. * Put a single space after keywords and before their parentheses. @@ -74,8 +77,6 @@ NSArray *theShit = @[ @1, @2, @3 ]; NSDictionary *keyedShit = @{ GHDidCreateStyleGuide: @YES }; ``` -* Use object literals, boxed expressions, and subscripting over the older, grosser alternatives. - ## Categories * Categories should be named for the sort of functionality they provide. Don't create umbrella categories.