Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Source code syntax is the set of language-specific rules that decides how characters and tokens may be arranged into a correctly structured program. Syntax answers one question: is this text arranged in a form the language accepts? It does not answer what the program will do once it runs.
What source code syntax means
MDN Web Docs defines syntax in its glossary as the required combination and sequence of characters that makes correctly structured code. The same definition notes that syntax covers grammar and layout rules, such as Python’s indentation, and that it governs ordering and structure rather than meaning. (Source: MDN Web Docs, “Syntax – Glossary”.)
Every language has its own syntax. A rule that is mandatory in one language may be illegal or meaningless in another, so a syntax judgment is only meaningful once you name the language and, where it matters, the version.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Syntax versus semantics
Syntax concerns arrangement. Semantics concerns what the arranged instructions mean. Code can pass every syntax rule and still produce the wrong result, because the author asked for the wrong thing. Code can also fail long after it has been accepted as well formed.
Several different kinds of failure are often lumped together as “errors”. They should be kept apart:
- Syntax error: the token sequence cannot be parsed under the language’s grammar, for example a missing closing parenthesis.
- Name-resolution error: the code is well formed, but it refers to an identifier that is not declared or not visible at that point. Whether this is detected before or during execution depends on the language.
- Type error: an operation is applied to a value of a kind it does not accept. Some languages check this before running the program; others check it at runtime.
- Runtime error or logic error: the program is accepted and starts running, then fails, or produces an incorrect result.
Only the first item is a syntax error. Calling every failure a syntax error makes diagnosis slower, because the fix for a missing delimiter is different from the fix for a wrong value.
How a language turns text into structure
A useful teaching model divides processing into two stages. It is a simplification, not a claim that every compiler or interpreter works in exactly these two passes:
- Lexical analysis. Source characters are grouped into lexical elements, usually called tokens: identifiers, keywords, literals, operators, and punctuation. Whitespace and comments are also defined here, and each language decides which of these elements are kept for later stages and which are discarded.
- Syntactic analysis. The token sequence is checked against a grammar. Successful parsing produces a structure, typically described as a parse tree, that shows how tokens form expressions, statements, and larger program units.
Meaning checks, such as type and name checks, come after or alongside these stages, depending on the language and implementation.
Lexical rules: identifying the pieces
Lexical rules define what a legal identifier looks like, which words are reserved as keywords, how numbers and strings are written as literals, which character sequences form operators, and what counts as punctuation. In the GNU C Language Manual, for example, lexical syntax covers characters, whitespace, comments, identifiers, operators, and punctuation. (Source: GNU, “Lexical Syntax (GNU C Language Manual)”.)
Syntactic grammar: combining the pieces
The syntactic grammar describes how tokens may be combined. An expression is built from operands and operators. A statement is built from expressions and keywords. A program unit is built from statements and declarations. A parser checks each combination against these rules. The ECMAScript 2021 Language Specification describes a lexical stage that turns source code points into input elements, followed by a syntactic grammar in which tokens act as terminal symbols. (Source: Ecma International, “ECMAScript® 2021 Language Specification”.)
Rank #3
Why a grammar is not the whole story
A formal grammar describes most of a language’s structure, but not always all of it. The ECMAScript 2021 specification states that its syntactic grammar, in clauses 13 through 16, “is not a complete account of which token sequences are accepted as a correct ECMAScript Script or Module.” Additional rules, including early errors and automatic semicolon insertion, also determine what is accepted. Anyone writing a parser or explaining a language’s validity rules has to read those extra rules too.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Lexical and syntactic rules in three languages
The three languages below all publish their lexical rules, but they document syntax in different places and to different depths. The table shows what the cited sources establish.
| Language and source | Lexical rules documented | Syntactic rules documented | Whitespace and line-break notes |
|---|---|---|---|
| C, GNU C Language Manual, “Lexical Syntax” | Characters, whitespace, comments, identifiers, operators, and punctuation | Not stated in the cited lexical-syntax section | Whitespace and comments are treated as lexical elements |
| C#, Microsoft, “Lexical structure – C# language specification” | Rules for forming tokens | Rules for combining tokens into programs | Not stated in the cited section |
| JavaScript, ECMAScript 2021 and MDN Web Docs, “Lexical grammar – JavaScript” | Input elements and tokens, with Script and Module as grammar goals | Syntactic grammar in clauses 13 through 16 of ECMAScript 2021, supplemented by early errors and semicolon insertion | Line terminators can affect automatic semicolon insertion |
The table reflects the cited documents only. A language’s full syntax may be documented in other chapters or editions that were not consulted for this article.
Syntax errors: what they are and how to read them
A syntax error means the token sequence cannot be parsed under the applicable grammar. A common example is an unclosed parenthesis, as in the expression result = (3 + 4. The parser reaches the end of the line or file while still expecting a closing parenthesis, so it reports a problem.
Error messages differ between compilers, interpreters, and editors. The wording, the error code, and the line number they report are tool-specific. The reported location can also sit after the actual mistake, because the parser only notices the problem when it reaches a token it cannot place. For that reason, treat the reported line as the starting point for the search.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Confirm the language and version the tool is using. A file saved with the wrong extension or compiled with the wrong standard can produce errors that look mysterious.
- Fix the first error reported. Later errors are often knock-on effects of the first one.
- Check delimiters: parentheses, brackets, braces, quotation marks, and comment markers.
- Check line breaks and indentation, if the language treats them as significant.
- Recompile or re-run. If the error changes to a type, name, or runtime error, the syntax problem has been resolved and the remaining problem is semantic.
Whitespace, line breaks and comments are not always ignored
It is tempting to treat all whitespace as decoration. Syntax rules do not work that way in every language:
Best Value
- Indentation: MDN cites Python’s indentation as a syntax rule, so changing the indentation of a block can change which statements belong to it.
- Line terminators: in JavaScript, line terminators can affect automatic semicolon insertion, so a line break can change how a statement is parsed.
- Comments: comments are defined by lexical rules, and their markers are recognised before the rest of the code is parsed. Their placement can matter in some languages, even though their contents are normally ignored.
Comparing syntax across languages
When comparing the syntax of two languages, the useful comparison points are:
- legal characters and identifiers;
- keywords, literals, operators, and punctuation;
- how expressions, statements, and program units are combined;
- treatment of whitespace, comments, and line breaks;
- extra rules such as indentation sensitivity, semicolon insertion, or context-dependent grammar.
Comparing only keyword lists misses most of the differences. Two languages can share the same operators and still differ in how a line break ends a statement.
Scope of the definition
The ECMAScript 2021 edition is the source cited for the clause numbers above. Later editions of the ECMAScript specification have been published since then, so check the current edition before relying on clause numbers or on the exact wording of any rule. The general definition of syntax, the lexical and syntactic division, and the distinction from semantics are stable across the sources cited here.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
