docs(Emily's-rules): added some new rules

EmilysRulesForSERiFCode.md

@@ -40,3 +40,12 @@ for correctness.
 - The less something is related to physics the more you may consider AI. A build system configuration for example is a good candidate for AI. A physics function is not.
 - Its not 1980, we are not working on dumb terminals connected to a PDP 11 with 80 charecters of width. Do not limit yourself to 80 charecter width lines if it limits the readability of that line
 - At the same time monitors do still have a finite width, as a line gets long consider if it makes sense to split it into multiple lines.
+- Do not pollute headers with namespaces, if you must use a namespace in a header make sure that you do it within some function or class scope. Never, and I mean never, use a using namespace directive in a header at the global scope (even using namespace std).
+- In fact, don't use using namespace std ANYWHERE in the code, at all, ever, I mean it. 
+- If you are writing code that references mfem try to keep it in a backend namespace. This wont always work but give it your best shot
+- If you do use a using namespace in a function or class scope place that at the very top, as the very first lines of that scope. 
+- use auto only where it is obvious what the type is or it would be so horrifically ugly to write the type out (e.g. lambda functions, iterators, etc...). Do not use auto for the sake of using auto, it makes it harder to reason about types (especially for those of us using tools like vi).
+- use structured bindings only where it is obvious what the types of each element are or the type is the same for all so you can use a single type for all of them.
+- Keep ternary operators to a single line, if it is too long or too complex to fit on a single line then it should be rewritten as an if statement or a function.
+- Use designated initializers for structs and classes wherever possible.
+- Use structs over classes for data containers