Course Schedule
0: Language and Tooling Teaching Guide
1: Frontend Basics Teaching Guide
2: Backend Basics Teaching Guide
3: Backend Applications Teaching Guide
4: Backend Structure Teaching Guide
5: Full-Stack Applications Teaching Guide
6: Frontend Infrastructure Teaching Guide
7: React Teaching Guide
8: Advanced React Teaching Guide
9: Advanced Topics Teaching Guide
Algorithms Teaching Guide
Interview Prep Teaching Guide
User Experience Teaching Guide
Naming, Casing, and Commenting Conventions
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 a set of naming, casing, and commenting conventions to follow during Coding Bootcamp (primarily for JavaScript), and hopefully beyond.



In general, variable names should be as specific as possible to prevent miscommunication. For example, for a game with 2 JS Objects, 1 an HTML element representing a playing card and 1 a JS Object containing playing 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 SMS language, because such naming may not be universal and can cause confusion and bugs. Strive for precision and concision, prioritising the former whenever 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.


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.


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

Callback functions that handle events are typically prefixed with handle and suffixed with the event type. For example, for the on-click callback function for a deal cards button, we might call it handleDealButtonClick.


Views and Public Asset Folders

You must have directories named views and public for view templates and public asset files respectively. You can change this in the configs, but we recommend keeping the defaults.

EJS File Names

EJS files are named the same as their respective routes in kebab-case. For example, the /recipes route should correspond to an EJS file called recipes.ejs.


The following are common naming conventions for routes, helping to communicate the functionality of each path-method combination.
URL Path
Render a form that will create a new resource.
Accept a POST request to create a new resource.
Render a single resource.
Render a list.
Render a form to edit.
Accept a request to edit.
Accept a request to delete.



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


Sometimes we have variables that are constant in our program and used in multiple places, for example game modes. To communicate clearly what these constants are and prevent bugs due to string or number misspelling, we often store these variables in "constant" variables, often near the top of our file or in a separate constants.js file.
Constants are typically cased with SCREAMING_SNAKE_CASE by convention, e.g. GAME_MODE_DEAL_CARDS.

Environment Variables


File Names

JavaScript file names typically use lowerCamelCase. Other file and folder names typically use kebab-case or snake_case for easy typing and autocomplete in the terminal.


Lowercase. E.g. <div>

HTML Attributes

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


IDs and classes in kebab-case. Prefix classes with identifiers for common grouping, if any, e.g. "card" for card-related CSS classes. .card-image and .card-text.

Git Branches

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


URL entities that consist of multiple words are separated by hyphens. For example,

SQL Table and Column Names

SQL column names should be 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.


For function-level comments, consider using JSDoc format for clearer identification of functions and what they do.
Last modified 2mo ago