MSDN Documentation...
-
Am I the only one that looks at some of the MSDN documentation and admits that yes it is correct and yes it does provide relevant information (that has nothing really to do with my question) but aside from that it's entirely unhelpful?:sigh: Sometimes it's the only source that is right (rare, almost endagered) most of the time it's relevant but useless (so common you have to wonder if they do it on purpose). Am I the only one? If not why do they do this? Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL? Why? Why? Why?:^) I think I'm going to fold up shop and start selling watches from door-to-door. It's gotta be easier...:rolleyes:
The worst MSDN pages are those that just have the method, paramter(s) and return type. It so looks like auto generated code documentation. Nothing more then what intellisense gives you. It would be good if they code link to a relevent code sample. I have found that sometimes a code sample exists but in an obscure place. Maybe there could be a way to automate adding more useful links. Like say text matching and then using rating on relevence of links. Or maybe using some kind of if you found this interesting you may also want to see what other people visited next (like Amazon).
-
Am I the only one that looks at some of the MSDN documentation and admits that yes it is correct and yes it does provide relevant information (that has nothing really to do with my question) but aside from that it's entirely unhelpful?:sigh: Sometimes it's the only source that is right (rare, almost endagered) most of the time it's relevant but useless (so common you have to wonder if they do it on purpose). Am I the only one? If not why do they do this? Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL? Why? Why? Why?:^) I think I'm going to fold up shop and start selling watches from door-to-door. It's gotta be easier...:rolleyes:
Yes, err, I mean, no. Again, No. To be roughly correct while still maintaining a positive bottom line To be roughly correct while still maintaining a positive bottom line To be roughly correct while still maintaining a positive bottom line To be roughly correct while still maintaining a positive bottom line
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify! || Fold With Us! || sighist -
Am I the only one that looks at some of the MSDN documentation and admits that yes it is correct and yes it does provide relevant information (that has nothing really to do with my question) but aside from that it's entirely unhelpful?:sigh: Sometimes it's the only source that is right (rare, almost endagered) most of the time it's relevant but useless (so common you have to wonder if they do it on purpose). Am I the only one? If not why do they do this? Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL? Why? Why? Why?:^) I think I'm going to fold up shop and start selling watches from door-to-door. It's gotta be easier...:rolleyes:
When reading MSDN doco the question I most frequently ask myself is (especially in respect of examples) - "Now why would I want to do that!". And it's predictably postmodern in its presentation, too much focus on what (form) and not enough on why (substance). But it sure beats dragging half a dozen CICS manuals out of the the bookshelf, only to find you dont have the one you need, and it'll take six weeks to get it!. PhilD
-
Am I the only one that looks at some of the MSDN documentation and admits that yes it is correct and yes it does provide relevant information (that has nothing really to do with my question) but aside from that it's entirely unhelpful?:sigh: Sometimes it's the only source that is right (rare, almost endagered) most of the time it's relevant but useless (so common you have to wonder if they do it on purpose). Am I the only one? If not why do they do this? Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL? Why? Why? Why?:^) I think I'm going to fold up shop and start selling watches from door-to-door. It's gotta be easier...:rolleyes:
Well, actually I think the MSDN version that shipped with the original release of Visual Studio 6 (the one including that rare jewel "Hardcore VisualBasic" book) was way much better and helpful... :| Back then I had no permanent Internet connection at my workplace, yet I almost always managed to obtain useful help on what I wanted to accomplish. The quality and thoroughness of the examples were better too IMHO.
An interesting form of object-oriented programming: You suggest a novel algorithm, and watch as the rest of your team objects! ;)
-
Am I the only one that looks at some of the MSDN documentation and admits that yes it is correct and yes it does provide relevant information (that has nothing really to do with my question) but aside from that it's entirely unhelpful?:sigh: Sometimes it's the only source that is right (rare, almost endagered) most of the time it's relevant but useless (so common you have to wonder if they do it on purpose). Am I the only one? If not why do they do this? Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL? Why? Why? Why?:^) I think I'm going to fold up shop and start selling watches from door-to-door. It's gotta be easier...:rolleyes:
MSDN really is poor these days. I am sure it used to be better. I used to bemoan the fact that I can't put MSDN on my IPAQ. Most of my core ref. manuals are either .pdf or .chm files, even BOL. But not MSDN. These days, however, I don't miss it because it is virtually useless anyway. But I'd be interested to know: how do you think MSDN could be imporved?
-
code-frog wrote:
Sometimes it's the only source that is right
Watch out for some rare errors though - because MSDN is nearly always accurate, the minority of erroneous documentation pages are even more dangerous than otherwise, because people'd be unsuspecting.
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blogI have found a number of errors in sample code (which of course are one of the easiest to prove, just compile and run). For example the example code for a console app for ConfigurationManager had two bugs I discovered: 1) In Sub DisplayAppSettings() the for at the end: For i = 0 To appSettings.Count Console.WriteLine("#{0} Name: {1} Value: {2}", i, _ keys(i), appSettings(i)) Next i Results in an exception, that is Index was outside the bounds of the array. The line should read: For i = 0 To appSettings.Count - 1 2) In Sub DisplayConnectionStrings() the while loop is missing incrementing i as in the commented line I added below: Dim conEnum As IEnumerator = connections.GetEnumerator() Dim i As Integer = 0 While conEnum.MoveNext() Dim name As String = connections(i).Name ''i += 1 Dim connectionString As String = _ connections(name).ConnectionString Dim provider As String = _ connections(name).ProviderName Console.WriteLine("Name: {0}", name) Console.WriteLine("Connection string: {0}", connectionString) Console.WriteLine("Provider: {0}", provider) End While Obviously these were not test (or not tested correctly). I admit they where easy to fix but still was a (minor) pain in the neck. It is interesting to note that similar code found during a search on connectionStrings is correct, i.e. with the index variable incremented. Thanks, John Leather
-
Am I the only one that looks at some of the MSDN documentation and admits that yes it is correct and yes it does provide relevant information (that has nothing really to do with my question) but aside from that it's entirely unhelpful?:sigh: Sometimes it's the only source that is right (rare, almost endagered) most of the time it's relevant but useless (so common you have to wonder if they do it on purpose). Am I the only one? If not why do they do this? Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL? Why? Why? Why?:^) I think I'm going to fold up shop and start selling watches from door-to-door. It's gotta be easier...:rolleyes:
-
Am I the only one that looks at some of the MSDN documentation and admits that yes it is correct and yes it does provide relevant information (that has nothing really to do with my question) but aside from that it's entirely unhelpful?:sigh: Sometimes it's the only source that is right (rare, almost endagered) most of the time it's relevant but useless (so common you have to wonder if they do it on purpose). Am I the only one? If not why do they do this? Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL? Why? Why? Why?:^) I think I'm going to fold up shop and start selling watches from door-to-door. It's gotta be easier...:rolleyes:
Learning a new computer language with Microsoft documentation is like learning a foreign language with a dictionary. All the words are there, but nothing on how to put them together. Oh well, without Microsoft documentation who'd support all of the third party documentation authors!:doh: Missileman