Lines Matching +full:out +full:- +full:functions

1 .. SPDX-License-Identifier: GPL-2.0
7 every day; look for little things that are out of place or in need of tidying.
9 spiraled out of control.
11 Things don't always have to be perfect - nitpicking often does more harm than
12 good. But appreciate beauty when you see it - and let people know.
26 you're not sure if it can happen and not sure how to handle it yet - make it a
33 expensive - but don't turn everything into a debug mode assertion, so that
34 we're not stuck debugging undefined behaviour should it turn out that you were
37 Assertions are documentation that can't go out of date. Good assertions are
41 required to shake out bugs.
52 elide - if we were working in a language with embedded correctness proofs that
56 invariants with runtime checks - much like the way people working in
60 Looking for ways to make your assertions simpler - and higher level - will
63 Good code is code where you can poke around and see what it's doing -
68 going on - fix that first.
70 We have the tools to make anything visible at runtime, efficiently - RCU and
73 The most important tool for introspection is the humble pretty printer - in
74 bcachefs, this means `*_to_text()` functions, which output to printbufs.
77 everywhere. Having functions to print whatever object you're working with will
83 labels, and good structure - we don't want files with a list of bare integers,
104 When debugging, try to get the most out of every bug you come across; don't
106 easier the next time around - introspection, new assertions, better error
111 Fix all that first, and then the original bug last - even if that means keeping
114 like to help - otherwise they wouldn't be reporting the bug in the first place.
121 Spend time doing support and helpdesk stuff. Don't just write code - code isn't
130 become product-manager focused. Often time an idea is a good one but needs to
131 wait for its proper time - but you won't know if it's the proper time for an
151 out.
160 often go astray - doing something because it seems like it'll be useful often
162 experience, or talking with people who have that experience - or from simply
175 time is being wasted because your tools are bad or too slow - don't accept it,
178 Put effort into your documentation, commit messages, and code comments - but
179 don't go overboard. A good commit message is wonderful - but if the information
186 for functions and variable, where every line of code has a clear purpose.