Good coding practices

General

Limit Scope of variables
Follow naming conventions
Think about access specifiers (private/public)
Try to define variables/function etc in alphabetical order
Don't call a method until unless it is required i.e scope of calling a method matters
Try not to call a method multiple times in a single API call. Try to pass data between functions
Fetch only data that is necessary. Don't get all details if not required
Similarly, Send only data that is necessary. Don't send all details if not required
Use bulk get and post function calls. Save latency. Make chunks
Create a master data and pass it around functions to save API calls
There should not be unused function arguments
Boolean switch arguments should not be present in function definition. This violates Single Respnsibility Principle
Try to follow REST
Don't call common methods if not all of it is required. Break that method
Use round for floats
Check for variable types int and string , don't compare both. Instead convert both to string and then compare
Normalize case of string, either upper or lower.
Try to model the solution by thinking which Data Structure will be effective. Yes, they are useful.
Add Auth where required
We should not give a user's data to another user
Validate data, strip, int, str, valid json etc
Validate max size in bulk requests
Have retrials for failure cases. Retry should be idempotent
Check for IDE warnings/errors
Check that the code is running
Don't change function contract without refactoring it's usages
No INFO logs if not required. Use debug logs for debugging
Add error logs where required
For bulk APIs instead of looping and fetching a single entity, fetch entity in bulk
Have one source of truth, don't duplicate
Don't create multiple ways of doing a same thing."There should be one-- and preferably only one --obvious way to do it." (see Zen of Python)
Check for I/O Blocking calls, should be either done in async or thread
Variable/Function names should be self explanatory
Environment level constants should be in config
Environment independent constants should be in constants file
Follow DRY
Try to write Pure functions
If any block of code is used >=2 times, try to make it a function . DRY
Enums are used instead of constants whereever applicable
No negatively named boolean variables
Catch clauses are fine grained and catch specific exceptions
Exceptions are not eaten if caught, unless explicitly documented otherwise
APIs and other public contracts check input values and fail fast
Floating point numbers are not compared for equality. Use Decimal instead
Loops have a set length and correct termination conditions. No Infinite While or For Loops
Order/index of a collection is not modified when it is being looped over
Methods return early without compromising code readability
Invalid parameter values handled such that exceptions are not thrown
No sensitive information is logged or visible in a stacktrace
There are no usages of 'magic numbers’
Know your Variables which are immutable
Arrays are checked for out of bound conditions
Comments exist and describe rationale or reasons for decisions in code
A class/module should have only one reason to change. Single Responsibility Principle
Where third-party utilities are used, are returning errors being caught?
Remove any commented out lines.
Function length: For a method above 50 lines, it should be cut into smaller pieces.
Number of method arguments: For the methods and functions, do they have 3 or fewer arguments? Greater than 3 is probably a sign that it could be grouped in a different way.
Some endpoints should be idempotent (Should not do anything if called twice)
Make parallel request for fast processing
Naming a new function → Check if it is defined before or not
Don’t make/calculate X if x is getting used multiple times, instead declare it
Reduce the scope of Action by adding Checks. Like action on a particular status
Use single resource pool per application
Use not (!) to your advantage by not writing many ==
Use code linting tool.
Reformat code
Use dead code detector tools
Always check for division by 0. i.e your divisor should never have value=0

Managing resources acquired

Add strict timeouts for every resource that you are using. Circuit breaker pattern
Don't forget to free the resource. Clear resource in finally statement if necessary
Release resource as soon as they are not required
Reuse resource, don't just create new ones every time
Refresh resources over time, they tend to hog on to memory with time
Know your resource usage limits. The min and the max
Have alerts in place for resource shortage. We can have multiple alerts
If possible dedicate/limit resource tied to a process

Caching

Add caching wherever applicable.
Don't forget to define action points to invalidate cache (on upates/delete and in some cases inserts)
Use memoization whereever applicable for CPU intensive functions
Model your data precisely. hashmap, string, boolean etc
Think of what should happen if the same function get called with same input

Production Bug

Try to look for patterns in the faulty set
If problem is still there, stop/fix it immediately. Look for what damage has been done. Look for how to minimize the damage. Look for other problems that might arise due to this. Fix the damage. Think about where we lacked. Make sure that this doesn't happen in future.
If nothing works, just Restart the server, restart everything :P

Third Party Integration

Test the PROD APIs before releasing
Always deal with domain names and not IPs
Use HTTPS
Have AUTH protected APIs on both sides for example some third parties take callback url this API should be Auth protected
Check for IP filtering
Have sandbox server to test
Prod and Stag AUTH should be different
API contract for PROD and Stag should be same. i.e they must run on the same code
Have API retries on failures
Deine mechanism after final failure occurs
Use statuscake/pingdom to get health checkups for 3rd party API downtime
Check if there is a rate limiting for APIs
If your data is being shared by a file url, make sure the url is not guessable and rate limited
Know exactly when retries will happen for example if you send a non 2XX code most 3rd parties will retry and you might not need that retry to overload your servers OR you don't want to retry if you receive 400 bad request as it will always result in a bad request
Taking any data from 3rd party in a file, upload it to your database/file utility service for future use

Database

Create index for keys in where query
Create index for keys in order by
Decrease the span of the query filtering or sql query by adding a indexed field conditions like if you know that your results are after a certain date and date field is indexed then add that date filter to the query

Logs

Use log rotation
Delete/Backup old files
Decide rotating policy : by date or by size or a mix of both

Subversion control

Don't commit config file

Security

Scripts

* Encoding/Decoding/Marshalling/De-Marshalling*

New feature release

Check for old code compatability

License

rohit-taneja/good-coding-practices

ErrorLooks like something went wrong!

About

Topics

Resources

License

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Error
Looks like something went wrong!

Packages