My point here is that readability/maintainability of code is by far the biggest quality of a piece of software. Being able to read the code and understand it rapidly makes everything easier, either bugfixing or modifying/enhancing the code. Think that the next one that might be reading the code might not be as experienced as you with that language so
- avoid using unnecessarily complicated constructs that feed you coder ego but slow down the maintenance activity. You are a good coder, no doubt, but if your code is not readable by the average coder that will have to then you are not making a good service to your colleagues
- Make clear what your code is doing and, if necessary use a comment to clarify what is not evident from the code (I’m not a huge fan of comments because most of them don’t tell anything more than the code). Use comments to refer to a requirement/user-story that is being implemented.
- Stick to the language style guidelines that were set for your team/company
- Tests are code too and often are read/reviewed more than real code : don’t fuck up in tests code just because “this is just a test, this code will not run in production”
Discussion on code quality is huge of course and these are simple rules that will impact on maintainability of your code (since a reviewer is doing the same activity of the next coder which will have to work on your code : read it). If you want to dig deeper into code quality measurement I’ll suggest this work from Idan Amit and Dror G. Feitelson really interesting : https://arxiv.org/pdf/2007.10912.pdf
Comic comes from here