> If I was tasked with changing anything in there, or analyzing the code, the first thing I would do is run autoformat on it. even if I have to preserve the cod

> If I was tasked with changing anything in there, or analyzing the code, the first thing I would do is run autoformat on it. even if I have to preserve the code style, I would just translate it back once I'm done This could be done with local reindentation/deindentation. You'd need some way to map back to the original style, maybe treating the whole process like a git edit, putting a newline before each new addition, highlighting it, with a checkmark button to "commit" them once the indentation is adapted to the original style, and by "commit" I mean make the highlighting go away. However the criticism about the right part of the code being visual noise I see in your reply and others is somehow unfair, the second pic bordering on the limits of what I find acceptable myself. It's still linguistically readable as in you'd still be able to replace the parens and braces by reading that one line of code aloud. It's not code that's supposed to be readable in a typographical sense, with harmonious spacing meant to catch the wandering eye like an ad, it's code that was written to be thought through. Sit and think. For 30 minutes before hitting 'build'. After minor compilation errors and the first successful build, I had just a single one-line fix to make before having the code run correctly.