Help:Editing/House Style

This page lists the various house style conventions that have been adopted on. Active contributors are expected to gradually master these, but when first starting to contribute, seasoned editors will come in and tidy the pages you write or create.

Internal References
Due to the desired standard of rigor on, there are a lot of concepts on any given (proof) page that have their own, dedicated Proof or Definition page on.

To ensure ease of reference and maximal clarity and consistency, the following rules for internal reference are to be adhered to.

For information on creating links, see this section.

References to Theorems and Axioms
Whenever a theorem is invoked or referred to, be it in a proof or, for example, a clarifying comment, it should be referenced by its full title.

Also, for ease of editing, there is no need to change the case of theorem names; the page title will suffice.

Thus, for example, a valid reference to the result Union Distributes over Intersection is simply:


 * "By Union Distributes over Intersection, $A \cup \left({B \cap C}\right) = \left({A \cup B}\right) \cap \left({A \cup C}\right)$."

This is achieved by simply putting the title of the page you want to reference between double square brackets,  and.

The same convention applies to axioms, except that the namespace identifier Axiom: should be removed.

The correct way to reference the page Axiom:Axiom of Choice thus is:


 * Axiom of Choice

which is produced by:



References to Definitions
Whether or not a particular concept should be linked to its definition page is subject to a less strict philosophy.

In general, whenever a part of a definition is critically used in an argument, or is important for understanding the flow of the argument, a link should be included.

A good rule of thumb is to include a reference at least at the first occurrence of a concept on a page, or whenever the concept is used in a new way, or a new context.

It is considered good practice to have at least one reference in a paragraph where the concept is used; this is - naturally - attached to the first occurrence of the concept.

These references are made in a non-intrusive way. Thus, we write:


 * Let $R$ be a ring.

and not:


 * Let $R$ be a Ring (Abstract Algebra).

For example, it is not necessary to include three references to Definition:Ring (Abstract Algebra) in one sentence which happens to have three occurrences of "ring" in it.

If however a proof contains three paragraphs, then it would be good to include at least one reference to Definition:Ring (Abstract Algebra) in each paragraph.

Code Style
There are a few general source code conventions which make your code easier to read and maintain:


 * Each variable, and each command beginning with a backslash should be preceded by a space, except (for some unexplained result of evolution) when enclosing things in brackets. See some of the above instance for a typical example.


 * When enclosing brackets around an object, always use the  format, for example   rather than.


 * There should be no need to use the commands  etc. for specifying the sizes of parentheses. Using the   technique (as above) will almost always automatically size the brackets aesthetically.


 * Punctuation should appear outside the LaTeX environment, for example:


 * Hence $f \left({x}\right)$. (produced by: )


 * as opposed to:


 * Hence $f \left({x}\right).$ (produced by: )


 * Single-character parameters to standard $\LaTeX$ constructs need not be put in curly braces. That is,  is preferred to  . They both produce: $\dfrac 1 2$

It makes the source code significantly easier to read.

Having said that, please do not ignore the rule about spacing. The same effect can also be achieved by  (see, it still looks like $\dfrac12$) but that is significantly harder to interpret visually.

Aligned Material
If an equation includes multiple equalities or inequalities, it is best to place each equality on a new line.

For example:


 * $\dfrac {\mathrm d} {\mathrm d t} H \left({U}\right) = \mathrm d H \left({U} \right) \cdot \dot U = \Omega \left({X_H \left({U}\right), \dot U} \right) = \Omega \left({X_H \left({U}\right), X_H \left({U}\right)} \right) = 0$

would look better as an aligned equation. This is done using the following commands:

...

Here, the section following  is a $\LaTeX$ environment, and should contain anything you want to appear to the left of the equals sign.

The section following  is the same, but will appear to the right of the equals sign.

and  are similar, but produce material in columns further to the left and further to the right respectively. In particular, the  column is often used for an "implies" sign where the   and   are used for either side of a string of equations.

All these $\LaTeX$ environments are already in  mode, so there is no need to include that command in your equation.

When entering such an  environment, it should globally look like this:

That is, it adheres to the following principles:


 * Every empty column should in general be omitted, except perhaps for  sections, which can be left as placeholders for possible future addition of comments
 * Non-empty columns are entered on separate lines, with the  and   all aligned.

These conventions serve to optimize readability.

More options and abilities of the  can be found on its page, Template:Eqn.

The section following  is not a $\LaTeX$ environment, and can be used to add any comments about the equation at this point.

So the example we gave above would be typeset as:

The finished result will look like:

The operator that is displayed in this template can be changed using  to show inequalities, etc.

Note the following:


 * Do not include two consecutive open or close curly braces:  or   anywhere in your eqn templates. It will break the interpreter.

Put spaces in:  or   and it will be okay.


 * Do not include the vertical line  (a.k.a. "pipe") in $\LaTeX$ expressions as this also breaks the interpreter. Use   (or   and  ) instead.


 * In particular,  (used to produce $\|$) has the same problem. Use   etc. instead.

These caveats apply only within the  environment. Elsewhere on the page such constructs should be fine. To accommodate for the inevitable copy-paste efforts, and for consistency's sake, it is however desirable to always use  and , and to insert a space between adjacent curly braces within $\LaTeX$ strings.