JCooney.NET

Joseph Cooney's Weblog

NAVIGATION - SEARCH

Good Programmers Read Good Code - What code should be essential reading for .NET Developers?

Recently I've been making a conscious effort to start finding and reading more good-quality source code, in an effort to become a better programmer (I won't come out and say I'm good, but it is OK to say you want to get better right). So far this has encompassed the ROTOR Source Code (I haven't read all 3M LOC yet...), and the Mozilla browser source code (once again, only scratching the surface on this one). This week-end I skimmed through the source for the recently released IssueTracker ASP.NET starter kit. IssueTracker seems like a pretty cool sample app, it is nicely architected and the code base is very clean and minimalist.

I think it is a great shame that most programmers don't read more high-quality code. This is purely anecdotal but I would imagine most programmers reading of other code falls into the following categories:

Reading Sample Code in the MSDN or in an article to learn how to do something.
OR
Reading code other team members have written (development/maintenance on an existing code base)

A 20 line demo program designed to illustrate on thing as simply as possible is very different from an application tens or hundreds of thousands of lines long. Studying these to become a good programmer would be like trying to become a good writer by studying sayings from fortune cookies. Reading team-mates code may be a good idea, or not (depending on the quality of your team-mates). You may pick up a few tips and tricks, you might pick up some bad habits too. If the code base is older it may not represent the current recommended practices (I'll use the word "recommended" here instead of "best" so you don't have to drag me out into the street and shoot me). You may learn just as much about what NOT to do (but hey, these lessons are still just as valuable). If you're doing some maintenance work on an existing code base then the focus may be more on making the required changes and getting back to something else rather than learning things.

A book was released recently on reading code, called (unsurprisingly) Code Reading. I borrowed it off Dominic and started reading it a while back, but did not get more than about 100 pages through it. It seemed to contain an equal mix between open-source motherhood statements "many eyes make bugs shallow" and tips that anybody who has ever done any maintenance programming has probably already figured out "set break points in the code and step through it to see how it works". This was about 6 months ago so maybe I am being a little harsh, and it could possibly get better later on.

What code-bases are essential reading for .NET developers? Obviously ROTOR and possibly MONO are golden for anybody working on libraries. Some of the sample from Microsoft like the starter kits and Taskvision should probably be on the list. Andy "MetaBuilder" Smith's free controls are probably a good starting point for webcontrol builders. What about .Text? Ghengis? SharpDevelop? With a finite amount of time and a wealth of good candidates, what is a developer to do? What about non - .NET code bases? Somebody once told me Don Knuth's TeX code base was a thing of beauty....maybe I should be reading that.

Comments (6) -

Frans Bouma
Frans Bouma

A lot of code is very bad. It's also pretty useless to read code alone. The reason for that is that code is the end phase of programming software. What's way more important is the algorithm or set of algorithms the code has to represent.



Only THEN you can learn something, because you can then see the start (algorithm) and end (code) of a transition every developer has to make a lot of times.



Only with the algorithms in your hand you can check if code is good code or not. What's considered 'good' is in a lot of occasions pretty bad.



When I looked at the rotor code when it was initially released, the class lib was very solid, the C# parser was, sorry, very bad, with static hardcoded buffers (in C/C++), strcpy stuff all over the place etc. I don't know if it's become better now, probably.



You can also check what the quality of code is by simple things like:

- what does it do and how many lines of code does it use to perform the tasks it has to do? Mozilla is an example that it is way too bloated

- how long is in development and is it still buggy? Mono is how long in development? It reached a state where it was 'somewhat usable' very quickly, but it is still on that level somewhat. It's very far from being production ready. Not that mono is *bad*, but I wouldn't say it is automatically an example of good code.



If you want to LEARN something, read the book 'Algorithms' by Robert Sedgewick. Very old, but very good and very real even today. Some code is C, but it's the learning experience to learn to write these algorithms in VB.NET or C# to learn the algorithms throughout so next time in your own code you can make the better decisions.



Looking at other people's code is thus IMHO more a waste of time. Look at the theory behind the code, you'll learn much more from that. "Why" is it constructed that way, is WAY more important than "How" is it constructed?.

Chris Taylor
Chris Taylor

While I am in agreement with Frans' view here. I feel that once a developer has a grasp of current coding practices, be it through reading books on Algorithms, Design Patterns and Refactoring, it is always advantageous to see how others have applied these techniques in real life situations. I have and will continue to learn from my own successes and failures and those of others, but mostly I learned from my or others failures to apply a 'recommended' practice. Understanding a 'recommended' practice is one thing, applying it is a whole different level of understanding and good samples are as usefull as bad samples as long as you understand that the bad samples are exactly that bad, and can use this to build insight into the application of a particular technigue.

Frans Bouma
Frans Bouma

In ebook format: ftp://194.85.35.67/BOOKS/Addison.Wesley.Algorithms..pdf

(this is the pascal version)

JosephCooney
JosephCooney

Thanks for commenting Frans - I replied to some of what you said in your blog. You make a good point - how do you know what is good and what isn't (which is, I suppose, why I was asking for reccomendations). Popular != good, and just because a program appears to function well doesn't necissarily mean the code is any good. I kind of picked mozilla because I am a fan of it (as a user), but I have little to no background in C++ so I am quite out of my depth trying to understand it.



I'm not sure if algorythms are what I need, but I will think about it. It probably wouldn't hurt, but finding the most productive use of time is always something I think about.

Alex James
Alex James

I normally agree with most of what Frans has to say, but this time I disagree, you can learn a lot looking at good code.



Things like how people who love coding translate a general pattern to a language... for example how does the Singleton pattern get implemented in C#, Java, etc. To much more complicated things like how to put together a lot of patterns to support a design goal like extensibility.



I learn't a lot looking at the Open source java (like James, Jakarta etc) stuff a few years ago, it started to expose me to Server design ideas, the idea of contexts etc, i.e. meaning I can now if the situation warrants it write my own servers, rather than relying on things like ASP.Net, COM+ etc.



Also most of the time I am convinced you can quickly get a feel for whether code is good or bad too, if you understand what it is trying to do.

Looking at algorithms certainly can be useful, but it won't necessarily make your code good. Studying linguists doesn't automatically mean you can communicate with French people.



Not far from there is learning other languages to get big picture ideas - *different* languages, like e.g. Lisp or Smalltalk. Try one a year. Learning Java if you've done C# .Net doesn't count Wink



I think it's also worth noting that nowadays specs (like HTTP) are probably as important as the algorithms.



But back down to the code... trying to refactor or extend existing code is probably the best way of getting a handle on it - and if that comes easy, then it's probably good code.





Comments are closed