Article Writing Guide

This course follows the article-first approach of the companion JavaScript course. Each chapter should form a useful mental model for an experienced programmer, not reproduce a beginner syntax workbook.

What an article should do

• Begin with a concrete program, failure, command, or engineering decision.
• Explain syntax through realistic embedded examples.
• Spend more time on semantics, ownership, boundaries, and judgment than on cataloging tokens.
• Move quickly past ideas familiar from Swift, Java, and C#.
• Call out prior-language intuition only when it is likely to produce a wrong native-code model.
• Distinguish standard language behavior, implementation behavior, operating-system APIs, compiler extensions, and community convention.
• State the applicable C or C++ standard when a feature is not available in every baseline.
• End with a compact synthesis and optional prompts with reasoned answers.

C and C++ are not one dialect

An article may compare the languages when that comparison clarifies a boundary, but it must label code and claims accurately. Do not present a construct that happens to compile as both languages as proof that it has identical rules. C chapters teach idiomatic C ownership and APIs; C++ chapters teach RAII and standard-library abstractions rather than mechanically wrapping C code in classes.

Tooling explanations

Every tool should be introduced as a solution to a named responsibility. Explain what inputs it reads, what outputs it creates, and which later layer consumes those outputs. Prefer target-oriented explanations over copied command catalogs.

When showing an IDE workflow, connect visible settings to compiler, linker, build-graph, and debugger concepts. When showing a terminal workflow, explain what an integrated environment would automate. Neither workflow is the "real" one; they expose different amounts of the same system.

Examples

Code fences use c, cpp, cmake, make, sh, powershell, text, or a data format. A self-contained compilable fence adds compile after its language, for example the fence info string cpp compile.

Use compile-run only when validation should execute the program. Use expect-fail only for a complete example whose diagnostic is the point. Fragments remain unmarked and must be valid in the context established by the prose.

Important examples should use warning-clean code under the course profile. Never demonstrate undefined behavior merely to obtain a particular output; explain that no portable prediction exists.

Article endings and size

Optional prompts should require prediction, diagnosis, explanation, or modification rather than sentence copying. Answers immediately follow each prompt so the course remains self-directed.

Focused chapters are normally 1,200–2,200 words. Core memory, object-model, compiler, build, and dependency chapters may run 2,500–4,500 words. Split independent mental models rather than enforcing a mechanical size.

Review checklist

• Is the central model accurate for the stated language version?
• Do code and command output match the prose?
• Are compile-time, link-time, load-time, and runtime failures named correctly?
• Are ownership and lifetime visible?
• Are C and C++ rules distinguished?
• Are platform or implementation assumptions explicit?
• Does the article avoid teaching a compiler extension as portable language syntax?
• Do examples use only concepts already introduced, or explain a necessary preview?
• Do optional prompts test the central model and include reasoning?