Anti-Patterns

Sometimes to better know the right way to do things we have to first look at the wrong way.

1. Anti-Patterns Robert Brown @robby_brown
2. Ask Questions My best presentations are not from what I say but rather what you ask It’s also fine not to agree with me
3. What is an anti-pattern? James Dempsey: Good intentions gone awry Code and practices you should avoid The code you write when you are writing it wrong
4. Principles to Remember Form good habits Optimize to humans Learn the rules well so you know when and how to break them.
5. Magic Numbers Magic numbers are evil They don’t convey any context They are like numbers with out units
6. #define #define is a simple copy-and-paste operation with no sense of context There are lots of gotchas Rule of thumb: If #if isn’t involved, don’t use #define
7. #define #define MY_CONSTANT 1 + 2 MY_CONSTANT * 5 = ?
8. #define #define MULTIPLY(A, B) MULTIPLY(1 + 2, 3 + 4) = ?
9. #define #define MAX(A, B) ((A) > (B) ? (A) : (B)) int x = 1; int y = 2; MAX(++x, ++y) = ?
10. #define Proper constants: const NSUInteger kTheAnswer = 42u; NSString * const kGreeting = @”Hello World!”; In header file: extern const NSUInteger kTheAnswer; extern NSString * const kGreeting;
11. Mass Constant Files Constant files make code less reusable Constants should be as close possible to their relevant code Categories are often a good place for constants
12. Implicit Type Conversions Operations must be performed on the same primitive types Type conversions may not be what you expect
13. Implicit Type Conversions Common mistakes: (-1 < 0u) => False (1 / 2) => 0 for (uint32 i = 10; i >= 0; i--) { } => Infinite loop
14. Implicit Type Conversions Rules: Signed int to larger signed int The smaller value is sign-extended Signed int to same-sized unsigned int Bit pattern preserved
15. Implicit Type Conversions Rules: Signed int to larger unsigned int Sign-extended then interpreted as unsigned Signed int to larger unsigned int Zero-extended
16. Implicit Type Conversions Rules: Unsigned int to same-sized int Interpreted as signed, may become negative Unsigned into to larger-sized int Zero-extended, then interpreted as signed
17. Implicit Type Conversions Rules: Downcast Upper bits dropped, may cause truncation
18. Implicit Type Conversions int: 42 unsigned int: 2u long: 3l unsigned long: 5ul long long 10ll unsigned long long 100ull float: 2.0f double: 3.14
19. Bit Fields Using hard-code binary numbers in a bit field can be error prone
20. Bit Fields enum { BitFieldNone = 0ull, BitFieldOne = 1ull, BitFieldTwo = 2ull, ... BitFieldThirtyThree = 8589934592ull, BitFieldAll = 18446744073709551615ull, }; typedef UInt64 BitField;
21. Bit Fields enum { BitFieldNone = 0ull, BitFieldOne = 1ull << 0, BitFieldTwo = 1ull << 1, ... BitFieldThirtyThree = 1ull << 32, BitFieldAll = ~BitFieldNone, }; typedef UInt64 BitField;
22. Unenforced Assumptions If you ever make an assumption, assert it If the assertion fails, you immediately know either your code or your assumption is wrong Assertions help catch bugs closer to the source Assumptions should also be documented
23. Unenforced Assumptions NSParameterAssert(number > 0 && number < 100); NSCParameterAssert([string length] > 0u); NSAssert([NSThread isMainThread], @”Oops”); NSCAssert(value != nil, @”Oops”);
24. Short Variable Names Variable names should be descriptive and unambiguous Modern IDEs provide auto-completion
25. Short Variable Names Bad examples: m billy NINE temp var3 abs
26. Short Variable Names Good examples: accountNumber firstName x (when used as a cartesian coordinate)
27. Overly Intimate Code Outside classes should only know what they need Encapsulation is one of the key principles of OOP Class extensions are great for private methods/data Categories are great for protected methods/data
28. Overly Intimate Code @interface MyObject () // Private properties // Private methods @end
29. Overly Intimate Code @interface MyObject (Protected) // Protected properties // Protected methods @end
30. Dead Code Dead code is just clutter Increases compile time Even though the code is no longer used, it still has mental maintenance costs Massive commented out methods are just as bad
31. Instance Variables Instance variables should not be accessed directly Getters and setters should be used instead Essentially internal encapsulation
32. Instance Variables Benefits of accessors: Enforce constraints Protect data integrity Provide flexibility Only minimal efficiency loss KVO Accessors don’t need to be backed by an ivar
33. Branching on Classes Branching on classes is essentially reimplementing polymorphism Categories solve this problem Not all languages support categories
34. Branching on Classes // Bad example if ([asset isKindOfClass:[Video class]]) [asset processVideo]; else if ([asset isKindOfClass:[Photo class]]) [asset processPhoto];
35. Branching on Classes // Good example [asset processAsset];
36. Branching on Classes // Categories @implementation Video (Processing) - (void)processAsset { } @end @implementation Photo (Processing) - (void)processAsset { } @end
37. Oversized Methods Short methods are easier to read and reuse Rule of thumb: 1-20 lines is optimal 100+ lines is excessive
38. Long Lines Shorter lines are easier to read Not everyone has 27+ inch screens Xcode doesn’t auto-wrap text very well Rule of thumb: 80-100 characters per line
39. Whitespace Whitespace makes code more readable It separates parts of methods into natural sections These sections are best accompanied with comments
40. Name Spacing Often classes have the same name Example: User, Tweet, Photo Naming conflicts are painful to fix
41. Name Spacing Some languages, such as C++, include name spaces The convention in Objective-C is to use 2-3 character prefixes
42. Want to Learn More? Code Complete 24 Deadly Sins of Software Security http://www.cprogramming.com/tutorial/ cpreprocessor.html
43. Questions?