Lines Matching full:we

4 we try to follow these standards to unify our contributors' code into a cohesive
6 followed. We're not perfect. Please be polite where you notice these discrepancies
7 and we'll try to be polite when we notice yours.
14 Being consistent makes code easier to understand. We've made an attempt to keep
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
22 vision for these tools. We're C developers and embedded software developers.
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
45 default. We believe that if you're working with a simple compiler and target,
46 you shouldn't need to configure very much... we try to make the tools guess as
52 Let's talk about naming things. Programming is all about naming things. We name
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 quite a bit of effort into
57 When naming things, we more or less follow this hierarchy, the first being the
58 most important to us (but we do all four whenever possible):
67 We want to read our code. This means we like names and flow that are more
68 naturally read. We try to avoid double negatives. We try to avoid cryptic
69 abbreviations (sticking to ones we feel are common).
74 We like descriptive names for things, especially functions and variables.
77 longer than the average. Guilty. We're okay with a tiny bit more typing if it
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 naming. We find i, j, and k are better loop counters than loopCounterVar or
91 whatnot. We only break this rule when we see that more description could improve
97 We like consistency, but we're not really obsessed with it. We try to name our
105 Where ever it doesn't violate the above principles, we try to apply memorable
107 often we strive for descriptive AND unique... we like quirky names that stand
109 names in Ceedling and you'll get a good idea of what we are talking about here.
118 We don't really want to add to the style battles out there. Tabs or spaces?
123 We've decided on our own style preferences. If you'd like to contribute to these
124 projects (and we hope that you do), then we ask if you do your best to follow
125 the same. It will only hurt a little. We promise.
131 power-of-2 number that looks decent on a wide screen. We have no more reason
132 than that. We break that rule when we have lines that wrap (macros or function
133 arguments or whatnot). When that happens, we like to indent further to line
163         //Like so. Even if only one line, we use braces.
170 Do you know what we hate? Old-school C block comments. BUT, we're using them
171 anyway. As we mentioned, our goal is to support every compiler we can,
173 support old-school block comments. So that is what we're using. We apologize. We
181 one method! We'll keep it really brief!
187 nice power-of-2 number that really grooves with Ruby's compact style. We have no
188 more reason than that. We break that rule when we have lines that wrap. When
189 that happens, we like to indent further to line things up in nice tidy columns.
203 Egad. Really? We use markdown and we like pdf files because they can be made to