Choose identifier names that are unambiguous, self-explanatory, and consistent with existing conventions already used elsewhere in the codebase or in the relevant external spec/ecosystem. Before introducing a new name, check how similar concepts are named in sibling modules (e.g. other middlewares, adapters, generics) and reuse that convention rather than inventing a new one. Specifically: - Prefer names whose meaning is unambiguous even without reading the docs. Avoid terms that can be read in opposite ways (e.g. `strict` was rejected because it was unclear whether `true` meant "always redirect" or "only on 404"; it was replaced with the explicit `alwaysRedirect`). Likewise avoid overloading well-known terms incorrectly (e.g. don't call something a "Factory" if it's a single function, not something that creates multiple instances — use `ExceptionFunction`/`HTTPExceptionFunction` instead). - Reuse the same option/parameter name across similar APIs. If one middleware uses `headerName` to configure a header, a new middleware with the same concept should also use `headerName` rather than `header` or `authorization`. - When exporting a named function for a middleware/handler, make sure the function's internal name matches its exported/public name (e.g. `export const languageDetector = ... return async function languageDetector(...)`), and always use a named function (not an anonymous one) so it's identifiable in stack traces/debugging tools. - When introducing a type/option that is specific to this project (not part of a native/standard type), prefix it clearly (e.g. `HonoJsonWebKey` extends the standard `JsonWebKey`) and export it consistently from the shared types module. - When wrapping or re-declaring web/platform APIs (HTML attributes, DOM options, etc.), match the exact casing/spelling defined by the official spec or MDN documentation rather than guessing (e.g. `srcdoc`, `datetime`, `disablePictureInPicture`). - Use the same generic type parameter conventions already established in the codebase (e.g. `E` for `Env`, not `TEnv`) and keep naming consistent across platform-specific builds (e.g. keep `toSSG` consistent between `deno`/`bun` adapters instead of renaming per-platform). - Double check for typos in exported names (e.g. `Uint` → `Unit`) since these become part of the public API and are hard to fix later. Example: ```ts // Bad: ambiguous option name, anonymous function, inconsistent with sibling middleware export const myMiddleware = (options: { authorization?: string; strict?: boolean }) => { return async (c, next) => { ... } } // Good: name matches existing convention, named function, avoids ambiguity export const myMiddleware = (options: { headerName?: string; alwaysRedirect?: boolean }) => { return async function myMiddleware(c, next) { ... } } ``` Applying this standard reduces confusion during code review, prevents churn from repeated renames, and keeps the public API coherent across the whole library.