DataDog
What topics should we include in the libdatadog developer guide?
With more teams actively contributing to libdatadog it is important we establish some guidelines for how to work within the workspace. We are going to put together a libdatadog developer guide to describe best practices and guidelines. The goal of this document is to increase consistency and ultimately make it easier to contribute to libdatadog through describing best practices and suggesting design patterns that can be made common across the myriad crates in our repo. A non-goal of this document is to debate or describe things that can be handled by automated tooling like linters and code formatters.
The goal of this issue is to collect topics that will be covered in the developer guide. Please reply with topics you think should be included. If the reasoning behind the topic is non-obvious please include a quick description about why it's important. And don't worry, if you can't think of something right away we can always add it later.
The point of this particular issue is not to debate the contents of those topics! We will have plenty of time to bikeshed and litigate later!
Topics to be included:
- TBD
Should we include a section about how to return errors via FFI? Or more broadly, some general API (both Rust and FFI) guidelines?
One suggestion (just so we don't end up second class citizens) - installing pre-reqs, building, and testing on Windows 🙂
One suggestion (just so we don't end up second class citizens) - installing pre-reqs, building, and testing on Windows
@andrewlock Good idea! We should include setup instructions for MacOS, WIndows, and Linux.
Should we include a section about how to return errors via FFI? Or more broadly, some general API (both Rust and FFI) guidelines?
Also how to handle error: some of our APIs return a pointer to a string to the client and it's the client responsibility to free the memory (otherwise, there is a memory leak). Other API don't do that: maybe we should align first the error handling api
