• Documenting Your Swift Code in Xcode Using Markdown
  • GABRIEL THEODOROPOULOS
  • Translator: yrq110

Of all the features included in Xcode 7, there is one new revolution that is undeniable: a better way to write code documentation. Developers can use powerful Markdown statements to write documents with multiple text styles, combining specific keywords to identify specific parts (such as parameters, function results, and so on) with unexpected results. The new Markdown-enabled document style has the following advantages: it provides a higher level of text customization, is more flexible, and of course more fun. But if you’re interested in old-fashioned documentation, check out our previous tutorial.

Writing code documentation is an important task for every developer, and while it may seem to slow down development, it is a part of it. I don’t think it’s easy to write appropriate, easy-to-understand documentation for every property, function, class, struct, and other items that exist in a project. Documents can be written using the following points:

  • Describe attributes, functions, and classes for their purpose, purpose, and details, and highlight function-specific conditions, use cases, or rules.
  • Highlight the input and output (parameters and return values) of the method.
  • After the initial implementation, when you review the code, it becomes clear what functions and attributes do.
  • Make other developers understand how to use your code or library.
  • Use tools to produce professional manuals (such as Jazzy).

There are three ways to preview and access code documents written in Xcode:

  • Hold down Option/Alt and click on the property name, method name, class name, etc. A quick preview window will pop up near the name.
  • Open Quick Help by placing the cursor over the property name, method name, or class name.
  • Use third-party tools that can generate manuals. For example, Jazzy is a great tool, we’ll talk about that later. With it, your documents can be compiled into web pages, and the entire document can form an offline website, saved in a subfolder in the project folder.

The code document is not static; it needs to be flexible, changing according to changes made in entities (attributes, methods, classes, structures, enumerations). If you don’t add documentation when you implement a new entity then you won’t add it later. So get in the habit of adding code documentation when appropriate, and allocate some time to do it.

directory

  • Markdown statement basics
  • Use the Markdown
  • Use keywords
  • Use Jazzy to generate the documentation page

Use keywords

Using Markdown statements is just one aspect of documented code. Obviously rich text formatting is great and produces a nice document, but if you leave it at that, you’ll miss something. Let’s look at another aspect of documented code ———— using keywords.

Every time a keyword is used, Xcode automatically recognizes it and renders the document in a default format (the same with third-party libraries). Using keywords is useful when annotating common code structures in documents to distinguish them. For example, there are keywords for highlighting method parameters, return values, class authors, function versions, and many more, not all of which are very uncommon. Familiarize yourself with some commonly used keywords, and look up others when you can.

With that said, it’s time to practice using keywords with some examples. The first keyword is used to label the arguments that a method or function takes:

/**
    This is an extremely complicated method that concatenates the first and last name and produces the full name.

    - Parameter firstname: The first part of the full name.
    - Parameter lastname: The last part of the fullname.
*/
func createFullName(firstname: String, lastname: String) {
    let fullname = "\(firstname) \(lastname)"
    print(fullname)
}Copy the code

The effect is as follows:

Note the dashes (-) before the keywords and the Spaces between them, followed by the actual arguments and their descriptions. As many parameters as exist here should be described (with appropriate descriptions).

Modify the above function slightly so that it returns fullname instead of just printing it. In this case, we need to add a new keyword that describes the return value of the function:

/**
    This is an extremely complicated method that concatenates the first and last name and produces the full name.

    - Parameter firstname: The first part of the full name.
    - Parameter lastname: The last part of the fullname.
    - Returns: The full name as a string value.
*/
func createFullName(firstname: String, lastname: String) -> String {
    return "\(firstname) \(lastname)"
}Copy the code

The effect is as follows:

The two keywords above (parameter and RETURNS) are the most commonly used. The fullname function splits the fullname into firstName and lastname in reverse:

/**
    Another complicated function.

    - Parameter fullname: The fullname that will be broken into its parts.
    - Returns: A *tuple* with the first and last name.

    - Remark:
        There's a counterpart function that concatenates the first and last name into a full name.

    - SeeAlso:  `createFullName(_:lastname:)`

*/
func breakFullName(fullname: String) -> (firstname: String, lastname: String) {
    let fullnameInPieces = fullname.componentsSeparatedByString(" ")
    return (fullnameInPieces[0], fullnameInPieces[1])
}Copy the code

There are two new elements: Remark and SeeAlso keywords. Using the first keyword you can highlight any important or special points to catch the reader’s attention. The SeeAlso keyword is often used to add associations to other parts of code (as in this case with a previous function), or to provide a link to a real URL. The following is displayed in quick Help:

Imagine that the above functions are just a part of what you share with other developers, and make it as good as you can. You want the people using this function to know two facts (or requirements) : The fullname argument cannot be nil. Fisrtname and lastName need to be included in fullName, separated by Spaces, for the function to work properly. You can update the document with the additional two keywords, Precondition and Requires, as shown below:

/**
    Another complicated function.

    - Parameter fullname: The fullname that will be broken into its parts.
    - Returns: A *tuple* with the first and last name.

    - Remark:
        There's a counterpart function that concatenates the first and last name into a full name.

    - SeeAlso:  `createFullName(_:lastname:)`

    - Precondition: `fullname` should not be nil.
    - Requires: Both first and last name should be parts of the full name, separated with a *space character*.

*/
func breakFullName(fullname: String) -> (firstname: String, lastname: String) {
    let fullnameInPieces = fullname.componentsSeparatedByString(" ")
    return (fullnameInPieces[0], fullnameInPieces[1])
}Copy the code

Looking to the future, you might want to make a note of the features you want to implement:

- Todo: Support middle name in the next version.Copy the code

You can also add warnings, versions, authors, and reminders:

/** Another complicated function. - Parameter fullname: The fullname that will be broken into its parts. - Returns: A *tuple* with the first and last name. - Remark: There's a counterpart function that concatenates the first and last name into a full name. - SeeAlso: `createFullName(_:lastname:)` - Precondition: `fullname` should not be nil. - Requires: Both first and last name should be parts of the full name, separated with a *space character*. - Todo: Support middle name in the next version. - Warning: A wonderful **crash** will be the result of A 'nil' argument. -version: 1.1 -author: Myself Only - Note: Too much documentation for such a small function. */ func breakFullName(fullname: String) -> (firstname: String, lastname: String) { let fullnameInPieces = fullname.componentsSeparatedByString(" ") return (fullnameInPieces[0], fullnameInPieces[1]) }Copy the code

This is what appears in quick Help:

The level of detail you understand above depends on your reception.Document important code as shown in the previous code snippet, and use basic elements for less important parts.

Apple provides a documentation of all the available keywords, and you can see a more detailed description here. Don’t miss it.

Use Jazzy to generate the documentation page

Jazzy is a great tool for generating Apple-style documentation for your code (whether swift or OC). Jazzy actually creates a separate page that contains all the code documentation. It’s a command-line tool, but it’s pretty easy to use.

To take a look at the implementation details of Jazzy, check out the GitHub introduction and see its environment requirements and installation methods. Just do the following to get started:

  1. Open your terminal.
  2. Enter: [sudo] gem install Jazzy.
  3. Enter the password
  4. Wait for…

To test Jazzy, I’ve prepared a small app, which you can download here, that contains the functions from the previous example – combine and split Fullname.

Assuming you’ve signed off the app, let’s see how Jazzy uses it. First use the CD command in terminal to enter the project folder:

cd path_to_project_folder
Copy the code

The simplest use is to simply type Jazzy and wait for it to complete, but these do not contain classes or other structures in the code that are not marked public. So if you want to include all structures, type the following command:

jazzy --min-acl internal
Copy the code

In addition, if your Swift is not the latest version you will not see Jazzy’s output, in which case you need to add a parameter to specify which swift version xcode supports:

Jazzy -- Swift-version 2.1.1 --min-acl internalCopy the code

It is highly recommended that you type Jazzy –help to see all the parameters available in Jazzy, and you may find many useful things to do to get the results you want.

Execute the generated document page, and the result is as follows:

The default output folder is named docs and saved in the root directory of the project (you can change it).

Use Finder to look at folders, open index.html in your browser, and you’ll see a default page style that looks a lot like an Apple document. Click on the link to see how the document looks. Now, try Jazzy in your project.