#ActuallyAutistic web dev. Does front of the front-end. Loves perf and minimalism. Prefers HTML, CSS, Web Standards over JS, UX over DX. Hates div disease.
I recommend reading a lot of garbage, hard-to-comprehend, awful code. Then rewrite it. Maybe port the logic to a different programming language in addition to refactoring in the code's original language.
The most important thing to find out when reading code is what happens with the state. Individual lines of code are not important at all. The only thing that matters is understanding the state and how it changes - and if there are leaky holes in the code logic when the state updates unintentionally, incorrectly or the state update is skipped.
The greatest challenge is not with just one snippet of code: sometimes you can have whole app which has multiple levels of badly constructed code. Issues may include: poor naming conventions, varying naming conventions, datatype mismatching, only handling the success path (ignoring any unexpected or error code paths), over-engineering (code having features that are made in case they might be needed, or unnecessary levels of abstraction), comments that do not reflect the code... it is all human stuff.
Trust input and output. Do not trust code. Human is always the error. You are probably wrong, too, until you give in and understand that you are wrong. You can only trust yourself if you do not trust yourself. Hardware failures are almost never the reason for bugs.
I recommend reading a lot of garbage, hard-to-comprehend, awful code. Then rewrite it. Maybe port the logic to a different programming language in addition to refactoring in the code's original language.
The most important thing to find out when reading code is what happens with the state. Individual lines of code are not important at all. The only thing that matters is understanding the state and how it changes - and if there are leaky holes in the code logic when the state updates unintentionally, incorrectly or the state update is skipped.
The greatest challenge is not with just one snippet of code: sometimes you can have whole app which has multiple levels of badly constructed code. Issues may include: poor naming conventions, varying naming conventions, datatype mismatching, only handling the success path (ignoring any unexpected or error code paths), over-engineering (code having features that are made in case they might be needed, or unnecessary levels of abstraction), comments that do not reflect the code... it is all human stuff.
Trust input and output. Do not trust code. Human is always the error. You are probably wrong, too, until you give in and understand that you are wrong. You can only trust yourself if you do not trust yourself. Hardware failures are almost never the reason for bugs.
Thanks Vesa, I completely agree. Understanding the movement and mutation of state is key and getting a view of the big picture. Thanks again