FixInsight for Delphi

← →
Kerk © (2015-04-30 22:50) [120]

> Юрий Зотов © (30.04.15 13:56) [116]
>
> > Kerk
>
> Еще бы fast fix добавить, где это возможно - полная конфета
> была бы. Понимаю, не просто. Ну на будущее - как вариант
> развития.

Что-то такое иметь было бы очень здорово. Постепенно, надеюсь, все получится.
Вообще, как можно плотнее интегрироваться с IDE - один главных приоритетов.

> Юрий Зотов © (30.04.15 20:58) [118]

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

> Юрий Зотов © (30.04.15 21:06) [119]
>
> Но FixInsight сработал правильно, место подозрительное.

Такие ситуация - моя большая боль. Одно дело действительно настоящие ложные срабатывания, с которыми я борюсь как могу. А другое - когда срабатывание верное, но программист эту ситуацию умышленно допустил. Это все-таки всего-лишь анализатор, а не искусственный интеллект, он не может такие тонкие вещи прочувствовать.

И по-моему в таком случае от предупреждения нет никакого вреда, человек просто посмотрит, убедится, что все в порядке и пойдет дальше.

А боль это для меня потому, что многие пользователи ждут от инструмента совершенно магического поведения и расстраиваются, что это не так. Имеют право, конечно.

← →
Юрий Зотов © (2015-05-01 09:14) [121]

> Kerk

> Это все-таки всего-лишь анализатор, а не искусственный интеллект,
> он не может такие тонкие вещи прочувствовать.

Естественно. Да и не нужно ему ничего чувствовать. А вот ввести что-то типа опции ON/OFF было бы, наверное полезно. Примерно так:

В своем модуле определяешь две опции:

{$DEFINE FixInsightOn} {$DEFINE FixInsightOff}

И если юзер хочет локально отключить FixInsight, то пишет что-то вроде этого:

{$FixInsightOff} tmrFilter.Enabled := false; tmrFilter.Enabled := true; {$FixInsightOn}

Код неверный, но суть показывает.

← →
Юрий Зотов © (2015-05-01 09:23) [122]

То есть, речь идет о комментарии специального вида. Встретив открывающий комментарий, FixInside пропускает код до закрывающего комментария (а если его нет, то до конца модуля).

← →
Игорь Шевченко © (2015-05-01 10:47) [123]

Kerk © (30.04.15 22:50) [120]

> Я бы на самом деле на любую передачу указателя на вложенную
> функцию ругался. Случаи, когда это оправдано придумать сложно,
> а вот проблем не оберешься.

итераторы в Collections в Turbo Vision. Я не понимаю, почему они так сделали, но факт остается фактом.

Если вложенные функции допустимы конструкцией языка, то почему бы и не передавать указатели на них ? :)
Я не понимаю (за 20 с лишним лет программирования на паскале) конструкции
repeat ... until и за все это время использовал ее считанное количество раз, но не ругаюсь, когда ее используют другие :)

← →
eldorad © (2015-05-01 12:28) [124]

>Я не понимаю (за 20 с лишним лет
>программирования на паскале) конструкции
>repeat ... unti

А вот это интересно.

Repeat тоже самое что while, только в первом случае тело цикла первый раз выполняется всегда, а потом уже проверяется условие, во втором случае сначала проверяется условие. В зависимости от задачи бывает удобно то так, то эдак. Что тут может быть непонятного?

← →
eldorad © (2015-05-01 12:48) [125]

Классика:

if FindFirst(FileName, faArchive,SearchRec) = 0 then
repeat
if (SearchRec.Attr and faAnyFile) = SearchRec.Attr then
begin
...
end;
until FindNext(SearchRec) <> 0;

Как это переписать так же лаконично через while?

← →
eldorad © (2015-05-01 12:52) [126]

Ну например как в си плюс в цикле for можно использовать ++i а можно i++
Бывает удобно так, бывает эдак.

Хочется послушать размышлений насчет непонимания.

← →
Юрий Зотов © (2015-05-01 15:26) [127]

> eldorad © (01.05.15 12:52) [126]

Похоже, Игорь имеет в виду не сам цикл, а условие выхода из него. Когда-то давно я тоже не сразу привык, что repeat заканчивается на true.

← →
eldorad © (2015-05-01 15:34) [128]

Дядя Юра, сказано достаточно четко:

Я не понимаю ... конструкции
repeat ... until и за все это время использовал ее считанное количество раз

← →
jack128 © (2015-05-01 19:18) [129]

> Ну например как в си плюс в цикле for можно использовать
> ++i а можно i++
> Бывает удобно так, бывает эдак.

C точки зрения производительности (в общем случае) - нужно писать ++i. Но если i - встроенный тип, то современные компиляторы соптимизимруют.

← →
Cobalt © (2015-05-01 20:51) [130]

У нас тут в коде у нас нашлось такое:
Result := Result;

← →
Rouse_ © (2015-05-01 21:21) [131]

Вовч, это ерунда. Помнишь, когда у нас еще работал был такой Леха и его код?
Оть это была реальная жесть, один тока перечислимый тип из полутора тыщ констант чего стоил :)

← →
Kerk © (2015-05-01 21:29) [132]

> Юрий Зотов © (01.05.15 09:14) [121]
> И если юзер хочет локально отключить FixInsight

Так есть что-то похоже уже. Можно использовать директиву компилятора _FIXINSIGHT_.

[delphi]
{$IFNDEF _FIXINSIGHT_}
tmrFilter.Enabled := false;
tmrFilter.Enabled := true;
{$ENDIF}
[/delphi]

Если директива _FIXINSIGHT_ установлена, значит идет анализ кода. И можно этим пользоваться, исключать какие-то куски.

> Игорь Шевченко © (01.05.15 10:47) [123]
> Если вложенные функции допустимы конструкцией языка, то
> почему бы и не передавать указатели на них ? :)

Допустимыми конструкциями языка является вообще много что. Например пустой except вполне допустим, и метод длиной 1000 строк тоже допустим, и даже Result := Result вполне допустимая конструкция :)

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

По поводу отключения проверка, у меня есть забавная история.

При удалении FixInsight открывается окошко с просьбой рассказать почему человек его удаляет: что-то не понравилось, не работает и т.п. Большинство это окошко просто молча закрывает, но некоторые отвечают. Это полезно.

Так вот один из отзывов звучит примерно так: "у меня плохой код, я это и сам знаю, утилита мне не нужна" :)

> Юрий Зотов © (01.05.15 15:26) [127]
>
> > eldorad © (01.05.15 12:52) [126]
>
> Похоже, Игорь имеет в виду не сам цикл, а условие выхода
> из него. Когда-то давно я тоже не сразу привык, что repeat
> заканчивается на true.

Я тоже постоянно на этом спотыкаюсь. Так-то с точки зрения английского языка все понятно ("пока не..."), но непонятно почему для постусловия нельзя было использовать тот же while.

Типа,
[delphi]
begin
Dec(I);
end while (I > 0);
[/delphi]
Хотя сейчас смотрю на этот код и неестественно он как-то выглядит.

← →
Германн © (2015-05-01 22:15) [133]

> непонятно почему для постусловия нельзя было использовать
> тот же while

Как раз с точки зрения английского понятно. :)
"В то время как" никак не вяжется с пост-условием.

← →
Ega23 © (2015-05-01 23:00) [134]

> Оть это была реальная жесть, один тока перечислимый тип
> из полутора тыщ констант чего стоил :)

А чё в прошедшем-то времени-то? Да и кот этот никуда не делся.

← →
Германн © (2015-05-02 01:20) [135]

> Rouse_ © (01.05.15 21:21) [131]
>
> Вовч, это ерунда. Помнишь, когда у нас еще работал был такой
> Леха и его код?
> Оть это была реальная жесть, один тока перечислимый тип
> из полутора тыщ констант чего стоил

Неужто кому-то было не лень писать столько констант? Или он автоматизировал сей процесс? :)

← →
Юрий Зотов © (2015-05-02 06:31) [136]

> Kerk © (01.05.15 21:29) [132]

Если вместо общих begin-end использовать специальные ключевые слова, то все становится естественно. Например:

repeat ... while ... ; // Выход при false

← →
Sha © (2015-05-02 15:49) [137]

> Когда-то давно я тоже не сразу привык, что repeat заканчивается на true.

В Паскале везде работает простая мнемоника:
при истинном условии всегда проваливаемся ниже к следующему оператору,
при ложном условии - последовательное выполнение операторов нарушается.

← →
eldorad © (2015-05-02 20:45) [138]

> C точки зрения производительности (в общем случае) - нужно
> писать ++i

Жень, я про порядок выполнения операций.

В общем, ИШ что-то такое сказал, что гадать бессмысленно :) Или автор пояснит, или это навсегда останется тайной :)))

← →
jack128 © (2015-05-02 22:14) [139]

> Жень, я про порядок выполнения операций.

Э-э-э. В контексте цикла for какое это имеет значение?
for (auto it = begin(container); it < end(container); it++) { } ... for (auto it = begin(container); it < end(container); ++it) { }
логически обе формы эквивалентны. А вот с точки зрения производительности разница есть.

← →
Inovet © (2015-05-02 23:11) [140]

Что-то там такое. В первом случае может быть вызван конструктор, присвоение во временную переменную, сравнение с ней, инкремент первой, возврат из операции инкрементированной переменной. Во втором работа с одним экземпляром.

Паскалевсикй цикл с постусловием требует каждый раз вспоминания его особенности.

← →
Игорь Шевченко © (2015-05-03 00:33) [141]

Sha © (02.05.15 15:49) [137]

> В Паскале везде работает простая мнемоника:
> при истинном условии всегда проваливаемся ниже к следующему
> оператору,
> при ложном условии - последовательное выполнение операторов
> нарушается.

И для соответствия этой мнемонике существует два разных оператора проверки условия продолжения цикла, потому они в разных местах записи цикла находятся ?

← →
Германн © (2015-05-03 02:40) [142]

> И для соответствия этой мнемонике существует два разных
> оператора проверки условия продолжения цикла, потому они
> в разных местах записи цикла находятся ?

Ну вроде бы/как бы ДА. Если сначала нужно проверить некое условие, а потом что-то делать в зависимости от результата проверки, то while.
Но если нужно обязательно что-то сделать хоть один раз, то почему бы и не repeat?

← →
Sha © (2015-05-03 11:13) [143]

> Игорь Шевченко © (03.05.15 00:33) [141]

Мнемоника помогает запомнить, что и как.
Она подбирается так, чтобы соответствовать чему-либо, а не наоборот.

← →
Kerk © (2015-05-03 20:21) [144]

Было бы удобно еще иметь в Delphi конструкцию вроде while-else, то есть цикл и отдельная ветка для случаев, когда он ни разу не выполнился.

Вроде

while i > 0 do Dec(I) else ShowMessage("I <= 0");

← →
Inovet © (2015-05-04 04:40) [145]

> [144] Kerk © (03.05.15 20:21)

Имхо, Оккама знал об этом.

← →
eldorad © (2015-05-04 07:45) [146]

Согласен с Kerk

← →
Sha © (2015-05-04 09:20) [147]

несогласен с eldorad )

← →
Юрий Зотов © (2015-05-04 09:28) [148]

И строковый case.
:o)

Согласен с дядей Юрой. Впрочем конструкция множественного else if не занимает больше места.

Для case компилятор мог бы какие-нибудь оптимизации применять.

Строковый case с регулярками

> Юрий Зотов © (04.05.15 09:28) [148]
>
> И строковый case.

Ну да. А то "женщины уже в баскетбол играют!" (с)
То бишь я хотел сказать, что в Лазарусе уже есть такой case. :)

С Format-ом есть баг. Ругается на

Result := Format("uif_%.*x", [8, I]);

Хотя количество аргументов именно то, которое должно быть - два.

и индесацию параметров тоже не понимает:

Lines.Add(Format(#9#9"<%s>%d</%0:s>", [xme_FilePos, FilePos]));

> q1w2e

У тебя похоже старая версия. Обновись.

Да, так и есть. После обновления ушло.

Но что-то я не разобрался как обучить утилиту командной строки разбору условной компиляции. Подозреваю, что как-то это можно сделать .ficfg-файл.

Где-то можно об этом почитать?

>Как это переписать так же лаконично через while?

k := FindFirst(RootPath + "Html\Report*.html", faReadOnly, SearchRec); while k = 0 do begin ShowMessage(SearchRec.Name); k := FindNext(SearchRec); end;

?

>Некрасиво, конечно, но если нормального способа не предусмотрено, то ничего другого не остается.

Я у себя делал специальный таймер TThreadTimer - работающий в параллельном потоке и вызывающий код в параллельном потоке, добавил методы Start, Stop и Restart. Почему что-то такое не добавить в VCL/FMX? Неудобно же как есть.

> q1w2e © (19.05.15 18:00) [156]
>
> Да, так и есть. После обновления ушло.
>
> Но что-то я не разобрался как обучить утилиту командной
> строки разбору условной компиляции. Подозреваю, что как-
> то это можно сделать .ficfg-файл.
>
> Где-то можно об этом почитать?

Директивы компиляции в командной строке можно указывать с помощью параметра --defines
А написано про это в документации :)

> Дмитрий Белькевич © (20.05.15 12:36) [158]
>
> >Некрасиво, конечно, но если нормального способа не предусмотрено, то ничего другого не остается.
>
> Я у себя делал специальный таймер TThreadTimer - работающий
> в параллельном потоке и вызывающий код в параллельном потоке,
> добавил методы Start, Stop и Restart. Почему что-то такое
> не добавить в VCL/FMX? Неудобно же как есть.
Мне кажется, не стоит нагружать Embarcadero вещами, которые может сделать каждый программист. Они со своими-то не справляются. А им это ещё поддерживать для разных платформ...

FixInsight for Delphi Найти похожие ветки