From e72dfafd440054ccdf6c8034112e36cd0156c1fb Mon Sep 17 00:00:00 2001 From: Deryew <40446717+Deryew@users.noreply.github.com> Date: Mon, 30 Jul 2018 10:53:02 +0800 Subject: [PATCH] Fixed some grammar errors on docs Fixed grammar errors and some sentences to make it easier to understand --- docs/ThrowTheSwitchCodingStandard.md | 19 +++++++++---------- docs/UnityAssertionsReference.md | 4 ++-- docs/UnityConfigurationGuide.md | 8 ++++---- docs/UnityGettingStartedGuide.md | 4 ++-- docs/UnityHelperScriptsGuide.md | 4 ++-- 5 files changed, 19 insertions(+), 20 deletions(-) diff --git a/docs/ThrowTheSwitchCodingStandard.md b/docs/ThrowTheSwitchCodingStandard.md index a85adef..bf4c099 100644 --- a/docs/ThrowTheSwitchCodingStandard.md +++ b/docs/ThrowTheSwitchCodingStandard.md @@ -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? diff --git a/docs/UnityAssertionsReference.md b/docs/UnityAssertionsReference.md index d569e76..eb855f3 100644 --- a/docs/UnityAssertionsReference.md +++ b/docs/UnityAssertionsReference.md @@ -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! diff --git a/docs/UnityConfigurationGuide.md b/docs/UnityConfigurationGuide.md index 1b69828..dace20c 100644 --- a/docs/UnityConfigurationGuide.md +++ b/docs/UnityConfigurationGuide.md @@ -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. diff --git a/docs/UnityGettingStartedGuide.md b/docs/UnityGettingStartedGuide.md index 81d0398..5e4427c 100644 --- a/docs/UnityGettingStartedGuide.md +++ b/docs/UnityGettingStartedGuide.md @@ -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. diff --git a/docs/UnityHelperScriptsGuide.md b/docs/UnityHelperScriptsGuide.md index 8b0df1b..12d68d3 100644 --- a/docs/UnityHelperScriptsGuide.md +++ b/docs/UnityHelperScriptsGuide.md @@ -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)