minor fixes for the sake of consistency

Author: cezarywojcik

README.md

@@ -95,7 +95,7 @@ let myValue = 20 + (30 / 2) * 3
 if 1 + 1 == 3 {
  fatalError("The universe is broken.")
 }
-func pancake() -> Pancake {
+func pancake(with syrup: Syrup) -> Pancake {
  /* ... */
 }
 ```
@@ -947,7 +947,7 @@ guard let thingOne = thingOne else { return }
 
 ### 4.1 Documentation
 
-If a function is more complicated than a simple O(1) operation, you should generally consider adding a doc comment for the function since there could be some information that the method signature does not make immediately obvious (A very useful plugin to do this [called VVDocumenter can be found here](https://github.com/onevcat/VVDocumenter-Xcode)). If there are any quirks to the way that something was implemented, whether technically interesting, tricky, not obvious, etc., this should be documented. Documentation should be added for complex classes/structs/enums/protocols and properties. All `public` functions/classes/properties/constants/structs/enums/protocols/etc. should be documented as well (provided, again, that their signature/name does not make their meaning/functionality immediately obvious).
+If a function is more complicated than a simple O(1) operation, you should generally consider adding a doc comment for the function since there could be some information that the method signature does not make immediately obvious. If there are any quirks to the way that something was implemented, whether technically interesting, tricky, not obvious, etc., this should be documented. Documentation should be added for complex classes/structs/enums/protocols and properties. All `public` functions/classes/properties/constants/structs/enums/protocols/etc. should be documented as well (provided, again, that their signature/name does not make their meaning/functionality immediately obvious).
 
 After writing a doc comment, you should option click the function/property/class/etc. to make sure that everything is formatted correctly.