Saturday, August 21, 2010
Recently, I was shown this quote. The person who showed it (in a general talk, not to me personally and specifically) is a smart person I respect, so I'm going to leave that person un-named. The authors of the quote, Kernighan and Plauger, are legends of the field. In 1979 (the very same year I was first paid to program) they wrote:
1. If a program is incorrect, it matters little what the documentation says.
2. If documentation does not agree with the code, it is not worth much.
3. Consequently, code must largely document itself. If it cannot, rewrite the code rather than increase the supplementary documentation. Good code needs fewer comments than bad code does.
4. Comments should provide additional information that is not readily obtainable from the code itself. They should never parrot the code.
5. Mnemonic variable names and labels, and a layout that emphasizes logical structure, help make a program self-documenting.
In general, I agree with this. Point 5 is really strong. But when I watched that person I respect walk through this quote I suddenly realized, for the first time in all the times I've seen this, that 1 and 2 are wrong. Really. They're wrong.
Imagine you came across this in a code review:
// Process the first 5 elements
for(i = 0; i <= 5; i++)
I hope it's clear that this code actually processes 6 elements. The program is almost certainly incorrect. Perhaps the reason we're reviewing this part of the code is that there is some sort of message in the event log or unprocessed records or incorrect answers that have led us here, suspecting and hoping to find some incorrect code. And look! A comment that disagrees with the code! It's like a giant arrow pointing to the incorrect code. The documentation doesn't agree with the code, and that's great! It makes it really likely that we've found the bug. This sort of thing happens all the time - developers write the correct logic, as agreed in the requirements, into a comment, but sometimes make mechanical errors in representing that logic in code.
If a program is incorrect, comments that represent what the developer hoped or planned or tried to write may be of great value in rendering the program correct (fixing the bug.) If the documentation doesn't agree with the code, with any luck at least one of them is correct.
I still actually agree with the conclusions of the quote, and of those who quote it. Good variable names and function names, well structured code, and written requirements are all more helpful than comments inside the code, as I've written before
. A true conclusion can follow from a false premise. Still, I was initially shocked to find myself disagreeing with these premises, and I wanted to share that insight. And don't feel bad if you leave "translating into English" comments around from time to time. They may surprise you some day.
Thursday, August 19, 2010
Telerik is having an Eastern Canada User Group Tour this fall. Evan Hutnick will visit 6 user groups to speak on Silverlight topics. Here are the details for the East of Toronto event:
Monday, September 13, 2010
Development Best Practices
Location: Whitby Public Library - Room 1B
405 Dundas Street West, Whitby, ON, L1N 6A1
In this session, we will
explore best practices of development with Silverlight. This will include a
look at the current toolset (VS2010/Blend) as well as the different options for
architecture and data access (to MVVM or not to MVVM, WCF RIA Services or not,
etc.), as well as how you can structure your application for intelligent reuse
of styles and resources, making it easier to design a large-scale application
with a unified look and feel.
|6:30 - 7:00
||Socialize and refreshments |
|7:00 - 9:00
See you there!
Tuesday, August 17, 2010
This is a story
you might find hard to believe. A guy's project is cancelled and he's laid off, but he just shows up to his building (without being paid) and keeps working on it. He gets other people to help him and the product actually ships! One of my favourite quotes:
"The secret to programming is not intelligence, though of course that helps. It is not hard work or experience, though they help, too. The secret to programming is having smart friends."
Could this happen today? Almost certainly not. It probably couldn't even happen in another company. Remember the start of all this wasn't the support from former coworkers - that only happened once the product was almost done and the glamour of working unpaid on a feature caught on. The start of this was that a laid-off guy's badge still worked, and then when it finally stopped working he was able to tailgate through the doors every morning. Which leads to my second favourite quote:
"We wanted to release a Windows version as part of Windows 98, but sadly, Microsoft has effective building security."
A fun read and a reminder of how some people felt (and still feel) about creating software.
Sunday, August 15, 2010
I'm collecting link on Windows Phone 7 topics and now is as good a time as any to blog some of them:
Plenty of material no matter how you prefer to learn. Why not get started?
Friday, August 13, 2010
I'm curious about Windows Phone 7, and I've been playing around a bit with the development tools. So when I read that Joey deVilla was holding another of his semi-regular Coffee and Code sessions in downtown Toronto, and bringing his phone, I made the last minute decision to pop down there and join them. I'm really glad I did.
A steady stream of people stopped by, mostly just to look at the phone, but a few to deploy their code onto it and see it in live action. There were technical conversations, and some less technical, and a general good time. Joey's blogged about it
(with pictures) and is looking for folks who think these would be fun where they live. Let him know if you would participate.
Wednesday, August 11, 2010
On August 10th, Udi Dahan came from Haifa, Israel, to Whitby, Ontario, to speak at the East of Toronto .NET Users Group meeting. (Well, OK, he was in Toronto to teach a course.) He was talking about high availability and some architectures that let you keep a system up, for example, even while you're upgrading it. I took a few pictures:
Udi did a great job demonstrating that design up front and thinking about architecture doesn't mean you're not agile. Taking the time to architect something so that it's highly available gives you the freedom to be agile.
Watch for the fall schedule of the East of Toronto group in the next few weeks. And if you're visiting the area and would like to speak, let me know!
Monday, August 09, 2010
Visual Studio 2010 has pretty cool Windows 7 integration. It gets jumplists right, for example:
But it could do more, and this little add-in adds some fun extras.
Here's a taskbar progress bar overlay during a build:
(If your build results in errors or warnings, you'll also get a taskbar icon overlay when it's done letting you know about them.)
And here we have handy thumbnail buttons - for build, debug, and start without debugging:
Give it a whirl! You can download it from the gallery, or use Tools, Extension Manager, Online Gallery right in Visual Studio and search for Taskbar.
Saturday, August 07, 2010
I got a call this week from a recruiter who is trying to find senior C++ developers for a firm with a growing need. He has placed people with them in the past and it's worked out well and they want more. They write performance-sensitive applications for the financial industry and need someone who's comfortable with templates, and has experience with applications that process high volumes of data. If you're interested, drop me an email and I'll forward it to him for you. Good luck!
© Copyright 2021 Kate Gregory
Theme design by Bryan Bell
newtelligence dasBlog 2.3.9074.18820
| Page rendered at Saturday, March 06, 2021 7:14:07 PM (Eastern Standard Time, UTC-05:00)
On this page....
Pluralsight Free Trial
Click Start a FREE 10-Day trial