codesearch 0.1.10

// Code smells example - demonstrates various code quality issues

use std::collections::HashMap;

// GOD OBJECT - Too many responsibilities
struct GodObject {
    user_data: HashMap<String, String>,
    database_connection: String,
    ui_settings: HashMap<String, String>,
    cache: HashMap<String, String>,
    network_config: HashMap<String, String>,
    logging_config: HashMap<String, String>,
    validation_rules: HashMap<String, String>,
    business_logic: HashMap<String, String>,
}

impl GodObject {
    // Too many methods handling different concerns
    fn save_user(&self, user: String) { }
    fn connect_db(&self) -> Result<(), String> { Ok(()) }
    fn render_ui(&self) { }
    fn cache_data(&self, key: String, value: String) { }
    fn send_network_request(&self, url: String) { }
    fn log_error(&self, error: String) { }
    fn validate_input(&self, input: String) -> bool { true }
    fn calculate_business_logic(&self, data: String) -> String { String::new() }
}

// LONG PARAMETER LIST - More than 4 parameters
fn process_data(
    param1: String,
    param2: i32,
    param3: bool,
    param4: f64,
    param5: Vec<String>,
    param6: HashMap<String, String>,
    param7: Option<String>,
) -> Result<String, String> {
    Ok(String::new())
}

// LONG PARAMETER LIST - More than 4 parameters
fn create_user_config(
    name: String,
    email: String,
    age: i32,
    address: String,
    phone: String,
    preferences: Vec<String>,
    notifications: bool,
) -> HashMap<String, String> {
    HashMap::new()
}

// FEATURE ENVY - Uses more data from other class than its own
struct OrderProcessor {
    order_id: String,
}

impl OrderProcessor {
    fn process_order(&self, user: &User, order: &Order) {
        // Feature envy: accesses many fields from User and Order
        let _ = format!("Processing order {} for user {} ({}), email: {}, address: {}",
            self.order_id,
            user.name,
            user.id,
            user.email,
            order.shipping_address
        );
        
        // More feature envy
        let _ = user.calculate_discount(order.total_amount);
        let _ = user.get_shipping_address();
        let _ = order.get_items();
        let _ = order.calculate_tax(user.get_region());
    }
}

struct User {
    name: String,
    id: String,
    email: String,
    address: String,
}

impl User {
    fn calculate_discount(&self, amount: f64) -> f64 { amount * 0.9 }
    fn get_shipping_address(&self) -> String { self.address.clone() }
    fn get_region(&self) -> String { String::from("US") }
}

struct Order {
    total_amount: f64,
    shipping_address: String,
}

impl Order {
    fn get_items(&self) -> Vec<String> { vec![] }
    fn calculate_tax(&self, region: String) -> f64 { 0.0 }
}

// DATA CLUMPS - Groups of parameters that always appear together
struct UserData {
    name: String,
    email: String,
    phone: String,
}

// Multiple functions taking the same data clump
fn create_user_1(name: String, email: String, phone: String) -> UserData {
    UserData { name, email, phone }
}

fn update_user_1(name: String, email: String, phone: String) -> UserData {
    UserData { name, email, phone }
}

fn validate_user_1(name: String, email: String, phone: String) -> bool {
    !name.is_empty() && !email.is_empty()
}

// PRIMITIVE OBSESSION - Using primitives instead of domain objects
type UserId = String; // Should be a proper UserId struct
type Email = String; // Should be a proper Email struct
type Money = f64; // Should be a proper Money struct

fn send_email(to: Email, subject: String, body: String) {
    println!("Sending to: {}", to);
}

fn process_payment(amount: Money, user_id: UserId) -> bool {
    amount > 0.0
}

// SHOTGUN SURGERY - Single change requires modifying many files
struct CustomerData;
impl CustomerData {
    fn update_email(&self, email: String) { }
}

struct EmailNotification;
impl EmailNotification {
    fn update_email(&self, email: String) { }
}

struct BackupService;
impl BackupService {
    fn update_email(&self, email: String) { }
}