Professional Documents
Culture Documents
WFY Style Guide
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.
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 => {
}
});
for(let it of array)
it.loadSomething();
if(statement)
doSomething();
callingNextCodeSegment();
doingSomething();
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
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
};
Whenever an interface has more than one field used at once, put them into multiple
lines:
interface IGoofyInterface {
value: number,
interestiongValue?: string,
mustHaveValue: number
};
Naming classes
Names should be descriptive
class Animal {}
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.
Constructor, destructor
Public functions
Public variables
Protected functions
Protected variables
Private functions
Private variables
class Animal {
constructor();
class Animal {
public:
Animal();
~Animal();
void doSomething();
int counter;
protected:
void doOtherThing();
int sum;
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.
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:
pagination works
File Organization
Possibly every project requires a different approach. For an Angular application use the
following:
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