--- title: "Modal Verbs" canonical: "https://documentation.chaos.com/space/DOCSGUIDE/113291187/Modal%20Verbs" format: markdown --- In general, avoid the use of might, may, should, would! If you can write the sentence without using a modal, it would be best! ### Should vs Must --- Before using *should* or *must*, consider other ways to discuss recommendations or requirements, such as the imperative mood for required actions and a phrase such as *we recommend* for optional ones. Be careful to make your tone helpful, not bossy. **Examples** - You'll need an internet connection to install the upgrade. - We recommend that you wait for us to notify you when we've confirmed that your PC is ready. - Free technical support is available when you register with Microsoft. Here are some examples of avoiding the use of modal verbs, as well as some cases of modal verbs wrong use: :check_mark: **Recommended: **Ensure that the Classroom Share Button conforms to our min-max size guidelines and related color/button templates. :cross_mark: **Not recommended: **The Classroom Share Button **should **conform to our min-max size guidelines and related color/button templates. :check_mark: **Recommended:** The column of the data table that the filter operates on. :cross_mark:** Not recommended: **The column of the data table that the filter **should **operate on. :check_mark: **Recommended: **Whether it's a brand new project or an existing one, perform the following steps. :cross_mark: **Not recommended:** Whether it's a brand new project or an existing one, here's what you **should **do. Use *should *only to describe an action that's **recommended** **but optional**. **Don't** use **should** to indicate **probability**. If you can't make a definitive statement, rephrase or use *might* as a last resort. **Examples** - You *should* back up your data periodically. - If you don't use automatic updating, you *should* check for updates yourself at least once every week. - If the antimalware app is compatible and current, it will be preserved during the upgrade. Use *must *only to describe a **required action**. **Example** - To save copies of a document in the same location, you *must* save each copy with a different file name. ### Can vs May --- When you see *can* in your writing, consider deleting it. *Can* implies ability but not action. Rewrite to describe the action if possible. **Example** - Use the /b option to force a black-and-white screen. When *ability* is what you need to express, it's OK to use *can* to describe actions or tasks that the reader or program is able to do. Use *might* to express possibility but only as a last resort. **Don't use may**, which might be interpreted as providing permission. Don't substitute *could* for *can* unless you're referring to the past. Also avoid using *could,* and use *can* where possible instead. Have in mind that *can* may imply **permission**,** optional action**, or **possibility (possible outcome)**. In general, reserve the use of *may* for official policy or legal considerations such as EULA. ### Might --- Indicates uncertain outcome or possibility. Avoid using it! **Example** - You *might* be prompted to enter your credentials. ### Would --- Avoid using it!