I can't answer the "should I follow a bad style" question but I figured I'd share a story from earlier on in my career; I actually did C++ before I did assembly language, and as a newish hire I was assigned to design part of a system from scratch in asm for a new project (embedded), it was going to be a new template going forward; the old template had about 10k+ lines per subroutine, 100% global memory, and no re-used subroutines, I assumed this was just legacy stuff that nobody liked.

It turned out I was dead wrong, that style was ingrained in the company, and even the industry, my code only got used once and they went right back to the old standard -- coders used to giant functions hated opening up functions every couple of lines to see what they did, and they didn't like not being able to debug memory stored on the stack from other functions, and they didn't like pointers, they preferred accessing memory bytes directly.

Copy/pasteable code was put at a high value, even if it required a substantial amount of editing afterwards, re-usable functions weren't as nice in their mind, they would prefer to just copy/paste/edit even thousands of lines over and over again.

I don't recommend that sort of coding style myself, but IMO it's important to remember who your audience is when you're writing code, if you work for Bob Martin, or for somebody who enjoys his work, absolutely follow his conventions, but it doesn't work everywhere.

I'd advise the OP to keep an open mind; all of programming is a cost-benefit analysis (as RH and I were talking about a while ago); to some there are costs to Uncle Bob's programming style, and generally if the code is written a certain way there's a reason for it; whether it's a good reason or a bad one usually isn't revealed until after you've worked with the code for a while.

It may be wise to assume initially that the state of the code as it is represents the coding style that the company likes, if there's any doubt it's probably best to ask first. (this goes for simple things like bracket alignment too)