I was going to email this exclusively to my mentor, xdotx, but I figured there may be others who have a say.
I am about to hop into some heavy documentation reading this week, and frankly, I have never done anything like this before. What advice do you more experienced programmers have on getting to know a piece of software through documentation? Is it, say, like reading a book? Studying for an exam? Memorization? Trial and error? Playing with code while reading? or a mix of all of the above? My initial idea, and please critique this, is to give the documentation a relatively quick read-over, not necessarily consulting with the code itself, just the docs. Then, having gotten a taste for it, I want to start going over sections of the documentation with actual source code on my other monitor, seeing how things are used, etc. From there, I don't know, perhaps creating "play" rulesets to toy with, etc. What do you think? Also, what rules/guidelines exist when it comes to creation of code. What I mean is preferred style of formatting, naming conventions, and all that jazz. As for commits, what is required in the comments? I see many commits in the logs are generally a line or two for small changes, and a paragraph or more for more extensive changes; is this proper? Thanks, Ryan (jphr)
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
