Over my career, I’ve noticed that a significant number of programmers ignore compiler and linter warnings. They either turn the warning levels down or just ignore the output. I’ve worked with teams using SonarQube that would have tens of thousands of warnings that they wouldn’t even look at.
A linguistic antipattern is a place in the code where the naming implies that it does one thing and in fact, it does something different. For example, the method
void isEmpty() suggests that it will return a boolean reflecting whether or not the object is empty, yet the method does not return anything.
Technical debt is made up of all those things in our system (architecture, code, documentation, etc) that are working but are of sufficiently poor quality that they cause us to move slower when implementing new functionality. Perhaps we need to do additional testing before we can add something new or we need to refactor the code to make it cleaner or more extensible. Perhaps it’s just hard to read or understand and therefore difficult to know how to add the new functionality.
Test Driven Development (TDD) is often though of as a testing activity but it really isn’t. It’s a design activity that leaves a bunch of automated tests behind in its wake. The basic idea is that we write a test first and then write the production code that allows that test to pass. It sounds simple, and it really is, but there are some important subtleties.
This article will show how to “test drive” the prime factors kata in Elixir with ESpec, a spec style unit testing framework.
This article will show how to “test drive” the prime factors kata in Ruby with RSpec, a spec style unit testing framework.
Years ago now, Bryan Beecham came up with the idea of using LEGO to teach the concept of Test Driven Development (TDD). Since this is a topic most often used by developers, previous trainings had focused on demonstrating this technique on actual code. However, Bryan wanted to introduce it to a different audience; he initially wanted to explain TDD to management and then later to other non-developers on the teams. To do this, he needed to be able to illustrate the concepts away from the actual source code. And thus was LEGO-TDD first created.
In the last article, we showed how pattern matching could solve FizzBuzz. It’s a deliberately simple example so let’s look at something a little bit more complex.
I’ve long advised people to learn multiple programming languages, as each new language you learn will make you better at all the ones you already know. Not just languages with different syntax, but languages that challenge how you look at problems.
Research shows that code comments rarely stay in sync with the code they’re describing. Other psychology research shows that incorrect comments are worse than no comments at all. Should we get rid of code comments entirely or are some worth keeping around?