Note: this post is now available with a tinyurl of http://tinyurl.com/stack-checklist
My earlier post on how to write a good question is pretty long, and I suspect that even when I refer people to it, often they don’t bother reading it. So here’s a short list of questions to check after you’ve written a question (and to think about before you write the question):
Have you done some research before asking the question? 1
Have you explained what you’ve already tried to solve your problem?
Have you specified which language and platform you’re using, including version number where relevant?
If your question includes code, have you written it as a short but complete program? 2
If your question includes code, have you checked that it’s correctly formatted? 3
If your code doesn’t compile, have you included the exact compiler error?
If your question doesn’t include code, are you sure it shouldn’t?
If your program throws an exception, have you included the exception, with both the message and the stack trace?
If your program produces different results to what you expected, have you stated what you expected, why you expected it, and the actual results?
If your question is related to anything locale-specific (languages, time zones) have you stated the relevant information about your system (e.g. your current time zone)?
Have you checked that your question looks reasonable in terms of formatting?
Have you checked the spelling and grammar to the best of your ability? 4
Have you read the whole question to yourself carefully, to make sure it makes sense and contains enough information for someone coming to it without any of the context that you already know?
If the answer to any of these questions is “no” you should take the time to fix up your question before posting. I realize this may seem like a lot of effort, but it will help you to get a useful answer as quickly as possible. Don’t forget that you’re basically asking other people to help you out of the goodness of their heart – it’s up to you to do all you can to make that as simple as possible.
1 If you went from “something’s not working” to “asking a question” in less than 10 minutes, you probably haven’t done enough research.
2 Ideally anyone answering the question should be able to copy your code, paste it into a text editor, compile it, run it, and observe the problem. Console applications are good for this – unless your question is directly about a user interface aspect, prefer to write a short console app. Remove anything not directly related to your question, but keep it complete enough to run.
3 Try to avoid code which makes users scroll horizontally. You may well need to change how you split lines from how you have it in your IDE. Take the time to make it as clear as possible for those trying to help you.
4 I realize that English isn’t the first language for many Stack Overflow users. We’re not looking for perfection – just some effort. If you know your English isn’t good, see if a colleague or friend can help you with your question before you post it.
Go get Noda Time 1.0!
Today is the end of the longest release cycle I’ve been personally involved in. On November 5th 2009, I announced my intention to write a port of Joda Time for .NET. The next day, Noda Time was born – with a lofty (foolhardy) set of targets.
Near the end of a talk *about* Noda Time this evening, I released Noda Time 1.0.0.
It’s taken three years, but I’m immensely proud of what we’ve managed to achieve. We’re far from "done" but I believe we’re already significantly ahead of most other date/time APIs I’ve seen in terms of providing a clean API which reduces *incidental* complexity while highlighting the *inherent* complexity of the domain. (This is a theme I’m becoming dogmatic about on various fronts.)
There’s more to do – I can’t see myself considering Noda Time to be "done" any time soon – but hopefully now we’ve got a stable release, we can start to build user momentum.
One point I raised at the DotNetDevNet presentation tonight was that there’s a definite benefit (in my very biased view) in just *looking into* Noda Time:
- If you can’t use it in your production code, use it when prototyping
- If you can’t use it in your prototype code, play with it in personal projects
- If you can’t use it in personal projects, read the user guide to understand the concepts
I hope that simply looking at the various types that Noda Time providers will give you more insight into how you should be thinking about date and time handling in your code. While the BCL API has a lot of flaws, you can work around most of them if you make it crystal clear what your data means at every step. The type system will leave that largely ambiguous, but there’s nothing to stop you from naming your variables descriptively, and adding appropriate
Of course, I would far prefer it if you’d start using Noda Time and raising issues on how to make it better. Spread the word.
Oh, and if anyone from the BCL team is reading this and would like to include something like Noda Time into .NET 5 as a "next generation" date/time, I’d be *really* interested in talking to you :)