How to Read Other People's Code -- And Why
designbygravity.wordpress.com
How to Read Other People's Code -- And Why
1–10 of 60 posts
Re: How to Read Other People's Code -- And Why
#2Of course, i never check in my comments/asserts to the main branch, since i'm not sure whether my understanding is correct
Re: How to Read Other People's Code -- And Why
#3As for the why: I used to decide I didn't like module X, then decide I was going to implement it myself. After some time I would end up with something looking like X, but not nearly as refined. As such, I learned it's better to read others' code and understand it -- much faster than reaching the same conclusions as the original authors w/ crappier code. Of course if after understanding you decide you still think it's crap -- have at it :).
Re: How to Read Other People's Code -- And Why
#4Re: How to Read Other People's Code -- And Why
#5Re: How to Read Other People's Code -- And Why
#6Love that one. A grad student friend I work with, whenever he catches me poring over documentation, always tells me to read the code. Such a seemingly simple tip, but so valuable.
Re: How to Read Other People's Code -- And Why
#7Re: How to Read Other People's Code -- And Why
#8Re: How to Read Other People's Code -- And Why
#9one technique i often use when trying to understand someone else's code is to add in comments myself in my private branch (of the form "I think that X works like Y and Z"), or even better, adding in run-time asserts that I think ought to hold, and then running tests to make sure they do hold. Of course, i never check in my comments/asserts to the main branch, since i'm not sure whether my understanding is correct
i can only speak from my own experience, thought processes and developing skillset. everyone's different. some people can keep track of numerous complex relationships in their head for months on end.
Re: How to Read Other People's Code -- And Why
#10One of the reasons I don't write comments is because it gets outdated so quickly. And I don't need them myself, because I read only the code, even my own. Reading the code makes also for reviewing the code. Quickly changing bits so it makes better sense (like counts outside the for-loop instead of in the statement) etc. And use version-control system to make changes, test them and roll it back (revert). TortoiseSVN h…
/* Does everything required to initialise the UI (DO NOT CALL DIRECTLY - see class foo) */
Get outdated quickly (without being updated) you have big problems.
Equally a one line comment before things like:
// Do this if we can be certain we are in month X
if (!(!x || ($chk(diff(y,o)) && (zSaves you having to draw out a truth table each time. Even if the logic gets tweaked a bit when bugs are found the purpose of the code is likely to remain and so the comment won't age too badly.