Строите ли вы блок схемы перед тем как начать писать код?

да делать мне нечего... ты представляешь себе объём бумаги при этом? зачем? в голове логика не укладывается?

(1) бумагу не обяз-но программки есть, а если алгоритм сложный то все равно в голове ?

(2) а в чём сложность алгоритма? в ветвлениях? не удержишь в голове?

головы у всех разные, некоторым в них нехватает места, приходится пользоваться програмками

() Много веток типа Если то иначеесли то и т.д.

+5 условия в если составные

(5) может ты что то не так в алгоритме подумал? может надо процедурами пользоваться?

(0) Блок схемы строить групо, куски алгоритмов стандартные. Зато неплохо строить схему взаимодействия классов, либо модулей и т.п.

(7) может и так, но что бы его оптимальнее сделать опять же этот процесс надо упрощать

(8) не факт что стандартный алгоритм

Весело тут у Вас
(7,8) Что Вы понимаете под блок-схемами?

(1) пиши на рулоне

Неужели только у меня такие проблемы ?

(8)+1
в программировании нет такого понятия как блок-схема, есть схема программы.
Рисовать их долго,муторно да и не зачем, они подходят в основном для структурного программирования. Сейчас лучше смотреть в сторону Uml.

+(14)я эти схемы в универе столько рисовал что до сих пор тошнит, в жизни больше не буду этим заниматься

(14) например блок схема функции.

А вот с UML не знаком, если есть статейка по использованию UML в 1с, почитал бы

(15) ну правильно, рисовать блок-схему целого отчета глупо, но какой-то части его алгоритма, которая наиболее сложна, разве это не упростит жизнь программиста - или я не прав ?

(16) uml - лишь одна из нотаций. Теже блок-схемы, т. е. схемы, структурные элементы которые представлены блоками + связи между этими блоками

(16) нафиг функции рисовать? тока если для документации. Алгоритм функции должен быть не сложным и умещаться на 2х экранах, иначе ее надо разбивать на подпрограммы - вбито в мою башку в вузе.
(18) жжошь.uml универсальное средство описания моделирования(программ). посмотреть для начала можно здесь
http://ru.wikipedia.org/wiki/UML

(19) Функция как раз 2 экрана, а вот запутался уже
в Книге знаний есть 'RUP с 1С' Книга знаний: Использование методологии RUP для написания приложений на платформе 1С:Предприятие но файлик удален, если у кого есть ссылка поделитесь

>>

(20) Если функция выполняет несколько действий, ее нужно разбивать. Одно действие на два экрана - чушь. Проектировать надо лучше.

+22 Да, еще, специалисты советуют сложные алгоритмы писать сперва на псевдокоде, а потом уже программировать. А блок схемы рисовать - глупо, от этого уже лет 15 как отошли.

(23) представь ситуацию, есть немного запутанная схема(запутанная потому что алгоритм сложноват - услови много и нигде схематично ее нет, только в коде 1С), она работает, потом требуется изменить поведение алгоритма в некоторых узлах, копаться в коде типа "если то ...иначеесли иначе ... " долго, как быть ?

(22) Зато потом весело все эти кучи функций перелопачивать для внесения исзменений, потому как задача чуть изменилась

(24) Если у тебя алгоритм сделан по образу если то иначе(20 вложеностей), то это ошибка проектирования. Как ее исправить - нужно рассматривать отдельно.

(25) Функции для того и придуманы, чтоб все их не перелапачивать. Хотя, если делать функции ради функций...

(24) Если хочешь, давай сюда алгоритм, модумаем как можно его упростить.

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

(26) ну хорошо, возможно это и ошибка проектирования .... Я правильно понял ты отрицаешь полезность составления и документирования алгоритмов

(28) какие принципы используешь чтобы оперативно исправить алгоритм ?

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

(28) Когда задача меняется, часть кода выкидывается. Если у тебя есть набор мало зависящих друг от друга функций(читай классов, методов классов), то ты легко можешь выкинуть из него несколько штук или добавить несколько. При этом тебе не нужно будет заботится, что изменение в одной точке повлияет на другую точку. А если у тебя разрастающаяся функция на два экрана, то ты уже не можешь гарантировать целостность связей при изменении.

(31) То есть ты пишешь прикладные объекты для решение задачи ?

(32) Да, как правило. Правда я пишу на php. Я даже пишу прикладные классы для работы с классами, описывающими реальные объекты.

(33) а в V7 это тоже в принципе можно - 1с++, тока никак не начну классы сам создавать, ООП программирование значительно отличается от структурного, сложно быстро перейти

(34) Я год уже перехожу. Пока осознаю, что ушел от процедурного уже далеко, но еще и не дошел и до середины.

я сначало пишу коментарии а потом между ними пишу код

Рисуем блок схемы из1С в екселе

(35) есть какой нить примерчик (на 1с++) несложный, показывающий как правильно применять классы для решения какой-нибудь задачи (или отчета например), но только с использованием ООП , а не классов из dll

(36) тоже так делаю, но не всегда

(38) Ага, размечтался. Каждой задаче - свое решение...

(40) ну вот так всегда.. как доходит до конкретики

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

(0) иногда рисую UML диаграммы, но редко и не долго

(42)Глобальник ввиде одной блок-схемы не представить, ибо там куча разных алгоритмов.

(42) А что, дизассемблек IDA умеет полученный ASM код представлять в виде блок схем (разбивает переходы по процедуркам). Очень удобно получается. Если бы иметь такой же автоматический анализатор кода.

(45) ИМХО, куда полезнее было бы иметь обратный инструмен - из_диаграммок_кодо_и_объектов_мд_создаватьель (на 1С, ессно)

(46) Ну как сказать. Такие вещи реализованны в SCADA системах. Не сказал бы что это было бы очень удобно в задачах ставящихся бухгалтерией.

(36)+1
(31)+1
(38)"но только с использованием ООП , а не классов из dll" - это как?
(45) ИМХО это документирование через ж...

(48) По п.4. Это не документирование. Такая вещь нужна только для поиска ошибки или внесения корректив в чужом коде при отсутствии документации.

(50)хм, интересная штука, хочешь сказать можно быстрее найти место где нарушена логика?

Не знаю как в нормальном ООП ориентированном(или процедурном) коде, но в ASM было очень удобно - сразу видно все связки данного куска программы. Думаю было бы удобно и в языках высокого уровня.

(48)
"(38)"но только с использованием ООП , а не классов из dll" - это как?"
Ну например класс 1с++ в ert, а пример классов из dll сама 1с++ (весь хелп по 1с++ практически описание классов и их методов)

(0) Для сложных алгоритмов обязательно. но не для документации, а для себя любимой - на бумаге. Много полезных и занятных мелочей всплывает, не учтенных ранее.

(31) подробные комментарии - вообще вещь!!!! Читаешь потом и удивляешься - неужели это я придумал. Как в  кавказской плениице: "А что часовню тоже я...."

(37) Прикольно...  Еще бы сделать составитель блок схем по готовому коду... А в идеале - генератор кода 1С по заданному алгоритму...

(55) формализация алгоритма всеравно останется ручной работой