Slashdot Mirror
Code Reading: The Open Source Perspective
A few books are tackling this subject, including Coder to Developer and Programming Language Pragmatics. These books don't teach you much about a particular language in the way that an introductory text would. Instead, you grow as a skilled developer by studying them and learning from them. That's one of the key things that people are talking about lately, that to be a strong developer requires more than a working knowledge of a language. It requires a familiarity with the strengths, weaknesses, and core features of a language and the base libraries to be efficient.
Code Reading: The Open Source Perspective is one of these books in this small but growing library. In it, Diomidis Spinellis takes you through a large body of code and focuses on several languages, techniques, and facets of development that differentiate strong developers from weak ones. What I like about this book is how much it covers, how practical the information is, and how much Spinellis teaches you. You wont learn a language, which is the complaint of some people who read this book, but if you know one or two you'll be a better programmer.
Perhaps one of the most telling things about the book is that it draws heavily from NetBSD source code, and features over 600 examples to make the point. Examples are often annotated using NetBSD as a reference. This makes sense, because NetBSD is a large project that's relatively stable and mature. Everything from how to define a C structure consistently and sanely to UML diagrams and build systems are covered, making this truly a developer's book. However, even Windows and Mac OS X developers will benefit, despite the BSD focus.
Chapter 1 introduces some of the basic tenets of the book, namely that code is literature and should be read as such. All too often people only read code when they have a specific problem to solve or want to get an example of an API. Instead, if you read code frequently you'll always be learning things and improving your skills. Also, Spinellis discusses the lifecycle of code (including its genesis, maintenance, and reuse), which simply must be taken into account if code is to be good. Poorly skilled developers forget these things and just slap it together, never thinking ahead.
In Chapter 2, a number of concepts basic to any programming language are covered, including the basic flow-control units common to many languages. The book focuses on C, with additional coverage given using C++, Java, and a few other things thrown in for good measure. As such, these chapters -- in fact the whole book -- focuses on concepts common to these languages but absent in some other languages, like Scheme or LISP. One neat section is called "refactoring in the small." It illustrates the real value of the book nicely, in showing you various ways to organize your code and your thoughts for various effects. Oftentimes a book will only teach you one way (which doesn't always suit your needs), and Spinellis' examples do a nice job of escaping that trap, not just here but throughout the book.
Chapter 3, "Advanced C Data Types," focuses on some language-specific matters. These are pointers, structures, unions and dynamic memory allocation, things that most people who code in C may use but only some truly understand well. Again, a somewhat basic chapter, but useful nonetheless. Make sure you read it; chances are you'll learn a thing or two.
In Chapter 4, some basic data structures (vectors, matrices, stacks, queues, maps and hash tables, sets, lists, trees and graphs) are covered. This is an important chapter since it helps you see these structure in real-world use and also helps you understand when to chose one structure over another. While Knuth, CLRS, or other algorithms and data structures texts cover these, they often do so in isolation and at a theoretical level. While their coverage is short, it's to the point and usable by anyone with a modest understanding of C.
Chapter 5, "Advanced Control Flow," the last chapter that deals with actual programming information, is another useful one. Again, short but to the point, this chapter covers things like recursion, exceptions, parallelism, and signals, all topics that have warranted their own books (or major sections in other books) but which are covered in a single chapter here. Still, seeing them side-by-side and in the context of each other and in real-world use provides some justification for the compact presentation.
The remaining chapters of the book go well beyond a normal programming book and focus on projects. These chapters complement the first bunch nicely by focusing on the organization of your code and projects. Chapter 6 deals specifically with many of the commonly identified (but rarely taught) things like design techniques, project organization, build processes, revision control, and testing. A number of things that aren't covered include defining and managing requirements for a release and their specifications, basics on how to use autoconf and automake, and instead rips through a whole slew of topics quite quickly.
Chapter 7 is sure to be controversial for some people: it covers "Coding Standards and Conventions." Some people seem to be big fans of the "if it feels good, do it" style of programming, and instead of writing sane, usable code, what they produce is buggy and messy. This chapter teaches you tried and tested methods of naming files, indentation (and how to do so consistently using your editor to help), formatting, naming conventions (for variables, functions, and classes), as well as standards and processes. The style and standards are (as you would expect) based on NetBSD, which differ slightly from GNU and Linux standards, as well as commonly found Windows practices. However, I think you'll agree that the style is readable with minimal effort, and that goal, coupled to consistency, is paramount in any standard.
Chapter 8 introduces you to documentation, including the use of man pages, Doxygen, revision histories, and the like. Also included are hints at using diagrams for added value. One thing I don't like about this chapter is the opening quote, which sets a bad precedent. It blithely suggests that bad documentation is better than none, which is highly questionable. Misleading docs can be worse than no docs at all, since someone without docs will have to dig through the code in front of them to understand it. Someone with bad docs will rely on the docs and wonder what's broken when things go awry.
Chapter 9 focuses on code architecture, such as class hierarchies, module organization, and even core features like frameworks to chose. This chapter covers a lot of material, and is, despite its size, simply too terse on many of these subjects. It serves as a decent introduction, but doesn't go very far in some places, considering the importance of the material. However, like much of the book, it's a good introduction to the topics at hand.
Chapter 10 also features a lot of good things to know. Granted, you could pick them all up with a lot of hard work and scouring for information, but it's easier to have them presented to you in a cohesive format. The chapter discusses code reading tools, things that you use to help you dig around a large body of code. One you get over a few source files, even if you have well-organized code and interfaces, many changes can require that you inspect the data path. You can do this manually, or you can be assisted with tools. Tools like regular expressions, grep, your editor -- Spinellis shows you how to make use of all of them when you write code. A lot of tools I've never used (but have heard about) are featured, and their use is demonstrated, but of course many tools are simply ignored, focusing on popular ones that will work for most people.
Finally, all of the above is brought together in Chapter 11, "A Complete Example." A small tour of a large, complex piece of code is taken (34,000 lines of Java) as the author makes changes. It's unfortunately in Java, when so much of the book focused on C (why couldn't they have been consistent examples?), but it works. The example itself could have covered a few more things, such as a proper JUnit example, but overall I'm pleased with it.
Overall, Code Reading: The Open Source Perspective is ambitious and worthwhile, both as a complement to a bookshelf of study that includes The Practice of Programming and Design Patterns, and to someone who is growing tired of books on learning a language. At times it feels like the author promised more than he wound up delivering, but it serves as an introduction to a large number of topics. You wont learn a language, and you wont be able to get as much out of the book if you don't engage it with practice, but it's a useful book to get started on the road from being someone who knows a language or two to someone who is a developer, ready to contribute to a team and work on large projects. Never underestimate the skills required to be a good developer, because they go well beyond knowing how to use a language.
You can purchase Code Reading: The Open Source Perspective from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
... you're saying that there's more to it than just getting it done?
Unfortunately, some experienced programmers write like ee cummings, and others like avant-guard poets.
Have you read my blog lately?
You can usually tell someone who's been writing a lot of code by how they write code.
/.
I looked at the slashcode once and I'm fairly sure Taco worked on debugging serial port line noise before starting
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Funny, my colleague posted many good comments here while on the job and he finally got sacked...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Speaking of which, I was recently browsing sourceforge, and happened to notice this project which MUST be a good one since its home page has an error screen:
/home/groups/c/cp/cphp/htdocs/funciones.php on line 4
:)
Fatal error: Cannot redeclare fecha2mysql() in
Not to mention they misspelled 'functions'!
This project can be found here, and there homepage here.
Oh yeah, if you happen to be reading this, agustindondo, no offense intended
<overrated>Insert Sig Here</overrated>
So the bottom line is experience? Then the following holds:
Bad Code + Bad Code + Bad Code = Good Code!
Yeah, right.
--
Select * from users where clue > 0
0 rows selected
I am waiting for the intelliSense to suggest the word!
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
From someone who's had a hand in dealing with function pointers named StupidSuckingGlobalCallbackFunction, trust me, the subject of this post is very, very, very wrong.
I pity the foo that isn't metasyntactic
I would say the concept of getting paid for programming.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
I write COBOL code. Since COBOL is just like writing in English, why should I need to comment?
:)
... on second thought...
Hooray for self-documenting code!!!
There are 10 kinds of people in the world, those who understand binary and those who don't...what about the other 8?
I don't understand
WordStar kicks ass, and joe is like WordStar.
Therefore, joe kicks ass. Alan Cox uses joe.
Unlike vi, joe is easy to operate over all sorts
of defective terminal emulators. For example, vi
users are screwed w/o the escape key. I've seen
that twice, on a real DECstation (OK, you could
use the F11 key to get an escape...) and on a
telnet program for the Mac.
No problem for joe!
Don't get me started on emacs...
Ah, like Vetinari, The Patrician ... he enjoyed reading music. He didn't want to play it, or listen to all that noise, merely to read it.
Do not mock my vision of impractical footwear
If you write Prolog or LISP, nothing can help you.
I am a mix of Cuban-American-Scottish-English-Irish-etc. I applied for minority status for Cuban-American-Scottish-English-Irish-etc's but they told me that there wasn't enough of us to form our own minority.
To all the other Cuban-American-Scottish-English-Irish-etc's out there I say "stand with me. power to the Cuban-American-Scottish-English-Irish-etc's"
Coding Blog
> (I know I'm dating myself here!)
Don't worry, we all do.
I always seem to end up with your code before the week is up.
We might not lend ourselves well to sympathetic portrals in commercials and other media, but every night we can come home in a shiny expensive car, to a nice furnished apartment, and eat some pussy before going to bed.
Eat some pussy before going to bed? You sound pretty whipped to me. I either get my dick sucked by my girl or stick my dick in a pussy and blow a giant load in her mouth or pussy (and sometimes in her ass). I never ever have to eat her pussy. Eating pussy is for lesbians.
I think the idea that geeks can't get laid is a huge misconception. Eventually some woman gives us a chance, and after years of masturbating we have such good sexual control and technique that we're able to make her cum like she's never cum before. That's what happened to me anyways. Having said that, though, having someone to fuck is really not that big of a deal, I don't know why people act like it is and put down people who can't get laid. Yes, sex can be really fucking good, but it doesn't improve you as a person to be getting it. If you were a stupid fuck before getting laid, you're a stupid fuck after getting laid.
And yes, I am one of those open source hippies. But I get paid for leveraging open source technologies. And I get laid. Boo-yah!
Zoot!
Unlike everywhere else, here we're waiting for key-release instead of key-press because the operating environment has a race condition and posts them out of order! Go Sun!
I have this one word for word in my own code. Kinda spooky to see it here, but also nice to know it's not just me.
I use liberal comments in most of my projects
Where precisely does something like "The Bush administration has no right to detain American Citizens as enemy combatants" fit into your projects. I guess it is better (IMHO) than commenting conservatively.