Я полностью поддерживаю использование УЛУЧШАТОРОВ типа SonarQube, PMD и прочие которые просто позволяют указать мне на явные ошибки типа potenrial null pointer de-referencing.
Но вот в части - написать по другому - я-бы сказал что это открытый вопрос. Ставить ТЗ нельзя так чтобы "сделать на выходе хоть что-нибудь". При таких критериях мы получим просто рандомный шум который тем не менее компилируется. Типа "бей посуду - я плачу". Но автору такое не надо.
Тогда давайте зададим вопрос. А что собсно надо автору? Приведу пример который я часто использую. Решения задач на codewars. Они разные. Но обычно в топе висят 2-3 штуки которые поражают своей краткостью и различностью парадигм. Например в топе висит одно решение с хвостовой рекурсией а другое с циклом. И я не могу решить которое мне больше нравится. Нравятся оба. Но скорее всего при разработке code beautifier я-бы не стал вообще копать 2 направления. Достаточно было-бы просто поставить задачу сделать код меньше. Я думаю что все согласятся что меньше строк - меньше надо будет скроллить вниз. Особенно эти дело любят Джависты. Как накидают своих бинов с геттерами-сеттерами ойойой. 80% кода - нечитаемый шлак. Ну да ладно. А насколько меньше? Есть обфускация. Это сознательне выпиливание смыслов из всех идентификаторов. Вобщем переменные можно называть $1,$2 e.t.c. и это тоже работает. Но ... согласитесь это путь в никуда.
Поэтому. Чтобы улучшать мы должны САМИ задать вектор улучшения. Парадигмы например. Мы хотим код тяготеющий к функциям или к объектам с методами? Мы хотим код с детальным дебагом (каждый оператор в своей строчке) или нам пойдет исходник как у Джона Кармака. Весь С++ исходник в 1 длинную строку. Мы хотим код на конечных автоматах? Или на комбинаторах? Мы хотим больше перформанс но хуже читаемость (вспоминаем знаменитую Кривую Шипилёва) или наоборот?
Вобщем думайте над вектором улучшения.
