ITT 2016 - Kevlin Henney - Seven Ineffective Coding Habits of Many Programmers

Habits help you manage the complexity of code. You apply existing skill and knowledge automatically to the detail while focusing on the bigger picture. But because you acquire habits largely by imitation, and rarely question them, how do you know your habits are effective? Many of the habits that programmers have for naming, formatting, commenting and unit testing do not stand up as rational and practical on closer inspection. Kevlin Henney examines seven coding habits that are not as effective as programmers believe, and to suggest alternatives.

Transcript

1. Seven Ineffective Coding Habits of Many Programmers @KevlinHenney
5. / WordFriday
7. It turns out that style matters in programming for the same reason that it matters in writing. It makes for better reading.
9. Noisy Code
10. Signal-to-noise ratio (often abbreviated SNR or S/N) is a measure used in science and engineering that compares the level of a desired signal to the level of background noise. Signal-to-noise ratio is sometimes used informally to refer to the ratio of useful information to false or irrelevant data in a conversation or exchange. http://en.wikipedia.org/wiki/Signal_to_noise_ratio
11. To be, or not to be: that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? William Shakespeare Hamlet
12. Continuing existence or cessation of existence: those are the scenarios. Is it more empowering mentally to work towards an accommodation of the downsizings and negative outcomes of adversarial circumstance, or would it be a greater enhancement of the bottom line to move forwards to a challenge to our current difficulties, and, by making a commitment to opposition, to effect their demise? Tom Burton Long Words Bother Me
13. public class RecentlyUsedList { private List<string> items; public RecentlyUsedList() { items = new List<string>(); } public void Add(string newItem) { if (items.Contains(newItem)) { int position = items.IndexOf(newItem); string existingItem = items[position]; items.RemoveAt(position); items.Insert(0, existingItem); } else { items.Insert(0, newItem); } } public int Count { get { int size = items.Count; return size; } } public string this[int index] { get { int position = 0; foreach (string item in items) { if (position == index) return item; ++position; } throw new ArgumentOutOfRangeException(); } } }
14. public class RecentlyUsedList { private List<string> items; public RecentlyUsedList() { items = new List<string>(); } public void Add(string newItem) { if (items.Contains(newItem)) { int position = items.IndexOf(newItem); string existingItem = list[position]; items.RemoveAt(position); items.Insert(0, existingItem); } else { items.Insert(0, newItem); } } public int Count { get { int size = items.Count; return size; } } public string this[int index] { get { int position = 0; foreach (string value in items) { if (position == index) return value; ++position; } throw new ArgumentOutOfRangeException(); } } } public class RecentlyUsedList { private List<string> items = new List<string>(); public void Add(string newItem) { items.Remove(newItem); items.Add(newItem); } public int Count { get { return items.Count; } } public string this[int index] { get { return items[Count - index - 1]; } } }
17. Comments A delicate matter, requiring taste and judgement. I tend to err on the side of eliminating comments, for several reasons. First, if the code is clear, and uses good type names and variable names, it should explain itself. Second, comments aren't checked by the compiler, so there is no guarantee they're right, especially after the code is modified. A misleading comment can be very confusing. Third, the issue of typography: comments clutter code. Rob Pike, "Notes on Programming in C"
18. There is a famously bad comment style: i=i+1; /* Add one to i */ and there are worse ways to do it: /********************************** * * * Add one to i * * * **********************************/ i=i+1; Don't laugh now, wait until you see it in real life. Rob Pike, "Notes on Programming in C"
19. A common fallacy is to assume authors of incomprehensible code will somehow be able to express themselves lucidly and clearly in comments. Kevlin Henney https://twitter.com/KevlinHenney/status/381021802941906944
21. Unsustainable Spacing
22. To be, or not to be: that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? William Shakespeare Hamlet
23. Continuing existence or cessation of existence: those are the scenarios. Is it more empowering mentally to work towards an accommodation of the downsizings and negative outcomes of adversarial circumstance, or would it be a greater enhancement of the bottom line to move forwards to a challenge to our current difficulties, and, by making a commitment to opposition, to effect their demise? Tom Burton Long Words Bother Me
24. Continuing existence or cessation of existence: those are the more empowe to work towa accommodati downsizings outcomes of circumstance a greater enh the bottom li forwards to a our current d by making a opposition, t demise?
25. How many programmers lay out their code Column 80
26. How people read
27. To answer the question "What is clean design?" most succinctly: a clean design is one that supports visual thinking so people can meet their informational needs with a minimum of conscious effort. Daniel Higginbotham ∙ "Clean Up Your Mess — A Guide to Visual Design for Everyone" ∙ http://www.visualmess.com/
28. 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 ∙ "Clean Up Your Mess — A Guide to Visual Design for Everyone" ∙ http://www.visualmess.com/
29. 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 ∙ "Clean Up Your Mess — A Guide to Visual Design for Everyone" ∙ http://www.visualmess.com/
30. public int howNotToLayoutAMethodHeader(int firstArgument, String secondArgument) public int ensureArgumentsAreAlignedLikeThis( int firstArgument, String secondArgument) public int orEnsureArgumentsAreGroupedLikeThis( int firstArgument, String secondArgument) public int butNotAlignedLikeThis(int firstArgument, String secondArgument)
31. int doNotFormat = likeThis(someArgumentOrExpression, anotherArgumentOrExpression); int insteadFormat = somethingLikeThis( someArgumentOrExpression, anotherArgumentOrExpression); int orFormat = somethingLikeThis( someArgumentOrExpression, anotherArgumentOrExpression);
32. int asItIs = unstable(someArgumentOrExpression, anotherArgumentOrExpression); int butThisIs = stable( someArgumentOrExpression, anotherArgumentOrExpression); int andThisIs = stable( someArgumentOrExpression, anotherArgumentOrExpression);
33. public ResultType arbitraryMethodName(FirstArgumentType firs SecondArgumentType sec ThirdArgumentType thir LocalVariableType localVariable = method(firstArgument, secondArgument) if (localVariable.isSomething(thirdArgument, SOME_SHOUTY_CONSTANT)) { doSomethingWith(localVariable); } return localVariable.getSomething(); }
34. public ResultType arbitraryMethodName( FirstArgumentType firstArgument, SecondArgumentType secondArgument, ThirdArgumentType thirdArgument) { LocalVariableType localVariable = method(firstArgument, secondArgument); if (localVariable.isSomething( thirdArgument, SOME_SHOUTY_CONSTANT)) { doSomething(localVariable); } return localVariable.getSomething(); }
35. XXXXXX XXXXXXXXXX XXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXX XXXXXXXXXXXXXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXXXXXX XXXXXXXXXXXXX XXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXXX XX XXXXXXXXXXXXX XXXXXXXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXX XXXXXXXXXXXXX XXXXXX XXXXXXXXXXXXX XXXXXXXXXXXX
36. public ResultType arbitraryMethodName( FirstArgumentType firstArgument, SecondArgumentType secondArgument, ThirdArgumentType thirdArgument) { LocalVariableType localVariable = method(firstArgument, secondArgument); if (localVariable.isSomething( thirdArgument, SOME_SHOUTY_CONSTANT)) { doSomething(localVariable); } return localVariable.getSomething(); }
37. XXXXXX XXXXXXXXXX XXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXX XXXXXXXXXXXXXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXXXXXX XXXXXXXXXXXXX XXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXXX XX XXXXXXXXXXXXX XXXXXXXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXX XXXXXXXXXXXXX XXXXXX XXXXXXXXXXXXX XXXXXXXXXXXX
38. public ResultType arbitraryMethodName( FirstArgumentType firstArgument, SecondArgumentType secondArgument, ThirdArgumentType thirdArgument) { LocalVariableType localVariable = method(firstArgument, secondArgument); if (localVariable.isSomething( thirdArgument, SOME_SHOUTY_CONSTANT)) { doSomething(localVariable); } return localVariable.getSomething(); }
39. XXXXXX XXXXXXXXXX XXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXX XXXXXXXXXXXXXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXXXXXX XXXXXXXXXXXXX XXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXXX XX XXXXXXXXXXXXX XXXXXXXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXX XXXXXXXXXXXXX XXXXXX XXXXXXXXXXXXX XXXXXXXXXXXX
41. Lego Naming
42. Agglutination is a process in linguistic morphology derivation in which complex words are formed by stringing together morphemes, each with a single grammatical or semantic meaning. Languages that use agglutination widely are called agglutinative languages. http://en.wikipedia.org/wiki/Agglutination
43. pneumonoultramicroscopicsilicovolcanoconiosis Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz fylkestrafikksikkerhetsutvalgssekretariatslederfunksjonene muvaffakiyetsizleştiricileştiriveremeyebileceklerimizdenmişsinizcesine
44. http://www.bonkersworld.net/object-world/
45. http://www.bonkersworld.net/object-world/ OBJECT-ORIENTED VenetianBlind Door Television Picture Glass Sofa TelevisionRemoteControl Peephole
47. People will be using the words you choose in their conversation for the next 20 years. You want to be sure you do it right. Unfortunately, many people get all formal [...]. Just calling it what it is isn't enough.
48. public interface ConditionChecker { boolean checkCondition(); ... }
49. public interface Condition { boolean isTrue(); ... }
50. They have to tack on a flowery, computer science-y, impressive sounding, but ultimately meaningless word, like Object, Thing, Component, Part, Manager, Entity, or Item.
51. AccessViolationException ArgumentOutOfRangeException ArrayTypeMismatchException BadImageFormatException CannotUnloadAppDomainException EntryPointNotFoundException IndexOutOfRangeException InvalidOperationException OverflowException
52. AccessViolation ArgumentOutOfRange ArrayTypeMismatch BadImageFormat CannotUnloadAppDomain EntryPointNotFound IndexOutOfRange InvalidOperation Overflow
53. ArgumentException ArithmeticException ContextMarshalException FieldAccessException FormatException NullReferenceException ObjectDisposedException RankException TypeAccessException
54. Argument Arithmetic ContextMarshal FieldAccess Format NullReference ObjectDisposed Rank TypeAccess
55. InvalidArgument InvalidArithmeticOperation FailedContextMarshal InvalidFieldAccess InvalidFormat NullDereferenced OperationOnDisposedObject ArrayRankMismatch InvalidTypeAccess
56. Omit needless words. William Strunk and E B White The Elements of Style
58. Underabstraction
59. http://fragmental.tw/2009/04/29/tag-clouds-see-how-noisy-your-code-is/
60. http://fragmental.tw/2009/04/29/tag-clouds-see-how-noisy-your-code-is/
61. if (portfolioIdsByTraderId.get(trader.getId()) .containsKey(portfolio.getId())) { ... } Dan North, "Code in the Language of the Domain" 97 Things Every Programmer Should Know
62. if (trader.canView(portfolio)) { ... } Dan North, "Code in the Language of the Domain" 97 Things Every Programmer Should Know
64. Unencapsulated State
65. public class RecentlyUsedList { private List<string> items = new List<string>(); public List<string> Items { get { return items; } } public void Add(string newItem) { if(newItem == null) throw new ArgumentNullException(); items.Remove(newItem); items.Insert(0, newItem); } ... }
66. public class RecentlyUsedList { private List<string> items = new List<string>(); public List<string> Items { get { return items; } } public void Add(string newItem) { if(newItem == null) throw new ArgumentNullException(); items.Remove(newItem); items.Insert(0, newItem); } ... }
67. public class RecentlyUsedList { private List<string> items = new List<string>(); public List<string> Items { get { return items; } } public void Add(string newItem) { if(newItem == null) throw new ArgumentNullException(); items.Remove(newItem); items.Insert(0, newItem); } ... } var list = new RecentlyUsedList(); list.Add("Hello, World!"); Console.WriteLine(list.Items.Count); list.Items.Add("Hello, World!"); Console.WriteLine(list.Items.Count); list.Items.Add(null);
68. Don't ever invite a vampire into your house, you silly boy. It renders you powerless.
69. public class RecentlyUsedList { private IList<string> items = new List<string>(); public int Count { get { return items.Count; } } public string this[int index] { get { return items[index]; } } public void Add(string newItem) { if(newItem == null) throw new ArgumentNullException(); items.Remove(newItem); items.Insert(0, newItem); } ... }
70. public class RecentlyUsedList { private IList<string> items = new List<string>(); public int Count { get { return items.Count; } } public string this[int index] { get { return items[Count – index - 1]; } } public void Add(string newItem) { if(newItem == null) throw new ArgumentNullException(); items.Remove(newItem); items.Add(newItem); } ... }
72. Getters and Setters
77. public class Money implements ... { ... public int getUnits() ... public int getHundredths() ... public Currency getCurrency() ... ... public void setUnits(int newUnits) ... public void setHundredths(int newHundredths) ... public void setCurrency(Currency newCurrency) ... ... }
78. public final class Money implements ... { ... public int getUnits() ... public int getHundredths() ... public Currency getCurrency() ... ... }
79. Just because you have a getter, doesn't mean you should have a setter.
80. public final class Money implements ... { ... public int getUnits() ... public int getHundredths() ... public Currency getCurrency() ... ... }
81. public final class Money implements ... { ... public int units() ... public int hundredths() ... public Currency currency() ... ... }
82. "Get something" is an imperative with an expected side effect.
84. Uncohesive Tests
85. Everybody knows that TDD stands for Test Driven Development. However, people too often concentrate on the words "Test" and "Development" and don't consider what the word "Driven" really implies. For tests to drive development they must do more than just test that code performs its required functionality: they must clearly express that required functionality to the reader. That is, they must be clear specifications of the required functionality. Tests that are not written with their role as specifications in mind can be very confusing to read. Nat Pryce and Steve Freeman "Are Your Tests Really Driving Your Development?"
86. public class RecentlyUsedList { ... public RecentlyUsedList() ... public int Count { get... } public string this[int index] { get... } public void Add(string newItem) ... ... }
87. [TestFixture] public class RecentlyUsedListTests { [Test] public void TestConstructor() ... [Test] public void TestCountGet() ... [Test] public void TestIndexerGet() ... [Test] public void TestAdd() ... ... }
88. method test test test method method test test
89. namespace RecentlyUsedList_spec { [TestFixture] public class A_new_list { [Test] public void is_empty()  } [TestFixture] public class An_empty_list { [Test] public void retains_a_single_addition()  [Test] public void retains_unique_additions_in_stack_order()  } [TestFixture] public class A_non_empty_list { [Test] public void is_unchanged_when_head_item_is_readded()  [Test] public void moves_non_head_item_to_head_when_it_is_readded()  } [TestFixture] public class Any_list_rejects { [Test] public void addition_of_null_items()  [Test] public void indexing_past_its_end()  [Test] public void negative_indexing()  } }
90. namespace RecentlyUsedList_spec { [TestFixture] public class A_new_list { [Test] public void is_empty()  } [TestFixture] public class An_empty_list { [Test] public void retains_a_single_addition()  [Test] public void retains_unique_additions_in_stack_order()  } [TestFixture] public class A_non_empty_list { [Test] public void is_unchanged_when_head_item_is_readded()  [Test] public void moves_non_head_item_to_head_when_it_is_readded()  } [TestFixture] public class Any_list_rejects { [Test] public void addition_of_null_items()  [Test] public void indexing_past_its_end()  [Test] public void negative_indexing()  } }
91. So who should you be writing the tests for? For the person trying to understand your code. Good tests act as documentation for the code they are testing. They describe how the code works. For each usage scenario, the test(s):  Describe the context, starting point, or preconditions that must be satisfied  Illustrate how the software is invoked  Describe the expected results or postconditions to be verified Different usage scenarios will have slightly different versions of each of these. Gerard Meszaros "Write Tests for People"
92. namespace RecentlyUsedList_spec { [TestFixture] public class A_new_list ... [TestFixture] public class An_empty_list { [Test] public void retains_a_single_addition( [Values("Budapest", "Istanbul", "Bristol")] string addend) { var items = new RecentlyUsedList(); // Given... items.Add(addend); // When... Assert.AreEqual(1, items.Count); // Then... Assert.AreEqual(addend, list[0]); } [Test] public void retains_unique_additions_in_stack_order()  } [TestFixture] public class A_non_empty_list ... [TestFixture] public class Any_list_rejects ... }
93. A test case should be just that: it should correspond to a single case.
94. At some level the style becomes the substance.