|
Notes |
|
|
(0015660)
|
|
zed
|
|
22-04-2015 10:44
|
|
|
У кого какие мысли, возражения? |
|
|
|
|
>или по его пути
Так представляется логичным вот почему: поскольку файлы раскиданы по папкам, то изменения с большей вероятностью затронут меньшее количество строк в dpr.
А вообще конечно не принципиально.
Но вообще если решите так формировать dpr и dproj - тоже перейду на этот скрипт, только вот дополнительные файлы куда-то деть надо будет (в отдельный модуль видимо).
>главное не переименовывать юнит
А что страшного будет, если юнит переименуется?
Старый пропадёт, новый появится. Diff-ы видно же. Чай не 100500+ файлов меняется за раз. |
|
|
|
|
|
Я за сортировку по пути. А еще лучше было бы сначала сортировать по префиксу в имени юнита, а потом уже по пути. Причем префиксы отсортировать не по алафавиту, а по предварительно заданному порядку: t_*.pas, c_*.pas, i_*.pas, u_*.pas, fr_*.pas, frm_*.pas |
|
|
|
|
>i_*.pas, u_*.pas
Хм. А чем плохо, если будет так:
i_BinaryData in 'Src\Basic\i_BinaryData.pas',
u_BinaryData in 'Src\Basic\u_BinaryData.pas',
u_BinaryDataByFileMapping in 'Src\Basic\u_BinaryDataByFileMapping.pas',
u_BinaryDataByMemStream in 'Src\Basic\u_BinaryDataByMemStream.pas',
i_BinaryDataListChangeable in 'Src\Basic\i_BinaryDataListChangeable.pas',
i_BinaryDataListStatic in 'Src\Basic\i_BinaryDataListStatic.pas',
u_BinaryDataListStatic in 'Src\Basic\u_BinaryDataListStatic.pas',
То есть, u_ цепляем к существующему i_, если такового нет, то смотрим какой максимальный есть (CamelCase тут рулит) и цепляем туда, сортируя среди всех его u_?
Не вижу смысла разделять "одноимённые" i_ и u_ пропастью в половину файлов проекта.
|
|
|
|
(0015670)
|
|
zed
|
|
22-04-2015 11:21
|
|
>А что страшного будет, если юнит переименуется?
Скрипт его проигнорирует и не исправит файлы проекта.
>А еще лучше было бы сначала сортировать по префиксу в имени юнита
По-моему, фигня получится. |
|
|
|
(0015671)
|
|
vasketsov
|
22-04-2015 11:24
(edited on: 22-04-2015 11:29) |
|
>проигнорирует и не исправит
Упс. А я понял, что скрипт просто строит часть файла проекта заново по фактическим файлам в каталогах, просто берёт начало и конец файла, а середину с файлами и путями с нуля собирает.
>фигня получится
Никогда не понимал, зачем все формы так яростно совать в самый конец проекта.
Так что уж лучше при сортировке вообще игнорировать префикс, чем такая вот фигня с перечнем префиксов.
XE2 вполне корректно обрабатывает ситуацию внешнего изменения фалов проекта (в том же блокноте), так что после запуска скрипта среда вполне в состоянии будет сама поднять его с диска, и лазить руками в файлы проекта не понадобится, соответственно, какой там порядок, важно только для самого порядка и изменений, а не для правки руками. И где будут frm - сугубо пофигу.
|
|
|
|
|
>Хм. А чем плохо, если будет так
>То есть, u_ цепляем к существующему i_, если такового нет, то смотрим какой максимальный есть (CamelCase тут рулит) и цепляем туда, сортируя среди всех его u_?
Нетривиальная сортировалка выходит.
>>фигня получится
>Никогда не понимал, зачем все формы так яростно совать в самый конец проекта.
Может быть и фигня. |
|
|
|
(0015673)
|
|
zed
|
|
22-04-2015 13:19
|
|
|
Отсортировал по пути и залил в репо. Для запуска скрипта нужен python 2.7. |
|
|
|
|
>Нетривиальная сортировалка
Ну в общем-то да, не сильно тривиальная.
Но это проблема скрипта и принципиального наличия консенсуса в том, что это вообще НАДО. А то если например кто-либо будет руками править dpr, то толку будет мало.
Поскольку мне тоже кажется предпочтительнее по папкам раскидывать, алгоритм вижу примерно такой:
а) скрипт берёт файл проекта, ищет начало списка модулей и его конец (весьма тривиально по характерным строчкам в файле проекта, что для dpr что для dproj);
б) проходит по дереву каталогов, строит его и в алфавитном порядке для каждой папки выполняет следующие шаги;
в) получает исходный список файлов;
г) сортирует i_ в чистый результирующий список (из исходного на каждом шаге обработанное удаляется);
д) добавляет в этот список все u_ (по алгоритму выше, это как раз самое нетривиальное);
е) добавляет в этот список все прочие файлы, для которых есть в точности одноимённый i_ или u_, непосредственно ПЕРЕД ним или любым другим с другим префиксом и той же смысловой частью имени файла (чтобы t_ и c_ соответствующие i_ были перед ними, но реализацию в u_ от i_ не отделяли) *);
ж) остальное сортируется между собой тупо по алфавиту (для форм и фреймов оставляется одна соответствующая запись вместо двух имён файлов в dpr) и помешается в результирующий список в начало (для простоты, а также если будут ещё новые префиксы);
з) результирующий список обрабатывается и падает в файл проекта;
и) цикл повторяется, покуда не прошли все каталоги;
*) если на шаге е) в список попадают одноимённые формы и фреймы, значит разработчик сделал это неспроста, и их тоже надо обработать на этом шаге аналогичным образом.
Поскольку краеугольным камнем проекта является именно интерфейсный файл i_, а реализация его в u_, подобный алгоритм представляется весьма оправданным.
А поскольку бардак в dpr существенно разросся с увеличением папок в проекте, делать всё равно что-то придётся. Например, я просто руками с разделяющими комментариями раскидал всё по папкам. Но идея со скриптом мне нравится больше. Особенно если его напишет уважаемый товарищ zed )))
Осталась самая "мелочь" - прийти к консенсусу. |
|
UnitsSortHelper.py (4,605) 22-04-2015 10:44