Reading code is good right? What pieces of code have people here read through recently? Was it inspirational/educational/helpful? Any code you would recommend to others?
Lots of good code in there, especially in regard of simplicity and beauty. If you're diving into functional programming, be sure to have a look at it, even if you're a beginner like I am.
Aside from the spaghetti code that my predecessor wrote, I've been reading a book called "Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin. The code in the book isn't always interesting for content, but rather for style and craft. He does a great job explaining industry best practices, along with How and Why they are used.
I have been reading the R base library code, mainly to understand the graphics functions. I'm amazed how simple and ordinary it looks. I have never worked on a big software project and it's exciting for me to see how something powerful is built from small chunks here and there.
Last year I spent some time reading the arc source code. It was a lot of fun. I didn't know any Lisp, so the recursions and macros were hard for me to get my head around, but it was amazing to realise that this site is built on some small core concepts which can be grokked if you spare the time.
I loved Douglas Crockford's book Javascript: The Good Parts. Again, I couldn't understand all of it but it gave me a good feel for well-written Javascript code.
That's an awesome book. Anyone interested in Javascript as a language, not just the browser library operations, should definitely read through it.
edit: Disclaimer for any planning on buying it: it only covers the language. There's no browser interaction code at all. I've seen a few people surprised / annoyed at that, but it keeps it lean and focused.
I learnt a few things from the Kohana source. How not to use regular expressions for validating certain strings (URLs) for one. filter_var can do this and a lot faster too.
I suggest anyone who's interested in PHP to take a look.
I've been reading some BSD userland source (awk, sed, trek, and OpenBSD's netcat) parts of Lua and OCaml's VMs, Redis, and Joy. Awk and Lua's source are particularly good, IMHO.
The code that had the biggest impact on me lately was the original J interpreter, though: http://nsl.com/papers/origins.htm . It looks like some sort of crazy brainfuck-ish thing, but it's not a joke. I highly recommend printing it out and trying to get in Arthur Whitney's head. (But if you run it, it will probably just segfault. It's rather cavalier with nonportable function pointer casting. It's prototype code from 20 years ago. If you want a working version, look at J (http://jsoftware.com) or Q (http://kx.com).)
Hacked together a game while doing laundry the other day with it. Read the source later to get an idea of what was going on under the hood. It's good stuff.
I have read through the modifications made to the Linux kernel by the Xenomai project ( http://www.xenomai.org/ ) lately. Its interesting to read up on how they work together with Linux in a symbiotic way.
Gave me some insight into how they created a dual kernel system.
I highly recommend reading through Lamson. Zed Shaw's rants may rub me the wrong way on occasion, but he's a seriously good coder. Lamson is fantastically well-written and documented.
I see this recommended everywhere, so I nabbed it from a library a while ago. My two cents (for others, not picking on you, rhythmAddict):
Ick. Bloated with manager-speak, light on quality suggestions, and massive. Not worth your time. Reading a few coding-suggestion articles here is significantly more likely to improve your code quality.
I think on the whole peoples reaction to Code Complete is very much connected to when in their coding career they first come across. If you come across it early in your career while still inexperienced it can completely change your approach to coding for the better. If you come across it later in your career it just seems like a collection of obvious ideas that you already know.
I came across it pretty early, though admittedly I'd read quite a few suggestion articles & management articles prior to it. It's still largely obvious, and super management-oriented. Even the little check-lists at the end of each chapter reek of a manager looking over someone's shoulder, tsk-ing, and marking "flaws" in code, rather than actually being a useful metric of any sort to measure quality against.
I can't get past the feeling (as it's a subjective assessment, I can't say "fact") that it's a book for non-programmers who are managing programmers, and it's being mis-applied as something a programmer should read. It's meant to raise the minimum code quality on a project, and it very well could with rather poor programmers, but it does so by sacrificing (nay, slaughtering) potentially better strategies which a decent programmer should know / be learning.
"Do X, Y, and Z and your code will improve" is something only managers believe, and they all want to find some magic combination which will work that way. Code Complete bills itself as exactly that.
""Do X, Y, and Z and your code will improve" is something only managers believe"
The thing is, it is absolutely correct for some definitions of X, Y and Z. There are plenty of programmers in the workplace who just suck at constructing code. They don't know how to write good comments, format their code logically and consistently, use good variable and function names, etc. It goes even further: they do not understand why these things are important. I still see plenty of code like this:
bool nothingToDo; // Is there anything to do
....
if (nothingToDo)
{
// We don't need to continue
return;
}
or
if (time.elapsed() > 10) // If ten seconds or more have passed
{...}
Requests to refactor such code are often met with "This is trivial, just step through the code and figure it out", sometimes from senior programmers (at least in title). And these are not necessarily stupid people, they are often good programmers but not very good software engineers. Have you ever read some of the code open sourced by Google and found yourself thinking "Sheetz, this code is ultra clean"? I bet the people responsible for Google's coding guidelines have read Code Complete. I have been involved in writing coding standards a few times and I referred to Code Complete in each of those instances.
I also completely disagree that this book was written for managers. A manager with no technical background is very likely to dismiss refactoring or code layout as wasted time.
they are often good programmers but not very good software engineers
Agreed. There was a gentleman I had the pleasure of working with years ago who wrote an application in Perl that literally performed an inventory of every switch, router and attached device and did so faster than anything I've seen commercially available.
He was a brilliant individual. Myself and a few of his coworkers enjoyed bouncing ideas off of him, often is areas outside of his expertise. When he didn't have an outright "try this instead", he knew what questions to ask to get us mere mortals to think about the solution differently.
If I didn't know the man better, I would say that he intentionally obfuscated his own code. But I get the impression after reviewing several of his projects that he simply thought differently and that expression was displayed in his work. Unfortunately, it made him an island and all of his projects a one-man effort. His manager didn't know good code from bad and didn't require documentation or review. Nobody could support this guy's code except this guy.
A manager with no technical background is very likely to dismiss refactoring or code layout as wasted time.
But they're very likely to throw the biggest "guaranteed to improve code" book they can find, with the biggest company name on it they can find (Microsoft), at all the programmers under them, whether or not it makes sense. And they're more likely to use the book dogmatically, rather than pragmatically, and much of the book seems structured to encourage this use.
I don't think the book encourages this. There are several instances where it concedes that consistency should take precedence over using the "bestest" practice for example. Also, the dogmatic manager will be dogmatic regardless of the book or standard they use as a reference.
Don Hopkins has a nice history of the various ports of SimCity which includes the Micropolis port linked above. [1]
""Micropolis" is the name of the current GPL open source code version of OLPC SimCity. That was the original working title of Will Wright's city simulation game. Since Micropolis is licensed under the GPL, anyone can do anything they want with it that conforms with the GPL, except they can't call it "SimCity" (and a few other limitations to protect EA's trademarks)."
Linux kernel for some time. Not the most well documented, but is full of great examples of how to wring every little ounce of performance from the machine. And, inspite of the low level nature of the code, it's beautifully modular.
39 comments
[ 5.3 ms ] story [ 75.5 ms ] threadLots of good code in there, especially in regard of simplicity and beauty. If you're diving into functional programming, be sure to have a look at it, even if you're a beginner like I am.
Nobody actually likes the standard one in its entirety, particularly Num, Monad, etc.
Last year I spent some time reading the arc source code. It was a lot of fun. I didn't know any Lisp, so the recursions and macros were hard for me to get my head around, but it was amazing to realise that this site is built on some small core concepts which can be grokked if you spare the time.
I loved Douglas Crockford's book Javascript: The Good Parts. Again, I couldn't understand all of it but it gave me a good feel for well-written Javascript code.
edit: Disclaimer for any planning on buying it: it only covers the language. There's no browser interaction code at all. I've seen a few people surprised / annoyed at that, but it keeps it lean and focused.
I learnt a few things from the Kohana source. How not to use regular expressions for validating certain strings (URLs) for one. filter_var can do this and a lot faster too.
I suggest anyone who's interested in PHP to take a look.
"Tornado is an open source version of the scalable, non-blocking web server and tools that power FriendFeed."
http://github.com/facebook/tornado
The code that had the biggest impact on me lately was the original J interpreter, though: http://nsl.com/papers/origins.htm . It looks like some sort of crazy brainfuck-ish thing, but it's not a joke. I highly recommend printing it out and trying to get in Arthur Whitney's head. (But if you run it, it will probably just segfault. It's rather cavalier with nonportable function pointer casting. It's prototype code from 20 years ago. If you want a working version, look at J (http://jsoftware.com) or Q (http://kx.com).)
Hacked together a game while doing laundry the other day with it. Read the source later to get an idea of what was going on under the hood. It's good stuff.
I'm far from being done and don't intend to read all of it, it isn't easy because it's huge !
Ick. Bloated with manager-speak, light on quality suggestions, and massive. Not worth your time. Reading a few coding-suggestion articles here is significantly more likely to improve your code quality.
I can't get past the feeling (as it's a subjective assessment, I can't say "fact") that it's a book for non-programmers who are managing programmers, and it's being mis-applied as something a programmer should read. It's meant to raise the minimum code quality on a project, and it very well could with rather poor programmers, but it does so by sacrificing (nay, slaughtering) potentially better strategies which a decent programmer should know / be learning.
"Do X, Y, and Z and your code will improve" is something only managers believe, and they all want to find some magic combination which will work that way. Code Complete bills itself as exactly that.
The thing is, it is absolutely correct for some definitions of X, Y and Z. There are plenty of programmers in the workplace who just suck at constructing code. They don't know how to write good comments, format their code logically and consistently, use good variable and function names, etc. It goes even further: they do not understand why these things are important. I still see plenty of code like this:
bool nothingToDo; // Is there anything to do
....
if (nothingToDo) {
}or
if (time.elapsed() > 10) // If ten seconds or more have passed
{...}
Requests to refactor such code are often met with "This is trivial, just step through the code and figure it out", sometimes from senior programmers (at least in title). And these are not necessarily stupid people, they are often good programmers but not very good software engineers. Have you ever read some of the code open sourced by Google and found yourself thinking "Sheetz, this code is ultra clean"? I bet the people responsible for Google's coding guidelines have read Code Complete. I have been involved in writing coding standards a few times and I referred to Code Complete in each of those instances.
I also completely disagree that this book was written for managers. A manager with no technical background is very likely to dismiss refactoring or code layout as wasted time.
Agreed. There was a gentleman I had the pleasure of working with years ago who wrote an application in Perl that literally performed an inventory of every switch, router and attached device and did so faster than anything I've seen commercially available.
He quit on negative terms (I can't remember the specifics) and upon examining his code, it was FORTRAN in Perl (http://www.codinghorror.com/blog/2005/04/you-can-write-fortr...).
He was a brilliant individual. Myself and a few of his coworkers enjoyed bouncing ideas off of him, often is areas outside of his expertise. When he didn't have an outright "try this instead", he knew what questions to ask to get us mere mortals to think about the solution differently.
If I didn't know the man better, I would say that he intentionally obfuscated his own code. But I get the impression after reviewing several of his projects that he simply thought differently and that expression was displayed in his work. Unfortunately, it made him an island and all of his projects a one-man effort. His manager didn't know good code from bad and didn't require documentation or review. Nobody could support this guy's code except this guy.
But they're very likely to throw the biggest "guaranteed to improve code" book they can find, with the biggest company name on it they can find (Microsoft), at all the programmers under them, whether or not it makes sense. And they're more likely to use the book dogmatically, rather than pragmatically, and much of the book seems structured to encourage this use.
http://jashkenas.github.com/coffee-script/
I realize it's a huge investment to make, but dammit, every open source project should do something like this.
This has a few different versions (even python) and is pretty solid/concise due to the hardware restrictions of the late 80s.
""Micropolis" is the name of the current GPL open source code version of OLPC SimCity. That was the original working title of Will Wright's city simulation game. Since Micropolis is licensed under the GPL, anyone can do anything they want with it that conforms with the GPL, except they can't call it "SimCity" (and a few other limitations to protect EA's trademarks)."
[1] http://www.donhopkins.com/drupal/node/131