Effective Strategies for Dealing with Bugs in Code
<p>We use the squash, splat and crush analogy from insects when talking about bugs. This is with good reason: Thomas Edison wrote about bugs during his hardware engineering travails and this means the term is probably here to stay.</p>
<blockquote>
<p>Get used to it, or bug off!</p>
</blockquote>
<h1>Approaches to dealing with bugs</h1>
<h2>Clean your area</h2>
<p>One way to make your code bug-free is to avoid writing them in the first place!</p>
<ul>
<li>Testing</li>
<li>Modularity</li>
<li>Simplicity and clarity</li>
</ul>
<p>By testing (perhaps using <a href="https://medium.com/@stevenpcurtis.sc/testing-differences-between-tdd-atdd-and-bdd-eeeeae862a2d" rel="noopener">TDD</a> or unit testing) your code is much less likely be to bugged as it is tested before ever getting close to production. The works hand-in-hand with modularity and making sure that your code is written in separate, testable chunks.</p>
<p>The third pillar of of well-written non-bugged code is simple clear code. This minimal code should be created with the eventual reader in mind (that is, another programmer should be able to pick up your code and understand it).</p>
<p>Writing a <code>//TODO</code> is fine for missing functionality, but code that is incomplete should not be checked in.</p>
<h2>Don’t ignore warnings</h2>
<p>Warnings are there for a reason. Using a linter helps to point out your errors before they grow and become real problems that can stop a release or mean that you’ll be working late into Friday night.</p>
<p><a href="https://stevenpcurtis.medium.com/effective-strategies-for-dealing-with-bugs-in-code-8eb9341243c">Click Here</a></p>