In order to create proper help content, you should incorporate it into your function and module development. While at the beginning, you might want to write comment-based help, consider writing file-based help content for larger projects, instead.

If you adopt the same style for all functions that you create, integrating help content early on will be very easy. You need to document what you did, anyway, so why not write it in your help? An example is as follows:

function Get-CommentBasedHelp {
    <#
        .SYNOPSIS
            This contains a brief description
        .DESCRIPTION
            This contains a long description
        .EXAMPLE
            Get-CommentBasedHelp

            These are examples for all parameter sets
        .NOTES
            This contains additional fluff like the author, changelog, ...
    #>
    [CmdletBinding()]
    param(
        # This is a parameter description
        [Parameter(Mandatory=$true)]
        [String]$SomeParameter
    )

}

Get-Help Get-CommentBasedHelp
Get-Help Get-CommentBasedHelp -Examples
Get-Help Get-CommentBasedHelp -Parameter SomeParameter

As your project grows, you may want to maintain your help separate from your code. Maybe you would like to offload translation tasks to a different team, and don't want them to work through your code. This is where PlatyPS steps in. PlatyPS is a module that helps with generating help files in a readable format, which also looks beautiful when hosted online:

# Generate help with PlatyPS
Install-Module PlatyPS -Scope CurrentUser -Force

# Create a temporary module to generate help for
New-Module -Name OnTheFly -ScriptBlock {function Get-Stuff {param([Parameter(Mandatory)]$SomeParameter)}}

# Generate help for all exported functions
New-MarkdownHelp -Module OnTheFly -OutputFolder .PlatyPSHelp
psedit .PlatyPSHelpGet-Stuff.md

# Generate generic help (See get-help about_* for those topics)
New-MarkdownAboutHelp -OutputFolder .PlatyPSHelp -AboutName StringTheory
psedit .PlatyPSHelpabout_StringTheory.md

We will revisit PlatyPS in Chapter 10, Creating Your Own PowerShell Repository, when we talk about developing and deploying proper documentation.

As a general recommendation you should opt to provide external help for any module that is hosted publicly in the PowerShell gallery for example. You might also want to provide external help in a corporate environment where not you but your colleagues or internal customers are consuming your module and might need help. Translating external help is also easier since you can ship the help files to your translation department instead of shipping your entire code base.