Вопросы по исходному коду.

[vdemidov]

Подскажите, пожалуйста, где находится код "проецирования" фрагмента (участка) карты на компонент TImage32?

Смотрите TMapType.LoadBitmapUni, загрузка с изменением проекции пока живет там, со временем переедет.

И как только вы это в памяти-то храните. Попробовал я реверснуть исходный код в диаграмму классов... комп 15 минут только парсил (надоело, прервал), потом ещё минут 5 строил отношения между классами из того, что распарсил. Такая паутина получилась, что страшно.

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

Нет ли у вас обзорной карты дебрей кода

Увы нет. Если бы кто-то занялся этим, я был бы очень благодарен. Так как иногда самому не хватает.

[uni]

Спасибо, я оказывается этот код находил, только не совсем понял что это то, что нужно. Ещё такой вопрос. У вас есть соглашения о форматировании кода? Типа как у команды RSDN. Просто всё так в кучу напихано, что такое чувство, что писалось на мониторе с маленькой диагональю и код не помещался на экран. Я то сам привык пользоваться Code Formatter'ом, который был с GExperts, но в RS2007 что-то не понял как его подключить. Это влияет на скорочтение кода. Тут явно кому-то нужно почитать "Совершенный код" Макконнелла (там есть некоторые простые советы, которые можно было бы использовать, самый простой совет, который очевидно не выполняется в коде: расположение декларации переменных в секции var в порядке их сложности, например: boolean, WORD, integer, string, TObject, ...) или купить монитор с большей диагональю, чтобы не было дискомфорта при чтении более разряженного кода. Это не упрёк, а пожелание.

Сам я привык к вот такому вот стилю форматирования как на картинке. Я больше на C++ пишу или на шарпе, там с этим делом куда лучше, особенно в MSVS2010, среда практически за тебя код переписывает (если есть некоторые плагины). Долго искал что-то подобное для Delphi, чтобы было в виде плагина. Нашёл пока вот этот самый Code Formatter, но не знаю как его использовать выше Delphi 7. Он в общем немного примитивный, но это лучшее из того, что я находил. Я изучение чужого кода начинаю с того, что нажимаю Ctrl + Alt + F (быстрая клавиша для форматирования) и спокойно уже читаю привычное форматирование.

Я понимаю, что вряд ли кто будет что-то переформатировать код в 1000 файлах, но всё-таки умные книжки говорят, что вот как раз для этих случаев (код больше читают, чем пишут), чтобы можно было применять общепринятые правила скорочтения кода, можно было бы ввести какие-то правила или соглашение о форматировании.

Я пока тут новичок, если смогу в чём-то разобраться, то может предложу что-нить по поводу обзорной карты. Желательно придумать что-то автоматизированное с минимальными ручными правками.

[vdemidov]

Ещё такой вопрос. У вас есть соглашения о форматировании кода? Типа как у команды RSDN.

У меня есть свои принципы форматирования и я их стараюсь придерживаться, но явно они нигде не сформулированы.

Просто всё так в кучу напихано, что такое чувство, что писалось на мониторе с маленькой диагональю и код не помещался на экран.

Крайне желательно ширину кода ограничивать 80 символами. Далеко не везде и не всегда есть огромные мониторы.

Тут явно кому-то нужно почитать "Совершенный код" Макконнелла (там есть некоторые простые советы, которые можно было бы использовать, самый простой совет, который очевидно не выполняется в коде: расположение декларации переменных в секции var в порядке их сложности, например: boolean, WORD, integer, string, TObject, ...)

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

или купить монитор с большей диагональю, чтобы не было дискомфорта при чтении более разряженного кода. Это не упрёк, а пожелание.

У меня на десктопе монитор 24 дюйма. Читать код шириной 80 символов вполне удобно и еще остается место под служебные окна.
На нетбуке монитор 10 дюймов и там даже 80 символов иногда многовато. Так что увы.

Нашёл пока вот этот самый Code Formatter, но не знаю как его использовать выше Delphi 7.

Я пользуюсь JediCodeFormat слегка допиленный под мой стиль. Взять и скомпилировать можно отсюда https://bitbucket.org/sas_team/jedicodeformat

Я пока тут новичок, если смогу в чём-то разобраться, то может предложу что-нить по поводу обзорной карты. Желательно придумать что-то автоматизированное с минимальными ручными правками.

Буду благодарен.

[vasketsov]

может предложу что-нить по поводу обзорной карты

Надеюсь понятно, что она будет вещью в себе, и будет устаревать быстрее чем публиковаться? )))
Для сравнения приведу пример к моделью (например БД), которая ведётся в PowerDesigner (или другом аналогичном инструменте).
Смысл этого заключается в том, что правится именно модель, и она является единым источником изменений, которые транслируются в остальные части проекта.
Тогда в этом есть смысл.
А если после каждой правки (ну или не каждой) пробовать собирать модель обратно из фактических правок, ходить по проекту, по БД и т.п. - это лишь нужно для визуализации, или для поиска чего-то типа циклов, но это отлично делают спецтулзы, которые например ищут неиспользуемые модули, отсутствие const у интерфейсов и т.п.
В общем польза весьма сомнительна, и полностью нивелируется быстрым устареванием.
зы. После проектов в СУБД типа в тысячу таблиц и сотни хранимок и кода под лимон строк - сас представляется весьма небольшим проектом. Нечто среднее между расчётом амортизации ОС и расчётом производственной себестоимости.
ззы. Лучше время на поиск генерилки красивых разных картинок потратить на ознакомление с кодом проекта. В любом случае поиск по проекту Ctrl+F будет всегда давать актуальную информацию, в отличие от "весёлых картинок".

[vasketsov]

Сам я привык к вот такому вот стилю форматирования как на картинке

Я вам могу с ходу объяснить его недостатки для длительных проектов с контролем версий.
С вероятностью 99% код будет правиться.
Соответственно кодить надо так, чтобы при правке было сразу понятно, что именно поправилось.
В этом смысле любая длинная строка типа if ... then ... будет подсвечиваться при показе различий, и мозгу надо дополнительное время, чтобы понять, где различие, в условии или нет.
Аналогично если вместо одной команды после then появится две - сразу будет понятно, что относится к условию, а что нет.
На картинке это соответствует например добавлению команды к строке 533.
Так что лучше сразу на будущее писать begin end. Чтобы правки в будущем были наглядными.
Аналогично при добавлении параметра в декларацию функции лучше не добавлять его в конец, так как изменится две строки, а не одна. И при вызове переносить параметры - сразу будет видно, что поправлено или добавлено. Хотя это мелочи.

Всё прочее типа "лишних" пробелов - мелочь, и переучка в рамках проекта происходит за пару часов.

А вот что реально радует - так это комментарии. И наличие, и их вид (отдельной строкой после //). Код лучше комментировать блочными в отдельных строках (* *), так как при показе различий между версиями будет видно, что сам код не изменился (а просто закомментирован и раскомментирован). А вот словами комментировать надо в отдельных строках, опять же чтобы не путаться, что поменялось в сроке, код или комментарий.

[vdemidov]

Полностью согласен со всем кроме одного пункта:

Код лучше комментировать блочными в отдельных строках (* *), так как при показе различий между версиями будет видно, что сам код не изменился (а просто закомментирован и раскомментирован).

ИМХО при наличии системы контроля версий комментировать так код нужно только временно в личных целях и ни в коем случае не коммитить это изменение, если код не нужен, то его нужно именно удалять.

[vasketsov]

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

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

[vdemidov]

А если это что-то новое, которое пока чего-то ждёт и вот прямо сейчас не может быть закоммичено, то есть этого ещё нет в репозитории, но по какой-либо причине код не подпадает под "если код не нужен", то тут либо коммитить в комментариях, либо залить и тут же поверх комментариев новым коммитом вычистить комментарии ))), либо прочие извраты типа сложить себе отдельно в "левую" папочку с вероятностью потерять, забыть и т.п.

Для этого в СКВ есть ветви. Так что ИМХО закомментированный код в коммите это зло в 99% случаев.

[uni]

Хорошо, я согласен с большинством замечаний, но всё-таки как потенциальный пользователь кода уведомляю, что он несколько отличается от тех размашистых стилей, который уже привносит .Net, Java, C# (обоснованно, т.к. пространства имён стали называться очень длинно) и хотел бы я посмотреть на статистику разработчиков, которые до сих пор свято верят в ширину 80 символов (и это при том, что в гнутых проектах кое-где табуляция в 8 символов). По-моему, это рудимент, оставшийся от DOS-совского стиля программирования. У меня от DOS'а остался только чёрный фон, всё остальное пришлось по разным мотивам переиначить до современного стиля (Макконнел мне тут многим помог, там хоть есть обоснование и примеры для каждого совета).

Общий стиль текущего форматирования похож на системные модули Delphi, потому я без особых претензий. Просто я знаю, что люди в среднем могут осознавать в одно время от 7 до 9 объектов. Та область, которую осознанно видит программист-человек на экране мала (если не тренироваться по таблицам Шульте). Если взглянуть на картинку ниже, где я выделил некоторый код, который я тут искал (функцию), то лично я по ощущениям при взгляде на эту область понимаю, что мне нужно дополнительное усилие для более внимательного разглядывания, т.е. внимание рассеивается, т.к. объектов больше, чем 7-9 в поле зрения.

А упомянутый мной совет из книжки Совершенный код помогает человеку быстрее ориентироваться, т.к. он уже знает, что человек, писавший код, использовал правило: от простого к сложному. Этим код становится как бы ближе, ты знаешь что ожидать. Это же очевидно, что поиск при отсортированном по типам и сложности списке всегда быстрее, чем в произвольно составленном.

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

[vdemidov]

Если взглянуть на картинку ниже, где я выделил некоторый код, который я тут искал (функцию), то лично я по ощущениям при взгляде на эту область понимаю, что мне нужно дополнительное усилие для более внимательного разглядывания, т.е. внимание рассеивается, т.к. объектов больше, чем 7-9 в поле зрения.

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