English | MP4 | AVC 1280×720 | AAC 44KHz 2ch | 80 Lessons (10h 38m) | 1.67 GB
Practical techniques for writing code that is robust, reliable, and easy for team members to understand and adapt.
In Good Code, Bad Code you’ll learn how to:
- Think about code like an effective software engineer
- Write functions that read like well-structured sentences
- Ensure code is reliable and bug-free
- Effectively unit test code
- Identify code that can cause problems and improve it
- Write code that is reusable and adaptable to new requirements
- Improve your medium and long-term productivity
- Save yourself and your team time
The difference between good code or bad code often comes down to how you apply the established practices of the software development community. In Good Code, Bad Code you’ll learn how to boost your productivity and effectiveness with code development insights normally only learned through careful mentorship and hundreds of code reviews.
Software development is a team sport. For an application to succeed, your code needs to be robust and easy for others to understand, maintain, and adapt. Whether you’re working on an enterprise team, contributing to an open source project, or bootstrapping a startup, it pays to know the difference between good code and bad code.
Good Code, Bad Code is a clear, practical introduction to writing code that’s a snap to read, apply, and remember. With dozens of instantly-useful techniques, you’ll find coding insights that normally take years of experience to master. In this fast-paced guide, Google software engineer Tom Long teaches you a host of rules to apply, along with advice on when to break them!
A wealth of knowledge to sharpen your toolset.
Joe Ivans, California Regional MLS
Table of Contents
1 In theory
2 Code quality
3 The goals of code quality
4 The pillars of code quality
5 Make code hard to misuse
6 Make code testable and test it properly
7 Layers of abstraction
8 Why create layers of abstraction
9 Layers of code
10 Classes, Part 1
11 Classes, Part 2
12 Interfaces
13 When layers get too thin
14 Other engineers and code contracts
15 How will others figure out how to use your code
16 Code contracts
17 Don’t rely too much on small print
18 Checks and assertions
19 Errors
20 Robustness vs. failure
21 Don’t hide errors
22 Ways of signaling errors
23 Explicit – Nullable return type
24 Implicit – Promise or future
25 Signaling errors that a caller might want to recover from
26 Arguments for using explicit techniques
27 In practice
28 Make code readable
29 Use comments appropriately
30 Don’t fixate on number of lines of code
31 Stick to a consistent coding style
32 Make function calls readable
33 Avoid using unexplained values
34 Use anonymous functions appropriately
35 Solution – Break large anonymous functions into named functions
36 Avoid surprises
37 Solution – Return null, an optional, or an error
38 Use the null object pattern appropriately
39 More complicated null objects can cause surprises
40 Avoid causing unexpected side effects
41 Beware of mutating input parameters
42 Avoid writing misleading functions
43 Future-proof enum handling
44 Beware of the default case
45 Make code hard to misuse
46 Solution – Set values only at construction time
47 Consider making things deeply immutable
48 Avoid overly general data types
49 Dealing with time
50 Have single sources of truth for data
51 Have single sources of truth for logic
52 Make code modular
53 Design code with dependency injection in mind
54 Beware of class inheritance
55 Solution – Use composition
56 Classes should care about themselves
57 Beware of leaking implementation details in return types
58 Beware of leaking implementation details in exceptions
59 Make code reusable and generalizable
60 Beware of global state
61 Use default return values appropriately
62 Keep function parameters focused
63 Unit testing
64 Unit testing principles
65 What makes a good unit test
66 Well-explained failures
67 Focus on the public API but don’t ignore important behaviors
68 Test doubles
69 Mocks
70 Mocks and stubs can be problematic
71 Fakes
72 Pick and choose from testing philosophies
73 Unit testing practices
74 Avoid making things visible just for testing
75 Test one behavior at a time
76 Use shared test setup appropriately
77 Shared configuration can be problematic
78 Use appropriate assertion matchers
79 Use dependency injection to aid testability
80 Appendix B. Null safety and optionals
Resolve the captcha to access the links!