Unit testing and TDD are all the rage. This is a good thing! Not long ago, most conversations I had about testing turned into a battle of philosophy about whether testing should happen. Nowadays, it seems that battle has been largely won. But as soon as you solve the big problem, the smaller problems start to show up. And that brings me to today’s “small problem”: The mockery that is “mocking”.

Tabs or spaces? I like to ask this cliché question during technical interviews. How would you answer? Most people nerviously laugh, and then try to lightly defend tabs, hoping I’m not a spaces guy. Or the other way around. The truth is, I don’t care about tabs or spaces (although spaces are clearly superior!) In my book, the correct answer is, “Don’t argue about it. Use a linter.” This, and so many other style debates, are just a waste of time.

Comments are like apologies to the next programmer. — Unknown I saw this quote today in an online forum. I love it! I have long reeled against comments in code. That’s not to say they’re never useful. It’s just that 95% of code comments are worthless, or even worse. But if this is true, then what are comments apologizing for? Hard-to-read code. // Determine the shipping rate var s = 15; if ( p >= 100 || q >= 5 ) { s = 0; } A little refactoring can avoid the need to apologize with a comment:

I’m a big fan of meaningful commit messages. commit ef4d5ce5b6f13a3cc07f8941449bcaf445111cbf Author: Jonathan Hall <flimzy@flimzy.com> Date: Thu Feb 11 10:35:34 2021 +0100 bugfix just doesn’t cut it. I’m also a big fan of git rebase instead of git merge, fixup and ammend, and a whole host of other git tricks to keep my git history pristine and readable. But why? I rarely find myself doing git archeaology, so why fuss with all this?

How much value does your code provide? And how closely is that value related to the amount of code?

Edited by Mitchell I’m knee-deep in some log refactoring on my current project, which is something that I’ve done now on several projects. This is one of my favorite ways to become familiar with a new code base, since it typically touches all of the code. As I do this on new projects, I’m consistently faced with many of the same frustrations, which I have decided to catalog here. Most projects I see make at least several of these mistakes, some make all of them.

Nancy, as you may know by reputation, is a detective. She uses Sonatype's OSS Index to check for vulnerabilities in your Go dependencies.

This post was edited by Taavi Kivisik A reader recently sent me this question: I'm getting quite serious with programming. I finished reading Clean Code and am doing a course about design patterns, nerding out on Node.js, etc. I have to say it's quite amazing to realize the level of sophistication and effort involved to make quality software. It makes me really appreciative working with engineers who are capable of working on that level.

There is a lot of variety when it comes to Continuous Integration and Continuous Deployment (CI/CD) configurations. But I am constantly amazed by how many projects fail to even implement the absolute minimum CI configuration. In this article, I outline what I believe to be the absolute, bare minimum automated continuous integration tests that should exist on practically every project. These are table stakes. You ought to be embarrassed if your project doesn’t do these things.

How often do you find some code like this in your production code base? form.submit(function(event) { console.log("Submit hit"); var formData = { It’s obvious case of stray debugging code that never got cleaned up during code review. Or have you ever seen something like this, perhaps in your CI config? script: # - npm install # - npm test - ./script/test.sh This one is especially dangerous. It appears that someone commented out the core functionality of the automated test stage of CI!

You’re building a complex piece of software. Then it comes time to deploy, so you spend a couple weeks stuffing it into a Docker container or a .deb or .rpm package, and debugging the build and deployment process. Then you add some sort of monitoring or logging, set up email or SMS alerts to tell you when it crashes, and probably a dozen other things to make it “production ready.”