5 Dead-Simple Programming Rules For Junior Developers To Write Senior Level Code Even If They Think They Can’t
I’ve been programming for the last 12 years and consumed dozens of books on software development.
Throughout that time, I observed general rules that make quality code that developers love and make a codebase easy to maintain long-term.
The worst codebases I worked in did not follow these rules. Let’s see what they are:
#1. Use pure functions
Pure function properties :
- the function returns the same result for the same arguments
- Calling it has no side effects (no mutation of local/global state or of other components).
Pure functions are easy to test, predictable, and easy to work with. We cannot build modern applications only with pure functions but use them as much as possible!
#2. Make it work, then make it pretty
It is easier to rewrite bad code that gets the job done than write good code from the start.
First, solve the problem, then make the code readable.
#3. Be clear, not clever
Junior programmers like “cool” syntax and code that makes them look “smart.”
- Don’t use regex unless you comment on what it does.
- Use the easiest syntax to understand
- Comment algorithm sections that are hard to understand
#4. Keep application levels separate
Spaghetti code — Code that is unorganized and involves different layers on the same level.
Example: You have the DB query logic in the same function that does logic for handling a request
Rule of thumb: Your function/method/code should do one thing, not two or three.
Think of it like this: If you write the database interaction layer for your app, you should write it so that if tomorrow you decide to switch from MongoDB to PostgreSQL, there should be no modifications in other layers of your application.
#5. Keep mutations on the outskirts of your application
Mutations are operations that modify the outside world/global state:
- POST/PUT requests
- DB insertions
- Writing to files
- Modifying application state
Mutations are not bad, but they can be unpredictable and hard to test.
You should make these operations at the last step of your flow.
Now go out there and write code others will love to read and maintain.
This post was created with Typeshare
