SDL3/README/documentation-rules

When adding or editing documentation, we don't (currently) have a style guide for what it should read like, so try to make it consistent with the rest of the existing text. It generally should read more like technical reference manuals and not sound conversational in tone.

Most of these rules are about how to make sure the documentation works on a technical level, as scripts need to parse it, and there are a few simple rules we need to obey to cooperate with those scripts.

The wiki and headers share the same text.

There is a massive Perl script (build-scripts/wikiheaders.pl, hereafter referred to as "wikiheaders") that can read both the wiki and the public headers, and move changes in one across to the other.

If you prefer to use the wiki, go ahead and edit there. If you prefer to use your own text editor, or command line tools to batch-process text, etc, you can clone the wiki as a git repo and work locally.

Don't taunt wikiheaders.

The script isn't magic; it's a massive pile of Regular Expressions and not a full C or markdown parser. While it isn't fragile, if you try to do clever things, you might confuse it. This is to the benefit of documentation, though, where we would rather you not do surprising things.

We sort of write in Doxygen format.

To document a symbol, we use something that looks like Doxygen (and Javadoc) standard comment format:

/**
 * This is a function that does something.
 *
 * It can be used for frozzling bobbles. Be aware that the Frozulator module
 * _must_ be initialized before calling this.
 *
 * \param frozzlevel The amount of frozzling to perform.
 * \param color What color bobble to frozzle. 0 is red, 1 is green.
 * \returns the number of bobbles that were actually frozzled, -1 on error.
 *
 * \threadsafety Do not call this from two threads at once, or the bobbles
 *               won't all frozzle correctly!
 *
 * \since This function is available since SDL 7.3.1.
 *
 * \sa SDL_DoSomethingElse
 */
extern SDL_DECLSPEC int SDLCALL SDL_DoSomething(int frozzlevel, int color);

Note the /** at the start of the comment. That's a "Doxygen-style" comment, and wikiheaders will treat this differently than a comment with one *, as this signifies that this is not just a comment, but documentation.

These comments must start in the first column of the line, or wikiheaders will ignore them, even with the "/**" start (we should improve the script someday to handle this, but currently this is a requirement).

We do not parse every magic Doxygen tag, and we don't parse them in @param format. The goal here was to mostly coexist with people that might want to run Doxygen on the SDL headers, not to build Doxygen from scratch. That being said, compatibility with Doxygen is not a hard requirement here.

wikiheaders uses these specific tags to turn this comment into a (hopefully) well-formatted wiki page, and also can generate manpages and books in LaTeX format from it!

Text markup in the headers is always done in Markdown format! But less is more: try not to markup text more than necessary.

Doxygen tags we support:

Other Doxygen things might exist in the headers, but they aren't understood by wikiheaders.

Use Markdown.

The wiki also supports MediaWiki format, but we are transitioning away from it. The headers always use Markdown. If you're editing the wiki from a git clone, just make .md files and the wiki will know what to do with them.

Most things in the headers can be documented.

wikiheaders understands functions, typedefs, structs/unions/enums, #defines ... basically most of what makes up a C header. Just slap a Doxygen-style comment in front of most things and it'll work.

Defines right below typedefs and functions bind.

Any #define directly below a function or non-struct/union/enum typedef is considered part of that declaration. This happens to work well with how our headers work, as these defines tend to be bitflags and such that are related to that symbol.

wikiheaders will include those defines in the syntax section of the wiki page, and generate stub pages for each define that simply says "please refer to (The Actual Symbol You Care About)" with a link. It will also pull in any blank lines and most preprocessor directives for the syntax text, too.

Sometimes an unrelated define, by itself, just happens to be right below one of these symbols in the header. The easiest way to deal with this is either to document that define with a Doxygen-style comment, if it makes sense to do so, or just add a normal C comment right above it if not, so wikiheaders doesn't bind it to the previous symbol.

Don't document the SDL_test*.h headers.

These are in the public headers but they aren't really considered public APIs. They live in a separate library that doesn't, or at least probably shouldn't, ship to end users. As such, we don't want it documented on the wiki.

For now, we do this by not having any Doxygen-style comments in these files. Please keep it that way! If you want to document these headers, just don't use the magic two-* comment.

The first line is the summary.

The first line of a piece of documentation is meant to be a succinct description. This is what Doxygen would call the \brief tag. wikiheaders will split this text out until the first period (end of sentence!), and when word wrapping, shuffle the overflow into a new paragraph below it.

Split paragraphs with a blank line.

And don't indent them at all (indenting in Markdown is treated as preformatted text).

wikiheaders will wordwrap header comments so they fit in 80 columns, so if you don't leave a blank line between paragraphs, they will smush into a single block of text when wordwrapping.

Don't worry about word wrapping.

If you don't word-wrap your header edits perfectly (and you won't, I promise), wikiheaders will send your change to the wiki, and then to make things match, send it right back to the headers with correct word wrapping. Since this happens right after you push your changes, you might as well just write however you like and assume the system will clean it up for you.

Things that start with SDL_ will automatically become wiki links.

wikiheaders knows to turn these into links to other pages, so if you reference an SDL symbol in the header documentation, you don't need to link to it. You can optionally wrap the symbol in backticks, and wikiheaders will know to link the backticked thing. It will not generate links in three-backtick code/preformatted blocks.

URLs will automatically become links.

You can use Markdown's [link markup format](https://example.com/), but sometimes it's clearer to list bare URLs; the URL will be visible on the wiki page, but also clickable to follow the link. This is up to your judgment on a case-by-case basis.

Hide stuff from wikiheaders.

If all else fails, you can block off pieces of the header with this magic line (whitespace is ignored):

#ifndef SDL_WIKI_DOCUMENTATION_SECTION

Everything between this line and the next #endif will just be skipped by wikiheaders. Note that wikiheaders is not a C preprocessor! Don't try to nest conditionals or use !defined.

Hide stuff from the compiler.

If you need to put something that's only of interest to wikiheaders, the convention is to put it in a block like this:

#ifdef SDL_WIKI_DOCUMENTATION_SECTION

Generally this is used when there's a collection of preprocessor conditionals to define the same symbol differently in different circumstances. You put that symbol in this block with some reasonable generic version and the Doxygen-style comment. Because wikiheaders doesn't care about this preprocessor magic, and the C compiler can be as fancy as it wants, this is strictly a useful convention.

Struct/union/enum typedefs must have the name on the first line.

typedef struct
{
    int a;
    int b;
} SDL_MyStruct;

typedef struct SDL_MyStruct
{
    int a;
    int b;
} SDL_MyStruct;

wikiheaders will complain loudly if you don't do this, and exit with an error message.

Code examples go in the wiki.

We don't want the headers cluttered up with code examples. These live on the wiki pages, and wikiheaders knows to not bridge them back to the headers.

Put them in a ## Code Examples section, and make sure to wrap them in a three-backtick-c section for formatting purposes. Only write code in C, please.

Do you need a code example?

Most code examples aren't actually useful. If your code example is just SDL_CreateWindow("Hello SDL", 640, 480, 0); then just delete it; if all you're showing is how to call a function in C, it's not a useful code example. Not all functions need an example. One with complex setup or usage details might, though!

Code examples are compiled by GitHub Actions.

On each change to the wiki, there is a script that pulls out all the code examples into discrete C files and attempts to compile them, and complains if they don't work.

Unrecognized sections are left alone in the wiki.

A wiki section that starts with ## Section Name (or == Section Name == in MediaWiki format) that isn't one of the recognized names will be left alone by wikiheaders. Recognized sections might get overwritten with new content from the headers, but the wiki file will not have other sections cleaned out (this is how Code Examples remain wiki only, for example). You can use this to add Wiki-specific text, or stuff that doesn't make sense in a header, or would merely clutter it up.

A possibly-incomplete list of sections that will be overwritten by changes to the headers:

It's okay to repeat yourself.

Each individual piece of documentation becomes a separate page on the wiki, so small repeated details can just exist in different pieces of documentation. If it's complicated, it's not unreasonable to say "Please refer to SDL_SomeOtherFunction for more details" ... wiki users can click right through, header users can search for the function name.

The docs directory is bridged to the wiki, too.

You might be reading this document on the wiki! Any README-*.md files in the docs directory are bridged to the wiki, so docs/README-linux.md lands at https://wiki.libsdl.org/SDL3/README/linux ...these are just copied directly without any further processing by wikiheaders, and changes go in both directions.

The wiki can have its own pages, too.

If a page name isn't a symbol that wikiheaders sees in the headers, or a README in the source's docs directory, or a few other exceptions, it'll assume it's an unrelated wiki page and leave it alone. So feel free to write any wiki-only pages that make sense and not worry about it junking up the headers!

Wiki categories are (mostly) managed automatically.

The wiki will see this pattern as the last thing on a page and treat it as a list of categories that page belongs to:

You can use this to simply tag a page as part of a category, and the user can click directly to see other pages in that category. The wiki will automatically manage a Category* pages that list any tagged pages.

You should not add tags to the public headers. They don't mean anything there. wikiheaders will add a few tags that make sense when generating wiki content from the header files, and it will preserve other tags already present on the page, so if you want to add extra categories to something, tag it on the wiki itself.

The wiki uses some magic HTML comment tags to decide how to list items on Category pages and let other content live on the page as well. You can see an example of this in action at:

Categorizing the headers.

Category documentation lives in headers.

To document a category (text that lives before the item lists on a wiki category page), you have to follow a simple rule:

If these conditions aren't met, wikiheaders will assume that documentation belongs to whatever is below it instead of the Category.

The text of this comment will be added to the appropriate wiki Category page, at the top, replacing everything in the file until it sees a line that starts with an HTML comment (<!--), or a line that starts with ----. Everything after that in the wiki file will be preserved.

Likewise, when bridging back to the headers, if wikiheaders sees one of these comments, it'll copy the top section of the Category page back into the comment.

Beyond stripping the initial * portion off each line, these comments are treated as pure Markdown. They don't support any Doxygen tags like \sa or \since.

Rules for documentation

No style guide

Don't taunt wikiheaders.

We sort of write in Doxygen format.

Doxygen tags we support:

Use Markdown.

Most things in the headers can be documented.

Defines right below typedefs and functions bind.

Don't document the `SDL_test*.h` headers.

The first line is the summary.

Split paragraphs with a blank line.

Don't worry about word wrapping.

Things that start with `SDL_` will automatically become wiki links.

URLs will automatically become links.

Hide stuff from wikiheaders.

Hide stuff from the compiler.

Struct/union/enum typedefs must have the name on the first line.

Code examples go in the wiki.

Do you need a code example?

Code examples are compiled by GitHub Actions.

Unrecognized sections are left alone in the wiki.

It's okay to repeat yourself.

The docs directory is bridged to the wiki, too.

The wiki can have its own pages, too.

Wiki categories are (mostly) managed automatically.

Categorizing the headers.

Category documentation lives in headers.

Rules for documentation

No style guide

The wiki and headers share the same text.

Don't taunt wikiheaders.

We sort of write in Doxygen format.

Doxygen tags we support:

Use Markdown.

Most things in the headers can be documented.

Defines right below typedefs and functions bind.

Don't document the SDL_test*.h headers.

The first line is the summary.

Split paragraphs with a blank line.

Don't worry about word wrapping.

Things that start with SDL_ will automatically become wiki links.

URLs will automatically become links.

Hide stuff from wikiheaders.

Hide stuff from the compiler.

Struct/union/enum typedefs must have the name on the first line.

Code examples go in the wiki.

Do you need a code example?

Code examples are compiled by GitHub Actions.

Unrecognized sections are left alone in the wiki.

It's okay to repeat yourself.

The docs directory is bridged to the wiki, too.

The wiki can have its own pages, too.

Wiki categories are (mostly) managed automatically.

Categorizing the headers.

Category documentation lives in headers.

Don't document the `SDL_test*.h` headers.

Things that start with `SDL_` will automatically become wiki links.