Coffee break #76. Debugging Tips: Act Like a Detective. 5 useful tricks for writing clean code

Debugging Tips: Act Like a Detective

Source: About Monica To debug software effectively, a developer needs to be a detective. As I have grown professionally, I have not only expanded my knowledge of the various ways programs can crash unexpectedly, but I have also improved my debugging skills. In this article, I'll talk about different approaches to understanding why a computer doesn't seem to do what you tell it to.

1. Use a linter

Do a lint. Are any syntax errors highlighted? Is your code referencing an undefined variable? More often than I'd like, my code didn't compile (locally) because of a red "f" I somehow added to a random string. This misplaced character is often removed when linting. But if the application compiles successfully and I want to see the changes myself, I use Git Lens . This tool helps to identify if anything in the code is highlighted as inappropriate. Don't be alarmed if any other errors pop up in your terminal, browser console, or web page. They can help you figure out what exactly is going wrong. If you are just getting used to error messages, check outadvice from Nicky Maleman on how to learn to understand them.

2. Only change one thing at a time

You may be tempted to change everything at once. But try to just change one thing. In general, before changing anything, think about how this particular change will help you confirm or refute your current assumptions about the problem. Will it bring you closer to a potential solution? Automated tests come in handy to check how the changes work in different test cases. They also ensure that you don't inexperience break pre-existing test cases that have been previously passed.

3. Check all your assumptions

Reproduce the problem sequentially manually or through tests. Under what conditions does the system fail? To better understand the underlying problem, you must determine under what conditions the program behaves unexpectedly. Use logs, breakpoints, tests, network call checks, and so on to determine exactly when the code stops working properly. Understanding when an error occurs will bring you closer to understanding why it occurs. Does your API return the expected data? Is the issue specific to the runtime? Are there any missing environment variables?

4. Use Tests to Validate Your Assumptions and Test Potential Solutions

Approach test-driven development with red-green-refactoring. This assumes that you first write a test that includes the desired functionality, and your code fails (because there is no code yet). Next, you write code that must pass this test (the result changes from red to green). After that, when you already have working code, you can start refactoring without worrying about accidentally breaking the functionality of the code. Using this method eliminates the situation when you create too much functionality without testing for performance. Git also has a git bisect command that can be used to quickly find the problematic commit. With it, you can quickly find the problem by checking specific commits from the git history. Then, depending on whether this issue is identified before or after the software regression is introduced, the next commit will occur either earlier or later in the git history until the culprit is identified. Git bisect can be combined with automated testing to make the process of identifying a problematic commit even more efficient.

5. Study your code line by line

Try to read the code with a fresh eye, even if it takes a break from work. It happens that the next day everything becomes much clearer. You don't have to constantly look at the monitor screen for your brain to keep looking for a solution.

6. Look at the source code of a third-party package

Check if there are open issues there. Perhaps someone else also faced a similar problem. If the error may be related to third-party software, view its source code.

7. Google is your best friend

A quick search can be a developer's best friend. If you are using a new feature or package, try to find an example where it already works. If you want to see code using the same APIs in context, I recommend looking in your local repository. Or you can search open source repositories with grep.app .

8. Call a friend

I recommend integrating git blame into your development environment. I am using the Git lens plugin, which shows who is the author of certain file changes, right in those files in the code editor. This plugin also shows the associated pull request, which can be useful for quickly getting more context on solutions (you can view this pull request or contact its author directly). Pair programming can be an effective way to debug and share knowledge. I have already mentioned the “magic” finding of solutions after a dream or a break. There is another useful technique: “duck debugging”. The point is that simply explaining the problem to someone else (even an inanimate rubber duck) can help make the solution more obvious. After dealing with the error, do not forget to document the knowledge gained. Even if it will be just a small note for myself for the future.

5 useful tricks for writing clean code

Source: Dev.to Anyone can learn to code. But can you write it cleanly? In this article, I will show you my methods for writing clean code.

1. Use a color palette

By using the color palette, not only will you write cleaner code, but you will be able to change the entire theme of your application by changing only 6 characters of code (referring to the hex code). Let's take a look at the color palette I used in my React Native project.

// creating and exporting the color palette
export default {
  black: "#000",
  darkBlue: "#090446",
  darkGreen: "#002E27",
  green: "#00B14F",
  light: "#ede6e6",
  medium: "#6e6969",
  pink: "#fc5c65",
  purple: "#4530B3",
  white: "#FFFFFF",
};

// using the palette (default import as colors)
const styles = StyleSheet.create({
  foodName: {
    color: colors.white,
    fontSize: 22,
    fontWeight: "bold",
    margin: 5,
  },
  foodPrice: {
    color: colors.green,
    fontSize: 16,
    margin: 5,
  },
});

Here, I can change the green color by choosing a different shade, and to do this, I will have to edit only the main palette, and not all the files in the project. You can go even further and declare primary and secondary colors.

2. Sort options and keys alphabetically

It's just a matter of cleanliness. Here are a couple of examples:

function doSomething(anArgument, anotherArgument, bIsAfterA, cIsAfterB, moreArgument, zIsTheLastAlphabet) {
   // do something...
}

container: {
  backgroundColor: colors.darkGreen,
  borderRadius: 10,
  justifyContent: "space-around",
  margin: 10,
  padding: 10,
  width: 180,
  height: 180,
},

Make names expressive, even if they are long

Everyone advises to write shorter code, and it really makes sense. But when it comes to variable and function names, you can make an exception. Let's look at an example:

const handlePress = () => {
  // do something...
}

const handlePress2 = () => {
  // do something...
}

const handlePress3 = () => {
  // do something...
}

If you have a small application, you can choose the naming option above. But imagine that we are talking about large-scale projects in a large company, where many developers work on a huge code base. Trust me, the last thing you want in the middle of a busy day at work is proofreading poorly written code and trying to figure out how it works. Here are more appropriate names for the same functions:

const handlePressAddButton = () => {
  // do something...
}

const handlePressCrossButton = () => {
  // do something...
}

const handlePressCircularView = () => {
  // do something...
}

4. Create an extensible directory structure, even for small projects

This is probably the most important point in this article. In my opinion, it is not difficult to create an extensible project structure. All you need to do is search Google for a sample for your technology stack. Meanwhile, this step will bring benefits throughout the development cycle. Here is a screenshot of the structure of one of my projects:

5. Build small, reusable, extensible components

Here is an example of a reusable component in React:

function Text({ children, style, ...otherProps }) {
  return (
    <h1 style={[styles.myCustomStyle, style]} {...otherProps}>
      {children}
    </h1>
  );
}

Here we have a fully finished h1 tag with default styles. All you need is to use it in your application. And thanks to the last REST parameter, the Text component may or may not have additional properties - as you wish. But that is not all. The style of this component is written to be self-contained, but it can also be extended or overwritten (the style parameter).