5 ineffective. MANY F# programmers. DON T have. coding habits

Transcription

1 5 ineffective coding habits MANY F# programmers DON T have

2 habit ˈhabɪt/ A settled or regular tendency or practice, especially one that is hard to give up.

3 I m not a great programmer; I m just a good programmer with great habits. - Kent Beck

4 Noisy Code Visual Dishonesty Lego Naming Underabstraction Unencapsulated State Getters and Setters Uncohesive Tests

5 does the language I use make a difference?

6 Programming languages have a devious influence: they shape our thinking habits. - Edsger W. Dijkstra

7 Noisy Code

8

9

10

11 every LOC is a cost

12 more code more chance for bugs

13 more code longer time-to-comprehension

14 more code more engineers

15

16 You should do whatever possible to increase the productivity of individual programmers in terms of the expressive power of the code they write. Less code to do the same thing (and possibly better). Less programmers to hire. Less organizational communication costs.

17 You should do whatever possible to increase the productivity of individual programmers in terms of the expressive power of the code they write. Less code to do the same thing (and possibly better). Less programmers to hire. Less organizational communication costs.

18 does the language I use make a difference?

19

20 source

21 source

22 source

23 source

24 source

25 source

26 source

27 Visual Dishonesty

28 a clean design is one that supports visual thinking so people can meet their informational needs with a minimum of conscious effort. - Daniel Higginbotham (

29 public void MyCleverMethod( int firstarg, string secondarg) signifies hierarchy

30 You convey information by the way you arrange a design s elements in relation to each other. This information is understood immediately, if not consciously, by the people viewing your designs. - Daniel Higginbotham (

31 This is great if the visual relationships are obvious and accurate, but if they re not, your audience is going to get confused. They ll have to examine your work carefully, going back and forth between the different parts to make sure they understand. - Daniel Higginbotham (

32 how we read ENGLISH Whilst talking with an ex-colleague, a question came up on how to implement the Stable Marriage problem using a message passing approach. Naturally, I wanted to answer that question with Erlang! Let s first dissect the problem and decide what processes we need and how they need to interact with one another. The stable marriage problem is commonly stated as: Given n men and n women, where each person has ranked all members of the opposite sex with a unique number between 1 and n in order of preference, marry the men and women together such that there are no two people of opposite sex who would both rather have each other than their current partners. If there are no such people, all the marriages are stable. (It is assumed that the participants are binary gendered and that marriages are not same-sex). From the problem description, we can see that we need: * a module for man * a module for woman * a module for orchestrating the experiment In terms of interaction between the different modules, I imagined something along the lines of see also

33 how we read ENGLISH Whilst talking with an ex-colleague, a question came up on how to implement the Stable Marriage problem using a message passing approach. Naturally, I wanted to answer that question with Erlang! 1.left-to-right Let s first dissect the problem and decide what processes we need and how they need to interact with one another. The stable marriage problem is commonly stated as: Given n men and n women, where each person has ranked all members of the opposite sex with a unique number between 1 and n in order of preference, marry the men and women together such that there are no two people of opposite sex who would both rather have each other than their current partners. If there are no such people, all the marriages are stable. (It is assumed that the participants are binary gendered and that marriages are not same-sex). From the problem description, we can see that we need: * a module for man * a module for woman * a module for orchestrating the experiment In terms of interaction between the different modules, I imagined something along the lines of 2. top-to-bottom see also

34 how we read CODE public void DoSomething(int x, int y) { Foo(y, Bar(x, Zoo(Monkey()))); } see also

35 how we read CODE public void DoSomething(int x, int y) { } 2. bottom-to-top Foo(y, Bar(x, Zoo(Monkey()))); 1.right-to-left see also

36 Whilst talking with an ex-colleague, a question came up on how to implement the Stable Marriage problem using a message passing 1.left-to-right approach. Naturally, I wanted to answer that question with Erlang! Let s first dissect the problem and decide what processes we need and how they need to interact with one another. 2. top-to-bottom The stable marriage problem is commonly stated as: Given n men and n women, where each person has ranked all members of the opposite sex with a unique number between 1 and n in order of preference, marry the men and women together such that there are no two people of opposite sex who would both rather have each other than their current partners. If there are no such people, all the marriages are stable. (It is assumed that the participants are binary gendered and that marriages are not same-sex). From the problem description, we can see that we need: * a module for man * a module for woman * a module for orchestrating the experiment In terms of interaction between the different modules, I imagined something along the lines of how we read ENGLISH 2. top-to-bottom how we read CODE public void DoSomething(int x, int y) { Foo(y, Bar(x, Zoo(Monkey()))); } 1.right-to-left see also

37 > see also

38 how we read CODE let drawcircle x y radius = circle radius > filled (rgb ) > alpha 0.5 > move (x, y) see also

39 how we read CODE 1.left-to-right let drawcircle x y radius = circle radius > filled (rgb ) > alpha 0.5 > move (x, y) 2. top-to-bottom see also

40 {}

41 public ResultType MyCleverMethod( int firstarg, string secondarg, string thirdarg) { var localvar = AnotherCleverMethod(firstArg, secondarg); if (localvar.issomething( thirdarg, MY_CONSTANT)) { DoSomething(localVar); } return localvar.getsomething(); }

42 XXXXXX XXXXXXXXXX XXXXXXXXXXXXXX XXX XXXXXXXX XXXXXX XXXXXXXXX XXXXXX XXXXXXXX XXX XXXXXXXX XXXXXXXXXXXXXXXXXXX XXXXXXXX XXXXXXXXX XX XXXXXXXX XXXXXXXXXXX XXXXXXXX XXXXXXXXXX XXXXXXXXXXX XXXXXXXX XXXXXX XXXXXXXX XXXXXXXXXXXX

43 public ResultType MyCleverMethod( int firstarg, string secondarg, string thirdarg) { var localvar = AnotherCleverMethod(firstArg, secondarg); if (localvar.issomething( thirdarg, MY_CONSTANT)) { DoSomething(localVar); } return localvar.getsomething(); }

44 public ResultType MyCleverMethod( int firstarg, string secondarg, string thirdarg) { var localvar = AnotherCleverMethod(firstArg, secondarg); if (localvar.issomething( thirdarg, MY_CONSTANT)) { DoSomething(localVar); } return localvar.getsomething(); }

45 XXXXXX XXXXXXXXXX XXXXXXXXXXXXXX XXX XXXXXXXX XXXXXX XXXXXXXXX XXXXXX XXXXXXXX XXX XXXXXXXX XXXXXXXXXXXXXXXXXXX XXXXXXXX XXXXXXXXX XX XXXXXXXX XXXXXXXXXXX XXXXXXXX XXXXXXXXXX XXXXXXXXXXX XXXXXXXX XXXXXX XXXXXXXX XXXXXXXXXXXX

46 It turns out that style matters in programming for the same reason that it matters in writing. It makes for better reading. - Douglas Crockford

47 two competing rules for structuring code in C-style languages

48 Compiler Human { } { } + whitespace

49 what if?

50 Compiler Human whitespace whitespace

51 xxx { } xxx { } no braces no problem

52 There should be one - and preferably only one - obvious way to do it. - the Zen of Python

53 let mycleverfunction x y z = let localvar = anothercleverfunction x y if localvar.issomething(z, MY_CONSTANT) then dosomething localvar localvar.getsomething()

54 XXX XXXXXXXXXXXXXXXX X X X XXX XXXXXXXX XXXXXXXXXXXXXXXXXXXX X X XX XXXXXXXX XXXXXXXXXXX X XXXXXXXXXX XXXX XXXXXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXXXXXX

55 You should do whatever possible to increase the productivity of individual programmers in terms of the expressive power of the code they write. Less code to do the same thing (and possibly better). Less programmers to hire. Less organizational communication costs.

56 Lego Naming

57 naming is HARD

58 There are only two hard things in Computer Science: cache invalidation and naming things. - Phil Karlton

59 Names are the one and only tool you have to explain what a variable does in every place it appears, without having to scatter comments everywhere. - Mike Mahemoff

60 Lego Naming Gluing common words together in an attempt to create meaning.

61 Remove Strategy Controller Proxy Factory Object Exception Do Check Enable Create Service Process Add Disable Set Update Get Validate

62 see

63 this is not naming

64 this is not naming this is labelling

65

66

67

68 naming is HARD

69 anonymous functions aka lambdas

70 fewer things to name

71 words > Array.map (fun x -> x.count) > Array.reduce (+)

72 smaller scope shorter names

73

74 "The length of a name should be related to the length of the scope. You can use very short variable names for tiny scopes, but for big scopes you should use longer names. Variable names like i and j are just fine if their scope is five lines long." - Robert C. Martin

75 tuples + pattern matching fewer abstractions fewer things to name

76 words > Seq.groupBy id > Seq.map (fun (word, gr) -> word, Seq.length gr) > Seq.iter (fun (word, len) -> printfn %s - %d word len)

77 words > Seq.groupBy id > Seq.map (fun (word, gr) -> word, Seq.length gr) > Seq.iter (fun (word, len) -> printfn %s - %d word len)

78 words > Seq.groupBy id > Seq.map (fun (word, gr) -> word, Seq.length gr) > Seq.iter (fun (word, len) -> printfn %s - %d word len)

79 words > Seq.groupBy id > Seq.map (fun (word, gr) -> word, Seq.length gr) > Seq.iter (fun (word, len) -> printfn %s - %d word len)

80 Lego Naming can also be the symptom of a failure to identify the right level of abstractions.

81 the RIGHT level of abstraction might be smaller than object

82 public interface ConditionChecker { bool CheckCondition(); }

83 public interface Condition { bool IsTrue(); }

84

85 type Condition = unit -> bool

86 source

87 ClassNotFoundException IllegalArgumentException IndexOutOfBoundsException NoSuchMethodException UnsupportedOperationException

88 ClassNotFound IllegalArgument IndexOutOfBounds NoSuchMethod UnsupportedOperation

89 ArithmeticException ArrayStoreException ClassCastException InstantiationException NullPointerException SecurityException

90 IntegerDivisionByZero IllegalArrayElementType CastToNonSubclass ClassCannotBeInstantiated NullDereferenced SecurityViolation

91 lightweight exception syntax

92 open System open System.IO exception InsufficientBytes

93 open System open System.IO exception InsufficientBytes what could this type represent?

94 Underabstraction

95

96

97 public Result DoSomething( int a, string b, string c, string d, DateTime e, DateTime f, string g, MyEnum h)

98 If you have a procedure with ten parameters, you probably missed some. - Alan Perlis

99 source

100 lightweight syntax for types and hierarchies

101 record

102 type Employee = { FirstName : string Surname : string Salary : int<pound> }

103 type Employee = { FirstName : string Surname : string Salary : int<pound> } immutable by default

104 let promote emp raise = let newsalary = emp.salary + raise { emp with Salary <- newsalary }

105 mutable state complects value and time

106 type Employee = { FirstName : string Surname : string Salary : int<pound> } unit-of-measure

107 [<Measure>] type Pound e.g. 42<Pound> 153<Pound>

108 10<Meter> / 2<Second> = 5<Meter/Second> 10<Meter> * 2<Second> = 20<Meter Second> 10<Meter> + 10<Meter> = 20<Meter> 10<Meter> * 10 = 100<Meter> 10<Meter> * 10<Meter> = 100<Meter 2 > 10<Meter> + 2<Second> // error 10<Meter> + 2 // error

109 10<Meter> / 2<Second> = 5<Meter/Second> 10<Meter> * 2<Second> = 20<Meter Second> 10<Meter> + 10<Meter> = 20<Meter> 10<Meter> * 10 = 100<Meter> 10<Meter> * 10<Meter> = 100<Meter 2 > 10<Meter> + 2<Second> // error 10<Meter> + 2 // error

110 discriminated unions

111 type PaymentMethod = Cash Cheque of ChequeNumber Card of CardType * CardNumber

112 Unencapsulated State

113

114

115 public class RecentlyUsedList { private List<string> items = new List<string>(); public List<string> Items { get { return items; } } }

116 immutability

117 type RecentlyUsedList (?items) = let items = defaultarg items [ ] member this.items = Array.ofList items member this.count = List.length items member this.add newitem = newitem::(items > List.filter ((<>) newitem)) > RecentlyUsedList

118 Affordance an affordance is a quality of an object, or an environment, which allows an individual to perform an action. For example, a knob affords twisting, and perhaps pushing, whilst a cord affords pulling.

119 source

120 your abstractions should afford right behaviour, whilst make it impossible to do the wrong thing

121 Make illegal states unrepresentable - Yaron Minsky

122 discriminated unions

123 type PaymentMethod = Cash Cheque of ChequeNumber Card of CardType * CardNumber finite, closed set of valid states ONLY

124 closed hierarchy

125 no Nulls

126 match paymentmethod with Cash -> Cheque chequenum -> Card (cardtype, cardnum) ->

127 Noisy Code Visual Dishonesty Lego Naming Underabstraction Unencapsulated State Getters and Setters Uncohesive Tests

128 Practice does not make perfect. Only perfect practice makes perfect. - Vince Lombardi

129 Perfection is not attainable. But if we chase perfection, we can catch excellence. - Vince Lombardi

130 Programming languages have a devious influence: they shape our thinking habits. - Edsger W. Dijkstra

131 One of the most disastrous thing we can learn is the first programming language, even if it's a good programming language. - Alan Kay

132 I m not a great programmer; I m just a good programmer with great habits. - Kent Beck

133 Explicit is better than implicit. - the Zen of Python

134 Simple is better than Complex. Complex is better than Complicated. - the Zen of Python

135 Special cases aren't special enough to break the rules. - the Zen of Python

136 Special cases aren't special enough to break the rules. Although practicality beats purity. - the Zen of Python

137 If the implementation is hard to explain, it's a bad idea. - the Zen of Python

138

139 Thu 12 October :30 21:30 BST Space Ape Games 100 New Oxford Street London WC1A 1HB

140 @theburningmonk theburningmonk.com github.com/theburningmonk