Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the crate conform to the API guidelines #125

Open
40 of 54 tasks
tcharding opened this issue Nov 18, 2024 · 13 comments
Open
40 of 54 tasks

Make the crate conform to the API guidelines #125

tcharding opened this issue Nov 18, 2024 · 13 comments

Comments

@tcharding
Copy link
Member

tcharding commented Nov 18, 2024

Rust API Guidelines Checklist

  • Naming (crate aligns with Rust naming conventions)
    • Casing conforms to RFC 430 (C-CASE)
    • Ad-hoc conversions follow as_, to_, into_ conventions (C-CONV)
    • Getter names follow Rust convention (C-GETTER)
    • Methods on collections that produce iterators follow iter, iter_mut, into_iter (C-ITER)
    • Iterator type names match the methods that produce them (C-ITER-TY)
    • Feature names are free of placeholder words (C-FEATURE)
    • Names use a consistent word order (C-WORD-ORDER)
  • Interoperability (crate interacts nicely with other library functionality)
  • Macros (crate presents well-behaved macros)
  • Documentation (crate is abundantly documented)
    • Crate level docs are thorough and include examples (C-CRATE-DOC)
    • All items have a rustdoc example (C-EXAMPLE)
    • Examples use ?, not try!, not unwrap (C-QUESTION-MARK)
    • Function docs include error, panic, and safety considerations (C-FAILURE)
    • Prose contains hyperlinks to relevant things (C-LINK)
    • Cargo.toml includes all common metadata (C-METADATA)
      • authors, description, license, homepage, documentation, repository,
        keywords, categories
    • Release notes document all significant changes (C-RELNOTES)
    • Rustdoc does not show unhelpful implementation details (C-HIDDEN)
  • Predictability (crate enables legible code that acts how it looks)
    • Smart pointers do not add inherent methods (C-SMART-PTR)
    • Conversions live on the most specific type involved (C-CONV-SPECIFIC)
    • Functions with a clear receiver are methods (C-METHOD)
    • Functions do not take out-parameters (C-NO-OUT)
    • Operator overloads are unsurprising (C-OVERLOAD)
    • Only smart pointers implement Deref and DerefMut (C-DEREF)
    • Constructors are static, inherent methods (C-CTOR)
  • Flexibility (crate supports diverse real-world use cases)
    • Functions expose intermediate results to avoid duplicate work (C-INTERMEDIATE)
    • Caller decides where to copy and place data (C-CALLER-CONTROL)
    • Functions minimize assumptions about parameters by using generics (C-GENERIC)
    • Traits are object-safe if they may be useful as a trait object (C-OBJECT)
  • Type safety (crate leverages the type system effectively)
    • Newtypes provide static distinctions (C-NEWTYPE)
    • Arguments convey meaning through types, not bool or Option (C-CUSTOM-TYPE)
    • Types for a set of flags are bitflags, not enums (C-BITFLAG)
    • Builders enable construction of complex values (C-BUILDER)
  • Dependability (crate is unlikely to do the wrong thing)
  • Debuggability (crate is conducive to easy debugging)
    (Both done in Make a start on verifying the API #136)
  • Future proofing (crate is free to improve without breaking users' code)
  • Necessities (to whom they matter, they really matter)
    • Public dependencies of a stable crate are stable (C-STABLE)
    • Crate and its dependencies have a permissive license (C-PERMISSIVE)
@tcharding
Copy link
Member Author

The only public dependency is serde and it is stable. arrayvec is unstable but is private. C-STABLE is done.

@tcharding
Copy link
Member Author

Both sered and arrayvec use MIT or Apache 2.0, this crate uses CC0-1.0. C-PERMISSIVE is done.

@tcharding
Copy link
Member Author

Done in #136:

  • C-DEBUG
  • C-DEBUG-NONEMPTY
  • C-COMMON-TRAITS
  • C-SEND-SYNC
  • C-GOOD-ERR

@tcharding
Copy link
Member Author

tcharding commented Jan 21, 2025

Type Safety section:

  • C-NEWTYPE and C-CUSTOM-TYPE: Manually checked function parameters using gg 'pub fn'
  • C-BITFLAG: There is only a single enum Case, it does not need to be a bitflag
  • C-BUILDER: There are no complex data structures in the hex crate

@tcharding
Copy link
Member Author

Future Profing section:

  • C-SEALED: There are two public traits that are meant to be implemented downstream (FromHex and DisplayHex) and one already sealed trait (IsRef).
  • C-STRUCT-PRIVATE: All structs have private fields except the serde ones which are public by design (see also Audit serde module #137)
  • C-NEWTYPE-HIDE: Manually checked public function return types
  • C-STRUCT-BOUNDS: Only the HexToBytesIter has trait bounds (on Iterator)

@tcharding
Copy link
Member Author

Dependability section:

  • C-VALIDATE: Manually checked all public functions.
  • C-DTOR-FAIL and C-DTOR-BLOCK: There are no custom Drop imlps

@tcharding
Copy link
Member Author

checked off up to here (excluding #136 stuff)

@tcharding
Copy link
Member Author

Macros section:

  • C-EVOCOTIVE: the hex test macro is deprecated, the impl_fmt_traits is evocotive already, and fmt_hex_exact is as evocotive as it can be IMO.
  • C-MACRO-ATTR: Done, only applies to impl_fmt_traits
  • C-ANYWHERE: Done in Test impl_fmt_traits in module scope #143
  • C-MACRO-VIS: No visibility specifiers in the two remaining public macros
  • C-MACRO-TY: No $t:ty in the macros

@tcharding
Copy link
Member Author

tcharding commented Jan 22, 2025

Flexibility section:

  • C-INTERMEDIATE: Done, we have two errors and the only one that could include intermediate data already does (position up to which the hex string is valid)
  • C-CALLER-CONTROL: Done, only two instances of clone - both commented and correct.
  • C-GENERIC: Done, manually checked all public functions
  • C-OBJECT: Done, neither the DisplayHex or FromHex traits are dyn compatible because they both have associated types.

@tcharding
Copy link
Member Author

Predictability section:

  • C-SMART-PTR: Done, we don't have smart pointers here.
  • C-CONV-SPECIFIC: Done, no real thinking required since this crate doesn't have typical data types
  • C-METHOD: The only stand alone functions are the sered ones
  • C-NO-OUT: Done, confirm with gg 'pub fn' | grep mut
  • C-OVERLOAD: Done, no use of ops in this crate
  • C-DEREF: No impls of Deref or DerefMut in this crate
  • C-CTOR: Done, manually checked public functions

@tcharding
Copy link
Member Author

Naming section:

  • C-CASE: Done, pretty sure the linter catches these. I checked all public types just for good measure.
  • C-CONV: Done, checked one as_ function and one into_ function - both correct.
  • C-GETTER: Done, grepped for 'fn get'
  • C-ITER: Done, there are no collections in this crate
  • C-ITER-TY: Done, our iterators are kind of internal, and we construct them with explicit constructors
  • C-FEATURE: Done, our only features are default, std, and alloc
  • C-WORD-ORDER: Done, checked manually using output from contrib/api.sh types

@tcharding
Copy link
Member Author

Interoperability section:

  • C-CONV-TRAITS: Done, this crate doesn't have types with data that would suit as_ref, as_mu etc
  • C-COLLECT: Done, there are no collections in this crate
  • C-SERDE: Done, there are no types in this crate that play the role of a data structure
  • C-NUM-FMT: Done, there are no number types in this crate
  • C-RW-VALUE: Done in Document and test HexWriter constructor #144

@tcharding
Copy link
Member Author

Crushing checklists like its my job - only docs to go.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant