Qt Writing Guidelines: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
 
(43 intermediate revisions by the same user not shown)
Line 2: Line 2:
The Qt Writing Guidelines contains information about writing Qt documentation in a consistent way. Though there are exceptions, maintain the consistency level outlined in the guidelines or the existing Qt documentation.
The Qt Writing Guidelines contains information about writing Qt documentation in a consistent way. Though there are exceptions, maintain the consistency level outlined in the guidelines or the existing Qt documentation.


This guideline is maintained by the Qt Documentation Team, with members across the different Qt Group sites. Visit their page at: [[:Category:Developing Qt::Documentation]]
This guideline is maintained by the Qt Documentation Team, with members across the different Qt Group sites. Visit their page at: [[Contributing to Qt Documentation]]


== Language Style ==
== Language style ==


'''''Say the text out loud. If it sounds weird, then it is weird...and may need editing.'''''


We use the [https://learn.microsoft.com/en-us/style-guide/welcome/ Microsoft Writing Style Guide] in the Qt documentation. Essentially, use clear and direct language in '''American English'''. We write to a diverse audience and we need to communicate Qt topics in an approachable and understandable manner.


Qt uses the [https://learn.microsoft.com/en-us/style-guide/welcome/ Microsoft Writing Style Guide] in the Qt documentation. Essentially, use clear and direct language in '''American English'''. We write to a diverse audience and we need to communicate Qt topics in an approachable and understandable manner.


Here are some specifics for Qt:
Here are some specifics for Qt:
# Use '''active voice''', not passive. Passive does not make a sentence formal, but unnecessarily weakens the sentence. See [https://learn.microsoft.com/en-us/style-guide/grammar/verbs Verbs]
# Use '''active voice''', not passive. Passive does not make a sentence formal, but unnecessarily weakens the sentence. See [https://learn.microsoft.com/en-us/style-guide/grammar/verbs Verbs]
# Use the pronoun '''you''' in to address the reader when appropriate. See [https://learn.microsoft.com/en-us/style-guide/grammar/nouns-pronouns Nouns and Pronouns].
# Use the pronoun '''you''' in to address the reader when appropriate. See [https://learn.microsoft.com/en-us/style-guide/grammar/nouns-pronouns Nouns and Pronouns].
# Use '''because''' instead of "since" or "as". See [https://learn.microsoft.com/en-us/style-guide/word-choice/use-simple-words-concise-sentences Use simple words, concise sentences].
# Use '''because''' instead of "since" or "as". See [https://learn.microsoft.com/en-us/style-guide/word-choice/use-simple-words-concise-sentences Use simple words, concise sentences].
# Use a serial comma, also known as the '''Oxford comma'''. See [https://learn.microsoft.com/en-us/style-guide/punctuation/commas Commas]
# Use a serial comma, also known as the '''Oxford comma'''. See [https://learn.microsoft.com/en-us/style-guide/punctuation/commas Commas].
# Use the correct spelling and case for Qt Products. See [[Qt Terms and Concepts]]
# Use the correct spelling and case for Qt Products. See [[Qt Terms and Concepts]].
# Be consistent with forming lists ('''\list'''). Use the '''same tone or mode''' and be consistent  about ending with periods.
# Use US spelling and avoid latin abbreviations. See [https://learn.microsoft.com/en-us/style-guide/word-choice/use-us-spelling-avoid-non-english-words Use US spelling and avoid non-English words]. Here is a summary :
# Use US spelling and avoid latin abbreviations. See [https://learn.microsoft.com/en-us/style-guide/word-choice/use-us-spelling-avoid-non-english-words Use US spelling and avoid non-English words]. Here is a summary :


Line 27: Line 28:
|i.e.
|i.e.
|-
|-
|namely
|for example
|viz.
|e.g.
|-
|-
|therefore
|and so on.
|ergo
|etc.
|}
|}


New in Qt 6.8, the Qt Reference Documentation is available in translated formats. Think about how translatable the sentence you are writing. If the text is too complicated, then  
=== Translated Documentation ===
New in Qt 6.8, the Qt Reference Documentation is available in translated formats. Think about how easy the text is easily translatable. If the text is too complicated, then it may be poorly translated by translation tools.
 
== Using QDoc to write documentation ==
These '''QDoc''' guidelines complement the [http://doc.qt.io/qt-5/qdoc-index.html QDoc Manual]
 
* [[QDocStyleGuidelines | Style Guidelines]] - proper use of commands, code blocks, markup, and indentation
* [[QDocLinkingGuidelines | Linking Guidelines]]
* [[ QDoc Project Templates]]
* [[Checklist for Adding Documentation for a New Module]]
* [[Qt_Documentation_Structure | Documentation Structure]] page contains a map of how the directory structure of a repository or module
 
== Writing API documentation ==
We document Qt APIs in the sources and use '''QDoc''' to generate the HTML for the doc.qt.io site and an offline version for Qt Creator.
 
C++ and QML documentation follow a similar style, but there are differences. See the following pages for documenting APIs.
 
* [https://doc.qt.io/qt-6/qtwritingstyle-cpp.html C++ Documentation Style]
* [https://doc.qt.io/qt-6/qtwritingstyle-qml.html QML Documentation Style]


it may confuse the reader.
For designing Qt APIs, visit:


* '''Tip: ''Say the text out loud. If it sounds weird, then it is weird...then it may also be wrong.'''''
* [[API Design Principles]]


== Creating Hierarchy in Documentation ==
== Quoting and marking code ==
Documentation needs to have structure and hierarchy for readability. Form topics and ideas separately and supplement with follow up sentences related to the topic.
'''''Make sure your snippet compiles and runs.'''''


Here is an example of structured overview, This also applies to documentation that is written into paragraphs.<blockquote>Title ('''\title''')
It is best to include code snippets using the '''\snippet <filename>''' command. We are striving to include compilable and usable code in the Qt documentation.


Introductory parapraph. Description about what the page is about.
If the code is inside a source file, then we can use code common to snippets and examples.  


Topic 1 ('''\section1''')
Read the ''QDoc Manual'' about the other commands relating to including sources in documentation. See [https://doc.qt.io/qt-6/07-0-qdoc-commands-includingexternalcode.html Including External Code]


* Topic 1 paragraph 1.  Sentence related to paragraph 1. Another sentence related to paragraph 1.
Markup with the '''\c''' command is beneficial to state that text is an input or output. See [https://doc.qt.io/qt-6/04-qdoc-commands-textmarkup.html Text Markup]
* Topic 1 paragraph 2. Sentence related to paragraph 2. Another sentence related to paragraph 2.


Topic 2 ('''\section1''')
The previous guideline about '''using ''\code''''' '''''and''' '''\endcode''' '''is no longer preferred''''', though it is still possible to use these commands.


* Topic 2 paragraph 1. Sentence related to paragraph 1. Another sentence related to paragraph 1.
For quoting input or output text (from the terminal, for example), use the various quotation commands. See [https://doc.qt.io/qt-6/06-qdoc-commands-includecodeinline.html Including Code Inline]
* Topic 2 paragraph 2. Sentence related to paragraph 2. Another sentence related to paragraph 2.


References/See Also ('''\section1''')
== Writing section titles ==
'''''Consistency is key...write sections in sentence-case, but maintain consistency with existing pages'''''.


* List of relevant pages.</blockquote>
Section titles are written as arguments to \section1 and \section2 commands.


== Writing API Documentation ==
Write section titles in '''sentence-case''' as indicated by the ''Microsoft Writing Style Guide.'' See [https://learn.microsoft.com/en-us/style-guide/text-formatting/formatting-titles Formatting titles].  
We document Qt APIs in the sources and use '''QDoc''' to generate the HTML for the doc.qt.io site and an offline version for Qt Creator.


C++ and QML documentation follow a similar style, but there are differences. See the following pages for documenting APIs.
The previous guideline about using title-case is no longer valid, but maintain consistency within the page for readability and neatness.


* [https://doc.qt.io/qt-6/qtwritingstyle-cpp.html C++ Documentation Style]
=== Task-based titles ===
* [https://doc.qt.io/qt-6/qtwritingstyle-qml.html QML Documentation Style]
The section title could be about performing tasks or a description of a sub-system.


For designing Qt APIs, visit:
Here are some suggestions:


* [[API Design Principles]]
* Sections about performing tasks, use verbs in progressive form: ''Building...'', ''Using...'', ''Creating...'', ''Connecting...'', and so on.
* Sections about a sub-system or a description, use nouns: ''Coordinate systems'',  ''Chart types'', ''Dynamic properties'', and so on.


== Using QDoc to Write Documentation ==
=== Linking issues ===
'''''Choose unique titles to avoid linking problems.'''''


These '''QDoc''' guidelines complement the [http://doc.qt.io/qt-5/qdoc-index.html QDoc Manual]
QDoc uses section titles as link targets, and a common issue is mis-linking to unwanted sections'''''.''''' This issue is due to writing titles that already exist.  


* [[QDocStyleGuidelines | Style Guidelines]] - proper use of commands, code blocks, markup, and indentation
Search for already existing titles, run QDoc, and check the HTML output for missing or misdirected links.
* [[QDocLinkingGuidelines | Linking Guidelines]]
* [[ QDoc Project Templates]]
* [[Checklist for Adding Documentation for a New Module]]
* [[Qt_Documentation_Structure | Documentation Structure]] page contains a map of how the directory structure of a repository or module


== Using QDoc \note and \warning ==
== Using QDoc \note and \warning ==
''This is a prevalent issue that warrants its own section.''
'''''Only noteworthy statements belong in a \note.'''''
 
 
QDoc has a '''\note''' command that creates a stylized '''Note:''' in the documentation. Similarly '''\warning''' creates a '''Warning:''' in the documentation.  
QDoc has a '''\note''' command that creates a stylized '''Note:''' in the documentation. Similarly, '''\warning''' creates a '''Warning:''' .  


Use them sparingly but be aware of their intended use and consequences.
Use them sparingly but be aware of their intended use and consequences.  


* Notes and warnings break the flow of the paragraph or section, creating an aside or detour from the usual topic.
* Notes and warnings break the flow of the paragraph or section, creating an aside or detour from the usual topic.
* '''\note is only for 1-sentence statements'''. See [https://doc.qt.io/qt-6/11-qdoc-commands-specialcontent.html#note \note command] in the QDoc manual.
* '''''\note is only for short statements'''.'' See [https://doc.qt.io/qt-6/11-qdoc-commands-specialcontent.html#note \note command] in the QDoc manual.
* Reserve '''\warning''' for critical information that lead to serious consequences.
* Reserve '''\warning''' for critical information that lead to serious consequences.
Think of the hierarchy of information. When highlighting several important content, only have the most important in a \note. Notes that are not critical may not be that important.
Think of the hierarchy of information. When highlighting several important content, only have the most important statement in a \note. Notes that are not critical may not be that important.


Instead, '''integrate the sentence or statement into a paragraph'''. A one-line paragraph dangling in a page is better than the overuse of notes.
Instead, '''''integrate the note into a paragraph'''.'' A one-line paragraph dangling in a page is better than the overuse of notes.


== Documenting Examples ==
== Documenting examples ==
Qt Examples are an important part of the Qt Framework. They show how the framework is to be used and inspire developers about possibilities with Qt. These pages help with creating examples, documenting examples, and how to contribute examples into the Qt repositories.
Qt Examples are an important part of the Qt Framework. They show how the framework is to be used and inspire developers about possibilities with Qt. These pages help with creating examples, documenting examples, and how to contribute examples into the Qt repositories.
* [[Qt Examples Guidelines]] - do's and don'ts for examples
* [[Qt Examples Guidelines]] - do's and don'ts for examples
Line 105: Line 120:
* [[Qt Examples in Qt Creator]] - ensuring that the example works within Qt Creator
* [[Qt Examples in Qt Creator]] - ensuring that the example works within Qt Creator


== Including Images ==
== Including images ==
The requirements for images in Qt documentation is outlined in QUIP-21.
The requirements for images in Qt documentation is outlined in QUIP-21.


* [https://contribute.qt-project.org/quips/21 QUIP-21] '''Using images in Qt documentation'''
* [https://contribute.qt-project.org/quips/21 QUIP-21] ''Using images in Qt documentation''


== Vale Support ==
== Linting with Vale ==
Vale is a linter that detects improper use of language and can make suggestions in-place. Vale has  command-line interface and is also available for Qt Creator and VS Code
Vale is a linter that detects improper use of language and can make suggestions in-place. Vale has  command-line interface and is also available for Qt Creator and VS Code.


For more information about Vale, visit [[Setting Up Vale]].
For more information about Vale, visit [[Setting Up Vale]].


== Qt 5 Documentation Requirements ==
== See also ==
 
* [[Qt5DocumentationProject | Qt 5 Documentation]] - for creators of Qt 5 documentation
For Qt 5 documentation, or those who create documentation using Qt 5, see the following pages:
* [[Qt5DocumentationProject | Qt 5 Documentation]]


QDoc changes should pass the [[QDocRegressionTesting]]
QDoc changes should pass the [[QDocRegressionTesting]]

Latest revision as of 16:29, 29 November 2024

The Qt Writing Guidelines contains information about writing Qt documentation in a consistent way. Though there are exceptions, maintain the consistency level outlined in the guidelines or the existing Qt documentation.

This guideline is maintained by the Qt Documentation Team, with members across the different Qt Group sites. Visit their page at: Contributing to Qt Documentation

Language style

Say the text out loud. If it sounds weird, then it is weird...and may need editing.


Qt uses the Microsoft Writing Style Guide in the Qt documentation. Essentially, use clear and direct language in American English. We write to a diverse audience and we need to communicate Qt topics in an approachable and understandable manner.

Here are some specifics for Qt:

  1. Use active voice, not passive. Passive does not make a sentence formal, but unnecessarily weakens the sentence. See Verbs
  2. Use the pronoun you in to address the reader when appropriate. See Nouns and Pronouns.
  3. Use because instead of "since" or "as". See Use simple words, concise sentences.
  4. Use a serial comma, also known as the Oxford comma. See Commas.
  5. Use the correct spelling and case for Qt Products. See Qt Terms and Concepts.
  6. Be consistent with forming lists (\list). Use the same tone or mode and be consistent about ending with periods.
  7. Use US spelling and avoid latin abbreviations. See Use US spelling and avoid non-English words. Here is a summary :
Use Instead of
that is i.e.
for example e.g.
and so on. etc.

Translated Documentation

New in Qt 6.8, the Qt Reference Documentation is available in translated formats. Think about how easy the text is easily translatable. If the text is too complicated, then it may be poorly translated by translation tools.

Using QDoc to write documentation

These QDoc guidelines complement the QDoc Manual

Writing API documentation

We document Qt APIs in the sources and use QDoc to generate the HTML for the doc.qt.io site and an offline version for Qt Creator.

C++ and QML documentation follow a similar style, but there are differences. See the following pages for documenting APIs.

For designing Qt APIs, visit:

Quoting and marking code

Make sure your snippet compiles and runs.

It is best to include code snippets using the \snippet <filename> command. We are striving to include compilable and usable code in the Qt documentation.

If the code is inside a source file, then we can use code common to snippets and examples.

Read the QDoc Manual about the other commands relating to including sources in documentation. See Including External Code

Markup with the \c command is beneficial to state that text is an input or output. See Text Markup

The previous guideline about using \code and \endcode is no longer preferred, though it is still possible to use these commands.

For quoting input or output text (from the terminal, for example), use the various quotation commands. See Including Code Inline

Writing section titles

Consistency is key...write sections in sentence-case, but maintain consistency with existing pages.

Section titles are written as arguments to \section1 and \section2 commands.

Write section titles in sentence-case as indicated by the Microsoft Writing Style Guide. See Formatting titles.

The previous guideline about using title-case is no longer valid, but maintain consistency within the page for readability and neatness.

Task-based titles

The section title could be about performing tasks or a description of a sub-system.

Here are some suggestions:

  • Sections about performing tasks, use verbs in progressive form: Building..., Using..., Creating..., Connecting..., and so on.
  • Sections about a sub-system or a description, use nouns: Coordinate systems, Chart types, Dynamic properties, and so on.

Linking issues

Choose unique titles to avoid linking problems.

QDoc uses section titles as link targets, and a common issue is mis-linking to unwanted sections. This issue is due to writing titles that already exist.

Search for already existing titles, run QDoc, and check the HTML output for missing or misdirected links.

Using QDoc \note and \warning

Only noteworthy statements belong in a \note.

QDoc has a \note command that creates a stylized Note: in the documentation. Similarly, \warning creates a Warning: .

Use them sparingly but be aware of their intended use and consequences.

  • Notes and warnings break the flow of the paragraph or section, creating an aside or detour from the usual topic.
  • \note is only for short statements. See \note command in the QDoc manual.
  • Reserve \warning for critical information that lead to serious consequences.

Think of the hierarchy of information. When highlighting several important content, only have the most important statement in a \note. Notes that are not critical may not be that important.

Instead, integrate the note into a paragraph. A one-line paragraph dangling in a page is better than the overuse of notes.

Documenting examples

Qt Examples are an important part of the Qt Framework. They show how the framework is to be used and inspire developers about possibilities with Qt. These pages help with creating examples, documenting examples, and how to contribute examples into the Qt repositories.

Including images

The requirements for images in Qt documentation is outlined in QUIP-21.

  • QUIP-21 Using images in Qt documentation

Linting with Vale

Vale is a linter that detects improper use of language and can make suggestions in-place. Vale has command-line interface and is also available for Qt Creator and VS Code.

For more information about Vale, visit Setting Up Vale.

See also

QDoc changes should pass the QDocRegressionTesting