Coding Conventions

Frontend Coding Conventions

Commenting

• Comments are only written when necessary. Please ensure that your comment is meaningful and helping others understand the code/logic that you have written
• Always put a space after the comment delimiter (//)

File Structure

Please ensure that your components follow the below file structure:

MyComponent/
--- SubComponent/
--- --- __snapshots__
--- --- index.js
--- --- style.module.scss
--- --- SubComponent.test.js
--- ...
--- index.js
--- style.module.scss
--- MyComponent.test.js

Additional util functions should be named with camel case.

Components that are pages (such as HomePage and LoginPage) belong in the pages folder and while other components that appear on a page belong in the components folder.

Example

The PlantButton component provides a good example of this file structure being used. The top level PlantButton component contains a PlantTreesModal. The modal contains a ControlButton, Plant, and UserFeedback components. Note the camel case stateUtils.js file.

React/JSX Style Convention

The following convention is partially adopted from the Airbnb React/JSX Style Guide

Basic File Rules

• Please only include one component per file
• Always use JSX syntax

Components

• Only use functional component with normal function declaration

// No
Class MyComponent extends React.Component {
    ......
}

// No
const MyComponent = () => {
    ......
}

// Yes
function MyComponent() {
    ......
}

• Explicitly declare all props in the component definition, with props types property defined. If the prop is not required, also specify the default prop value

// No
function MyComponent(props) {
    ......
}

// Yes
function MyComponent({ prop1, prop2, prop3 }) {
   ......
}
MyComponent.propTypes = {
    prop1: PropTypes.string.isRequired,
    prop2: PropTypes.bool,
    prop3: PropTypes.number
};
MyComponent.defaultProps = {
    prop2: false,
    prop3: 0
}

Naming

• Use .js extension for all React Components
• Use PascalCase for component name, e.g. MyComponent, ToDoList, SearchBar
• Use camalCase for their instance, e.g. const myComponent = <MyComponent />
• Always use the component folder name as the component name. Do not directly reference the index file of the component when importing

import MyComponent from "./components/MyComponent"

• All prop names should also use camelCase, avoid using a prop name that is the same as one of the DOM attributes.

Parentheses

• Wrap JSX tags in parentheses when they span more than one line

return (
    <div>
        <h1>Hello World</h1>
    </div>
);

Tags

• When the tag has no children, always use a self-close tag
• When using a self-close tag, always include a single whitespace

// No
<MyComponent key="foo"></MyComponent>

// No
<MyComponent key="foo"/>

// Yes
<MyComponent key="foo" />

String

• All String should be enclosed by double quotes "", not single quote

CSS Convention

This project has a preference for styling using module.scss files. Auto-generated .css files from create-react-app have not been adapted. Material UI styles can be inline using the useStyles function

Backend Coding Conventions

Code Quality

Format

• Line size should not exceed 80 characters.
• Each functional block should be indented by one tab space or four regular spaces.
• Refrain from using code with too many nested blocks, limit to a maximum of 4 levels.
• Make sure to leave each symbol spaced from one another, unless dealing with parentheses, or section commas/semicolons.
• Keep object-key pairs in the same line.

Do:

for (let i = 0; i < 100; i++) {
  if (condition) {
    // do something...
  }
}

Don't:

for( let i=0;i<100;i++ ){
  for( let j=0;j<100;j++ ){
    if(something == somethingElse){
      if(something == somethingElseMore){
      if(something == somethingElseMost){
      // do something...
      }
      }
    }
  }
}

Commenting

• Each functional block should be commented as required, unless trivial.
• Each function/method should have its purpose described above the function prototype, unless trivial.
• Do not put comment under the code it describes.

Naming

• Function, variable, and prototype names must be meaningful.
• Stick to "PascalCase" for classes, and "camelCase" for variables, functions, and properties.
• Usage of acronyms or abbreviations should be commented if not common.

File Structure

• Use same file structure as frontend.
• Organise test files into a separate folder.
• API endpoint types must be clearly labelled in the filename.

General

• Prioritise "const" and "let" over "var" wherever possible.