Think back to the last time you looked at an unfamiliar block of code. Did you immediately understand what it was doing? If not, you’re not alone – many software developers, including myself, find it challenging to grasp unfamiliar code quickly…
If the doco we’re talking about is specifically an API reference, then the documentation should be written first. Generate code stubs (can be as little as an interface, or include some basic actual code such as validating required properties are included, if you can get that code working purely with a generated template). Then write your actual functional implementation implementing those stubs.
That way you can regenerate when you change the doco without overriding your implementation, but you are still forced to think about the user (as in the programmer implementing your API) experience first and foremost, rather than the often more haphazard result you can get if you write code first.
For example, if writing a web API, write documentation in something like OpenAPI and generate stubs using Swagger.
Yup absolutely. I mentioned web APIs because that’s what I’ve got the most experience with, but .h files, class library public interfaces, and any other time users who are not the implementor of the functionality might want to call it, the code they’ll be interacting with should be tailored to be good to interact with.
Documentation should be generated from code imo
Code should be generated from documentation generated from code
@key @verstra documentation should be generated from neuro-waves, generated from a brainstorm.
This means war
Just run both in a loop until it reaches a state of equilibrium.
Or use LLM to generate the doc from all sources you have. Foolproof 100%
Better yet, use LLM to generate the docs - then use it again to generate the code form the docs. WCPGW
You sound like a CEO. Do you have a spare CTO role?
Could be
.jartoo.If the doco we’re talking about is specifically an API reference, then the documentation should be written first. Generate code stubs (can be as little as an interface, or include some basic actual code such as validating required properties are included, if you can get that code working purely with a generated template). Then write your actual functional implementation implementing those stubs.
That way you can regenerate when you change the doco without overriding your implementation, but you are still forced to think about the user (as in the programmer implementing your API) experience first and foremost, rather than the often more haphazard result you can get if you write code first.
For example, if writing a web API, write documentation in something like OpenAPI and generate stubs using Swagger.
Same for drivers. Generate headers from documentation and distribute it you fucking morons
Yup absolutely. I mentioned web APIs because that’s what I’ve got the most experience with, but .h files, class library public interfaces, and any other time users who are not the implementor of the functionality might want to call it, the code they’ll be interacting with should be tailored to be good to interact with.