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 PascalCase 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.
500	Internal Server Error	the server encountered an unexpected condition that prevented it from fulfilling the request.

5. Health Checks

• Health checks help with monitoring the uptime of your service so that you can resolve issues quickly and mitigate the impact before it prolongs.
• We should have health checks and maybe later logging.

6. Relevant Links

• Django Coding Style Documentation
• Best Practice Examples about Django Code Conventions

7. Commenting Conventions

• Comments should be written in a new line under the code line we comment on.
• Comments should start with a blank space " " as we write Python code, it is usual.
• Comments should start with capital letters.
• Comments should end with a ".".