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