Чистится ли код после удаления компонентов?

[Снег Север]

А удобство чтения?

Представления об удобстве - дело крайне субъективное.

[Mirage]

Так что сколько-нибудь серьезной причины в "чистке кода" не имеется.

В команде не доводилось работать?
Включение неиспользуемых модулей в код было бы наименьшей проблемой. А секции инициализации кстати включаются.
Куда как серьезнее неявное использование всякого из них просто по причине совпадения имени.
Это можно долго отлаживать.
Да и просто мусор в коде это неуважение к тому, кто будет его поддерживать.

А если серьезно, то удалить модули из USES IDE не может, потому что, они могут содержать:1. Секцию инициализации

Импорт модуля ради его секции инициализации, это исключение. Просто должна быть возможность объяснить IDE, что вот этот модуль нужен, его не трогаем.

2. Глобальные переменные

А эти зачем, если обращений к ним нет?

[Снег Север]

В команде не доводилось работать?

Регулярно работаю. Никакой проблемы с "чисткой кода" не встречал. Да и SVN наше всё - всегда можно увидеть кто когда и что насовал в модуль.

[daesher]

Импорт модуля ради его секции инициализации, это исключение. Просто должна быть возможность объяснить IDE, что вот этот модуль нужен, его не трогаем.

На самом деле, не такая уж это и редкость. Многие модули - причём зачастую стандартные и обязательные - формально "висят" только на секции инициализации. Возьмите тот же Interfaces или cthreads. Формально они "не нужны", давайте предложим их "оптимизировать"? Или спросим у паскалиста-новичка? Что он ответит? Нужен ему такой модуль? Зачем? Раз - и у программы нет GUI. Или она не может нормально работать с потоками (причём только в определённой ОС при определённых условиях).
С другой стороны, идея проводить принудительную очистку очень даже здравая (и не только от модулей и компонентов, но и от собственных неиспользуемых переменных). Правда, возникает ряд проблем.
1. Такие вот стандартные модули. Логично, что в IDE должен быть сигнал типа {#Do_not_remove_by_source_optimization} как у самого модуля, так и у идентификаторов.
2. У кроссплатформенных программ отдельные переменные могут использоваться только для отдельных платформ. Конечно, идеологически это неверно, такие переменные тоже надо загонять в IFDEF, но какую-нибудь мелочь (вроде счётчика цикла i) можно и забыть - ведь она всё равно уйдёт на стадии оптимизации уже на компиляции. В итоге, под одной платформой IDE эту переменную успешно удалит, а под другой - такую программу не удастся собрать, переменную придётся восстанавливать.
3. В пользовательских модулях (Unit1/Form1) удалять неиспользуемые в программе идентификаторы можно невозбранно, даже если они глобальны (хотя и здесь есть исключения), а в стандартных глобальные трогать нельзя - одна программа может использовать одно, а другая - совсем другое.

[Kemet]

На самом деле, не такая уж это и редкость. Многие модули - причём зачастую стандартные и обязательные - формально "висят" только на секции инициализации. Возьмите тот же Interfaces или cthreads. Формально они "не нужны", давайте предложим их "оптимизировать"? Или спросим у паскалиста-новичка? Что он ответит? Нужен ему такой модуль? Зачем? Раз - и у программы нет GUI. Или она не может нормально работать с потоками (причём только в определённой ОС при определённых условиях).

это архитектурная ошибка

[Mirage]

Регулярно работаю.

И кто-то согласен работать с мусором в коде? Да еще и чужим? Повезло. Но проблемы от него никуда не денутся. И заглядыванием в SVN их не решить.

Многие модули - причём зачастую стандартные и обязательные - формально "висят" только на секции инициализации.

Тоже думаю, что это нехорошая практика и надо бы отходить от нее.
Такие и придется помечать как неприкасаемые. С IFDEF'ами проблем нет. Неприкасаемость действует для всех платформ.
Чистить секцию uses предполагается разумеется только в пользовательском коде. Стандартные модули (RTL?) какой вообще смысл трогать? Только их разработчикам.

Удалять же неиспользуемые идентификаторы автоматически, думаю, плохая идея. Помечать обязательно. Т.к. это может быть просто ошибка - вместо нужного идентификатора используется другой.

[Снег Север]

Но проблемы от него никуда не денутся.

"Мне бы ваши проблемы..." (С) Вовочка.
Вот уж от чего проблем пока не встречал, это от "мусора в коде".

[Kemet]

вообще, надеяться на Лазарус сильно не стоит, ибо IDE часто лажает, вот буквально только что смотрел исходники компилятора в модуле dbgstabs строка 967
[tostr(TConstExprInt(tarraydef(def).elepackedbitsize) * tarraydef(def).elecount),tempstr]);
лаазарус показывает, что tostr находится в модуле cutils, тогда как реально оно в модуле constexp.
А вот если бы разработчики квалифицировали все обращения к сущностям других модулей, то и проблемы такой бы не было и код был бы понятным сразу. Ну или по-крайней мере, не видно было бы эту проблему, а так, на каждом углу.