Writing code that you’re proud of
Almost every time that someone shows me a snippet of their code, I hear a comment like this:
- "This isn’t finished, I have a lot of cleanup to do"
- "I wrote this code a long time ago, it’s not very good"
- "Ignore all these bugs, I haven’t had time to fix them yet"
We’ve all done it. It’s very rare that I hear a developer that is truly proud of their code.
So why aren’t you proud of your code? Part of the reason is that we often combine planning with writing code. I know that purists don’t like that, but the reality is that there are so many details in software that perfect planning is impossible.
The other reason is that we get our code working, and keep telling ourselves that we’ll go back and clean it up later. Then you tell yourself "why fix it if it isn’t broken?" You move on to the next task, and the cycle continues.
Common things that are overlooked:
- Proper exception handling and failure modes
- Properly disposing of unmanaged resources (IDisposable)
- Inefficient coding style
- Missing documentation
- Well thought out architecture
- Comprehensive unit tests & code coverage
- Following established coding standards
- Simplifying to minimize LoC to maintain
This post was inspired by a number of personal projects that I’m releasing as open source. I found myself doing a lot of cleanup work before uploading the source. I’m regretting not spending more time on it when I had written it.
So here is my challenge for you. Write code that you’re proud of! Do a personal code review before checking in your code. Then do a peer code review. If you’re embarrassed by the code you’ve written, go back and fix it. It’s commonly known that fixing the problems early on will have massive returns in the long run.
Will said,
Wrote on May 16, 2008 @ 8:15 am
Missing documentation. I hate people who don’t document their methods and classes thoroughly. Scumbags. Bastards.
It is my displeasure to have to use Leadtools imaging dll’s in one of my projects. Those lasy douches didn’t put ANY xml documentation in their classes. Over a hundred classes, structs and enums; upwards of a thousand methods. NOT. ONE. LINE.
Brent said,
Wrote on May 16, 2008 @ 8:02 pm
To expand on “Simplifying to minimize LoC to maintain:”
- Simplify your public interfaces.
superjason said,
Wrote on May 16, 2008 @ 8:14 pm
Excellent point Brent. I’m doing that on a project I’m working on right now. A common interface that is uses in a number of classes used to have 5 properties/methods. I’ve simplified it down to 1. Now that’s easy to use!
Jeff said,
Wrote on May 16, 2008 @ 11:02 pm
I feel this way about almost everything I write. The final result works, but under the hood it’s usually an ugly mess. It’s not laziness or lack of caring — it’s being rushed by management. I don’t let this happen to personal projects, but I can’t think of the last line of code I wrote for my own enjoyment. Wow, that’s really depressing actually…
Fredrik said,
Wrote on May 17, 2008 @ 2:47 am
Very true. And whats worse, for many developers “I’ll do it later” never comes to pass.
Where I work, we’ve started doing code reviews for for every iteration in an effort to focus on this. Knowing that the work item you’re closing might end up on the big screen being scrutinized by your fellow developers is a nice incentive to take a few minutes to ensure the code passes mustard
jim said,
Wrote on May 17, 2008 @ 6:15 am
Amen, brother! I recently joined a project where the tech lead ACTIVELY DELETES ANY COMMENTS I put in the code! A solution with 30+ projects in it, not one stinkin’ line of code. He’s one of these over-zealous agile folks who thinks the code “should be self-documenting”. Arrrg
Alain said,
Wrote on May 17, 2008 @ 7:45 am
I won’t be ashame of code if I have no sufficient time to do it.
making good code it’s time consuming and
managers don’t understand it. from my experience
I have less problems when I do code which just
work and eventually come back on it when a bug
appear.
It’s all about methodology adopted by the company and
how good is the team leader.
Binny V A said,
Wrote on May 17, 2008 @ 1:14 pm
Nice points. But I think you repeated a point…
* Following established coding standards
* Inefficient coding style
Is there any difference between these two?
Abhishek Tripathi said,
Wrote on May 17, 2008 @ 1:28 pm
Much to my pleasure !! something I strongly feel about. I like the comments to be written and the APIs explained. After joining this new company I found a legacy project being worked upon with the fusion of new dotnet technology. But the fellow programmers are all following the same legacy pattern. No commenting, no documentation and no design. All the modules are being coded on the fly and integrated by implementing new loop holes (make a class public simply because you want to access it from other library).
My manager says that he doesnt want the comments and the code should be self explanatory. IMO! to certain extent documenting everything is unnecessary but to a larger extent it is required.
Good programming practices must be enforced by the enterprises. Having said that, it is the virtue of every programmer to adopt industry recommended standards. I wonder how a programmer doesnt do that.
Interesting Finds: 2008.05.18 - gOODiDEA.NET said,
Wrote on May 17, 2008 @ 8:50 pm
[...] Writing code that you’re proud of Published Saturday, May 17, 2008 9:49 PM by gOODiDEA Filed under: Interesting Finds, Web, Powershell, .NET, Javascript, WinDbg, Utility [...]
Dalton Filho said,
Wrote on May 17, 2008 @ 8:56 pm
I always document code for an odd reason: I don’t trust my memory.
Dew Drop - May 17, 2008 | Alvin Ashcraft's Morning Dew said,
Wrote on May 17, 2008 @ 9:09 pm
[...] Writing Code That You’re Proud Of (Jason Young) [...]
Anis uddin Ahmad said,
Wrote on May 18, 2008 @ 12:47 pm
It’s possible to not having enough time for clean up some code.
But, if there is a chance to a snippet to be edited or visited by other programmer, it’s a MUST to cleaning up, documenting and following standard coding style.
Documenting code for self reference is also an important point.
Thanks for this NICE post.
Fruity Loops said,
Wrote on May 18, 2008 @ 9:03 pm
Jim – Code should be self commenting. This does not mean that methods shouldn’t have XML comments to describe the parameters and what the method does (API Documentation).
Methods should be short enough that they don’t require any additional comments to explain what they do.
I hate it when you get comments in code like:
// Set the object fields
Object.Field1 = Field1.Text
…
// Save the object
Object.Save();
if it is obvious to a developer what the code does, don’t add unnessecary comments.
mibus said,
Wrote on May 18, 2008 @ 9:50 pm
I haven’t got much I’m proud of lately, mostly because I can’t spend countless hours perfecting things – reality gets in the way, and I need to move on and stay productive.
Chris said,
Wrote on May 18, 2008 @ 10:05 pm
Hmmm, the comments on managers not allowing enough time are annoying. Didn’t they allow enough time to get the crappy code done?
I’d be willing to bet that since the term “manager” is even being used as a description of the person driving the development effort, that they probably have no way of measuring or detecting good versus bad code in the first place.
So why not produce the good code and set the expectation for the manager for how long it takes to produce stuff?
Lars Corneliussen said,
Wrote on May 19, 2008 @ 2:45 am
When I post code on my blog I always had to refactor and document it at least a bit to be able to say: “I’m proud of it!”
I should always write code like this.
@Chris: I also don’t like theese arguments. But it is still an issue, and it requires some discipline to just not offer “bad code” to our “managers” – because collegues also do, and it works – sometimes, somehow.
Wöchentliche Rundablage: Silverlight 2, ASP.NET MVC, C# 3.0, .NET 3.5 SP1… | Code-Inside Blog said,
Wrote on May 19, 2008 @ 2:42 pm
[...] Writing code that you’re proud of [...]
Weekly Links: Silverlight 2, ASP.NET MVC, C# 3.0, .NET 3.5 SP1… | Code-Inside Blog International said,
Wrote on May 19, 2008 @ 2:43 pm
[...] Writing code that you’re proud of [...]
Sam said,
Wrote on May 19, 2008 @ 5:11 pm
An inspirational post, good job