Applying Clean Code Principles in Rust: Understanding and Implementing the DRY Principle

Applying Clean Code Principles in Rust: Understanding and Implementing the DRY Principle | CodeSignal Learn

Introduction

Welcome to the very first lesson of the "Applying Clean Code Principles in Rust" course! In this lesson, we will focus on a fundamental concept in clean coding: the DRY ("Don't Repeat Yourself") principle. Understanding DRY is crucial for writing efficient, maintainable, and clean code. This principle is vital for everyday software development, aiding in creating robust and easily modifiable codebases. Today, let's delve into the issues caused by repetitive code and explore strategies to combat redundancy using Rust. 🚀

Understanding the Problem

Repetitive functionality in code can introduce several issues that affect the efficiency and maintainability of your software: Code Bloat : Repeating similar code across different parts of your application unnecessarily increases the size of the codebase. This makes the code harder to navigate and increases the chances of introducing errors. Risk of Inconsistencies : When similar pieces of logic are scattered across different areas, it's easy for them to become out of sync during updates or bug fixes. This can result in logic discrepancies and potentially introduce new problems. Maintenance Challenges : Updating code often requires modifications in multiple places, leading to increased work and a higher likelihood of errors. Redundant code makes it difficult for developers to ensure all necessary changes have been made consistently.

DRY Strategies

To adhere to the DRY principle and avoid repeating yourself, several strategies can be employed with Rust: Extracting Methods : Move repeated logic into dedicated functions or methods within an impl block that can be reused. This promotes code reuse and simplifies updates while respecting Rust's ownership model and borrowing rules. Extracting Variables : Consolidate repeated expressions or values into variables. Leveraging Rust's default immutability with let, we centralize changes and reduce potential errors. Replacing Temporaries with Queries : Utilize functions or methods to compute values on demand, enhancing readability and reducing redundancy. Using Generics and Traits : Abstract over common behaviors using generics and traits, reducing code repetition while leveraging Rust’s powerful type system. Leveraging Macros : Employ macros to generate repetitive code patterns at compile time, ensuring DRY code without sacrificing performance. Organizing Code with Modules and Crates : Structure your code into modules and crates to promote reuse and reduce duplication across larger projects. Now, let's explore some practical examples in Rust.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Problem 1: Duplicated Business Logic

Consider the following problematic code snippet, where repetitive logic is used for calculating the total price based on different shipping methods: Ruststruct Item { price: f64, quantity: u32, } struct Order { items: Vec<Item>, tax: f64, } fn calculate_click_and_collect_total(order: &Order) -> f64 { let items_total: f64 = order .items .iter() .map(|item| item.price * f64::from(item.quantity)) .sum(); let shipping_cost = if items_total > 100.0 { 0.0 } else { 5.0 }; items_total + shipping_cost + order.tax } fn calculate_post_shipment_total(order: &Order, is_express: bool) -> f64 { let items_total: f64 = order .items .iter() .map(|item| item.price * f64::from(item.quantity)) .sum(); let shipping_cost = if is_express { items_total * 0.1 } else { items_total * 0.05 }; items_total + shipping_cost + order.tax }struct Item { price: f64, quantity: u32, } struct Order { items: Vec<Item>, tax: f64, } fn calculate_click_and_collect_total(order: &Order) -> f64 { let items_total: f64 = order .items .iter() .map(|item| item.price * f64::from(item.quantity)) .sum(); let shipping_cost = if items_total > 100.0 { 0.0 } else { 5.0 }; items_total + shipping_cost + order.tax } fn calculate_post_shipment_total(order: &Order, is_express: bool) -> f64 { let items_total: f64 = order .items .iter() .map(|item| item.price * f64::from(item.quantity)) .sum(); let shipping_cost = if is_express { items_total * 0.1 } else { items_total * 0.05 }; items_total + shipping_cost + order.tax } Both functions contain duplicated logic for calculating the total price of items, making them error-prone and hard to maintain. Now, let's refactor this code.

Solution 1: Centralizing Logic by Extracting Methods

By consolidating the shared logic into a separate method, we can eliminate redundancy and streamline updates: Ruststruct Item { price: f64, quantity: u32, } struct Order { items: Vec<Item>, tax: f64, } impl Order { fn calculate_items_total(&self) -> f64 { self.items .iter() .map(|item| item.price * f64::from(item.quantity)) .sum() } } fn calculate_click_and_collect_total(order: &Order) -> f64 { let items_total = order.calculate_items_total(); let shipping_cost = if items_total > 100.0 { 0.0 } else { 5.0 }; items_total + shipping_cost + order.tax } fn calculate_post_shipment_total(order: &Order, is_express: bool) -> f64 { let items_total = order.calculate_items_total(); let shipping_cost = if is_express { items_total * 0.1 } else { items_total * 0.05 }; items_total + shipping_cost + order.tax }struct Item { price: f64, quantity: u32, } struct Order { items: Vec<Item>, tax: f64, } impl Order { fn calculate_items_total(&self) -> f64 { self.items .iter() .map(|item| item.price * f64::from(item.quantity)) .sum() } } fn calculate_click_and_collect_total(order: &Order) -> f64 { let items_total = order.calculate_items_total(); let shipping_cost = if items_total > 100.0 { 0.0 } else { 5.0 }; items_total + shipping_cost + order.tax } fn calculate_post_shipment_total(order: &Order, is_express: bool) -> f64 { let items_total = order.calculate_items_total(); let shipping_cost = if is_express { items_total * 0.1 } else { items_total * 0.05 }; items_total + shipping_cost + order.tax } By extracting the calculate_items_total method into the Order struct, we centralize the logic of item total calculation, leading to cleaner and more maintainable code. This method also respects Rust's ownership and borrowing rules by taking &self and returning a f64, avoiding unnecessary data copying.

Problem 2: Scattered Constants and Calculations

Let's look at an example that deals with repeated calculations for discount rates: Rustfn apply_discount(price: f64, loyalty_level: f64) -> f64 { let mut loyalty_discount = loyalty_level * 0.02; let mut discounted_price = price * (1.0 - loyalty_discount); let seasonal_discount = 0.10; discounted_price *= (1.0 - seasonal_discount); discounted_price }fn apply_discount(price: f64, loyalty_level: f64) -> f64 { let mut loyalty_discount = loyalty_level * 0.02; let mut discounted_price = price * (1.0 - loyalty_discount); let seasonal_discount = 0.10; discounted_price *= (1.0 - seasonal_discount); discounted_price } Here, the discount rates are scattered throughout the code, which complicates management and updates. Additionally, variables are declared as mut unnecessarily, which goes against Rust's preference for immutability.

Solution 2: Organizing Constants and Calculations by Extracting Variables

We can simplify this by extracting the discount rates into immutable variables: Rustfn apply_discount(price: f64, loyalty_level: f64) -> f64 { let loyalty_discount = loyalty_level * 0.02; let seasonal_discount = 0.10; let discounted_price = price * (1.0 - loyalty_discount); let final_price = discounted_price * (1.0 - seasonal_discount); final_price }fn apply_discount(price: f64, loyalty_level: f64) -> f64 { let loyalty_discount = loyalty_level * 0.02; let seasonal_discount = 0.10; let discounted_price = price * (1.0 - loyalty_discount); let final_price = discounted_price * (1.0 - seasonal_discount); final_price } In this refactored code: Variables are declared as immutable (let), aligning with Rust's emphasis on immutability, which also reduces potential side effects and enhances code safety. The calculation logic is more concise, improving readability and making it easier to understand the purpose of each variable. Centralizing discount rates into variables facilitates easier updates, as changes are localized, reducing the risk of errors. This code is cleaner, more readable, and allows changes in just one place. 🎉

Problem 3: Repeated Temporary Variables

Our final example involves temporary variables that lead to repetition: Rustuse std::time::{SystemTime, Duration}; fn is_eligible_for_discount(sign_up_date: SystemTime, purchase_history_size: usize) -> bool { let twelve_weeks = Duration::from_secs(12 * 7 * 24 * 60 * 60); // Duration of 12 weeks let new_customer = match SystemTime::now().duration_since(sign_up_date) { Ok(duration) => duration < twelve_weeks, Err(_) => false, }; new_customer && purchase_history_size > 5 } fn is_eligible_for_loyalty_program(sign_up_date: SystemTime, loyalty_level: i32) -> bool { let twelve_weeks = Duration::from_secs(12 * 7 * 24 * 60 * 60); let new_customer = match SystemTime::now().duration_since(sign_up_date) { Ok(duration) => duration < twelve_weeks, Err(_) => false, }; new_customer || loyalty_level > 3 }use std::time::{SystemTime, Duration}; fn is_eligible_for_discount(sign_up_date: SystemTime, purchase_history_size: usize) -> bool { let twelve_weeks = Duration::from_secs(12 * 7 * 24 * 60 * 60); // Duration of 12 weeks let new_customer = match SystemTime::now().duration_since(sign_up_date) { Ok(duration) => duration < twelve_weeks, Err(_) => false, }; new_customer && purchase_history_size > 5 } fn is_eligible_for_loyalty_program(sign_up_date: SystemTime, loyalty_level: i32) -> bool { let twelve_weeks = Duration::from_secs(12 * 7 * 24 * 60 * 60); let new_customer = match SystemTime::now().duration_since(sign_up_date) { Ok(duration) => duration < twelve_weeks, Err(_) => false, }; new_customer || loyalty_level > 3 } The variable new_customer is used in multiple places, causing duplicated logic; this suggests that the code can be improved by refactoring. As a side note, we're utilizing Rust's standard library std::time module for time calculations. The SystemTime type represents a moment in time, and Duration allows us to specify time intervals. We create a duration of twelve weeks using Duration::from_secs(12 * 7 * 24 * 60 * 60), and we compare times using SystemTime::now().duration_since(). This method returns a Result because the sign-up date could theoretically be in the future, which we handle appropriately in our code.

Solution 3: Using Functions for Computed Values

Let's refactor by extracting the logic into a function, reducing duplication and enhancing modularity: Rustuse std::time::{SystemTime, Duration}; fn is_new_customer(sign_up_date: SystemTime) -> bool { let twelve_weeks = Duration::from_secs(12 * 7 * 24 * 60 * 60); // Duration of 12 weeks match SystemTime::now().duration_since(sign_up_date) { Ok(duration) => duration < twelve_weeks, Err(_) => false, } } fn is_eligible_for_discount(sign_up_date: SystemTime, purchase_history_size: usize) -> bool { is_new_customer(sign_up_date) && purchase_history_size > 5 } fn is_eligible_for_loyalty_program(sign_up_date: SystemTime, loyalty_level: i32) -> bool { is_new_customer(sign_up_date) || loyalty_level > 3 }use std::time::{SystemTime, Duration}; fn is_new_customer(sign_up_date: SystemTime) -> bool { let twelve_weeks = Duration::from_secs(12 * 7 * 24 * 60 * 60); // Duration of 12 weeks match SystemTime::now().duration_since(sign_up_date) { Ok(duration) => duration < twelve_weeks, Err(_) => false, } } fn is_eligible_for_discount(sign_up_date: SystemTime, purchase_history_size: usize) -> bool { is_new_customer(sign_up_date) && purchase_history_size > 5 } fn is_eligible_for_loyalty_program(sign_up_date: SystemTime, loyalty_level: i32) -> bool { is_new_customer(sign_up_date) || loyalty_level > 3 } By creating the is_new_customer function, we've simplified the code and made it more maintainable. This function encapsulates the logic for determining if a customer is new based on their sign-up date and the current date.