I think the only other documentation that I've seen that comes close to MSDN is Tech on the Net (for Oracle documentation) and some Javadoc stuff from several years ago (can't comment on it now - haven't used java in ages).
I have found a few minor errors in documentation, but for the most part it's pretty good. Like everyone else mentioned, it's good reference material, not a how-to guide.
MSDN: Pretty good, or pretty bad documentation?
MSDN is good. In fact, MSDN is actually impressive considering the sheer size of the library. I have no doubts that other docs may be better, but on a much smaller scale. I'd love to see anybody get documentation better than MS on such large scale projects..
Y.
Y.
MSDN is good (though I dont use it much myself, then again I use help resources much less than I used to like say 10 years ago ) A couple of issues I do have though are
A/ some things are dumbed down quite a bit
B/ searching is always a PITA
A/ some things are dumbed down quite a bit
B/ searching is always a PITA
MSDN is pretty good to me, I had nothing but good experiences, I think that is because it's by developers, for developers. Though when I was using it, last around half a year ago, it was easier to use Google to search for something in MSDN than the built in search function :)
It has been helpful for me especially when working with MFC and GDI, and it was more than just a reference, it gives enough extra explanations and examples to make you do what you want to achieve.
It has been helpful for me especially when working with MFC and GDI, and it was more than just a reference, it gives enough extra explanations and examples to make you do what you want to achieve.
I spend a fair amount of my time working with code that is not included in MSDN, and can say without hesitation that MSDN is a real help when I can use it.
Some of the stricter unix stuff is also well documented, but rarely at a single, authoritative place, and documentation doesn't always match from the various places you do see it. That said, a lot of the regularly used stuff on linux and unix systems isn't actually strict unix stuff [as there are a whole lot of other, 3rd party libraries floating about].
And if you want to compare it to the documentation of anything that isn't core unix material? Like any of the large number of open source things that are common place on linux systems? The documentation for these are often poor, if not completely absent, and on more than a few occasions I have personally found it to be outright incorrect.
MSDN can honestly use some work, specifically in selecting between versions of the same library [but in other places as well]. The language it is written in though is usually well structured and clear. Honestly, I also like the examples when the use of something isn't really all that clear from the description that can be given in text [as others have said, not in a tutorial sense. It is nice sometimes to see how something fits together though for some things. As an example, MSDN helped me out a fair bit with how .NET attributes fit into regular code properly]
Some of the stricter unix stuff is also well documented, but rarely at a single, authoritative place, and documentation doesn't always match from the various places you do see it. That said, a lot of the regularly used stuff on linux and unix systems isn't actually strict unix stuff [as there are a whole lot of other, 3rd party libraries floating about].
And if you want to compare it to the documentation of anything that isn't core unix material? Like any of the large number of open source things that are common place on linux systems? The documentation for these are often poor, if not completely absent, and on more than a few occasions I have personally found it to be outright incorrect.
MSDN can honestly use some work, specifically in selecting between versions of the same library [but in other places as well]. The language it is written in though is usually well structured and clear. Honestly, I also like the examples when the use of something isn't really all that clear from the description that can be given in text [as others have said, not in a tutorial sense. It is nice sometimes to see how something fits together though for some things. As an example, MSDN helped me out a fair bit with how .NET attributes fit into regular code properly]
I like the MSDN as well, but for reasons I obviously don't understand, certain functions can return values that are not listed as possible return values. There was a thread I made about it. Granted, it was clearly an issue with my computer (and still is), but I think listing all the possible return values is best when listing possible return values. Simply put, they could say "can also return a value from X" in which case it may be a very long tree of possible returns, but at least I'd know the true possible return values.
Quote: Original post by Crazyfool
I like the MSDN as well, but for reasons I obviously don't understand, certain functions can return values that are not listed as possible return values. There was a thread I made about it. Granted, it was clearly an issue with my computer (and still is), but I think listing all the possible return values is best when listing possible return values. Simply put, they could say "can also return a value from X" in which case it may be a very long tree of possible returns, but at least I'd know the true possible return values.
That's impossible without a time machine. Think about it: HRESULT Foo() return the possible error code. It can be reliant on a, say, HRESULT from a third party COM component which might return new errors in the future, that's why there's a failt bit in HRESULTs, or docs say something like "On success, returns X, on failure returns Y, Z, W or other error codes" - because if you code your app on windows 7 assuming only Y, Z or W are possible error codes windows 8 will add a new error code and break your app. Happened in MSDOS btw, when networking was introduced. I think Larry Osterman's blog had more information about that last topic.
Holy crap I started a blog - http://unobvious.typepad.com/
Quote: Original post by bzroom
I've never had a problem with their documentation, infact i think i actually enjoy it. I just make sure to always use google to find what i'm looking for, rather than the MSDN search.
Word! [grin]
Former Microsoft XNA and Xbox MVP | Check out my blog for random ramblings on game development
Quote: Original post by BeanDog
In lecture today, someone noted that they'd found a mistake in some of Microsoft's documentation. The professor then said something along these lines:
"Does that really surprise you? Microsoft has quite a reputation for bad documentation. And bad software."
That last jab reveals the depth of the professor's bias (attacking on an issue unrelated to the question). But I wonder if I'm just biased the other way. I've generally found MSDN to be pretty good, but am I wrong?
Anyone else here have feelings one way or the other on MSDN compared to other technical documentation for programmers?
MSDN documentation is far better than all the average documentation of the last two companies I've worked with, astronomically better than all open source software I've worked with, and better than about 60-70% of all vendor-purchased library documentation I've worked with.
The only part of MSDN that drove me bonkers was the XNA stuff when it was first released.
This is my signature. There are many like it, but this one is mine. My signature is my best friend. It is my life. I must master it as I must master my life. My signature, without me, is useless. Without my signature, I am useless.
Quote: Original post by Sneftel
Universities are Unix shops. Some bias is to be expected.
This. To be fair, it's pretty justified on their part: they don't have the time or resources to teach you to use an IDE at the same time as a programming language (actually, does anyone even really know how to teach use of an IDE?), and Unix does tend to make it easier to do things at the bear-skins-and-stone-knives level. Just as long as you get to use a text editor with mouse support. :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement