Reviews and improves **names** in code — variables, functions, classes, modules, parameters — for clarity, intent, and consistency with language/team conventions. Triggers when asked to review names, rename things, improve code readability, clean up confusing code, or when examining code with generic/vague names like "data", "info", "manager", "temp", "util". Does NOT trigger for general code review unrelated to naming, architecture design, debugging, or performance optimization. Identifies naming anti-patterns (generic names, misleading names, type-encoding, abbreviations), suggests role-based names that reveal intent, checks consistency with project/domain vocabulary, and flags misalignment with language culture.
91
90%
Does it follow best practices?
Impact
94%
1.05xAverage score across 5 eval scenarios
Passed
No known issues
A Rust crate exposes a small cache wrapper. The API works, but downstream users keep asking what methods consume, borrow, or merely check state. Maintainers want a naming review that aligns the public API with Rust ecosystem expectations before a minor release.
Review the code, propose better names, and provide a revised version. Keep the implementation simple; focus on clarity and API naming.
Produce rust_naming_review.md with the issues and proposed names. Produce cache.rs with revised identifiers and comments for any public API rename that could affect users.
=============== FILE: cache.rs ===============
pub struct cache_data<T> {
data: Vec<T>,
}
impl<T> cache_data<T> {
pub fn new(items: Vec<T>) -> Self {
Self { data: items }
}
pub fn get_data(&self) -> &Vec<T> {
&self.data
}
pub fn convert_to_vec(self) -> Vec<T> {
self.data
}
pub fn check_empty(&self) -> bool {
self.data.is_empty()
}
pub fn do_thing(&mut self, item: T) {
self.data.push(item)
}
}
pub const max_items: usize = 1000;
pub enum cache_status {
ok,
not_found,
}