CreativeTech Wiki (internal)

Explore

Processes

Clean Code

The Clean Code Golden Rule

It is your developer responsibility to ensure that all code is easy to read and easy to understand by other developers.

Naming

Meaningful Names

Use names that are pronounceable, searchable, expressive and “intention-revealing” for all your variables, arguments, functions, classes, directories, and packages. When naming, be as practical as possible. Don’t be cute. Don’t pun.

// number of days

let d = 10;

// this is better as it more expressive AND you can avoid the comment.

let numberOfDays = 10;

// second options is better

let list = ['mike', 'monica', 'tanvir'];

let listOfFirstNames = ['mike', 'monica', 'tanvir'];

Classes, Functions, Arguments, Variables

Classes

Class name should be “noun” based, like Person, Account, etc. They should be pascal-cased.

Functions

When possible, functions should be “verb” based. They should be camel-cased.

Arguments and Variables

These should be camel-cased.

class Person {

function getFullName(String firstName, String lastName) {

let fullName = firstName + " " + lastname

return fullName

}

Comments

STANDARD COMMENTS: Use comments to tell a story or describe code. Comments belongs next to the “commented” line. Do not separate with a line.

DOCBLOCKS: Use

Docblocks⁠

to define functions for classes. Comments that tell a story can be part of the Docblock.

Docblocks

Adding properly formatted docblocks at the top of files, as well as documenting the use of a function are critical for clean code. Be sure to give a concise description of your file or function, and include a brief explanation of any parameters and returns that are expected.

Example of leading docblock:

<!--

Index: FlexXL (Desktop)

@environment Production

@version 2.0.0

-->

Example of function docblock:

/**

* Two Column Display

* @desc Fn to display two columns

* @param inputEl: element where two columns will live

* @return formattedEl: element formatted with two columns

Code Formatting

General Rules for cleaner code

Clean as you go.

Use Prettier to format your code. This will keep your code 99% clean.

Keep your code well-indented and well-spaced vertically.

Do not use leading spaces at the beginning of a document (this includes GAM). Trailing spaces is ok.

Keep it lean and clean. Remove unnecessary code, comments, and log outputs.

.prettierrc

When started a new project, we use Prettier that we may stay as consistent as possible between developers with formatting. To use Prettier, simply add a .prettierrc file to your project directory and copy the following values.

See here for all

Prettier⁠

options.

{

"arrowParens": "always",

"bracketSameLine": false,

"bracketSpacing": false,

"printWidth": 240,

"proseWrap": "always",

"semi": true,

"singleQuote": true,

"tabWidth": 4,

"trailingComma": "es5",

"useTabs": false

}

Indenting

Indent properly. It matters!

If you encounter poorly indented code in GAM, copy it, paste into you IDE, format it, and copy it back to GAM. Every time you touch a piece of code, it is your responsibility to clean it.

IDE Configuration

Built into your IDE are formatting options you can configure to ensure all files we touch are following the same clean code practice and formatting moving forward.

Enable Prettier As Default Formatter

VS Code Configuration

⁠

⁠

Search for the following rule in Settings: Editor: Default Formatter

Default value: null

Webstorm Configuration

TODO

Format Files On Save

VS Code Configuration

⁠

⁠

Search for the following rule in Settings: Editor: Format On Save

Default value: disabled

Webstorm Configuration

TODO

Add Padding At Top Of Files

VS Code Configuration

⁠

⁠

Search for the following rule in Settings: Editor > Padding: Top

Default value: 0

Webstorm Configuration

TODO

Common Anti-patterns

Use semantic HTML

Don’t use IDs more than once

Use H-tags properly

Functions

Avoid the tendency to write God-functions, functions that do everything. Functions should be small and single-purpose.

The try/catch conundrum — Proper Error Handling

Always do some kind of error-handling to ensure your code will work when something unexpected happens. As a developer, you should be anticipating potential issues as you write your code and guarding against them. It is not necessarily up to a PM or manager to tell you how to guard your code.

A common technique for catching errors is to use a try/catch. However, if you catch an error, you must do something with it. Having an empty catch is an anti-pattern.

Don’t repeat yourself

Avoid repetitive code between classes and functions as best as possible.

Commented code

Avoid commenting out large blocks of code. Over time, that code may have been rewritten or the reason for commenting the code may have been forgotten. It is better to just remove the code and keep your document clean.

Repository Management

.gitignore

All repositories should have a .gitignore file that prevent unnecessary file from being added to the repo. Use this .gitignore file as your starting point for every project.

# VSCode

.vscode/*

!.vscode/settings.json

!.vscode/tasks.json

!.vscode/launch.json

!.vscode/extensions.json

*.code-workspace

# Local History for Visual Studio Code

.history/

# dotenv environment variables file

.env

.venv

env/

venv/

ENV/

env.bak/

venv.bak/

# compiled output

/dist

/tmp

/out-tsc

# IDEs and editors

.idea

.project

.classpath

.c9/

*.launch

.settings/

*.sublime-workspace

.zip

# IDE - VSCode

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.