When you begin writing code, it's very simple to just write anything and not hold yourself accountable. Besides, you're the one that's in your room or office writing the code. Who's paying attention anyways? Well, one person should be, you.
How about when it's not just you looking at the code?
It's simple to slap together a few variables, some strings, a function, and run code. Like magic, there's some output on the console. But how do you know the code is written as it's supposed to be. Is it following best practices? Will someone else who reads it and be able to know what's happening in the code? Is there documentation for the code?
There are a plethora different ways to write quality code, but I'm pretty sure no one wants to read a 10,000 word blog post. Because of that, in this blog post, I'll specify the three easiest ways to achieve the beginning of quality code.
A Linter
Linters from a technical perspective are probably the easiest to implement. A linter simply put, analyzes code that's written and checks it for issues that are specific to a language.
For example, a language that's white-spaced based (like Python) can use tabs OR spaces. A linter may not like the fact that you use tabs AND spaces.
The common scenarios that linters pick up are:
- Errors
- Bugs
- Code quality
- Stylistic errors (like the spaces and tabs debate)
- Structural (think architectural) issues with the code. It's easy to slab some pieces of wood together and say you built a house, but if there are no windows, it may get dark and lonely.
- Best practices. All programming languages have a best practice that you should follow. If you don't know everything about the best practices (who does?), a linter is a great way to implement them
Easy to Understand
The great thing about writing code is there are a ton of different ways to write an application or automation code. The bad thing about writing code is there are a ton of different ways to write an application or automation code.
Yes, that was intentional.
When you're writing code, especially in the beginning, it's often fun to make it as complex as possible. After-all, you want to show off how many for loops you can have embedded in each other and how many different ways you can output data.
Don't.
The idea behind programming and automation code is it makes lives easier. Automation code, for example, provides an easier way to interact with an application or platform instead of having to press a bunch of buttons in a UI.
Don't make it harder than it has to be.
Write code in a way that's efficient and people can understand. Your goal is to get a job done with the least amount of code as possible. When I say the least amount of code as possible, I don't mean write an application or automation code half-way and call it a day. I mean finish the idea, but finish it with the least amount of code as possible.
You want the code to be easy to read, functional, and ensure the ability for others to learn it is there.
Documentation
I understand that writing documentation isn't the most glorious and fun thing in the world, but in all reality, it's crucial. Think about it for a second.
How many times (and yes, I know all tech professionals have had this happen at one time or another) have you tried to do something and it had poor documentation? It doesn't even have to be tech related. It could be that one time you tried to put together a piece of furniture or a grill and the documentation was terrible. I can't tell you how many times I went to put something together for my son, looked at the documentation, and immediately had to go to YouTube and hope someone put it together and recorded it.
Now think about that one time (hopefully many times) you tried to do something and the documentation was great. It makes the process easy, repeatable, and reliable.
It's no different when you're writing code. Whether it's an application, a console program, or automation code. The documentation that you write will help people understand what's happening.
It'll make the process easy, repeatable, and reliable (like that one time you read awesome documentation).
Top comments (2)
I'd suggest this approach:
quii.gitbook.io/learn-go-with-tests/
It pretty much covers all the above.
Yep! There are a ton of awesome ways to tests. I actually love that because they're teaching you Go with TDD concepts. Thanks for sharing :).