-
Notifications
You must be signed in to change notification settings - Fork 360
Open
Labels
docsIssues relating primarily to documentation or API visibility.Issues relating primarily to documentation or API visibility.good first issueA good issue to start contributing to ndarray!A good issue to start contributing to ndarray!tracking-issueIssue to track multiple changes or collect information.Issue to track multiple changes or collect information.
Description
ndarray has a lot of modules! They tend to be a little hard to read through, and it can be hard to know where code should go when adding or modifying the library. I'd like for us to refactor our codebase to follow a few principles for module definition:
- Always have module-level documentation, even for private modules. By telling readers what a module aims to do, we can help contributors know where to add/remove/change code.
- Reduce or eliminate most module-level code, opting for just
mod ...and... use ...declarations. This should make it really fast for contributors to figure out how a module is structured.
This is especially important for public modules, but preferably should be applied to private modules, as well.
Metadata
Metadata
Assignees
Labels
docsIssues relating primarily to documentation or API visibility.Issues relating primarily to documentation or API visibility.good first issueA good issue to start contributing to ndarray!A good issue to start contributing to ndarray!tracking-issueIssue to track multiple changes or collect information.Issue to track multiple changes or collect information.