Being a developer doesn't mean you're just coding all the time. You code, but you also communicate, interact with other people's code, maybe even get on a zoom call. Whatever it might be that you do, being on the same page is probably a good idea.
In my various development experiences, I've found that setting expectations of what "good code" or "clean code" looks like is a great way to help folks who do not necessarily know what questions to ask or if they even have any questions.
What is good code?
Well, honestly, good code is what you make it to be. As long as it works / compiles / whatever, it's code. You can show your fellow coworkers / cohorts what good code looks like, but until you write down or codify (giggle) what that is, folks are going to write what they want to get the job done.
Why is this necessary?
For a lack of better jokes: so that everyone is speaking the same language. If everyone writes code similarly then it helps code reviews, discovering bugs and pairing in general. I find myself doing at least two things before I really can start thinking about the problem being presented to me when I am pairing with someone:
- Adjusting to the style of the code, whether that is the organization of the CSS rules or how abstracted the JS is.
- Re-reading through everything before making sense of it and making recommendations.
I feel like this goes faster when everyone kinda does things similarly.
Style guides help do the following:
- Ensure everyone is writing similar code
- Ensure readability
- Ramp up new developers to the "expectations" of "good code" or "clean code"
- Clears up any issues regarding the above otherwise vague terms.
What does a good style guide look like?
Well, again, that's up to you! I have some recommendations, though:
- StandardJS (an enforced style guide)
There are many others out there, and some of those out there come with their own tooling, such as Airbnb's
banel-preset-airbnb or even StandardJS'
npm install standard.
Being on the same page with your team with regard to "good code" not only improves communication and team dynamics, but it reduces the "omg who wrote this?" reaction you might have before you pull out git blame :)