It's a good idea to always write code that is useful and readable to you and/or someone in the future. It’s easy to wrap oneselves up into writing haphazard code to quickly solve a pressing problem or because their higher-ups are mounting pressure on them, that they forget to focus on writing clean code. I know because I am in that class of people. I’m so focused on delivering a quick result that I’m forsaking code readability, simplicity, and documentation. After the work has been done, I would revisit my old code and that’s when I would begin splitting hairs. I would struggle to read my own code! There is no proper documentation that explains the purpose of the code and that which explains and provides useful context for the different components of the code. What if someone needs my code for important purposes? I could very well be collaborating with a bunch of developers in my team and see that they’re grinding their teeth over the mess I wrote
To prevent (or atleast reduces the chances of) such unfortunate events, it is crucial that when I’m writing programs, I need to frequently think of the softer aspects of the code. The code:
- Should be readable by my future self or someone else
- Should be self-documented. External documentation is a good idea too but it shouldn’t overcomplicate the mechanisms of the code nor should it make redundant what is already self-explanatory or basic
- Should attempt to adhere to best programming practices. If it’s within a company’s software team, it’s necessary to stick to the best practices they are following. If there’s no local set of practices, stick to the programming language’s own best practices (for example, Python’s PEP 8)
- Should be written with future optimism. The code that I’m writing is aiming to solve a real-world problem. I am having motivating thoughts and confidence in my code that I’m contributing towards making some meaningful change for the benefit of humankind. Following the codex of Extropianism is key