Fix severat typos

Merge pull request #124 from Calinou/fix-typos

Author: Jaykul

Best-Practices/Performance.md

@@ -65,5 +65,4 @@ This example reverts back to a native PowerShell approach, using commands and pa
 
 You will generally find that it is possible to conform with the community's general aesthetic preferences while still maintaining a good level of performance. Doing so may require more work - such as writing PowerShell wrapper commands around underlying .NET Framework classes. Most would argue that, for a tool that is intended for long-term use, the additional work is a worthwhile investment.
 
-The moral here is that both aesthetic and performance are important considerations, and without some work context, neither is inherently more important than the other. It is often possible, with the right technique, to satisfy both. As a general practice, you should avoid giving up on aesthetics solely because of performance concesrns - when possible, make the effort to satisfy both performance and aesthetics.
-
+The moral here is that both aesthetic and performance are important considerations, and without some work context, neither is inherently more important than the other. It is often possible, with the right technique, to satisfy both. As a general practice, you should avoid giving up on aesthetics solely because of performance concerns - when possible, make the effort to satisfy both performance and aesthetics.

Best-Practices/TODO.md

@@ -246,7 +246,7 @@ My choice: Configuration module. Otherwise, use clixml (or XAML) to persist to A
 #### Provide aliases in your modules
 You should feel free to create and use aliases within your modules. In some cases, you can even improve readability by using an alias without the verb, or shortening command names.
 
-For exported aliases, follow the guidance of Microsoft ("ip" for import, "s" for set, "g" for get, "r" for remove, etc.), make up somethign for your nouns.
+For exported aliases, follow the guidance of Microsoft ("ip" for import, "s" for set, "g" for get, "r" for remove, etc.), make up something for your nouns.
 
 Use `New-Alias ... -ErrorAction SilentlyContinue` to avoid overwriting existing aliases.
 
@@ -293,7 +293,7 @@ Additionally, avoid using `[string]` with ParameterSets because anything can be
 
 When passing on parameters to another command, you should be _at least_ as strongly typed as the other command, to avoid casting exceptions within your script.
 
-One notable exception is when you could accept more than one type. In PowerShell you can speficy parameter set overloads, but you can't change the type of a parameter.
+One notable exception is when you could accept more than one type. In PowerShell you can specify parameter set overloads, but you can't change the type of a parameter.
 
 
 ### Don't reinvent the wheel

LICENSE.md

@@ -8,7 +8,7 @@ This work is licensed under a [Creative Commons Attribution-ShareAlike 4.0 Inter
 
 **Adapt** — remix, transform, and build upon the material 
 
-The authors encourage you to redistribute this content as widely as possible, but require that you give credit to the primary authors below, and that you notify us on github of any improvements you make.
+The authors encourage you to redistribute this content as widely as possible, but require that you give credit to the primary authors below, and that you notify us on GitHub of any improvements you make.
 
 
 #### Credits
@@ -29,6 +29,6 @@ Portions copyright (c) Joel Bennett, 2015
 
 The *PowerShell Best Practices* are always evolving, and continue to be edited and updated as the language and tools (and our community understanding of them) evolve. We encourage you to check back for new editions at least twice a year, by visiting [https://github.com/PoshCode/PowerShellPracticeAndStyle](https://github.com/PoshCode/PowerShellPracticeAndStyle)
 
-The *PowerShell Style Guide* in particular is in PREVIEW, and we are still actively working out our disagreements about the rules in the guide through the github issues system. Please don't be suprised if over then next few weeks we change rules to contradict what they say at this current moment.
+The *PowerShell Style Guide* in particular is in PREVIEW, and we are still actively working out our disagreements about the rules in the guide through the GitHub issues system. Please don't be surprised if over then next few weeks we change rules to contradict what they say at this current moment.
 
 <p align="center"><a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/" style="display: inline-block; float: left; vertical-align: middle; margin: 10px;"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-sa/4.0/88x31.png" /></a></p>

README.md

@@ -12,7 +12,7 @@ This work is licensed under a [Creative Commons Attribution-ShareAlike 4.0 Inter
 
 **Adapt** — remix, transform, and build upon the material
 
-The authors encourage you to redistribute this content as widely as possible, but require that you give credit to the primary authors below, and that you notify us on github of any improvements you make.
+The authors encourage you to redistribute this content as widely as possible, but require that you give credit to the primary authors below, and that you notify us on GitHub of any improvements you make.
 
 ### What are Best Practices
 
@@ -52,7 +52,7 @@ Remember [what we mean by _Best Practices_](#what-are-best-practices)
 
 The *PowerShell Best Practices* are always evolving, and continue to be edited and updated as the language and tools (and our community understanding of them) evolve. We encourage you to check back for new editions at least twice a year, by visiting [https://github.com/PoshCode/PowerShellPracticeAndStyle](https://github.com/PoshCode/PowerShellPracticeAndStyle)
 
-The *PowerShell Style Guide* in particular is in PREVIEW, and we are still actively working out our disagreements about the rules in the guide through the github issues system.
+The *PowerShell Style Guide* in particular is in PREVIEW, and we are still actively working out our disagreements about the rules in the guide through the GitHub issues system.
 
 #### Contributing
 

Style-Guide/Code-Layout-and-Formatting.md

@@ -69,13 +69,13 @@ If you wish, you may use camelCase for variables within your functions (or modul
 
 #### One True Brace Style
 
-This guide recommends the so-called ["One True Brace Style" variant to K&R](https://github.com/PoshCode/PowerShellPracticeAndStyle/issues/81#issuecomment-285835313), which requires that every braceable _statement_ should  have the opening brace on the _end of a line_, and the closing brace at the _beginning of a line_. 
+This guide recommends the so-called ["One True Brace Style" variant to K&R](https://github.com/PoshCode/PowerShellPracticeAndStyle/issues/81#issuecomment-285835313), which requires that every braceable _statement_ should  have the opening brace on the _end of a line_, and the closing brace at the _beginning of a line_.
 
 There is one notable exception when passing small scriptblocks to parameters (where K&R would allow leaving off the braces entirely), we allow putting the entire statement on a single line.
 
 ```powershell
 enum Color {
-    Black, 
+    Black,
     White
 }
 
@@ -88,7 +88,7 @@ function Test-Code {
         if (10 -gt $ParameterOne) {
             "Greater"
         } else {
-            "Lesser"    
+            "Lesser"
         }
     }
 }
@@ -151,11 +151,11 @@ function Test-Code {
 
 Limit lines to 115 characters when possible.
 
-Keeping lines to a small width allows scripts to be read in _one_ direction (top to bottom) without scrolling back-and-forth horizontally. What, exactly, this width should be is a one of the favorite arguing points among developers on the internet (more splintered than emacs vs vi or gnu GPL vs MIT). 
+Keeping lines to a small width allows scripts to be read in _one_ direction (top to bottom) without scrolling back-and-forth horizontally. What, exactly, this width should be is a one of the favorite arguing points among developers on the internet (more splintered than emacs vs vi or gnu GPL vs MIT).
 
 In this guide we use two particular sources for the maximum line width:
 
-The PowerShell console is, by default, 120 characters wide, but it allows only 119 characters on output lines, and when entering multi-line text, PowerShell uses a line continuation prompt: `>>> ` and thus limits your line length to 116 anyway.  
+The PowerShell console is, by default, 120 characters wide, but it allows only 119 characters on output lines, and when entering multi-line text, PowerShell uses a line continuation prompt: `>>> ` and thus limits your line length to 116 anyway.
 
 Github's current maximum line width varies between 121 and 126 depending on your browser and OS (and thus, font). However, the 115 line length suggested by PowerShell would be enough to even allow side-by-side diffs to be displayed without scrolling or wrapping on the current "standard" 1080p monitor.
 
@@ -175,7 +175,7 @@ Surround function and class definitions with _two_ blank lines.
 
 Method definitions within a class are surrounded by a single blank line.
 
-Blank lines may be ommitted between a bunch of related one-liners (e.g. empty functions)
+Blank lines may be omitted between a bunch of related one-liners (e.g. empty functions)
 
 Additional blank lines may be used sparingly to separate groups of related functions, or within functions to indicate logical sections (e.g. before a block comment).
 
@@ -220,7 +220,7 @@ $yesterdaysDate = (Get-Date).AddDays(-$i)
 
 #### Spaces around special characters
 
-White-space is (mostly) irrelevant to PowerShell, but its proper use is key to writing easily readable code. 
+White-space is (mostly) irrelevant to PowerShell, but its proper use is key to writing easily readable code.
 
 Use a single space after commas and semicolons, and around pairs of curly braces.
 
@@ -241,7 +241,7 @@ Obviously, these rules should not be applied in such a way as to affect output.
 
 PowerShell will not complain about extra semicolons, but they are unnecessary, and can get in the way when code is being edited or copy-pasted. They also result in extra do-nothing edits in source control when someone finally decides to delete them.
 
-They are also unecessary when declaring hashtables if you are already putting each element on it's own line:
+They are also unnecessary when declaring hashtables if you are already putting each element on its own line:
 
 ```PowerShell
 # This is the preferred way to declare a hashtable if it extends past one line:

Style-Guide/Documentation-and-Comments.md

@@ -2,7 +2,7 @@
 
 Comments that contradict the code are worse than no comments. Always make a priority of keeping the comments up-to-date when the code changes! 
 
-Comments should be in English, and should be complete sentences. If the comment is short, the period at the end can be ommited.  
+Comments should be in English, and should be complete sentences. If the comment is short, the period at the end can be omitted.  
 
 Remember that comments should serve to your reasoning and decision-making, not attempt to explain what a command does. With the exception of regular expressions, well-written PowerShell can be pretty self-explanatory.