Refactoring and Code Smells in Go

Topic Overview

Welcome to the world of refactoring! In this lesson, we're learning about Code Smells, which are patterns in code that hint at potential problems. Our mission is to help you spot these smells and understand how to improve them or, in programming terms, how to refactor them. We'll delve into the concept of code smells, examine different types, and apply real-world code examples to solidify your understanding. Let's get started!

Introduction to Code Smells

Code smells are signs that something could be amiss in our code. You could compare them to an unpleasant smell in a room. But instead of indicating rotten food or a dirty sock, they signal that our code may not be as readable, efficient, or manageable as it could be. Consider this bit of code: Go package main import "fmt" func Calculate(quantity int, price int) int {return quantity * price} func main() {total := Calculate(5, 3) fmt.Println(total)} The function name Calculate is too vague. What exactly does it calculate? For whom? This ambiguity is a sign of a bad naming code smell. Let's see how this and other code smells can be improved!

Duplicate Code

If you notice the same piece of code in more than one place, you may be looking at an example of the Duplicate Code smell. Duplicate code leaves room for errors and bugs. If you need to make a change, you might overlook one instance of duplication. Here's an example: Go totalApplesPrice := quantityApples * priceApple - 5 totalBananasPrice := quantityBananas * priceBanana - 5 This code performs the same operation on different data. Instead of duplicating the operation, we can create a function to handle it: Go package main import "fmt" func CalculatePrice(quantity, price int) int {discount := 5 return quantity*price - discount} func main() {totalApplesPrice := CalculatePrice(quantityApples, priceApple) totalBananasPrice := CalculatePrice(quantityBananas, priceBanana) fmt.Println(totalApplesPrice) fmt.Println(totalBananasPrice)} With this solution, if we need to change the discount or the formula, we can do so in one place: the CalculatePrice function.

Too Long Method

Join the 1M+ learners on CodeSignal

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

package main import "fmt" type Order struct { PaymentType string } func ProcessOrder(order Order) bool { fmt.Println("Processing order...") if order.PaymentType == "credit_card" { ProcessCreditCardPayment(order) SendOrderConfirmationEmail(order) } else if order.PaymentType == "paypal" { ProcessPaypalPayment(order) SendOrderConfirmationEmail(order) } else if order.PaymentType == "bank_transfer" { ProcessBankTransferPayment(order) SendOrderConfirmationEmail(order) } else { fmt.Println("Unsupported payment type") return false } fmt.Println("Order processed successfully!") return true } func ProcessCreditCardPayment(order Order) {} func ProcessPaypalPayment(order Order) {} func ProcessBankTransferPayment(order Order) {} func SendOrderConfirmationEmail(order Order) {}

package main import "fmt" type Order struct { PaymentType string } func ProcessPayment(paymentType string, order Order) bool { switch paymentType { case "credit_card": ProcessCreditCardPayment(order) case "paypal": ProcessPaypalPayment(order) case "bank_transfer": ProcessBankTransferPayment(order) default: fmt.Println("Unsupported payment type") return false } return true } func ProcessOrder(order Order) bool { fmt.Println("Processing order...") if ProcessPayment(order.PaymentType, order) { SendOrderConfirmationEmail(order) fmt.Println("Order processed successfully!") return true } fmt.Println("Invalid order") return false } func ProcessCreditCardPayment(order Order) {} func ProcessPaypalPayment(order Order) {} func ProcessBankTransferPayment(order Order) {} func SendOrderConfirmationEmail(order Order) {}

Comment Abuse

Comments within your code should provide useful information, but remember, too much of a good thing can be a problem. Over-commenting can distract from the code itself, and more often than not, it's a sign that the code isn't clear enough.

Consider this revised function, which calculates the area of a triangle, now with comments:

package main

import "fmt"

func CalculateTriangleArea(base, height float64) float64 {
    // Calculate the area of a triangle
    // Formula: 0.5 * base * height
    area := 0.5 * base * height // Area calculation
    return area // Return the result
}

func main() {
    area := CalculateTriangleArea(5, 10)
    fmt.Println(area)
}

package main

import "fmt"

func CalculateTriangleArea(base, height float64) float64 {
    // Calculate the area of a triangle
    // Formula: 0.5 * base * height
    area := 0.5 * base * height // Area calculation
    return area // Return the result
}

func main() {
    area := CalculateTriangleArea(5, 10)
    fmt.Println(area)
}

While comments explaining the formula might be helpful for some, the code itself is quite straightforward, and the comments on the calculation itself might be seen as unnecessary. If the function's name and parameters are clear, the need for additional comments can be minimized.

Here is how we could change this:

package main

import "fmt"

// CalculateTriangleArea calculates the area of a triangle given the base and height.
func CalculateTriangleArea(base, height float64) float64 {
    area := 0.5 * base * height
    return area
}

func main() {
    area := CalculateTriangleArea(5, 10)
    fmt.Println(area)
}

package main

import "fmt"

// CalculateTriangleArea calculates the area of a triangle given the base and height.
func CalculateTriangleArea(base, height float64) float64 {
    area := 0.5 * base * height
    return area
}

func main() {
    area := CalculateTriangleArea(5, 10)
    fmt.Println(area)
}

In this version, a single comment placed at the function level provides a high-level overview of what the function does, which is sufficient given the clarity of the function name and parameters. Comments within the function have been removed as they were unnecessary.