Rocket Academy Bootcamp
  • 🚀Welcome to Bootcamp!
  • 🛠️Logistics
    • Course Schedules
    • Course Methodology
    • Required Software
    • LinkedIn Education Badge
  • 📚General Reference
    • Naming, Casing, and Commenting Conventions
    • VS Code Tips
    • Recommended Resources
  • 🪨0: Foundations
    • 0.1: Command Line
    • 0.2: Git
      • 0.2.1: Branches
    • 0.3: GitHub
      • 0.3.1: Pull Requests
    • 0.4: JavaScript
      • 0.4.1: ES6
      • 0.4.2: Common Syntax
      • 0.4.3: Reference vs Value
      • 0.4.4: Classes
      • 0.4.5: Destructuring and Spread Operator
      • 0.4.6: Promises
        • 0.4.6.1: Async Await
    • 0.5: Node.js
      • 0.5.1: Node Modules
      • 0.5.2: NPM
      • 0.5.3: Nodemon
  • 🖼️1: Frontend
    • 1.1: HTML
    • 1.2: CSS
      • 1.2.1: Layout
    • 1.3: React
      • Styling in ReactJs
      • Using Styling Libraries with React
      • React Deployment
    • 1.E: Exercises
      • 1.E.1: Recipe Site
      • 1.E.2: Portfolio Page
      • 1.E.3: World Clock
      • 1.E.4: High Card
      • 1.E.5: Guess The Word
    • 1.P: Frontend App
  • 🏭2: Full Stack
    • 2.1: Internet 101
      • 2.1.1: Chrome DevTools Network Panel
      • 2.1.2: HTTP Requests and Responses
    • 2.2: Advanced React
      • 2.2.1: AJAX
      • 2.2.2: React Router
      • 2.2.3: useContext
      • 2.2.4: useReducer
      • 2.2.5: Environmental Variables
      • 2.2.6: React useMemo - useCallback
    • 2.3: Firebase
      • 2.3.1: Firebase Realtime Database
      • 2.3.2: Firebase Storage
      • 2.3.3: Firebase Authentication
      • 2.3.4: Firebase Hosting
      • 2.3.5: Firebase Techniques
    • 2.E: Exercises
      • 2.E.1: Weather App
      • 2.E.2: Instagram Chat
      • 2.E.3: Instagram Posts
      • 2.E.4: Instagram Auth
      • 2.E.5: Instagram Routes
    • 2.P: Full-Stack App (Firebase)
  • 🤖3: Backend
    • 3.1: Express.js
      • 3.1.1 : MVC
    • 3.2: SQL
      • 3.2.1: SQL 1-M Relationships
      • 3.2.2: SQL M-M Relationships
      • 3.2.3: SQL Schema Design
      • 3.2.4: Advanced SQL Concepts
      • 3.2.5: SQL - Express
      • 3.2.6: DBeaver
    • 3.3: Sequelize
      • 3.3.1: Sequelize One-To-Many (1-M) Relationships
      • 3.3.2: Sequelize Many-To-Many (M-M) Relationships
      • 3.3.3: Advanced Sequelize Concepts
      • 3.3.4 Database Design
    • 3.4: Authentication
      • 3.4.1: JWT App
    • 3.5: Application Deployment
    • 3.E: Exercises
      • 3.E.1: Bigfoot JSON
      • 3.E.2: Bigfoot SQL
      • 3.E.3: Bigfoot SQL 1-M
      • 3.E.4: Bigfoot SQL M-M
      • 3.E.5: Carousell Schema Design
      • 3.E.6: Carousell Auth
    • 3.P: Full-Stack App (Express)
  • 🏞️4: Capstone
    • 4.1: Testing
      • 4.1.1: Frontend React Testing
      • 4.1.2: Backend Expressjs Testing
    • 4.2: Continuous Integration
      • 4.2.1 Continuous Deployment (Fly.io)
      • 4.2.2: Circle Ci
    • 4.3: TypeScript
    • 4.4: Security
    • 4.5: ChatGPT for SWE
    • 4.6: Soft Skills for SWE
    • 4.P: Capstone
  • 🧮Algorithms
    • A.1: Data Structures
      • A.1.1: Arrays
        • A.1.1.1: Binary Search
        • A.1.1.2: Sliding Windows
      • A.1.2: Hash Tables
      • A.1.3: Stacks
      • A.1.4: Queues
      • A.1.5: Linked Lists
      • A.1.6: Trees
      • A.1.7: Graphs
      • A.1.8: Heaps
    • A.2: Complexity Analysis
    • A.3: Object-Oriented Programming
    • A.4: Recursion
    • A.5: Dynamic Programming
    • A.6: Bit Manipulation
    • A.7: Python
  • 💼Interview Prep
    • IP.1: Job Application Strategy
    • IP.2: Resume
    • IP.3: Portfolio
Powered by GitBook
On this page
  • Naming
  • General
  • Functions
  • Booleans
  • Event Handlers
  • Casing
  • Variables
  • Constants
  • Environment Variables
  • File Names
  • HTML Tags
  • HTML Attributes
  • React Components
  • CSS
  • Git Branches
  • URLs
  • SQL Table and Column Names
  • Commenting
  • Inline Comments
  • Function-Level Comments
  1. General Reference

Naming, Casing, and Commenting Conventions

PreviousGeneral ReferenceNextVS Code Tips

Last updated 1 year ago

Naming, casing, and commenting are critical to software engineering because they help us communicate what our code does, preventing miscommunication and bugs. The following are Rocket Academy's naming, casing, and commenting conventions.

Naming

General

In general, variable names should be as specific as needed to prevent miscommunication. For example, for a card game with 2 representations of a card, one the card's HTML element and one a JS Object containing the card's name, suit, and rank, we might name the former cardElement and the latter cardMetadata. Avoid naming either variable card to prevent miscommunication.

Avoid using shorthand in variable names that might be common in , because such terminology may not be universal and can cause confusion and bugs. Strive for precision and concision, prioritising the former where necessary. For example, in Singapore it may be common to use the letter "n" as an abbreviation for "and" and the letter "w" as an abbreviation for "with". Avoid these in variable names because they may not be universal.

Functions

Function names should start with a verb. This is to distinguish functions from data that might take a similar name. For example, the function getRandomNum may return a random number that gets stored in a variable randomNum.

Booleans

Boolean variable names should start with a question word. This is to clearly communicate that this variable stores a boolean. For example, isGameOver and hasPlayerWon would be preferred boolean variable names than gameOver and playerWon because the former more explicitly store booleans.

Event Handlers

By convention, we typically name callback functions that handle events with the prefix handle and suffix event type. For example, we would name the callback function for an onClick event handleClick.

Casing

Variables

Constants

Sometimes we have variables that are constant in our program and used in multiple places, for example number of starting points in a game. To communicate clearly what these constants are and prevent bugs due to string or number misspelling, we often store these variables in "constant" variables, typically near the top of our file or in a separate constants.js file.

Environment Variables

SCREAMING_SNAKE_CASE. MY_ENV_VAR.

File Names

HTML Tags

Lowercase. E.g. <div>

HTML Attributes

Lowercase kebab-case. E.g. <div my-attr="lowercase">hello</div>

React Components

UpperCamelCase. E.g. MyReactComponent

CSS

IDs and classes in kebab-case. Prefix related classes with common prefix for organisation, e.g. .card-image and .card-text.

Git Branches

Git branches are typically named with kebab-case, e.g. my-new-feature.

URLs

URL entities that consist of multiple words are separated by hyphens. For example, www.mysite.com/my-url-entity.

SQL Table and Column Names

SQL table names should be plural and in snake_case, and column names should be singular and in snake_case. SQL is case-insensitive, and SQL commands such as CREATE and WHERE are often capitalised, thus lowercase is preferred for column names. Underscores are preferred over hyphens to separate words because hyphens are special characters in some SQL implementations.

Commenting

Inline Comments

  1. Comments should only exist to clarify code

  2. Start comments with a capitalised word like we would an English sentence

  3. Inline comments go directly above the line or lines they are commenting on

Function-Level Comments

/**
 * A function that sums numbers
 * @param  a {number} number to add together
 * @param  b {number} number to add together
 * @return {number}   a and b added together
 */
var add = function (a, b) {
  return a + b;
};

By default, JavaScript uses for variable names. Treat acronyms like regular words and use for greater readability, e.g. cardHtmlElement instead of cardHTMLElement.

Constants are typically cased with by convention, e.g. NUM_STARTING_POINTS.

There is no definitive file naming case convention for JS. Rocket Academy prefers because it's easier to navigate between words than , where word processors do not consider underscores to be word separators. Some teams use CamelCase for React component file names; this is subjective so long as we are consistent.

For function-level comments in JS, consider using for clearer identification of functions and what they do. JSDoc is a standard format for JS comments, as well as a tool that auto-generates HTML pages that document code files.

The @ symbol in JSDocs signifies a "tag"- some structure of the code to document. In Rocket Academy JavaScript documentation we will be almost exclusively using only the param and return tags in JSDoc formatted comments. See the full list of tags .

📚
SMS language
camelCase
camelCase for the acronym
SCREAMING_SNAKE_CASE
kebab-case
snake_case
JSDoc format
here