26 lines
1.7 KiB
Markdown
26 lines
1.7 KiB
Markdown
|
---
|
||
|
|
title: >
|
||
|
|
Version-controlled commented-out code
|
||
|
|
pubDate: 2022-11-20
|
||
|
|
permalink: >-
|
||
|
|
archive/2022/11/20/version-controlled-commented-out-code
|
||
|
|
tags:
|
||
|
|
- git
|
||
|
|
---
|
||
|
|
|
||
|
|
Today, whilst debugging some legacy code within an application, I found several blocks of commented-out code.
|
||
|
|
|
||
|
|
Some were previous debugging code which had been commented out, and some were old components or previous implementations - but instead of being removed when they were no longer needed, they remained in the codebase as commented-out lines - inactive but adding noise and complexity around the code that I was trying to understand and debug.
|
||
|
|
|
||
|
|
To make it easier for me to figure out this code, I'd like it to be as clean to read and as simple to understand as possible.
|
||
|
|
|
||
|
|
The codebase is version-controlled, so why would there be a need to comment out and keep the lines?
|
||
|
|
|
||
|
|
Version control systems have a log of each change, so if you need to see previous changes, you can view the log and see what changed, when, and by who.
|
||
|
|
|
||
|
|
You can also see any other files that were changed in the same commit, and usually, there will be a reference to the issue or ticket that required that change.
|
||
|
|
|
||
|
|
If you need to re-add a change that had been removed, you can either do this manually or by reverting the commit.
|
||
|
|
|
||
|
|
Should there be commented-out code within a codebase if it's version controlled? I'd say no unless there's a good reason for it to be there and it's providing some additional context or for a specific purpose. If it's an outdated implementation, some old debugging code, or a component that's no longer needed, I think that it should be removed, and people can use version control tools to find or re-introduce those changes if needed.
|