- Use 4-space indentation, no tabs
- Wrap lines so that they don’t exceed 79 characters
- Use blank lines to separate functions and classes, and larger blocks of code inside functions
- When possible, put comments on a line of their own
- Use docstrings
- Use spaces around operators and after commas
- Name your classes and functions consistently; the convention is to use CamelCase for classes and lower_case_with_underscores for functions and methods
- Always use self as the name for the first method argument
- Don’t use fancy encodings if your code is meant to be used in international environments
Variables / functions – use_lower_case_separated_by_underscore
Class names – UseCamelCase
Error classes end in Error, i.e. MyError
I’m an AWS Serverless Hero and the author of Production-Ready Serverless. I have run production workload at scale in AWS for nearly 10 years and I have been an architect or principal engineer with a variety of industries ranging from banking, e-commerce, sports streaming to mobile gaming. I currently work as an independent consultant focused on AWS and serverless.
Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.
- Lambda optimization tip – enable HTTP keep-alive
- You are thinking about serverless costs all wrong
- Many faced threats to Serverless security
- We can do better than percentile latencies
- I’m afraid you’re thinking about AWS Lambda cold starts all wrong
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong