Lines Matching full:and

6 Good development is like gardening, and codebases are our gardens. Tend to them
8 A little weeding here and there goes a long way; don't wait until things have
12 good. But appreciate beauty when you see it - and let people know.
16 A little organizing here and there goes a long way.
20 Good code is readable code, where the structure is simple and leaves nowhere
25 happen (and will have unpredictable or undefined behaviour if it does), or
26 you're not sure if it can happen and not sure how to handle it yet - make it a
30 assertions need to be handled and turned into checks with error paths, and
40 Good assertions drastically and dramatically reduce the amount of testing
46 Good invariants and assertions will hold everywhere in your codebase. This
51 A good assertion checks something that the compiler could check for us, and
55 can still incorporate that kind of thinking into our code and document the
60 Looking for ways to make your assertions simpler - and higher level - will
61 often nudge you towards making the entire system simpler and more robust.
63 Good code is code where you can poke around and see what it's doing -
66 Whenever we're debugging, and the solution isn't immediately obvious, if the
70 We have the tools to make anything visible at runtime, efficiently - RCU and
76 Pretty printers are wonderful, because they compose and you can use them
79 exist) and much more informative. And they can be used from sysfs/debugfs, as
82 Runtime info and debugging tools should come with clear descriptions and
83 labels, and good structure - we don't want files with a list of bare integers,
84 like in procfs. Part of the job of the debugging tools is to educate users and
93 and then we have to run the troublesome workload, and then we have to sift
95 something, and if it's intermittent it may not even be possible.
97 The humble counter is an incredibly useful tool. They're cheap and simple to
98 use, and many complicated internal operations with lots of things that can
107 messages, new debug tools, and do those first. Look for ways to make the system
111 Fix all that first, and then the original bug last - even if that means keeping
112 a user waiting. They'll thank you in the long run, and when they understand
118 Users notice all sorts of interesting things, and by just talking to them and
121 Spend time doing support and helpdesk stuff. Don't just write code - code isn't
125 and perhaps even your documentation, too. Like anything else in life, the more
126 time you spend at it the better you'll get, and you the developer are the
127 person most able to improve the tools to make debugging quick and easy.
129 Be wary of how you take on and commit to big projects. Don't let development
135 Nobody writes all perfect code that all gets shipped, and you'll be much more
136 productive in the long run if you notice this early and shift to something
137 else. The experience gained and lessons learned will be valuable for all the
142 us to make existing code more general, more flexible, more multipurpose and
157 will be useful, and make the big projects easier.
163 reading lots of code and looking for common patterns and issues. Don't be
164 afraid to throw things away and do something simpler.
171 The most important tools (besides the compiler and our text editor) are the
173 essential for working productively. We learn, gain experience, and discover the
174 errors in our thinking by running our code and seeing what happens. If your
178 Put effort into your documentation, commit messages, and code comments - but
185 organized into small clean and tidy modules, with clear and descriptive names
186 for functions and variable, where every line of code has a clear purpose.