112_wrirting_easytochangecode

8/12/2019 112_wrirting_easytochangecode

1/207

These are confidential sessionsplease refrain from streaming, blogging, or taking pictures

Your second-most important goal as a developer

Session 112

Ken KociendaPrincipal Engineer, iOS Apps and Frameworks

1


2/207

This is a talk about writing code

2


3/207

Easy to read

learn

understand

maintain

change

3


4/207

Easy to change software

4


5/207

Your second-most important goal

5


6/207

What is your most important goal?

6


7/207

Ship products!

7


8/207

This is how we think at Apple

8


9/207

Over 30 iOS releases since 2007

9


10/207

Releases are complicated

Legal

Marketing

Bug fixesNew app features

Improving existing features

Changing priorities

Competition

Tight schedules

Too few people

Testing

New hardware

New OS features

Work with other companies

Too many people

App Store submission

10


11/207

Help you make change easier

11


12/207

You always change your software

12


13/207

Bug fixes

Adding new features

Enhancing existing features

Changing code someone else wrote

Changing code you wrote six months ago

13


14/207

General conventions

14


15/207

Mac and iOS conventions

15


16/207


17/207

Style

Stories

Laziness

Hygiene

Notifications

Optimization

Dependencies

Mixing

Expectations

Wrap up

17


18/207


19/207

Coding conventions

19


20/207

Brace style for if-else

Parenthesis Style

Leading underscores

Code indenting

CapitalizationStyle (i.e. capitalization_style)

20


21/207

Local consistency is important

21


22/207

The beginnings of style

22


23/207

Style goes deeper

23


24/207

Matthew Arnold

24


25/207

Clarity

25


26/207

Clear writing is easier to understand

26


27/207

Clear code is easier to change

27


28/207

Elements of a clear coding style?

28


29/207

!

!

Good names

Common idioms

29


30/207


31/207

NSString *searchString = [self _searchString];BOOL searchStringIsNotEmpty = [searchString length] != 0;

if (searchStringIsNotEmpty) { [self _findBanner]->findString(searchString,

shouldBeep ? BeepOnFailure: DoNotBeepOnFailure);}

31


32/207

NSString *searchString = [self _searchString];

BOOL searchStringIsNotEmpty = [searchString length] != 0;

if (searchStringIsNotEmpty) { [self _findBanner]->findString(searchString,

shouldBeep ? YES: NO);}

32


33/207


34/207


35/207

Hard to know what they mean

- (void)stopMagnifying:(BOOL)animated;

35


36/207


- (void)stopMagnifyingAnimated:(BOOL)animated;

36


37/207

Good names are descriptive

37


38/207

!

!

Good names

Common idioms

38


39/207

!

!

Good names

Common idioms

39


40/207


[_rightView setAlpha:![[_temporary text] length] ? 1.0 : 0.0];

40


41/207

Count square brackets?

41


42/207


[_rightView setAlpha:![[_temporary text] length] ? 1.0 : 0.0];

42


43/207

Be clear!

BOOL textIsEmpty = [_temporary.text length] == 0;float alpha = textIsEmpty ? 1.0 : 0.0;[_rightView setAlpha:alpha];

43


44/207

Read and understand quickly

44


45/207

Design patterns

45


46/207


47/207

Patterns used in Apple frameworks

MVC

Target-action

Delegation

Autorelease

View controller

47


48/207

Idioms communicate at a high level

48


49/207


50/207

!

!

Good names

Common idioms

50


51/207

More than skin deep

51


52/207

Now I understand

52


53/207

Bug. Why?

53


54/207

Did not anticipate

Did not understand

54


55/207

Debug

55


56/207


57/207

Step 1: Debugger

57


58/207

What are you really looking for?

58


59/207


60/207

How could this bug happen?

60


61/207

Brian Kernighan

61


62/207

Debugging is understanding

62


63/207

Debugging is not jiggling code

63


64/207


65/207

Why?

[self foo];

[self bar];

65


66/207

Each bug fix should tell a story

66


67/207

Investigate. Eureka!

Tell someone before you code the fix

67


68/207


69/207

Write the story into your bug tracker

69


70/207

Anticipate more

Understand better

70


71/207

Now I understand

71


72/207

Wake me when it is over

72


73/207

Lazy initialization

73


74/207

It is good

74


75/207

It is not magic

75


76/207

Lazy initialization is common

FooController *controller = [FooController sharedInstance];

76


77/207


@implementation FooController

+ (FooController *)sharedInstance

{ static dispatch_once_t once; static FooController *instance; dispatch_once(&once, ^{ instance = [[FooController alloc] init]; }); return instance;}

@end

77


78/207


79/207


@implementation BarController

- (id)init

{ ... FooController*fooController = [FooController

sharedInstance];...

}

@end

79


80/207

Init storm

80


81/207


82/207

Long pause

82


83/207

Order of initialization

83


84/207

How many do you have?



{ static dispatch_once_t once; static FooController *instance; dispatch_once(&once, ^{ instance = [[FooController alloc] init]; }); return instance;}

@end

84


85/207

How many do you have?



{ static FooController *instance; if (!instance) instance = [[FooController alloc] init]; return instance;}

@end

85


86/207

Multiple instantiation of singleton

86


87/207

Mess

87


88/207

Think through lazy initialization

88


89/207

No silver bullets

89


90/207

Lightweight alloc at program start

Better singleton decomposition

90


91/207

Alternative accessor patterns

91


92/207

Create or not?

@interface FooController

+ (FooController *)sharedInstance; // will create

+ (FooController *)activeInstance; // wont create+ (FooController *)sharedInstance createIfNeeded:(BOOL)createIfNeeded;

@end

92


93/207

Wake me when it is over

93


94/207

You make the mess you clean it up!

94


95/207

Good hygiene takes effort

95


96/207

E.B. White

96


97/207

Do not throw away code

97


98/207

Conflict?

98


99/207

Changes are part of a process

99


100/207

Your top priority should be to ship

100


101/207

Do not rewrite refactor

101


102/207

Refactoring

Keep functionality, but change form

102


103/207

What about cruft?

103


104/207


105/207

What is genuine cruft?

105


106/207

Dead code

Comments which no longer apply

There is no number three

106


107/207

Use compiler for dead code checks

107


108/207

Delete or check old comments

108


109/207


110/207

Size of change is important

110


111/207

Small: clean up as you go

111


112/207


113/207

Large: need real planning

113


114/207


115/207

Test!

115


116/207

You make the mess you clean it up!

116


117/207


118/207

goto

118


119/207

Notifications are a glorified goto

119


120/207

You do not even say where to go!

120


121/207

You can go to more than one place!

121


122/207


123/207

Non-deterministic behavior

Callbacks are unordered

123


124/207

Notifications can complicate change

124


125/207

Not all bad

125


126/207

Notifications promote loose coupling

126


127/207

Model/View/Controller (MVC)

CoreData

127


128/207

will/did

128


129/207

You should know about endpoints

129


130/207

Think twice about other uses

130


131/207

Code can be too loosely coupled

131


132/207


133/207

goto NextTopic;

133


134/207

The 3% solution

134


135/207


136/207

97% of the time

100% - 97% = 3%

136


137/207

Which 3% to worry about?

137


138/207

Memory allocation

View creation

Drawing

Questionable algorithms Questionable data structures

I/O

Blocking on information

Unnecessary work

New work you just added

138


139/207

Optimize when you have measured

139


140/207


141/207

Optimize when you understand

141


142/207


143/207

Optimize slowestand oldest3%

143


144/207


145/207


146/207

Change, test, measure, optimize

146


147/207

The 3% solution

147


148/207


149/207

Implications of change

149


150/207


151/207

!

!

Inheritance trees

Call graphs

151


152/207

!

!

Inheritance trees

Call graphs

152


153/207


154/207

Avoid layers of overridden methods

154


155/207

Use delegation

155


156/207

Customize by calling another object

Keeps conceptual overhead small

Vary customization at runtime as needed

156


157/207

!

!

Inheritance trees

Call graphs

157


158/207

Smaller is better

158


159/207


160/207


161/207

Strive for unidirectional calling

161


162/207

We are all friends here

162


163/207


163


164/207


164


165/207


166/207

Rethink relationship

166


167/207

!

!

Inheritance trees

Call graphs

167


168/207


169/207

Purity of essence (OPE)

169


170/207

Model/View/Controller (MVC)

170


171/207

Do not mix model and view changes

171


172/207

Do not mix different things

172


173/207


174/207

Algorithms and data sources

174


175/207


176/207

UX and an interface paradigm

176


177/207

Is this mixing too much?

- (void)setEditing:(BOOL)editing animated:(BOOL)animated;

177


178/207

Hard-code animations?

178


179/207

Multitasking gestures

179


180/207

We change how the system works

180


181/207

App launch without animating hard

181


182/207

Do not mix different things

182


183/207

Purity of essence (OPE)

183


184/207

How do I work this thing?

184


185/207

Bugs are often disappointments

185


186/207

I expected A, you did B

186


187/207


188/207

Hard to use wrong

188


189/207

Method arguments

Assertions and early returns

189


190/207

This will never work

// UIActionSheet.m

- (void)showInView:(UIView *)view{ NSParameterAssert(view != nil);

...}

190


191/207


192/207

What about ivars?

192


193/207

Global variables are bad, right?

193


194/207

Scope is too broad

194


195/207

ivar scope also can be too broad

195


196/207

As few as possible

Simple life-cycles

Avoid tight relationships

Avoid letting non-setter methods change ivars

196


197/207

Hard to manage ivar state?

197


198/207

Use a state machine

198


199/207

UIGestureRecognizers

199


200/207

Multitasking gestures

200


201/207


202/207

Hard to use wrong

202


203/207

How do I work this thing?

203


204/207

Ten things to think about

204


205/207



206/207


6. Keep new code easy to change

7. Optimize slowest and oldest code

8. Limit dependencies

9. Do not mix different things

10. Make code that is hard to use wrong

206


207/207

Documents

112_wrirting_easytochangecode