Writing Math Expressions That Actually Work
Most people approach math notation like it is typing prose, and they spend more time debugging formatting than doing actual math. A math expression is just a structured way of representing a calculation or relationship using symbols, operators, and numbers. It can be as simple as 2 + 2 or as complex as a nested piecewise function with integrals and limits. The key thing nobody tells you is that the correctness of an expression is not the same as its readability, and most errors happen at the intersection of those two concepts. I spent three weeks once trying to figure out why a perfectly valid LaTeX expression was rendering as garbage in a web interface. The expression itself was fine. The HTML serializer was dropping semicolons from the \; spacing commands. We ended up just switching to plain ‹ entities instead. This is the kind of edge case that never makes it into any tutorial but will eat your afternoon if you do any serious technical writing online.
How To Write A Math Expression
There are really three environments where you will write math expressions, and each has a completely different workflow. Pick the right one first or you will waste a lot of time on the wrong syntax. When the expression lives inside a regular paragraph, you want it compact and non-disruptive. LaTeX uses single dollar signs. AsciiMath uses backticks. Plain HTML math uses the <math> tag from MathML. The expression goes directly between the delimiters without any additional markup wrapper. Most people mess this up by accidentally using display mode inside running text, which pushes the line height and breaks the visual flow of the paragraph entirely. An inline expression looks like this in LaTeX: $\alpha = \frac{F}{m}$. That is it. Single dollars. The renderer handles the rest. If you are writing for a system that does not support LaTeX, you fall back to Unicode characters or descriptive text. Nobody wants to read "alpha equals F over m" in a technical document. It slows comprehension and looks unprofessional.
Display Mode
When the expression deserves its own line, you use display mode. In LaTeX that means double dollar signs or the $$...$$ syntax, or better yet the \[ ... \] delimiter pair. Double dollars still work but they are technically not the recommended approach in modern LaTeX documentation. The \[ \] version is safer because it behaves more predictably inside lists and tables. Display mode expressions get more vertical space and larger fraction bars. Use this for equations you want the reader to actually study. Do not use display mode for a quick coefficient reference mid-paragraph. I have seen people stack a dozen inline-quality expressions in display mode across a two-page section and the result is visually exhausting. One or two display expressions per page is plenty for most technical documents.
Get the Full Details
Common Operators and Structure
Every math expression follows a basic structure: operands connected by operators, optionally grouped with parentheses or braces. The most common mistake beginners make is assuming that implicit multiplication works the same way across all renderers. 2x means 2 * x in standard mathematical notation, but in some plain-text math systems like Asymptote or older AsciiMath parsers, you must explicitly type 2*x or the expression throws an error. Always include the operator if there is any doubt about the target platform. Fractions should be written with proper fraction commands rather than forward slashes unless the fraction is trivial. \frac{a}{b} is the LaTeX standard and it renders with the horizontal bar properly sized. A forward slash like a/b is fine for inline use where space is tight, but it breaks down visually when the numerator or denominator contains multiple terms. (x+1)/(x-1) is readable. x+1/x-1 is ambiguous and will be misinterpreted by most parsers as x + (1/x) - 1 unless you add explicit grouping.
Subscripts and Superscripts
This is where I see the most preventable errors in production work. Subscripts and superscripts use _ and ^ respectively. The critical detail is that when you need to apply them to more than a single character, you must wrap the target in curly braces. x_i produces a single subscript i on x. x_{ij} produces both i and j as subscripts. Write x_ij and the j becomes a separate superscript or subscript depending on the renderer, and you get garbage output. I spent an hour once debugging an expression where n_k+1 was supposed to mean n_{k+1} but instead rendered as n subscript k, plus 1. The reader could not tell the difference because the typesetting was clean. The only way to catch this kind of thing is to render the expression and verify the grouping visually before embedding it. Never trust the raw source to produce what you intended just because the source looks correct on the surface.
Functions and Special Symbols
Built-in functions like sine, logarithm, and limit should always use the backslash prefix. \sin(x) renders with proper Roman upright font. sin(x) renders in italics, which makes it look like three variables multiplied together. This is not a cosmetic preference, it is a convention that experienced readers rely on for quick parsing. Same rule applies to \log, \exp, \lim, \int, \sum, \prod, \infty, \partial, and dozens of others. If you are writing a lot of expressions, learning the short names saves significant time. \leq is less than or equal. \geq is greater than or equal. \neq is not equal. \approx is approximately equal. \equiv is identical by definition. Using the spelled-out English words in place of symbols reads as amateurish and some renderers do not recognize them at all.
Common Pitfalls
One major pitfall is mixing modes carelessly. Switching from inline to display mode without the proper delimiter tells the renderer to change spacing behavior, and it can push content off the edge of a column or break table layouts entirely. Another pitfall is using Unicode symbols in environments that expect LaTeX syntax. The degree symbol ° is fine in HTML text but will not render correctly inside a LaTeX math block. Use ^\circ instead. Stacked fractions are another trap. Writing \frac{a}{\frac{b}{c}} works but produces ugly nested fractions that are hard to read. The better approach is \frac{ac}{b} if the algebra allows it. If the expression genuinely requires a complex continued fraction, use \cfrac from the amsmath package instead of \frac. It renders with consistent sizing and looks cleaner.
Test Your Expressions Before Publishing
Use a local renderer or an online editor to preview expressions before embedding them in any document. Overleaf is the standard tool for LaTeX-based work. It gives you immediate visual feedback. For HTML-based systems, the MathJax demo page or the KaTeX playground works well. Spend five minutes validating your expressions rather than spending an hour fixing broken layouts after they have gone live. The workflow I use is simple. Write the expression in the editor, verify the render matches my intent, then copy the source into the document. If I am writing a batch of expressions, I put them all in a single test file and scan through the renders quickly. This catches the weird edge cases where a parser silently falls back to a different interpretation of ambiguous syntax.
When Not to Write Math Expressions
Sometimes the best choice is to not write a math expression at all. If an expression requires more than three nested grouping levels, or if it depends heavily on context-specific notation that the target audience will not understand, you should consider a textual description or a diagram instead. No amount of correct syntax will make a genuinely unreadable expression readable. I have seen people write six-line matrix expressions inline in paragraphs and then wonder why nobody could follow the derivation. Keep expressions as simple as the content allows. A single well-placed variable definition is clearer than three paragraphs of symbolic manipulation. The goal is communication, not decoration.
