Merge pull request #8486 from joaothallis/fix/link-typo

docs: fix typo and links

Author: guggero

docs/MAKEFILE.md

@@ -95,7 +95,7 @@ Related: [`unit`](#unit)
 
 `flakehunter`
 -------------
-Runs the itegration test suite endlessly until a failure is detected.
+Runs the integration test suite endlessly until a failure is detected.
 
 Arguments:
 - `icase=<itestcase>`

docs/code_contribution_guidelines.md

@@ -86,7 +86,7 @@ security and performance implications.
     - The original LN was written for a rather narrow audience, the paper may be a bit unapproachable to many. Thanks to the Bitcoin community, there exist many easily accessible supplemental resources which can help one see how all the pieces fit together from double-spend protection all the way up to commitment state transitions and Hash Time Locked Contracts (HTLCs): 
         - [Lightning Network Summary](https://lightning.network/lightning-network-summary.pdf)
         - [Understanding the Lightning Network 3-Part series](https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-building-a-bidirectional-payment-channel-1464710791) 
-        - [Deployable Lightning](https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf) 
+        - [Deployable Lightning](https://github.com/ElementsProject/lightning/blob/master/doc/miscellaneous/deployable-lightning.pdf)
 
 
 Note that the core design of the Lightning Network has shifted over time as

docs/code_formatting_rules.md

@@ -16,7 +16,8 @@ in `lnd` to help improve the overall readability.
 
 Blocks of code within `lnd` should be segmented into logical stanzas of
 operation. Such spacing makes the code easier to follow at a skim, and reduces
-unnecessary line noise. Coupled with the commenting scheme specified above,
+unnecessary line noise. Coupled with the commenting scheme specified in the
+[contribution guide](./code_contribution_guidelines.md#code-documentation-and-commenting),
 proper spacing allows readers to quickly scan code, extracting semantics quickly.
 Functions should _not_ just be laid out as a bare contiguous block of code.