refactor: standardize parameter naming and improve code clarity#13
Merged
Conversation
Add `_json` suffix to the `config` parameter in `new_client()` to match the consistent naming pattern used by all other JSON parameters (`context_json`, `items_json`, `terms_json`). Updates both the Rust FFI function signature and the C header declaration to use `config_json`. This creates consistent naming across the FFI interface where all JSON string parameters are explicitly marked with the `_json` suffix, making the parameter types clear.
Remove unnecessary `_str` suffixes from function parameters and internal variables where the type is already clear from context. This simplifies variable names while maintaining clarity, as the string type is evident from function signatures and usage context.
This change updates function parameters throughout the codebase to use more descriptive names and idiomatic Rust types. Function signatures now use `&str` instead of `&String` and `&[u8]` instead of `&Vec<u8>` for better flexibility. These types accept both owned and borrowed data, making the functions easier to call from different contexts. The changes also improve consistency by using descriptive variable names like `identifier` instead of `ident`, making the code more self-documenting.
…larity This change updates the parameter name to better describe what it represents, which is a complete operation that includes setup, execution, and result processing, rather than just a simple FFI call. The new name aligns with the method name `executeFFIOperation` and makes the code more self-documenting.
calvinbrewer
approved these changes
Jul 2, 2025
coreyhn
added a commit
that referenced
this pull request
Jul 6, 2025
This change updates utility function names and parameters to better reflect their ownership semantics. Changes include: - Rename `string_to_c_str` to `string_to_c_string` to correctly indicate it returns an owned `CString` rather than a borrowed `CStr` - Update parameter names from `c_string_ptr` to `c_str_ptr` in functions that work with borrowed `CStr` types The naming now follows this pattern: `c_str` for borrowed C strings (`CStr`) and `c_string` for owned C strings (`CString`). This makes ownership semantics clear. This builds upon and improves the standardization in PR #13.
coreyhn
added a commit
that referenced
this pull request
Jul 6, 2025
This change updates utility function names and parameters to better reflect their ownership semantics. Changes include: - Rename `string_to_c_str` to `string_to_c_string` to correctly indicate it returns an owned `CString` rather than a borrowed `CStr` - Update parameter names from `c_string_ptr` to `c_str_ptr` in functions that work with borrowed `CStr` types The naming now follows this pattern: `c_str` for borrowed C strings (`CStr`) and `c_string` for owned C strings (`CString`). This makes ownership semantics clear. This builds upon and improves the standardization in PR #13.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR is a small tidy-up and naming consistency sweep (mostly for my own peace of mind), but it should make things clearer for anyone else wandering on through.
&strand&[u8]instead of&Stringand&Vec<u8], and switching to more descriptive names likeidentifier. I also removed redundant_strsuffixes where the type is already clear, keeping things concise but readable. I also standardized JSON parameter naming in the FFI interface, adding a_jsonsuffix where appropriate for consistency with other parameters likecontext_json,items_json, andterms_json.$ffiCallparameter to$operationto better reflect its purpose as a full operation, not just a raw FFI call. This lines up with theexecuteFFIOperationmethod and makes the intent more obvious.This is a bit of self-soothing PR (maybe more than a bit), but it makes the code more self-documenting and pleasant to work with (at least for me).