@KevinMarks@mcc I have given up on so many source repos where the build command failed to compile or run the example, and it just isn't quite worth it to try to troubleshoot a problem *before* I try it out.
Another thing I am begging of people who make APIs: When you include sample code in the docs, include the "using"/"use"/"import"/"#include" statements. Please. Please. I just pasted this inline sample code https://mlem.ellpeck.de/articles/ui.html#setting-it-up into my hello world program, and it's failing because the symbol "UntexturedStyle" could not be found. "Are you missing a using directive or an assembly reference?", asks dotnet. Yeah, probably?? because you didn't tell me what using directives I needed?!?
@mcc This is something the UNIX man pages got right nearly 50 years ago. The synopsis included linker flags and #include files needed to call any routine.
@bassplayer They can be done well, with excellent examples and guidance and all, but they can also be just a list of endpoints, and depending on the backend the spec may or may not match the implementation.
@bassplayer In principle I agree with you, and I think a form of executable documentation is the best documentation. An excellent Swagger UI is a great troubleshooting and teaching tool.
But there's no guarantee, and it's easy to say "documentation? oh yeah we have a swagger", which may be glorious or it may mean almost nothing.
@mcc Yeah, that stuff is super annoying. A good thing is, in Visual Studio, you can right click the thing and it'll show you which namespaces it can be found it. Well, for C# at least.
But obviously you shouldn't have to, I completely agree that ofc it should be in the sample code.
Edit: Also, wow, that sample code really likes putting "this" before stuff :O
@mcc I also think it would be good if the very first thing you find on their website is a high level description of what the API does, and why you might want to use it.
@jasonekratz I mean, it would be nice to have one of each. Ideally. I often run into problems where I wanna make something really simple, and the only sample is very complex and it's not clear what is separable lol
@mcc lets be more specific - it should be *good* sample code. Too often I see these ridiculous, absolute bare minimum examples. Make sure the samples really give good working code, not just crap you're throwing on last minute. Of course thats why so many APIs have shitty samples/docs. It's not easy nor quick.
@mcc 100% agree. IMO sample code should be treated like test code: if it doesn't compile and pass, then the build/release must fail. Few systems have the necessary tooling, but I've seen it frequently enough to know that "can't be done" isn't the real reason this isn't more widespread.