StackOverflow content is licensed under CC BY-SA, so you're legally required to do that if you copy code from an answer. (Unless it's so trivial the code is not copyrightable, but it's better to be on the safe side and attribute the source correctly anyway.)
It already happened to me a couple of times that I had a problem, googled it, and found a helpful SO answer .. by myself some years ago. So this is definitely a helpful suggestion.
If I'm trying to fix a bug, and only have to change one line for it to start working, and the tests still pass - but that line was there for a reason that wasn't commented (some edge case) - I'll likely miss it.
One of the differences i've noticed between myself and some of the junior devs i've worked with. I would usually use the official docs as my first resource, and they would use stack overflow instead.
I'm impatient and Stack overflow can often give me an easy solution. But just as often, it can't and I will spend 30 minutes unproductively trying things with little progress.
As I become a better developer I become more inclined to spend 30 minutes with the documentation instead.
Of course most of interesting problems are not described in documentation.
I know it'll be worth it in the long run, but it feels like I'm wasting time because "I'm not doing anything" - I'm not committing any changes while my coworkers are busy adding new features.
I would use whichever googles first and most relevant results are. Also what the issue is matters.
I don't always go to MDN for javascript issues.
But if I want to know why something is the way it is, I will.
This is not granted, but it happens a lot. Although if the docs are good, you should definitely expect to find good information about deprecation notices there, too! But it's not at all uncommon for conversations about code, on StackOverflow or wherever else, to include the footnotes about what is different and what version changed it.
The people who made the mistake in the OP probably did exactly that.
Take their Azure Python API, which is clearly translated directly from C#: There's a number of functions, which according to the documentation takes a string as an input. The thing is that it won't actually take a string, it will take three or four predefined strings. Everything else will yield no result. The only thing Microsoft doesn't care to put in the documentation is which strings are actually valid and what result you can expect from them.
i was trying to do some work with their crm solution it took me a literal week to find out how to do simple oauth -- mostly because 99% of the documentation only had .NET examples using their own framework!
No, I don't want to do a full reload for every overload of a method. Yes, I might want to see where these extension methods are popping up from, out of nowhere.
The documentation is definitely there, but finding it can be a curse. The search is worse than Google, the site is surprisingly slow for a bunch of static text, and the ability to discover something when you don't know the right search terms is poor because Microsoft name everything in the most generic way possible.
Sometimes there is just no usable documentation for certain things at all. I've even seen documentation for certain Azure things where it just directs you to Stack Overflow!
The content is bad: Quick, is System.DateTime[0] timezone-aware? The examples also use (the harmful and bug-prone) DateTime.Now 5 times, while DateTime.UtcNow is only mentioned once, as a minor aside.
The structure is bad: Is something part of "Core", "Framework", "Standard", or "Platform Extensions"? It's particularly ridiculous that trying to switch from Core to Platform Extensions while you're viewing a Core class (such as System.DateTime[0]), you'll get kicked over to.. Framework.
The layout is bad: Look at System.DateTime's list of constructors[1]. It takes up a whole screenful to say what Python's datetime.datetime constructor[2] paragraph says in three lines.
The design is bad: Compare the method listing of .NET's IDictionary[3] to Scala's Map[4], or Rust's HashMap[5]. Which one makes the type signatures the easiest to parse? Which one helps you get where you want to the fastest?
(Hint: For me, at least, not the one that insists on making everything a uniform shade of baby blue.)
[0]: https://docs.microsoft.com/en-us/dotnet/api/system.datetime?...
[1]: https://docs.microsoft.com/en-us/dotnet/api/system.datetime?...
[2]: https://docs.python.org/3/library/datetime.html?highlight=da...
[3]: https://docs.microsoft.com/en-us/dotnet/api/system.collectio...
[4]: https://www.scala-lang.org/api/current/scala/collection/immu...
[5]: https://doc.rust-lang.org/stable/std/collections/struct.Hash...
For a similar example, Scala's old collections library had a ton of machinery to ensure that `map` and co. would specialize correctly.[0] But the user never sees that, because they added a mechanism called "use cases", that allow you to override the signature shown in the docs with a simpler one.[1]
[0]: https://github.com/scala/scala/blob/v2.12.10/src/library/sca...
[1]: https://www.scala-lang.org/api/2.12.10/scala/collection/immu...
- open source libraries - online casual browser games - development/staging environment counterpart to a .com
Namely, "some dude's gist or blogpost [or stack overflow answer]" not getting updated. Not just that they didn't but that they couldn't.
Unsurprisingly, which you should rely on depends heavily on context. It takes experience and patience to figure out which one is correct based on circumstances.
IDE type search and doc comments are much more likely to be useful.
Recently I found an interesting snippet of C code which was using an sprintf to write a string into a char array. Unfortunately, it contained an off-by-one error where the null terminator would be written outside the char.
I proposed to fix the answer, but for incomprehensible reasons the edit was rejected (!)
If an answer is factually wrong (as opposed to just poorly formatted or missing a few details), generally its better to leave a comment rather than try to edit it.
I agree its not ideal, but suggested edits go into a site-wide review queue, so not everyone reviewing them will necessarily be familiar with C. This makes edit reviews a poor tool for evaluating factual correctness; the comments section and voting system on answers is a better tool for that job.
That's not correct; the questioner can accept any answer, the criteria is that the questioner chooses which answer helped them. There is no connection between votes and acceptance, no claim that "accepted" is endorsement by StackOverflow the company, by subject matter experts, or by "the community".
It is a good thing to test and to do more research, it is even better to add them to the post. Share your knowledge :)
The fastest correct looking answers on SO are usually the accepted answers. I read an post or tweet a few years back suggesting that you have the quickest draw if you want SO rep: create a bare-bones answer, with no research, so that it gets accepted. I understand why: my answers have been on the receiving end of this - I spent way too much time and effort answering and my answer dropped into obscurity.
That's why I no longer answer on SO.
Questions are often long abandoned, and the original questioner won't come back and choose a new correct answer. On a rarely looked at question, it would take years for a correct answer to raise up the ranks.
I've seen various answers which used cryptography dangerously, and asked if there was any way they could be fixed, and I just got the answer you gave. That shouldn't be acceptable when dangerously bad code is being showed to people.
With sufficient "rep" (2000, where an upvote on one of your questions or answers is worth 10), edits don't even require approval from others (before that, they must be peer reviewed before the edit takes effect)
I was explictly told "Inform and educate, don't censor!." -- which from context clearly means "don't edit answers just because they are wrong".
In practice however???
---
The system works well for fast and easy. A system like StackOverflow will never work well for highly specialized tasks and that's alright.
SO is perfectly happy to accept better answers, especially to those which have gone stale and perhaps no longer applicable.
If you are offering further information that can benefit the reader its always welcome.
Its one of the reasons a lot of the more concise answers are not always the accepted answers. Because people do ask quite often : "Okay but why did that fix it"
In-fact : Answering without giving a proper reason for the solution is frowned upon mostly.
Agreed. I find that the "accepted" answer usually gets refined/improved/made more generic after acceptance.
This usually means that the "best" solution over all similar problems is usually further down the list of answers.
* * Cunningham’s law is the one I’m thinking of. https://meta.m.wikimedia.org/wiki/Cunningham%27s_Law
I've spent WAY too much time banging my head on the keyboard while trying to implement a solution posted 3-4 years ago, which doesn't apply in the slightest for the latest version of whatever I'm doing.
If I need to use stackoverflow, these days I make sure I do a few things:
- read a number of answers, comments included. Just because an answer is accepted doesn’t mean it’s the best one
- read API docs for anything I’m unfamiliar with, and make sure I understand how the solution works
- never copy paste; instead use the general idea or concept to rewrite a solution in a safe, future proof manner
- if an answer works but doesn’t feel like the right solution, be prepared to do my own research to find a better approach
Hopefully this results in a better engineered product, but one of the main benefits is learning and expanding knowledge of APIs/techniques.