Welcome to the new Bug Driven Developers this week! If you enjoy this post, forward it to your developer friends so they can join us.

Here’s what we got for you today:

• Reworking repeated code into arrays

• Inconsistent error handling makes debugging more difficult than needed

• The Kubernetes Desktop Client you've been waiting for

• Mr. Google Incognito

Let's start off this week by talking about some Dev Pet Peeves

As developers, we've all come across code that makes us cringe. The two pet peeves we'll discuss today – repetitive code and inconsistent error handling – can wreak havoc on a codebase. But don't worry! We'll provide you with solutions to overcome these common challenges and make your code cleaner, more efficient, and easier to maintain.

Repetitive Code – Embrace Arrays and Iterations

This past few weeks, we have seen way to much repetitive code and it drives us nuts!

I was looking for a new chair for my home office set up and wanted to take some measurements to see how well it would fit. The issue was my tape measure is in imperial system and the measurements on the website for the chair was in metric system. For doing the conversions I was looking for a simple calculator like tool that I could use to quickly see if the chair will fit (seems straight forward enough).

I came across an open-source project that seemed to offer what I needed, so I started examining the code to see how well it would work for me. My intrinsic developer curiosity caused me dive into the codebase, and I stumbled upon a section that made me cringe: a long series of repetitive if statements, each one handling a different unit conversion.

The code looked something like this:

if (unitFrom === 'meters' && unitTo === 'feet') {
  convertedValue = inputValue * 3.28084;
} else if (unitFrom === 'meters' && unitTo === 'inches') {
  convertedValue = inputValue * 39.3701;
} else if (unitFrom === 'feet' && unitTo === 'meters') {
  convertedValue = inputValue * 0.3048;
} // and so on, for every possible conversion...

This approach is not only cumbersome but also makes the code harder to maintain and prone to errors. A much better approach would be to use a nested object to store the conversion factors for each unit, something like this:

const conversionFactors = {
  meters: {
    feet: 3.28084,
    inches: 39.3701,
  },
  feet: {
    meters: 0.3048,
  },
  // ... and so on, for every possible conversion
};

This gives the conversion factors in a more manageable structure, which you could quickly perform the desired conversion using a single line of code:

const convertedValue = inputValue * conversionFactors[unitFrom][unitTo];

This code is cleaner, more efficient, and much easier to maintain. This simple example just goes to show the importance of using appropriate data structures and prevalent developers not structuring their programs correctly is.

Inconsistent Error Handling – Create a Single Error Function

Inconsistent error handling is another pet peeve that can lead to messy, hard-to-maintain code. Often, developers handle errors in different ways throughout the codebase. For example with Javascript, some might use console.log(), while others use console.error(), and some may not handle errors at all.

To create a more consistent and efficient error handling system, implement a single error function that handles all errors in your codebase. This function should log the error, notify the appropriate team members, and, if necessary, handle the error gracefully.

Here's a simple example of a custom error handling function:

function handleError(error) {
  console.error(error);
  // Send error notification to the team via email or other channels
  // Send log to a log server
  // Perform necessary actions to recover from the error
}

Now, whenever an error occurs, you can use this function to handle it consistently:

try {
  // Your code here
} catch (error) {
  handleError(error);
}

Its a much cleaner and more extendable approach to error handling. One enhancement you can make to this is passing in additional inputs to the handleError function that can trigger different actions. For example, you can pass in a parameter which would signify that support should be emailed about the issue, or that for this type of issue the log should be sent to a log server, etc.

🔗Links in Tech

Some additional reads we liked this week

• The Open Source Ruby on Rails SaaS Framework

• Twitter fueled run on Silicon Valley Bank, new paper finds

• YouTube, the jewel of the internet

• 100 Days of SwiftUI! This is a free collection of videos and tutorials

• The Kubernetes Desktop Client you've been waiting for

😂 Meme of the Week

🤖 SoftwareTesting.ai Update

The SoftwareTesting.ai pivot is going well so far!

From a development standpoint we have starting aligning the architecture to be supportive of receiving webhooks from GitHub and we expect the MVP launch to be next weekend!

For the initial launch we are going to:

1. Analyze your Code Coverage

2. Generate Unit Tests to fill the gaps in coverage

3. Add these as suggestions as GitHub Comments in your PR

This will give you quick feedback on how to improve your code coverage and allow you to implement the suggested tests in the comments through the already existing “Apply Suggestions“ workflow built into GitHub.

If you are interested in finding out more about the SoftwareTesting.ai pivot check out our new landing page that has more details 😀 

Thanks for tuning in to this week’s newsletter! If you have any questions, feel free to let us know on Twitter (Justin's Twitter) (Kevin's Twitter)

Thanks,

Justin + Kevin

P.S. What new things about Software Development did you learn this week?

Did you enjoy reading this week's Bug Driven Development?

• Yes

• Meh

• No