The truth is that most code, whether old or new, is terrible. The odds of any old code you might end up having to look at being terrible is very high.
Nowadays, we have linters to point out common classes of mistakes, programming languages with actual type systems to enforce invariants, integrated testing tools, etc...
Note that, yes, we do still have new, terrible codebases. But at least the tooling nowadays raised the bar to have a minimum floor of quality that, while very low, is still oh so much higher than it used to be.
I've looked at 1990s code in the Windows NT kernel. It was wonderful.
Oldest source file I went through was from 1993. Perfectly readable and understandable.
One of the best modern code bases I ever worked in didn't even have a linter setup. The principle dev reviewed every single commit and enforced a consistency across the code base that was better than what any tools ever could have done.
How was it so much better that it justified that level of busywork on the part of the senior member of the team (and busywork for everyone else, to fix the style nits they enforced in review)? I would have guessed that taking a few hours to install and configure a formatting linter to free up the principal dev's time to focus on other things would have been hugely high leverage.
Developers quickly set their IDEs to follow the team's coding guidelines, style wasn't really a problem.
> Nowadays, we have linter
I was using a C linter in 1986. The tooling is better now but it still comes down to the author.
Putting BEGIN..END around a one line block was always a contention since it wasn't required. Less code vs arguably more readable code (Pascal)
If BLA Then
Begin
DO STUFF
End
If BLA Then
DO STUFFThis is nonsense. The worst authors can still produce bad code with the best tools and the best authors can still produce good code with the worst tools, but most authors are somewhere in the middle, and tooling makes a huge difference to the average.