Code Craft - Yellow-Spotted-Lizard/SERLER GitHub Wiki

Code Craft

Intentionality Programming

It is a good practice to name the functions, classes, variables showing their intentions. With this approach the code can be self-documented and more readable.

This is a function with the name disposeStudies which clearly showing what it does.

The following function shows it does a "signout". Without this name, it is hard to tell this functionality from its body.

This is another example with intentional function name.

The following snapshot shows two functions to "add" and "remove" filters. Without the names, it is hard to figure out what they do.

Usage of Small Methods

Small methods are more readable and maintainable. We try to break our code into small functions and classes to get better modularity and readability. It's also easier to follow "single responsibility" principle with smaller functions or classes. Some examples from our code are listed as follows. Some small functions even only contains a single line but it is good abstraction and greatly improved readability.

Usage of Small Unit Tests

We try to keep our test case short, simple and focusing on single aspect. One test case for one facet so we can test our code more fine-grained, and that will enable quick problem locating when something broken. Also we have more complex test case to test the combination of several features.

Coding Standards

W3Schools JavaScript Coding Conventions

We follow a simple JavaScript standard from W3Schools: https://www.w3schools.com/js/js_conventions.asp. Following a good coding standard will improve code readability and make maintaining code easier.

  • use camelCase for identifier names (variables and functions).

    examples:

  • Always put spaces around operators ( = + - * / ), and after commas:

  • Always use 2 spaces for indentation of code blocks:

    We use spaces instead of tabs as indentation, however, we mix 2 and 4 spaces in our code, which is a drawback. This is because we are lack of consideration and agreement on this and we need improvement on this.

  • Always end a simple statement with a semicolon.

  • complex (compound) statements:

    • Put the opening bracket at the end of the first line.

    • Use one space before the opening bracket.

    • Put the closing bracket on a new line, without leading spaces.

    • Do not end a complex statement with a semicolon.

    examples:

    • Functions & conditions

    • try/catch

  • Object Rules

    Place the opening bracket on the same line as the object name. Use colon plus one space between each property and its value. Use quotes around string values, not around numeric values. Do not add a comma after the last property-value pair. Place the closing bracket on a new line, without leading spaces. Always end an object definition with a semicolon.

    example:

  • Line Length < 80

  • Use Lower Case File Names

    example:

Airbnb React/JSX Style Guide

In the front-end development, we try to follow Airbnb React/JSX Style Guide: https://github.com/airbnb/javascript/tree/master/react#quotes.

  • Only include one React component per file

    The example below shows the search component which is the most complex component in our project. For demonstration the methods are folded. As can be seen here there is only one component even for the most complex part in our project.

  • prefer class extends React.Component over React.createClass

    We always use class extends React.Component for every component.

  • Do not use mixins.

    We don't use mixins. We think it's complicated and makes code less predictable and readable.

  • Use PascalCase for React components and camelCase for their instances

    Always use camelCase for prop names.

  • Follow alignment styles for JSX syntax.

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