A Philosophy of Software Design by Ousterhout, John -- Read -- Imperial Library of Trantor

Index

Title Page Copyright Contents Preface 1 Introduction

1.1 How to use this book

2 The Nature of Complexity

2.1 Complexity defined 2.2 Symptoms of complexity 2.3 Causes of complexity 2.4 Complexity is incremental 2.5 Conclusion

3 Working Code Isn’t Enough

3.1 Tactical programming 3.2 Strategic programming 3.3 How much to invest? 3.4 Startups and investment 3.5 Conclusion

4 Modules Should Be Deep

4.1 Modular design 4.2 What’s in an interface? 4.3 Abstractions 4.4 Deep modules 4.5 Shallow modules 4.6 Classitis 4.7 Examples: Java and Unix I/O 4.8 Conclusion

5 Information Hiding (and Leakage)

5.1 Information hiding 5.2 Information leakage 5.3 Temporal decomposition 5.4 Example: HTTP server 5.5 Example: too many classes 5.6 Example: HTTP parameter handling 5.7 Example: defaults in HTTP responses 5.8 Information hiding within a class 5.9 Taking it too far 5.10 Conclusion

6 General-Purpose Modules are Deeper

6.1 Make classes somewhat general-purpose 6.2 Example: storing text for an editor 6.3 A more general-purpose API 6.4 Generality leads to better information hiding 6.5 Questions to ask yourself 6.6 Conclusion

7 Different Layer, Different Abstraction

7.1 Pass-through methods 7.2 When is interface duplication OK? 7.3 Decorators 7.4 Interface versus implementation 7.5 Pass-through variables 7.6 Conclusion

8 Pull Complexity Downwards

8.1 Example: editor text class 8.2 Example: configuration parameters 8.3 Taking it too far 8.4 Conclusion

9 Better Together Or Better Apart?

9.1 Bring together if information is shared 9.2 Bring together if it will simplify the interface 9.3 Bring together to eliminate duplication 9.4 Separate general-purpose and special-purpose code 9.5 Example: insertion cursor and selection 9.6 Example: separate class for logging 9.7 Example: editor undo mechanism 9.8 Splitting and joining methods 9.9 Conclusion

10 Define Errors Out Of Existence

10.1 Why exceptions add complexity 10.2 Too many exceptions 10.3 Define errors out of existence 10.4 Example: file deletion in Windows 10.5 Example: Java substring method 10.6 Mask exceptions 10.7 Exception aggregation 10.8 Just crash? 10.9 Design special cases out of existence 10.10 Taking it too far 10.11 Conclusion

11 Design it Twice 12 Why Write Comments? The Four Excuses

12.1 Good code is self-documenting 12.2 I don’t have time to write comments 12.3 Comments get out of date and become misleading 12.4 All the comments I have seen are worthless 12.5 Benefits of well-written comments

13 Comments Should Describe Things that Aren’t Obvious from the Code

13.1 Pick conventions 13.2 Don’t repeat the code 13.3 Lower-level comments add precision 13.4 Higher-level comments enhance intuition 13.5 Interface documentation 13.6 Implementation comments: what and why, not how 13.7 Cross-module design decisions 13.8 Conclusion 13.9 Answers to questions on page 113

14 Choosing Names

14.1 Example: bad names cause bugs 14.2 Create an image 14.3 Names should be precise 14.4 Use names consistently 14.5 A different opinion: Go style guide 14.6 Conclusion

15 Write The Comments First

15.1 Delayed comments are bad comments 15.2 Write the comments first 15.3 Comments are a design tool 15.4 Early comments are fun comments 15.5 Are early comments expensive? 15.6 Conclusion

16 Modifying Existing Code

16.1 Stay strategic 16.2 Maintaining comments: keep the comments near the code 16.3 Comments belong in the code, not the commit log 16.4 Maintaining comments: avoid duplication 16.5 Maintaining comments: check the diffs 16.6 Higher-level comments are easier to maintain

17 Consistency

17.1 Examples of consistency 17.2 Ensuring consistency 17.3 Taking it too far 17.4 Conclusion

18 Code Should be Obvious

18.1 Things that make code more obvious 18.2 Things that make code less obvious 18.3 Conclusion

19 Software Trends

19.1 Object-oriented programming and inheritance 19.2 Agile development 19.3 Unit tests 19.4 Test-driven development 19.5 Design patterns 19.6 Getters and setters 19.7 Conclusion

20 Designing for Performance

20.1 How to think about performance 20.2 Measure before modifying 20.3 Design around the critical path 20.4 An example: RAMCloud Buffers 20.5 Conclusion

21 Conclusion Index Summary of Design Principles Summary of Red Flags About the Author