> Игорь Шевченко ©   (07.10.14 15:21) [39]


> Вот мне интересно, кто-нибудь из этого встроенного аудита
> хоть какую-то пользу имеет ? Кроме тучи цифири, в которой
> без стакана разобраться невозможно, я там ничего полезного
> не обнаружил

Аналогично. Слишком там всего много и большая часть - бестолковая на практике.
Его настраивать очень долго надо под себя, тогда может и будет полезен. Но нужно завидное терпение.

Да, я тоже подумал, что Kerk прочитал про PVS Studio на хабре (пиарятся они толково) и решил что-то типа такого запилить )

> Игорь Шевченко ©   (07.10.14 15:21) [39]
> DVM ©   (07.10.14 15:14) [38]
>
> Вот мне интересно, кто-нибудь из этого встроенного аудита
> хоть какую-то пользу имеет ?

Исходя из того что на нашем проекте тупо падает (примерно полтора ляма строк кода только на основе, без учета кода от плагинов и т.п.) пользы нет вообще.
На более легком пробовал запустить - как ты и сказал: "тучи цифири, в которой без стакана разобраться невозможно"

Кстати вопрос в принципе по теме (парсинг и анализ кода) я в свое время писал анализатор проекта, который показывал бы понятную глазу диаграмму зависимостей классов.
http://rouse.drkb.ru/other/uw.gif

Он тогда был заточен под 2007, впрочем проект я забросил, а те люди, которым передал исходники так и не стали его развивать.
Оть тут последнее о нем упоминание: http://www.delphimaster.net/view/1-1237789977/all

Вот щас на XE4 он конечно не работает, но вопрос: а есть ли аналоги такого плана? Мне нужно просто диаграму посмотреть дабы правильно все зарефакторить.

ЗЫ: Если аналогов нет, а инструмент лично мне нужен, придется конечно его поднимать опять и пробовать перепилить на ХЕ4 взяв за основу парсер от Ромки

Rouse_
Вот эти инструменты нужного тебе не делают?  (я глубоко не смотрел)
http://www.peganza.com/

> Rouse_ ©   (07.10.14 19:30) [43]
> диаграмму зависимостей классов.

Это не оно?
http://www.modelmakertools.com/

> примерно полтора ляма строк кода

и сколько по времени билд?

> Kerk ©   (07.10.14 19:38) [45]
> Это не оно?

Неа. Ну в принципе как - оно конечно, но не фурычит оно так, как мне нужно, именно поэтому и писал свой инструмент под прошлый рефакторинг.


> MBo ©   (07.10.14 19:35) [44]

Спасибо, завтра гляну.

> ProstoTak ©   (07.10.14 20:08) [46]
> и сколько по времени билд?

Дебаг в районе 45 секунд, релиз около 4 минут (билд, защита, снятие хэшей, цифровуха и т.п.)

> Kerk ©

А можно сделать portable версию? Что бы без setup/install?

[FixInsight Warning] untFrontolSvc.pas(104): W511 Object "SDE" created in TRY block

Добавь проверку, что объект освобождается в Finally
там конструкция

Cobalt ©   (08.10.14 10:19) [50]

Такой код желательно переписать на

SDE := TServiceOperation.Create;
try
 ...
finally
 SDE.Free;
end;

код в [50] может иметь смысл, если несколько объектов создается

>код в [50] может иметь смысл, если несколько объектов создается

в параллельных потоках? или как?

всё равно лучше [51] делать

>Добавь проверку, что объект освобождается в Finally

здесь проблема не в том, что объект освобождается в файнали, а в том, что он создаётся в блоке try.

> [53] Дмитрий Белькевич ©   (08.10.14 10:44)

obj1 := TClass1.Create;
...
objN := TClass1.Create; -> exception, obj1-obj[N-1] - утечка памяти
try

finally
 objN.Free;
 ...
 obj1.Free;
end;

junglecat ©   (08.10.14 10:39) [52]

С точки зрения компилятора любой код имеет право на жизнь. С точки зрения программиста один код проще читается, в нем легче разобраться и меньше мест для потенциальных ошибок. Другой код читается труднее, в нем дольше разбираться, ...

Для меня образцом хорошего кода служат исходные тексты VCL, до 1999 года. При их изучении я не сталкивался с одновременным созданием и освобождением нескольких объектов с необходимостью обнуления ссылок на них перед созданием.

Сразу возникает вопрос, а почему бы эту группу связанных объектов не объединить в один класс и создавать и уничтожать именно этот класс.

Бывает так, что этих классов всего 2-3 штуки и они смыслово между собой не связаны.
Скажем, два словаря, Тстринглист, Тстрим и какой-нить FTP

Cobalt ©   (08.10.14 11:40) [57]

Мне кажется, что дизайном в этом случае что-то не так. Еще раз, посмотри в VCL там вполне массово используемый продукт.

Я к чему - если Рома делает программу, ищущую недостатки или потенциальные ошибки в работающем коде, то не стоит туда вводить правила, скажем так, расчитанные на поощрение такого рода приемов в разработке приложений. Точно так же можно сказать, что except end вполне себе допустимая конструкция, "я же знаю, что исключения возникнуть только определенного типа и я хочу их игнорировать".

> Для меня образцом хорошего кода служат исходные тексты VCL,
> до 1999 года

а я бы не брал их за идеал в данном случае. Потому как это абстрактный фреймворк, не имеющий связи с какой-либо предметной областью.
А в рамках предметной области могут быть разные казусы. В том числе и создание нескольких явно не связанных объектов в одном участке кода.