progmasoft-cpp/ADOPTING.md, branch docs/guidelines-layout

Use the two names consistently

2026-11-13T14:38:17+00:00

Progmasoft C/C++ Styles names the repository, where a text speaks of
all of it: the README introduction, the license texts, CONTRIBUTING and
the changelog. Progmasoft Core C++ Coding Guidelines names its C++
guide, and its own documents call it "the guidelines", in the plural
like its name, instead of "the guide" or "this guide"; the verbs follow.
Dated changelog entries keep their wording. Paragraphs that grew past
120 columns are rewrapped; every link and anchor still resolves.

Co-Authored-By: Claude Opus 5.5

Name the repository Progmasoft C/C++ Styles in the license texts

2026-11-13T14:31:48+00:00

LICENSE.md, LICENSES/CC0-1.0.md and CONTRIBUTING.md cover the whole
repository, so they name it Progmasoft C/C++ Styles, as the README
does. ADOPTING.md keeps the name of the guidelines a C++ project
adopts, Progmasoft Core C++ Coding Guidelines.

Co-Authored-By: Claude Opus 5.5

Name the guide Progmasoft Core C++ Coding Guidelines

2026-11-13T14:23:57+00:00

The README, ADOPTING, CONTRIBUTING and the license texts use the new
name, matching its directory; the changelog records that it was
Progmasoft C++ Style. Earlier changelog entries keep the name they had.

Co-Authored-By: Claude Opus 5.5

Lay the guide out as Common, Cpp17 and Cpp20 with an index

2026-11-13T14:21:51+00:00

The guide moves to Progmasoft_Core_Cpp_Coding_Guidelines/:

- Common/ holds the thirteen chapters, which apply to C++17 and C++20
  alike. Where a chapter used a C++20 feature, it now states the rule
  for both versions and links to the page of each.
- Cpp20/LANGUAGE.md holds the rules that use C++20 features: building
  with -std=c++20, designated initializers, consteval and constinit,
  std::bit_cast, concepts, defaulted comparisons, ranges, std::span,
  std::format, the smaller features, and the C++20 features not used.
- Cpp17/LANGUAGE.md holds what a C++17 project does instead: building
  with -std=c++17, the C++17 form of each C++20 rule (the former
  section 5.13) and the checks a C++17 library needs for later
  standards.
- index.json lists every document with its chapter, its path and the
  versions it applies to, and names the default version.

No rule changed. The README lists the version pages and the layout,
ADOPTING.md points to the page of the chosen version, and the changelog
says where Guide/ went. Every relative link and heading anchor was
checked.

Co-Authored-By: Claude Opus 5.5

Cover C++17 as well as C++20

2026-10-31T10:01:04+00:00

A project now picks one version. C++20 stays the default, and C++17 is
for libraries meant for other people's projects, because it is still the
widest common target and works in every later standard.

Section 5.13 gives the C++17 form of each C++20 feature the guide uses
and the checks such a project needs: CI in the versions it promises, with
each compiler, and headers that compile in default compiler modes.

Co-Authored-By: Claude Opus 5.5

Write the first revision of Progmasoft C++ Style

2026-10-18T17:00:39+00:00

Progmasoft C++ Style is a style guide for C++20, written for anyone
who wants a complete rule set to adopt. It writes down the conventions
the Progmasoft C++ projects already follow (naming, the clang-format
and clang-tidy profiles, exception-free error handling, Doxygen) and
decides what they left open.

Thirteen chapters under Guide/:

1. Principles: what the guide optimizes for and how to decide a case
   it does not cover.
2. Formatting: the full .clang-format profile, the reason for each
   choice, and the rules the tool cannot apply.
3. Naming: casing for every kind of name, acronyms, choosing words,
   namespaces, files.
4. Files and headers: extensions, #pragma once, includes, what goes in
   a header, the order inside a class, file size, vendored code.
5. Language: functions, auto, initialization, const and constexpr,
   casts, integers, strings, enumerations, templates and concepts,
   lambdas, control flow, and the features not used.
6. Types and classes: struct or class, final, construction, the rule of
   zero, inheritance, operators, strong types, optional and variant.
7. Errors: no exceptions by default, Expected and Error, invariants,
   fatal defects, destructors, diagnostics.
8. Ownership and memory: owners and borrowers, views and lifetimes,
   RAII, containers and deterministic iteration, allocation, undefined
   behavior.
9. Comments and documentation: Doxygen for public declarations,
   comments that explain why, TODOs that name an issue.
10. C interfaces: C11 headers, prefixes, opaque types, ownership and
    failure across the boundary, stability.
11. Concurrency: sharing less, threads, locks, thread-safety
    annotations, atomics, statics.
12. Testing: unit tests, fuzzing, sanitizers, benchmarks, coverage.
13. Tooling: the compiler flags, the full .clang-tidy profile with the
    reason for every disabled check, other checks, version pinning.

The guide prescribes no test, fuzzing or benchmark framework and no
error library; it prescribes how they are used. ADOPTING.md explains
how a project points to the guide, copies the profiles and records its
deviations. CONTRIBUTING.md explains how to propose a change.

The text is licensed under CC BY 4.0. The configuration and code
examples are dedicated to the public domain under CC0 1.0, so projects
can copy them under their own license.

Co-Authored-By: Claude Opus 5.5