Trace:
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision |
| blog:2020:01:11:2020-01-11_-_self-documenting_code [2020/01/11 22:34] – created basz | blog:2020:01:11:2020-01-11_-_self-documenting_code [2021/06/15 20:09] (current) – external edit 127.0.0.1 |
|---|
| you can think of it as climbing a ladder of difficulty. first you get "sth that mostly works", then you get "sth that works stable" and then you make it so that others can maintain/understand it as well. writing self documenting code falls into 3rd category -- i.e. it is really hard and most programmers don't reach that point before "senior level" (and some never -- life). ppl heavily commenting code are typically around 2nd level (1st level often has neither comments nor order ;)). | you can think of it as climbing a ladder of difficulty. first you get "sth that mostly works", then you get "sth that works stable" and then you make it so that others can maintain/understand it as well. writing self documenting code falls into 3rd category -- i.e. it is really hard and most programmers don't reach that point before "senior level" (and some never -- life). ppl heavily commenting code are typically around 2nd level (1st level often has neither comments nor order ;)). |
| |
| | note that an excellent feedback loop regarding your coding style + code/documentation balance is a code review. during this process, another human being tries to understand what you meant. getting code reviews from some1 more experienced than yourself is of a great benefit here. |
| | |
| | btw: i've recently added a note to my CV, regarding my ambition/goal: |
| | > Being a least-competent member of a high-end professionals team. |
| | it's always good to be surrounded by ppl you can learn from. |
search
