> I'd encourage you to understand that you are not saving any time by focusing on styling before functionality.

Far more developer time is spent reading code than writing it.

If you can speed up the time required to understand a piece a code by improving the style then it's almost always worth it. For a professional software engineer, just above "absolutely unreadable" is far too low a bar to aim for.

I am still not convinced that readability comes before functionality.

Imagine a developer building a PR for 2 weeks, then reviews back and forth for 2 more weeks. Now 4 weeks have passed and only now the reviewer reviews the functionality - only to find that the entire implementation is wrong/could be done in a better way.

What a waste of 4 weeks of both the author and the reviewer! This could have been short-circuited very early in the process.

On my team, we default to early feedback on functionality and let the CI enforce what it can. Everything else is debatable.

Trying to understand the functionality of code which is hard to read is also a huge waste of time. You should try to keep the code easy to read even in very early drafts instead of leaving that until the end.

Hard to read code is subjective. I am guessing you are working with professionals and not high school programmers. Most of the code I see from professional programmers is passable enough for me to

1. Review functionality and then

2. Point out something about coding style.

In fact, if the functionality is good, I even approve the PR leaving a lot of code styling comments that the author can fix at their own leisure.

Readability has very little to do with styling.

It's about clearly and concisely expressing ideas.

Leave styling to linters. Reviewers should be focusing on how the code is communicating.