Code Formatting & Online Runner Guide
Formatting, validating and trying code online cover most of what you do with a snippet day to day. This page spells out where each stops and tabulates the style choices teams argue about most: indentation, quotes and semicolons.
Three Tools Compared
| Tool | What It Does | Typical Use | Watch Out |
|---|---|---|---|
| XML Formatter | Re-indent and validate XML structure | API payloads, config files, SOAP responses | Unclosed tags are reported as errors |
| JS Formatter | Normalise indentation, quotes, semicolons and line breaks | Inheriting code, unifying style before a merge | Layout only, never semantics; confirm the semicolon rule first |
| JS Runner | Execute snippets in the browser and inspect output | Testing regex, trying algorithms, debugging small functions | Runs in a browser sandbox with no filesystem access |
Common Style Trade-offs
| Dimension | Option A | Why A | Option B | Why B |
|---|---|---|---|---|
| Indentation | 2 空格 | Front-end default; saves horizontal space when nesting is deep | 4 空格 | Preferred by Python and some back ends; hierarchy is clearer |
| Indentation | 空格 | Renders identically in every editor | Tab | Width is configurable, but mixing it with spaces breaks alignment |
| Quotes | 单引号 | Common in JS and Python; safer inside HTML attributes | 双引号 | Required by JSON; conventional for JSX attributes |
| Line Endings | 加分号 | Avoids edge cases in automatic semicolon insertion | 不加分号 | Terser, but lines starting with ( [ ` need care |
Frequently Asked Questions
Does formatting change how code runs?
A proper formatter works purely at the lexical level and never alters syntax, so behaviour is unchanged. Two real risks remain. The first is automatic semicolon insertion: in a semicolon-free JavaScript style, a line beginning with a bracket, square bracket or backtick can be joined onto the previous one, and re-flowing lines can expose this. The second is that minification is the inverse of formatting — it strips whitespace and line breaks, so if the code relies on semicolons they must be complete before minifying. A safe habit is to run tests or a linter after formatting.
Should I choose XML or JSON?
Default to JSON for new work unless you have a concrete reason otherwise. JSON is lighter, has clearer types, interoperates natively with JavaScript and is generally faster to parse. XML still wins where you need schema validation, namespace isolation, mixed content with attributes, or integration with an existing enterprise system — much of finance and government still speaks SOAP or XML. XML also supports comments, which standard JSON does not, and that occasionally matters for human-readable configuration.
Is running JavaScript in a web page safe?
It depends on where the code came from. The browser execution environment is sandboxed: it cannot read or write local files and cannot reach cross-origin resources, so running your own snippets is safe. The risk is pasting code of unknown provenance, which could issue network requests that exfiltrate data or act within the current page context. Run only code you wrote or trust, and never handle secrets or real data in an online runner.
Our team cannot agree on indentation. What should we do?
Do not settle it by discussion — settle it with tooling. Pick a mainstream style (two spaces for front-end work, four for Python is the least friction starting point), encode it in the editor config and the formatter config file, commit that file, and let formatting happen automatically on save. The point is automation rather than consensus: with a committed config, new members never need to know the history of the argument. What remains for human judgement is naming and structure, which no formatter can decide.