Establish consistent patterns for nullable return values in APIs and document them clearly. Use null consistently for “not found” or “unavailable” cases rather than mixing null, undefined, and false. Always document when and why nullable values are returned, explaining the specific conditions that lead to these values.
For return type documentation, specify the nullable type and provide clear explanations:
// Good: Consistent use of null with clear documentation
Returns `WebContents | null` - The `WebContents` owned by this view
or `null` if the contents are destroyed.
Returns `WebFrameMain | null` - A frame with the given process and frame token,
or `null` if there is no WebFrameMain associated with the given IDs.
// Avoid: Mixing null, undefined, and false inconsistently
Returns `string | false` // when documented as `string | null`
Returns `ServiceWorkerMain | undefined` // when other APIs use `null`
Ensure implementation matches documentation - if the docs specify string | null, the implementation should return null, not false or undefined. This consistency helps developers understand and handle edge cases predictably across the entire API surface.
Enter the URL of a public GitHub repository