Backend Code Conventions

1. Testing and Documentation

• New functionalities and features must come with unit tests.
• A good unit test should:
  • focus on a single use-case at a time
  • have a minimal set of assertions per test
  • demonstrate every possibility. The rule of thumb is: if it can happen, it should be covered
• Documentation before the implementation of an API is a good practice.
• We are now putting them on the Sidebar under API Documentations.
• Later we will try and use Swagger, too.

2. Variable Naming Convention

• We use snake_case in function and variable names.
• We use CamelCase in class names.

3. Separations of Concerns

• Separation of functions: A function must do one specific thing.
• Separation of modules/things: Different features must be under different classes/functions/places, or folders.

4. Validation of Inputs and Error Handling

We may not encounter with hackers for this project. But knowing the HTTP error codes to facilitate troubleshooting might be nice, so here is a table.

Error Code	Title	Description
200	OK	Standard response for successful HTTP requests. The actual response will depend on the used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request, the response will contain an entity describing or containing the result of the action.
400	Bad Request	The server cannot or will not process the request due to something that is perceived to be a client error.
401	Unauthorized	Although the HTTP standard specifies "unauthorized", semantically this response means "unauthenticated". That is, the client must authenticate itself to get the requested response.
403	Forbidden	User not having the necessary permissions for a resource or needing an account of some sort, or attempting a prohibited action.
404	Not Found	The requested resource could not be found but may be available in the future. Subsequent requests by the client are permissible.