Clean up headers in markdown

Some markdown headers needed tweaking to adhere
to standards, including blank lines above and below,
only one space after hash, first header should be
h1, and only one h1 per doc

1 files changed, 10 insertions, 10 deletions

diff --git a/doc/development/module_with_instance_variables.md b/doc/development/module_with_instance_variables.md
index 7bdfa04fc57..443eee0b62c 100644
--- a/doc/development/module_with_instance_variables.md
+++ b/doc/development/module_with_instance_variables.md
@@ -1,6 +1,6 @@
-## Modules with instance variables could be considered harmful
+# Modules with instance variables could be considered harmful
 
-### Background
+## Background
 
 Rails somehow encourages people using modules and instance variables
 everywhere. For example, using instance variables in the controllers,
@@ -9,7 +9,7 @@ helpers, and views. They're also encouraging the use of
 saving everything in a giant, single object, and people could access
 everything in that one giant object.
 
-### The problems
+## The problems
 
 Of course this is convenient to develop, because we just have everything
 within reach. However this has a number of downsides when that chosen object
@@ -24,7 +24,7 @@ manipulated from 3 different modules. It's hard to track when those variables
 start giving us troubles. We don't know which module would suddenly change
 one of the variables. Everything could touch anything.
 
-### Similar concerns
+## Similar concerns
 
 People are saying multiple inheritance is bad. Mixing multiple modules with
 multiple instance variables scattering everywhere suffer from the same issue.
@@ -40,7 +40,7 @@ Note that `included` doesn't solve the whole issue. They define the
 dependencies, but they still allow each modules to talk implicitly via the
 instance variables in the final giant object, and that's where the problem is.
 
-### Solutions
+## Solutions
 
 We should split the giant object into multiple objects, and they communicate
 with each other with the API, i.e. public methods. In short, composition over
@@ -53,7 +53,7 @@ With clearly defined API, this would make things less coupled and much easier
 to debug and track, and much more extensible for other objects to use, because
 they communicate in a clear way, rather than implicit dependencies.
 
-### Acceptable use
+## Acceptable use
 
 However, it's not always bad to use instance variables in a module,
 as long as it's contained in the same module; that is, no other modules or
@@ -74,7 +74,7 @@ Unfortunately it's not easy to code more complex rules into the cop, so
 we rely on people's best judgement. If we could find another good pattern
 we could easily add to the cop, we should do it.
 
-### How to rewrite and avoid disabling this cop
+## How to rewrite and avoid disabling this cop
 
 Even if we could just disable the cop, we should avoid doing so. Some code
 could be easily rewritten in simple form. Consider this acceptable method:
@@ -181,7 +181,7 @@ rather than whatever includes the module, and those modules which were also
 included, making it much easier to track down any issues,
 and reducing the chance of having name conflicts.
 
-### How to disable this cop
+## How to disable this cop
 
 Put the disabling comment right after your code in the same line:
 
@@ -210,14 +210,14 @@ end
 Note that you need to enable it at some point, otherwise everything below
 won't be checked.
 
-### Things we might need to ignore right now
+## Things we might need to ignore right now
 
 Because of the way Rails helpers and mailers work, we might not be able to
 avoid the use of instance variables there. For those cases, we could ignore
 them at the moment. At least we're not going to share those modules with
 other random objects, so they're still somewhat isolated.
 
-### Instance variables in views
+## Instance variables in views
 
 They're bad because we can't easily tell who's using the instance variables
 (from controller's point of view) and where we set them up (from partials'