Code standards

Naming and structure

• Class names — Use the design system’s existing class names (e.g. eth-button, eth-button--primary). For custom components, use a clear prefix and consistent naming (e.g. my-card, my-card__title).
• Files and folders — Organize styles and assets in a predictable way. Keep component-related files together and use names that describe the component or feature.
• Variables and tokens — Reuse design system tokens (e.g. --primary, --ethio-gray-100) instead of hard-coding colors or spacing. See CSS variables and Design tokens.

Accessibility

All contributions should keep or improve accessibility:

• Use semantic structure (headings, lists, landmarks) so the page makes sense to assistive technologies.
• Provide visible focus styles and ensure keyboard navigation works.
• Use sufficient color contrast and don’t rely on color alone to convey information.
• Associate labels with form controls and use ARIA only when necessary.

See Accessibility for more.

Consistency with the design system

• Use the same spacing scale (see Spacing) and breakpoints (see Breakpoints) as the rest of the system.
• Reuse existing components and patterns before adding new ones.
• Document new components or tokens so others know how to use them.

Commit messages

Write clear commit messages so the project history stays readable. Use a short summary line; add more detail in the body if needed. Examples:

• feat: add new button variant
• fix: improve contrast in dark theme
• docs: update installation guide

See also

Contributing — How to contribute. Guidance — Design principles and best practices. Testing — How to test your changes.