WFY Style Guide

Introduction
General
Indentation, code style
Semicolons
Bracket usage
If, else and switch statements (ternary operator)
Functions
Interfaces
Class Organization, Naming conventions
Naming classes
Naming variables and functions
Naming interfaces
Organizing member variables and functions
Documentation
Testing
Version control
Review Process
Commit Messages
File Organization
Exceptions
Conclusion

Introduction
Maintaining consistent coding practices is essential for producing high-quality software
that is easy to read, understand, and maintain. This style guide outlines the preferred
coding conventions and best practices for our company's projects.

General
Code should be written in a clear, concise, and self-documenting manner.

Use meaningful variable and function names.

WFY Style Guide 1

 Follow the DRY (Don’t repeat yourself) principle.

Use comments to explain complex or non-obvious logic.

Keep line lengths reasonably short, ideally under 100 characters.

Indentation, code style

We do not use spaces, only tabs. One tab should be 4 spaces long across every single
file type.

Semicolons
TypeScript and JavaScript works with or without them, but to be consistent please
use semicolons whenever possible. This helps ensure that the code does not
continue in the next line with a dot.

Bracket usage
It should be clear where code blocks start end begin. To ensure this please use
these conventions:

function main() {
// logic
}

if(statement) {
//logic
}

this.sApi.getData('source').subscribe({
next: res => {

},
error: err => {

}
});

WFY Style Guide 2

 For one liners do not use brackets, just make sure you leave an empty line after
them. For example:

for(let it of array)
it.loadSomething();

if(statement)
doSomething();

callingNextCodeSegment();
doingSomething();

If, else and switch statements (ternary operator)

Use if statements for more complex statements, avoid if-else statements whenever
possible. Try not to get into nested if’s, around 3 layers deep should be the
maximum.
For simple string or number checks use switch statements.

Ternary operators should be used whenever there is a simple if-else situation with
one liners.

//if statement
if((onThing && otherThing) || thirdThing) {
doThisOrThat();
advancedLogic();
}

//if else
if(theCondition) {
doSomething();
theSlumber();
} else {
weDoAdvancedStuff();
pop();
}

//ternary
condition ? trueCase() : falseCase();

Functions

WFY Style Guide 3

 Aim to keep function length under 100 lines.

If a function exceeds this limit, consider refactoring.

Interfaces
We use interfaces for API and component to component communication. Never in the
code should be an ‘any’ as a data type.

I must stress that using interfaces and therefore objects is not necessary the best
practice. Whenever possible please use maps and other simple data types.

Inside interfaces we should mark every variable as optional, unless they are not. This is
to avoid infinite initialization lines.

interface IGoofyInterface {
value?: number,
interestiongValue?: string,
mustHaveValue: number
};

let data: IGoofyInterface = { mustHaveValue: 'value' };

Whenever an interface has more than one field used at once, put them into multiple
lines:

interface IGoofyInterface {
value: number,
interestiongValue?: string,
mustHaveValue: number
};

let data: IGoofyInterface = {

value: 12,
mustHaveValue: 'value'
};

Class Organization, Naming conventions

WFY Style Guide 4

 We use classes for OOP (Object Oriented Programming) and it is important to keep
them well organized for clarity.

Naming classes
Names should be descriptive

Always start with upper case and use camel case

class Animal {}

class GiantBlueWhale extends Animal {}

Naming variables and functions

Use camel case

Functions should always start with a verb

Function scoped variables should always start with an ‘_’

function speak(): void {

let _language: string = 'en'; //only used inside this function
this.nativeLanguage = _language;
}

Naming interfaces
A name of the interface should be conceptually unique, meaning that it would not be
so great to check every time what that interface is and if it’s actually an other
interface or not.

Every interface name starts with an ‘I’ for example:

export interface ISomeApiResponse {

num?: number,
str?: string
};

Organizing member variables and functions

WFY Style Guide 5

 The order of them should be always the following:

Constructor, destructor

Public functions

Public variables

Protected functions

Protected variables

Private functions

Private variables

class Animal {

constructor();

public doSomething(): void {}

public counter: number;

protected doOtherThing(): void {}

protected sum: number;

private doPrivateStuff(): void {}

private secret: string;

class Animal {

public:
Animal();
~Animal();

void doSomething();

int counter;

protected:
void doOtherThing();

int sum;

WFY Style Guide 6

 private:
void doPrivateStuff();

std::string secret;
}

Documentation
Document public functions whenever necessary (meaning you use them in different
parts of the codebase)

/**
* Description that is necessary in this situation
* @param text The parsed text
* @returns the counted unique letters
*/
export function countUniqueLetters(text: string): number {
return 0;
}

Testing
Currently we do manual testing, depending on the project specification later we should
write a testing software.

Version control
Main branch should ONLY be used by the actual project lead. This means the this
person does the review and merge process.

For every new feature, bugfix or anything create a new branch with a descriptive
name. This branch will be deleted after merging into main.

Only push code that works. (no compile errors)

When asking for help, create a PR (Pull Request)

WFY Style Guide 7

 Review Process
When you consider the feature done submit it for review (make a PR). Ask the
project lead for review and an other member of the team. A PR needs to pass 2
reviews in order to be merged in. (Except if the project lead just merges it in).
In the PR description please write a few sentences about the feature. What exactly
did you do and how did you do it.
It is important to learn to read code.

Commit Messages
To keep a consistent commit history please use descriptive commit messages. Also
do not commit unless you have finished something, or you need help with
something.
Some guidelines for good commit messages:

Write commits in English.

Mark your commit messages:

[MINOR] ← A segment of the feature you are working on

[MAJOR] ← You have finished the feature you are working on

[FIX] ← You fixed a bug, or something visual on FE

Try to summarize the contents of the commit in one sentence.

Example of BAD commit message:

pagination works

Same commit message, but the correct way:

[MINOR] Pagination for bookings page

File Organization
Possibly every project requires a different approach. For an Angular application use the
following:

WFY Style Guide 8

 Under ROOT:

node_modules

src

app

directives

footer

header

pages

landing-page

login-page

store-page

assets

interfaces

services

api

routeMemory

Exceptions
Use as few ‘try . . . catch . . . ‘ blocks as you can. Throwing exceptions everywhere
is a bad practice.

When throwing custom exceptions the message should contain the exact place in
the code, so anyone other than the developer can have a better guess as to what
the problem is.

Conclusion
Consistency in coding practices not only enhances code quality but also improves
collaboration among team members. This style guide is a reference to help ensure that

WFY Style Guide 9

 our codebase remains clean, maintainable, and easy to work with. It should be followed
by all developers working on our projects.

WFY Style Guide 10