Lines Matching refs:we

4 we try to follow these standards to unify our contributors' code into a cohesive
7 and we'll try to be polite when we notice yours.
15 our standard simple because we also believe that we can only expect someone to
21 Before we get into details on syntax, let's take a moment to talk about our
28 Our philosophy is "support every compiler we can". Most often, this means that
29 we aim for writing C code that is standards compliant (often C89... that seems
34 standard library functions. A lot of Unity is configurable and we have worked
40 compile to a particular location. It's just what we do, because we like
43 Speaking of having things Just Work™, that's our second philosophy. By that, we
44 mean that we do our best to have EVERY configuration option have a logical
46 you shouldn't need to configure very much... we try to make the tools guess as
53 files, functions, variables, and so much more. While we're not always going to
54 find the best name for something, we actually put a bit of effort into
57 When naming things, we follow this hierarchy, the first being the
58 most important to us (but we do all four when possible):
67 We want to read our code. This means we like names and flow that are more
69 abbreviations (sticking to ones we feel are common).
80 There are two exceptions to this rule that we also stick to as religiously as
83 First, while we realize hungarian notation (and similar systems for encoding
84 type information into variable names) is providing a more descriptive name, we
90 whatnot. We only break this rule when we see that more description could improve
96 We like consistency, but we're not really obsessed with it. We try to name our
104 Where ever it doesn't violate the above principles, we try to apply memorable
106 often we strive for descriptive AND unique... we like quirky names that stand
108 names in Ceedling and you'll get a good idea of what we are talking about here.
123 projects (and we hope that you do), then we ask if you do your best to follow
131 than that. We break that rule when we have lines that wrap (macros or function
132 arguments or whatnot). When that happens, we like to indent further to line
162         //Like so. Even if only one line, we use braces.
169 Do you know what we hate? Old-school C block comments. BUT, we're using them
170 anyway. As we mentioned, our goal is to support every compiler we can,
172 support old-school block comments. So that is what we're using. We apologize. We
187 more reason than that. We break that rule when we have lines that wrap. When
188 that happens, we like to indent further to line things up in nice tidy columns.
202 Egad. Really? We use mark down and we like pdf files because they can be made to