3 Practical Code Writing Ethics For Programmers (Short Article)
Every programmer codes a little bit differently. This is always the case since everyone thinks and acts a little differently than their peers, right? So how do we deal with this? How do we deal with this by not being super strict in terms of coding and at the same time, by not killing the creativity of our team. So here are 3 practical code writing ethics that I think we should practice.
#1 Communicate!
Programmers are mainly introverts and it’s hard to get them to communicate with each other. Actual communication can really help us write better code. Why? One example would be communicating with the team if certain functionality is already existing that can be reused in a certain way to avoid the effort of coding the same thing from scratch.
Some programmers don’t communicate well with the team and they sometimes if not most of the time end up coding the same thing. This will only be prevented to the point when the code is now up for code reviews in the Pull Request. But if we practice good communication with our peers, this can simply be prevented before the code review happens. As a result of this, the productivity of the team will improve, lessening turn-around times for code reviews and code revisions.
#2 Write A Story
I’ve seen my fair share of the so-called “spaghetti-coded” projects in my career and the main reason why it's called a “spaghetti” is that the way it was coded was just a mess. It’s all over the place. It’s hard to read and it's hard to follow. So here are some common tricks to remind us how to actually avoid this. Spoiler alert… we already know how to deal with this. We’re just not practicing it.
#2.1 Writing pseudocode and flowcharts
I know… I know… we all know this and sometimes our projects have tight target dates that we skip writing these documents but if we want to be able to write good code, we need to be able to structure the logic properly so that other people can also be able to read and maintain your code.
A good code is a code that mostly everyone can read, understand, and maintain. And of course, a bad code is a code that mostly only the author can read, understand and maintain.
#2.2 Write comments, please
Please place comments on your code especially on the functions, methods, classes that you write. Why? Because sometimes we write complex code that even we will have a hard time reading it. Outside work, we post sticky notes on the refrigerator or leave text messages for other people to let them know an important message, right? So writing comments for your code is actually helpful to you and to someone to understand what you wrote. You know what I’m talking about (wink).
#2.3 Create Markdowns
For better documentation, create a markdown file for your code. It really helps other team members to navigate and understand the purpose of your code and you can also use the markdowns to illustrate how to properly initiate your classes, how to properly invoke your functions and outright describe the functionalities that your code can do. This is a good way to also tell a story about the code that you wrote on a higher level than reading comments.
#3 Adapt to Best Practices
So why do people cling so much about best practices? There are actually a bunch of answers to this single question. And probably one the simplest answer is that it sets a group of programmers on a particular mindset on how to do things. It’s like in music, for the band to jam with each other they need to be able to play on the same key.
Summary
The challenge really for any of us is to be able to collaborate well with others and to identify and use the mediums for us to be able to clearly communicate and collaborate to another down to the low-level details of what we’re doing so the shared 3 practical code ethics here are just a few of many mediums for us to communicate and collaborate with other people.
If you have additions to this topic, you can write a reply to this article. I would love to read your thoughts on this, too.
