This was the path I followed to enlightenment after I took my undergrad software engineering course in C in the early 90s. I set out with a similar goal to find what real world systems looked like with proper decomposition, class structure, commenting, etc. At the time FreeBSD was getting a lot of interest, so I decided to dive into that code base a look. That made my head spin and seemed to violate all sorts of tenants we were being taught. Shortly thereafter, I accepted an internship at Microsoft and thought "Aha! Now these guys are doing great and must have a truly excellent software engineering culture. I can really see some good code now."
I cracked open the code base for Excel and PowerPoint and got lost in that for a while. A lot of the Excel code was still based around Simonyi's design in C, and actually had a reasonable core structure given the limitations of C. But it was also a real world system and had an amazing amount of cruft built up around it that was difficult, at best, to understand. Mac PowerPoint at the time was a hodge podge of Pascal, 68000 assembly, C++. Some of the code was clearly written with some serious thought and design, but a large chunk of it wasn't.
My favorite code review during the internship was a bit of assembly that processed a code resource loaded on the Mac to patch in a fix to the OS routines for FileDialogs in order to prevent a crash in our application.
As others noted, the scoring mentioned above is incorrect. Scoring in Go is essentially determined based on territory (empty intersections you 'control') minus the number of your captured stones. Even doing this calculation can be a bit tricky especially when the players have not fully played out the game (one player conceded).
You can try a simple 9x9 version of the game with an AI client by searching for Many Faces of Go. That mini game has an AI that ramps up the difficulty and removes your handicap as you beat it. Its a good way to play around with a simple version of the game.
Slashdot Mirror
This was the path I followed to enlightenment after I took my undergrad software engineering course in C in the early 90s. I set out with a similar goal to find what real world systems looked like with proper decomposition, class structure, commenting, etc. At the time FreeBSD was getting a lot of interest, so I decided to dive into that code base a look. That made my head spin and seemed to violate all sorts of tenants we were being taught. Shortly thereafter, I accepted an internship at Microsoft and thought "Aha! Now these guys are doing great and must have a truly excellent software engineering culture. I can really see some good code now." I cracked open the code base for Excel and PowerPoint and got lost in that for a while. A lot of the Excel code was still based around Simonyi's design in C, and actually had a reasonable core structure given the limitations of C. But it was also a real world system and had an amazing amount of cruft built up around it that was difficult, at best, to understand. Mac PowerPoint at the time was a hodge podge of Pascal, 68000 assembly, C++. Some of the code was clearly written with some serious thought and design, but a large chunk of it wasn't. My favorite code review during the internship was a bit of assembly that processed a code resource loaded on the Mac to patch in a fix to the OS routines for FileDialogs in order to prevent a crash in our application.
As others noted, the scoring mentioned above is incorrect. Scoring in Go is essentially determined based on territory (empty intersections you 'control') minus the number of your captured stones. Even doing this calculation can be a bit tricky especially when the players have not fully played out the game (one player conceded). You can try a simple 9x9 version of the game with an AI client by searching for Many Faces of Go. That mini game has an AI that ramps up the difficulty and removes your handicap as you beat it. Its a good way to play around with a simple version of the game.