docs: remove bad words from the documentation (#332)

Replaced following words with other relevant words so that gist of the sentence won't differ that much, from all the documentation within the project. Words include: just, simply, clearly, of course, easy, so, basically, technically, very, in order to, everyone knows. 

Also, some of the grammatical improvement has been checked and corrected.

related to #328

.jsdoc.json

@@ -1,3 +1,3 @@
 {
   "plugins": ["./node_modules/jsdoc-escape-at"]
-}
+}

CONTRIBUTING.md

@@ -42,15 +42,15 @@ We use ESLint on the code to ensure a consistent style. Any new code committed m
 ### Commit Rules
 We follow [conventional commits'](https://www.conventionalcommits.org/en/v1.0.0-beta.2/#specification) specification.
 
-Please follow the spec in order to have a successful commit.
+Please follow the spec to have a successful commit.
 
 ## What should be included?
 
 Anything that contributes to the idea of creating cross-platform styles.
 
 ### What transforms/transform groups/formats should be included?
 
-If it has a generic and flexible enough use-case, it can be included. We would like to keep this type of code to a minimum because we don't want to be a swiss army knife that does everything out of the box. Instead, we want to focus on core tasks that are useful to the largest number of projects. The spirit of this framework is to allow flexibility and modularity so that anyone can fit it to their needs. This is why you can write your own transforms, and formats with the register methods.
+If it has a generic and flexible enough use-case, it can be included. We would like to keep this type of code to a minimum because we don't want to be a swiss army knife that does everything out of the box. Instead, we want to focus on core tasks that are useful to the largest number of projects. The spirit of this framework is to allow flexibility and modularity which helps anyone fit it to their needs. This is why you can write your own transforms, and formats with the register methods.
 
 ### Where do things go?
 

README.md

@@ -38,7 +38,7 @@ If you want to use the CLI, you can install it globally via npm:
 $ npm install -g style-dictionary
 ```
 
-Or you can install it like a normal npm dependency. This is a build tool so you are most likely going to want to save it as a dev dependency:
+Or you can install it like a normal npm dependency. This is a build tool and you are most likely going to want to save it as a dev dependency:
 ```bash
 $ npm install -D style-dictionary
 ```
@@ -108,7 +108,7 @@ A style dictionary is a collection of style properties, key/value pairs that des
 ```
 
 ### config.json
-This tells the style dictionary build system how and what to build. The default file path is config.json in the root of the project, but you can name it whatever you want, just pass in the `--config` flag.
+This tells the style dictionary build system how and what to build. The default file path is config.json in the root of the project, but you can name it whatever you want, you can pass in the `--config` flag.
 ```json
 {
   "source": ["properties/**/*.json"],
@@ -160,9 +160,9 @@ This tells the style dictionary build system how and what to build. The default
 }
 ```
 
-Here we are creating some basic font size properties. The style definition size.font.small.value is "10px" for example.  The style definition size.font.base.value is automatically aliased to the value found in size.font.medium.value, so both of those resolve to "16px".
+Here we are creating some basic font size properties. The style definition size.font.small.value is "10px" for example. The style definition size.font.base.value is automatically aliased to the value found in size.font.medium.value and both of those resolve to "16px".
 
-Now what the style dictionary build system will do with this information is convert it to different formats so that you can use these values in any type of codebase. From this one file you can generate any number of files like:
+Now what the style dictionary build system will do with this information is convert it to different formats, enabling these values to be used in any type of codebase. From this one file you can generate any number of files like:
 
 ```scss
 $size-font-small: 10px;
@@ -229,7 +229,7 @@ While not exactly necessary, we feel this classification structure of style prop
 
  Structuring style properties in this manner gives us consistent naming and accessing of these properties. You don't need to remember if it is button_color_error or error_button_color, it is color_background_button_error!
 
- Technically, you can organize and name your style properties however you want, there are no restrictions. But we have a good amount of helpers if you do use this structure, like the 'attribute/cti' transform which adds attributes to the property of its CTI based on the path in the object. There are a lot of name transforms as well for when you want a flat structure like for Sass variables.
+ You can organize and name your style properties however you want, there are no restrictions. But we have a good amount of helpers if you do use this structure, like the 'attribute/cti' transform which adds attributes to the property of its CTI based on the path in the object. There are a lot of name transforms as well for when you want a flat structure like for Sass variables.
 
  Also, the CTI structure provides a good mechanism to target transforms for specific kinds of properties. All of the transforms provided by the framework use the CTI of a property to know if it should be applied. For instance, the 'color/hex' transform only applies to properties of the category 'color'.
 
@@ -257,7 +257,7 @@ The comment  will appear in the output files, where relevant or the output forma
 
 ## Extending
 
-The style dictionary build system is made to be extended. We don't know exactly how everyone will want to use style dictionaries in their project, which is why it is easy to create custom transforms and formats.
+The style dictionary build system is made to be extended. We don't know exactly how everyone will want to use style dictionaries in their project, which is why you can create custom transforms and formats.
 
 ```javascript
 const StyleDictionary = require('style-dictionary').extend('config.json');

docs/README.md

@@ -39,7 +39,7 @@ __Things you can build with a style dictionary:__
 
 **The value of using Style Dictionary to build all of these is that they are all consistent and up to date.**
 
-The Style Dictionary framework is fully extensible and modular so you can create any type of file from a style dictionary.
+The Style Dictionary framework is fully extensible and modular. You can create any type of file from a style dictionary.
 If there is a new language, platform, or file type you need, you can easily [extend](extending.md) the style dictionary framework to create the necessary files.
 
 

docs/api.md

@@ -148,8 +148,8 @@ base64'ing files, running other build scripts, etc.
 After you register a custom action, you then use that
 action in a platform your config.json
 
-Actions run after the files in a platform are generated so you
-can perform operations on files generated by the style dictionary.
+You can perform operations on files generated by the style dictionary
+as actions run after these files are generated.
 Actions are run sequentially, if you write synchronous code then
 it will block other actions, or if you use asynchronous code like Promises
 it will not block.
@@ -274,9 +274,9 @@ Transforms can manipulate a property's name, value, or attributes
 | --- | --- | --- |
 | transform | <code>Object</code> | Transform object |
 | transform.type | <code>String</code> | Type of transform, can be: name, attribute, or value |
-| transform.name | <code>String</code> | Name of the transformer so a transformGroup can call a list of transforms. |
+| transform.name | <code>String</code> | Name of the transformer (used by transformGroup to call a list of transforms). |
 | [transform.matcher] | <code>function</code> | Matcher function, return boolean if transform should be applied. If you omit the matcher function, it will match all properties. |
-| transform.transformer | <code>function</code> | Performs a transform on a property object, should return a string or object depending on the type. Will only update certain properties so you can't mess up property objects on accident. |
+| transform.transformer | <code>function</code> | Performs a transform on a property object, should return a string or object depending on the type. Will only update certain properties by which you can't mess up property objects on accident. |
 
 **Example**  
 ```js

docs/architecture.md

@@ -20,7 +20,7 @@ Style Dictionary takes all the files it found and performs a deep merge. This al
 
 ## 4. Iterate over the platforms
 
-For each platform defined in your [config](config.md), Style Dictionary will do a few steps to get it ready to be consumed on that platform. Everything that happens in a platform is non-destructive so you don't need to worry about one platform affecting another.
+For each platform defined in your [config](config.md), Style Dictionary will do a few steps to get it ready to be consumed on that platform. Everything that happens in a platform is non-destructive; you don't need to worry about one platform affecting another.
 
 ## 4a. Transform the tokens
 

docs/config.md

@@ -38,9 +38,9 @@ You can find out more about creating configurations in JS in our documentation a
 | Attribute | Type | Description |
 | :--- | :--- | :--- |
 | include | Array[String] (optional) | An array of path [globs](https://github.com/isaacs/node-glob) to Style Dictionary property files that contain default styles. The Style Dictionary uses this as a base collection of properties. The properties found using the "source" attribute will overwrite properties found using include. |
-| source | Array[String] | An array of path [globs](https://github.com/isaacs/node-glob) to JSON files that contain style properties. The Style Dictionary will do a deep merge of all of the JSON files so you can separate your properties into multiple files. |
+| source | Array[String] | An array of paths that can be [globs](https://github.com/isaacs/node-glob) to JSON files that contain style properties. This allows you to separate your properties into multiple files as Style Dictionary will do a deep merge of all of the JSON files to create the dictionary. |
 | platforms | Object | An object containing platform config objects that describe how the Style Dictionary should build for that platform. You can add any arbitrary attributes on this object that will get passed to formats and actions (more on these in a bit). This is useful for things like build paths, name prefixes, variable names, etc.  |
-| platform.transforms | Array[String] (optional) | An array of [transforms](transforms.md) to be performed on the style properties object. These will transform the properties in a non-destructive way so each platform can transform the properties. Transforms to apply sequentially to all properties. Can be a built-in one or you can create your own. |
+| platform.transforms | Array[String] (optional) | An array of [transforms](transforms.md) to be performed on the style properties object. These transform the properties in a non-destructive way as each platform can transform the properties in a unique manner. Transforms to apply sequentially to all properties. Can be a built-in one or you can create your own. |
 | platform.transformGroup | String (optional) | A string that maps to an array of transforms. This makes it easier to reference transforms by grouping them together. You must either define this or [transforms](transforms.md). |
 | platform.buildPath | String (optional) | Base path to build the files, must end with a trailing slash. |
 | platform.files | Array (optional) | Files to be generated for this platform. |

docs/extending.md

@@ -1,6 +1,6 @@
 # Extending
 
-The style dictionary build system is easily extended. We don't know exactly how everyone will want to use style dictionaries in their project, which is why we made it easy to create custom transforms and formats.
+There is a straightforward way to extend Style Dictionary to meet your needs - since we don't know exactly how everyone will want to use style dictionaries in their project, we created custom transforms and formats as a manner to add your desired functionality.
 
 ## Extension Functions in the API
 * [registerTransform](api.md#registertransform)

docs/formats.md

@@ -33,7 +33,7 @@ There is an extensive (but not exhaustive) list of [included formats](#pre-defin
 
 ### Format configuration
 
-Formats can take configuration to make them more flexible. This allows you to re-use the same format multiple times with different configuration or to allow the format to use data not defined in the tokens themselves. To configure a format add extra attributes on the file object in your configuration like so:
+Formats can take configuration to make them more flexible. This allows you to re-use the same format multiple times with different configurations or to allow the format to use data not defined in the tokens themselves. To configure a format, add extra attributes on the file object in your configuration like the following:
 
 ```json
 {
@@ -73,7 +73,7 @@ A special file configuration is `filter`, which will filter the tokens before th
 
 ### Creating formats
 
-You can create custom formats using the [`registerFormat`](api.md#registerformat) function. If you want to add configuration to your custom format, `this` is bound to the file object so you can access attributes on the file object with `this.myCustomAttribute` if the file object looks like:
+You can create custom formats using the [`registerFormat`](api.md#registerformat) function. If you want to add configuration to your custom format, `this` is bound to the file object. Using this, you can access attributes on the file object with `this.myCustomAttribute` if the file object looks like:
 
 ```json
 {
@@ -86,7 +86,7 @@ You can create custom formats using the [`registerFormat`](api.md#registerformat
 
 ### Using a template / templating engine to create a format
 
-A formatter is just a simple function and created easily with most templating engines. Templates are useful if there is a lot of boilerplate code to insert (e.g. ObjectiveC files). If the output consists of just the values (e.g. a flat SCSS variables file), writing a formatter function directly may be easier.
+Formatters are functions and created easily with most templating engines. Formats can be built using templates if there is a lot of boilerplate code to insert (e.g. ObjectiveC files). If the output consists of only the values (e.g. a flat SCSS variables file), writing a formatter function directly may be easier.
 
 Any templating language can work as there is a node module for it. All you need to do is register a format that calls your template and returns a string.
 
@@ -622,7 +622,7 @@ Creates a JSON file of the style dictionary.
 ### json/asset 
 
 
-Creates a JSON file of just the assets defined in the style dictionary.
+Creates a JSON file of the assets defined in the style dictionary.
 
 **Example**  
 ```js
@@ -695,7 +695,7 @@ Creates a sketchpalette file of all the base colors
 
 
 Creates a sketchpalette file compatible with version 2 of
-the sketchpalette plugin. To use this you should use the 
+the sketchpalette plugin. To use this you should use the
 'color/sketch' transform to get the correct value for the colors.
 
 **Example**  

docs/properties.md

@@ -2,15 +2,15 @@
 
 > Synonyms: design tokens, design variables, design constants, atoms
 
-Style properties are stored in a collection of JSON or JS module files. We usually keep them in a `properties` directory, but you can put them wherever you like, they just need to be referenced in the `source` attribute on your `config.json` file.
+Style properties are stored in a collection of JSON or JS module files. We usually keep them in a `properties` directory, but you can put them wherever you like, they need to be referenced in the `source` attribute on your `config.json` file.
 
 A property is a collection of attributes that describe any fundamental/atomic visual style. Each attribute is a `key:value` pair. A property name and its value are considered a design token (or design variable/constant/atom).
 
 ![Terminology for different parts of a JSON property](assets/property-definitions.png)
 
-A property is transformed for use in different platforms, languages, and contexts. A simple example is a color. A color can be represented in many ways, all of these are the same color: `#ffffff`, `rgb(255,255,255)`, `hsl(0,0,1)`.
+A property is transformed for use in different platforms, languages, and contexts. A simple example is color. A color can be represented in many ways, all of these are the same color: `#ffffff`, `rgb(255,255,255)`, `hsl(0,0,1)`.
 
-A property file organizes properties in a structured way for easy access. Property files are organized as a deep object with the leaf nodes being the style key:value pairs.
+A property file organizes properties in a structured way for quick access. Property files are organized as a deep object with the leaf nodes being the style key:value pairs.
 
 ## Examples
 
@@ -29,7 +29,7 @@ A property file organizes properties in a structured way for easy access. Proper
 }
 ```
 
-Any object in the JSON that has a `value` attribute on it is a property, so in this example there are 4 style properties: `color.font.base`, `color.font.secondary`, `color.font.tertiary`, and `color.font.inverse.base`.
+Any object in the JSON that has a `value` attribute on it is a property; in this example there are 4 style properties: `color.font.base`, `color.font.secondary`, `color.font.tertiary`, and `color.font.inverse.base`.
 
 For any properties you wish to output, the "value" attribute is required. This provides the data that will be used throughout the build process (and ultimately used for styling in your deliverables). You can optionally include any custom attributes you would like (e.g. "comment" with a string or "metadata" as an object with its own attributes).
 
@@ -88,7 +88,7 @@ Style properties are organized into a hierarchical tree structure with 'category
 
 ![](assets/cti.png)
 
-Now you can structure your property json files like simple objects:
+Now you can structure your property JSON files like simple objects:
 
 ```json
 {
@@ -105,7 +105,7 @@ The CTI is implicit in the structure, the category is 'size' and the type is 'fo
 
 Structuring style properties in this manner gives us consistent naming and accessing of these properties. You don't need to remember if it is `button_color_error` or `error_button_color`, it is `color_background_button_error`!
 
-You can organize and name your style properties however you want, **there are no restrictions**. But there are a good amount of helpers if you do use this structure, like the 'attribute/cti' transform which adds attributes to the property of its CTI based on the path in the object. There are a lot of name transforms as well for when you want a flat structure like for Sass variables.
+You can organize and name your style properties however you want, **there are no restrictions**. But there are a good amount of helpers if you do use this structure, like the 'attribute/cti' transform which adds attributes to the property of its CTI based on the path in the object. There are a lot of names transforms as well for when you want a flat structure like for Sass variables.
 
 Also, the CTI structure provides a good mechanism to target transforms for specific kinds of properties. All of the transforms provided by the framework use the CTI structure to know if it should be applied. For instance, the 'color/hex' transform only applies to properties of the category 'color'.