Soften guidelines for `return`

When using long-form functions always use the return keyword

We may want adjust the the hard stance on using return with long-form functions. Some examples that adding in the return makes things worse:

function load!(tz_source::TZSource, file::AbstractString)
    open(file, "r") do io
        load!(tz_source, file, io)
    end
end

# VS

function load!(tz_source::TZSource, file::AbstractString)
    return open(file, "r") do io
        load!(tz_source, file, io)
    end
end

function isarchive(path)
    @static if Sys.iswindows()
        success(`$exe7z t $path -y`)
    else
        success(`tar tf $path`)
    end
end

# VS

function isarchive(path)
    return @static if Sys.iswindows()
        success(`$exe7z t $path -y`)
    else
        success(`tar tf $path`)
    end
end

function VariableTimeZone(name::AbstractString, args...)
    new(name, args...)
end

# VS

function VariableTimeZone(name::AbstractString, args...)
    return new(name, args...)
end

function extract(archive, directory, files=AbstractString[]; verbose::Bool=false)
    ...

    run(cmd)
end

# VS

function extract(archive, directory, files=AbstractString[]; verbose::Bool=false)
    ...

    return run(cmd)  # Note: We don't actually want to return anything from this function
end

I would suggest we re-word to something like:

When using long-form functions prefer the use the return keyword especially when control flow constructs are used. Avoid the use of return when your function should not return anything.

No file or test is named in the issue. Start by locating the guideline containing “When using long-form functions always use the return keyword,” then compare its wording with the supplied examples and proposed revision. Done means the guideline is softened to distinguish control-flow returns from functions that should not return a value.