mirror of
https://github.com/ThrowTheSwitch/Unity.git
synced 2025-06-24 00:28:35 +08:00
Merge pull request #341 from Deryew/master
Fixed some grammar errors on docs (Thanks @Deryew !)
This commit is contained in:
@ -1,4 +1,4 @@
|
||||
# ThrowTheSwitch.org Coding Standard
|
||||
# ThrowTheSwitch.org Coding Standard
|
||||
|
||||
Hi. Welcome to the coding standard for ThrowTheSwitch.org. For the most part,
|
||||
we try to follow these standards to unify our contributors' code into a cohesive
|
||||
@ -11,7 +11,7 @@ and we'll try to be polite when we notice yours.
|
||||
|
||||
## Why Have A Coding Standard?
|
||||
|
||||
Being consistent makes code easier to understand. We've made an attempt to keep
|
||||
Being consistent makes code easier to understand. We've tried to keep
|
||||
our standard simple because we also believe that we can only expect someone to
|
||||
follow something that is understandable. Please do your best.
|
||||
|
||||
@ -51,11 +51,11 @@ much as they can, but give the user the power to override it when it's wrong.
|
||||
|
||||
Let's talk about naming things. Programming is all about naming things. We name
|
||||
files, functions, variables, and so much more. While we're not always going to
|
||||
find the best name for something, we actually put quite a bit of effort into
|
||||
find the best name for something, we actually put a bit of effort into
|
||||
finding *What Something WANTS to be Called*™.
|
||||
|
||||
When naming things, we more or less follow this hierarchy, the first being the
|
||||
most important to us (but we do all four whenever possible):
|
||||
When naming things, we follow this hierarchy, the first being the
|
||||
most important to us (but we do all four when possible):
|
||||
1. Readable
|
||||
2. Descriptive
|
||||
3. Consistent
|
||||
@ -74,7 +74,7 @@ abbreviations (sticking to ones we feel are common).
|
||||
We like descriptive names for things, especially functions and variables.
|
||||
Finding the right name for something is an important endeavor. You might notice
|
||||
from poking around our code that this often results in names that are a little
|
||||
longer than the average. Guilty. We're okay with a tiny bit more typing if it
|
||||
longer than the average. Guilty. We're okay with a bit more typing if it
|
||||
means our code is easier to understand.
|
||||
|
||||
There are two exceptions to this rule that we also stick to as religiously as
|
||||
@ -82,8 +82,7 @@ possible:
|
||||
|
||||
First, while we realize hungarian notation (and similar systems for encoding
|
||||
type information into variable names) is providing a more descriptive name, we
|
||||
feel that (for the average developer) it takes away from readability and
|
||||
therefore is to be avoided.
|
||||
feel that (for the average developer) it takes away from readability and is to be avoided.
|
||||
|
||||
Second, loop counters and other local throw-away variables often have a purpose
|
||||
which is obvious. There's no need, therefore, to get carried away with complex
|
||||
@ -128,7 +127,7 @@ the same. It will only hurt a little. We promise.
|
||||
#### Whitespace
|
||||
|
||||
Our C-style is to use spaces and to use 4 of them per indent level. It's a nice
|
||||
power-of-2 number that looks decent on a wide screen. We have no more reason
|
||||
power-of-2 number that looks decent on a wide-screen. We have no more reason
|
||||
than that. We break that rule when we have lines that wrap (macros or function
|
||||
arguments or whatnot). When that happens, we like to indent further to line
|
||||
things up in nice tidy columns.
|
||||
@ -200,7 +199,7 @@ that happens, we like to indent further to line things up in nice tidy columns.
|
||||
|
||||
## Documentation
|
||||
|
||||
Egad. Really? We use markdown and we like pdf files because they can be made to
|
||||
Egad. Really? We use mark down and we like pdf files because they can be made to
|
||||
look nice while still being portable. Good enough?
|
||||
|
||||
|
||||
|
@ -80,7 +80,7 @@ marked as an optional parameter because some assertions only need a single
|
||||
"actual" parameter (e.g. null check).
|
||||
"Size/count" refers to string lengths, number of array elements, etc.
|
||||
|
||||
Many of Unity's assertions are apparent duplications in that the same data type
|
||||
Many of Unity's assertions are clear duplications in that the same data type
|
||||
is handled by several assertions. The differences among these are in how failure
|
||||
messages are presented. For instance, a `_HEX` variant of an assertion prints
|
||||
the expected and actual values of that assertion formatted as hexadecimal.
|
||||
@ -703,7 +703,7 @@ point value.
|
||||
|
||||
So what happens when it's zero? Zero - even more than other floating point
|
||||
values - can be represented many different ways. It doesn't matter if you have
|
||||
0 x 20or 0 x 263.It's still zero, right? Luckily, if you
|
||||
0 x 20 or 0 x 263.It's still zero, right? Luckily, if you
|
||||
subtract these values from each other, they will always produce a difference of
|
||||
zero, which will still fall between 0 plus or minus a delta of 0. So it still
|
||||
works!
|
||||
|
@ -1,4 +1,4 @@
|
||||
# Unity Configuration Guide
|
||||
# Unity Configuration Guide
|
||||
|
||||
## C Standards, Compilers and Microcontrollers
|
||||
|
||||
@ -19,7 +19,7 @@ definitions. A couple are macros with arguments. They live inside the
|
||||
unity_internals.h header file. We don't necessarily recommend opening that file
|
||||
unless you really need to. That file is proof that a cross-platform library is
|
||||
challenging to build. From a more positive perspective, it is also proof that a
|
||||
great deal of complexity can be centralized primarily to one place in order to
|
||||
great deal of complexity can be centralized primarily to one place to
|
||||
provide a more consistent and simple experience elsewhere.
|
||||
|
||||
|
||||
@ -58,7 +58,7 @@ sizes. It starts off by trying to do it automatically.
|
||||
##### `UNITY_EXCLUDE_STDINT_H`
|
||||
|
||||
The first thing that Unity does to guess your types is check `stdint.h`.
|
||||
This file includes defines like `UINT_MAX` that Unity can make use of to
|
||||
This file includes defines like `UINT_MAX` that Unity can use to
|
||||
learn a lot about your system. It's possible you don't want it to do this
|
||||
(um. why not?) or (more likely) it's possible that your system doesn't
|
||||
support `stdint.h`. If that's the case, you're going to want to define this.
|
||||
@ -222,7 +222,7 @@ In addition to the options listed above, there are a number of other options
|
||||
which will come in handy to customize Unity's behavior for your specific
|
||||
toolchain. It is possible that you may not need to touch any of these... but
|
||||
certain platforms, particularly those running in simulators, may need to jump
|
||||
through extra hoops to operate properly. These macros will help in those
|
||||
through extra hoops to run properly. These macros will help in those
|
||||
situations.
|
||||
|
||||
|
||||
|
@ -11,7 +11,7 @@ functional. The core Unity test framework is three files: a single C file and a
|
||||
couple header files. These team up to provide functions and macros to make
|
||||
testing easier.
|
||||
|
||||
Unity was designed to be cross platform. It works hard to stick with C standards
|
||||
Unity was designed to be cross-platform. It works hard to stick with C standards
|
||||
while still providing support for the many embedded C compilers that bend the
|
||||
rules. Unity has been used with many compilers, including GCC, IAR, Clang,
|
||||
Green Hills, Microchip, and MS Visual Studio. It's not much work to get it to
|
||||
@ -149,7 +149,7 @@ int main(void) {
|
||||
}
|
||||
```
|
||||
|
||||
It's possible that you will require more customization than this, eventually.
|
||||
It's possible that you will need more customization than this, eventually.
|
||||
For that sort of thing, you're going to want to look at the configuration guide.
|
||||
This should be enough to get you going, though.
|
||||
|
||||
|
@ -3,7 +3,7 @@
|
||||
## With a Little Help From Our Friends
|
||||
|
||||
Sometimes what it takes to be a really efficient C programmer is a little non-C.
|
||||
The Unity project includes a couple Ruby scripts for making your life just a tad
|
||||
The Unity project includes a couple of Ruby scripts for making your life just a tad
|
||||
easier. They are completely optional. If you choose to use them, you'll need a
|
||||
copy of Ruby, of course. Just install whatever the latest version is, and it is
|
||||
likely to work. You can find Ruby at [ruby-lang.org](https://ruby-labg.org/).
|
||||
@ -105,7 +105,7 @@ UnityTestRunnerGenerator.new.run(testfile, runner_name, options)
|
||||
|
||||
If you have multiple files to generate in a build script (such as a Rakefile),
|
||||
you might want to instantiate a generator object with your options and call it
|
||||
to generate each runner thereafter. Like thus:
|
||||
to generate each runner afterwards. Like thus:
|
||||
|
||||
```Ruby
|
||||
gen = UnityTestRunnerGenerator.new(options)
|
||||
|
Reference in New Issue
Block a user