31 lines
1.1 KiB
Markdown
31 lines
1.1 KiB
Markdown
|
---
|
||
|
|
title: Having less code than you started with
|
||
|
|
date: 2025-02-07
|
||
|
|
permalink: daily/2025/02/07/less
|
||
|
|
tags:
|
||
|
|
- software-development
|
||
|
|
cta: ~
|
||
|
|
snippet: |
|
||
|
|
My favourite type of commits and merge requsts are ones that have less code than there was before.
|
||
|
|
---
|
||
|
|
|
||
|
|
When running commands like `git log` or viewing pull requests, you can see the number of lines that have been added, edited or removed.
|
||
|
|
|
||
|
|
When adding new features, it's likely you'll be adding code.
|
||
|
|
|
||
|
|
If you're refactoring code, you may have less code than before.
|
||
|
|
|
||
|
|
I like commits like this.
|
||
|
|
|
||
|
|
It's not true that having fewer lines of code means the code is better, but having less code makes it easier to maintain and more secure.
|
||
|
|
|
||
|
|
You don't need to upgrade and maintain code that you aren't using, so why not remove it?
|
||
|
|
|
||
|
|
Why have old TODO comments, `dd()`, `var_dump()` or `console.log()` functions in the code?
|
||
|
|
|
||
|
|
If they're not used, they can be removed.
|
||
|
|
|
||
|
|
I recently read a post that suggested there were 5 to 10 bugs in each 1,000 lines of production code as a general rule, so the less code there is, the fewer places there are for bugs to hide.
|
||
|
|
|
||
|
|
In general, for production code, less is more.
|