Documentation
  • Home
  • ABOUT
    • Introduction
    • Terminology
    • Community Code of Conduct
    • Branding Guidelines
    • FAQs
    • Team
    • The OSCA Way
      • Values
      • OSCA Governance
      • Core Contributors Guidelines
      • Core Contributors: Communication
  • COMMUNITY
    • Community Discord Server
    • Chapters
      • Chapter Leads Application
      • Chapter Leads OnBoarding Guide
      • Chapters Design Guide
    • OSS Jobs
    • Roadmap
  • FINANCE
    • Sponsorship Tiers
    • Expense Policy
    • Expenses & Getting Paid
      • Submitting Expenses
      • Approving Expenses
      • Editing Expenses
      • Core Contributors Expense Guidelines
  • OSS PROGRAMS
    • OSCA Open Source Challenge
    • Hacktoberfest
    • Google Summer of Code
    • Google Season of Docs
    • Outreachy
  • CONTRIBUTING
    • Engineering
      • Contribution Guidelines
      • Conventions
    • Design
      • Contribution Guidelines
      • Style Guide
    • Documentation
      • Contribution Guidelines
      • Style Guide
    • Issue Labels
  • PROJECTS
    • Awesome Open Source
    • OSCA Community Website
    • OSF Website
    • OSCA Chapters Directory
    • OSCA Documentation
    • OSCA Design
  • FINANCIAL CONTRIBUTORS
    • Individuals
    • Organizations
Powered by GitBook
LogoLogo

Community

  • Website
  • Chapters
  • Open Source Festival

Socials

  • Discord
  • LinkedIn
  • Others

Sponsor

  • Open Collective
  • GitHub Sponsors

Copyright © Open Source Community Africa

On this page
  • Code
  • Naming
  • Styling

Was this helpful?

Edit on GitHub
  1. CONTRIBUTING
  2. Engineering

Conventions

Conventions include generic patterns that ensure that written code adheres to certain formatting conventions.

Code

  • Tabs or two-space indentation

  • Use shorthand for conditional statements

  • Always open braces on the same line as the previous statement and close braces on the same indent as the original function like so:

function textComponent() {
  return {
    name: "OSCA"
  };
}

Naming

  • Constructor functions should use the TitleCase

  • Variables, directories and methods should use the camelCase

  • Variables or elements with multiple words should always use an underscore between words.

const user_params = null;
  • Private methods should start with a leading underscore to separate them from public methods

const _inputType = inputType;
  • Abbreviations should be avoided please to avoid confusion

  • Comments should include enough information about what a part of code is supposed to do.

// Define default props of the TextBox component

TextBox.defaultProps = {
  className: "",
  disabled: false,
  inputType: "text"
};

Styling

BEM (Block, Element, Modifier) is a component-based approach to web development. The idea behind it is to divide the user interface into independent blocks

Naming Rules:

blockName__elementName_modifierName_modifierValue
  • Names are written in lowercase Latin letters.

  • Each word inside a name begins with an uppercase letter.

  • The block name defines the namespace for its elements and modifiers.

  • The element name is separated from the block name by a double underscore (__).

  • The modifier name is separated from the block or element name by a single underscore (_).

  • The modifier value is separated from the modifier name by a single underscore (_).

  • For boolean modifiers, the value is not included in the name.

PreviousContribution GuidelinesNextDesign

Last updated 4 years ago

Was this helpful?

This project uses the Methodology with a camelCase style. Read the start guide

BEM
here