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

сижу рисую временами

ну как бэ их в голове обычно рисуешь, практически всегда, а тебя именно на бумажке интересуют?

В уме рисуются сами.

когда надо заказчику через чур умному объяснить как и что работает

(2) Иногда сложные задачи попадаются, на уме не могу, слишком объемно

Сейчас в школе, на математике, рекомендуют рисовать.
Любой рисунок, что бы понять лучше.

пока в ВУЗе учился, делал в первых лабораторных работах все наоборот - сначала писал программу, а потом рисовал блок-схему.

Только чтобы показать заказчику схему работы продукта...

UML лучше, а блок схемы слишком муторно

Хочется IDF3 иногда порисовать, но руки не доходят и инструмента нет...

(10) ErWin -- можно рисовать диаграммы БД.

(11) $3900. Нет уж спасибо =)

мыслю кодом

Блок-схемы уже устарели.
Они не позволяют полностью со всех точек зрения представить поведение программы.
На смену блок-схемам сейчас используется UML.
UML - современный язык для проектирования и моделирования программных систем.
ORD - диаграммы для представления структуры БД.
Подробнее - в интернете.

Человеческий мозг так устроен, что структуры, состоящие из 7 - 10 элементов, он удержать и одновременно выполнять с ними мысленные манипуляции не может.
Величайшие шахматные гроссмейстеры могут рассчитывать ходы вперед только на 20-25 полу-ходов.
Поэтому моделирование нужно обязательно.
Ведь моделируют везде: в строительстве, в машиностроении и т.д. Где-то читал, что перед тем как строить подводную лодку составляют документацию и чертежи, которые по объему занимают объем как несколько грузовиков.

Для простых задач - модель необязательно рисовать на бумаге или в какой-то программе. Модель имеется в голове.
Но когда возможностей мозга уже не хватает, такие задачи человек называет "сложными".
Сложность - это и означает - сложность для восприятия человеком.
В таких случаях средства для построения моделей (архитектуры программы, поведения программы) просто необходимы.
Причем сейчас есть бесплатные пакеты и для UML, и для проектирования структуры БД. Например, Visual UML, если не ошибаюсь.

Большинство моих задач требуют моделирования, хотя и не все. Но моделировать приходиться чаще чем "иногда".
Поэтому я отвечаю "всегда".

Если сложные условия в кучу, то рисую. Чтобы ветви разделить без ошибок. Как-то более по нраву, чем потом ошибку вылавливать, которая может еще и не сразу проявиться :)

Полезная штука

(13) Машинным? :)

Еще и логические матрицы.

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

UML - такая же фигня, как и блок-схемы.

При проектном подходе к внедрениям всегда используем блок-схемы для описания всех бизнес-процессов. При мелких доработках уже нет.
Хотя в (14) правы, не всегда блок-схема способно наглядно описать сложный процесс. Надо будет изучить что такое UML.

Если делать без них получается овнокод

(0) что это ?

(4) Ты в слове "когда нужно впарить" допустил дофига ошибок.

(20) обоснуй!

(25) За 6 лет практики они пригодились лишь однажды - когда оформлял ПЗ.

только для сложных условий

(26) ну многие и ООП не используют, это не значит, что ООП не нужно

Рисовал пару раз. А вообще для документации полезная штука, наверное!

Тролль главный рисуешь блок-схемы ?

(30) рисую UML, не для 1С правда

(0) Есть задачи, когда это нужно использовать, есть задачи, когда это возможно использовать, есть задачи, когда это не нужно использовать, есть задачи, когда это вредно с точки зрения воровства времени, есть задачи, когда это не нужно совсем.
Блок - схема не единственный и не обязательный способ представления алгоритмического решения задачи.
У любого представления есть существенный недостаток: это представление необходимо регулярно использовать, чтобы это был действительно рабочим инструментом. Только "анафига"?!
Чаще всего неясна не задача целиком, какие-то отдельные моменты-подзадачи. Их можно набросать отдельно на клочке экрана монитора или на салфетке от бутерброда.
А вот если нужно выпендриться и показать себя с необычной стороны, то графическое представление проекта, даже если он пустяковый, делает из программиста бога программирования.
И еще один момент, если всю вариативность хотелок представлять графически, то ты только и будешь этим заниматься. И графическое представление удобно использовать тогда, когда задача ясна на 90-95 процентов. Если ты будешь рисовать блок схему той задачи, в которой ты не в теме ты поймешь, что пустяковая мысль в твоей схеме занимает большую площадь, старательно пряча общую идею и концептуальную суть.
А если учесть, что сегодняшняя хотелка заказчика - дальнейшая реализация и доработка хотелки такой динамичный процесс, что ты своими стрелочками все сроки внредрения сорвешь.
Вывод: графическое рисование или для временного самовыпендрежа, или для эпизодического выпендрежа перед зазчиком или у тебя времени дофига.
Да есть еще вариант, что ты тупой на ровном месте, но я его не рассматриваю.

(32)Дерзко однако! Не с той ноги?

(32) Допустим у меня задача переписать с нуля расчет индивидуального подоходного налога и пенсионных отчислений.
Задача имеет повороты, условия.
Если все это держать в голове, то обязательно что-нибудь пропущу. Тогда придется заново переписать код или надо будет дохрена допилить.
А если перед тобой тщательно проработанная блок-схема, то танцы на бубенцах уменьшатся в разы.
Ща перед мной стоит дилемма именно в контексте жанной задачи.
Поэтому интересно мнения большинства.

Рисую когда в голове решение не укладывается.

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

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

(37) Спокойно, попей чайку с мятой! ;)

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

(34) Как я уже указал, "когда задача ясна на 90-95 процентов" то это (графическое представление) уместно, с нуля ... грустно ...

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

(37) "графическое представление"
Чо-та не понял в чем сложность, взять ручку,
лист бумаги и поводить ручкой по бумаге.

Мечты, мечты... а время диктует свои условия :)

(12) Ну, это -- CASE-средство, оно еще много чего умеет. Кроме того, есть специальная бесплатная российская версия на рутракере :)
Еще как вариант, в Visio наклепать пользовательских контролов и их использовать.

(42) Ты можешь и не "выводить" блок-схему.

(44) > в Visio наклепать пользовательских контролов и их использовать
Не лучше тогда уж в каком-то специализированном средстве, может и в бесплатном каком нибудь...

Не использую.

в своё время изучал нотации, прочитал книгу по UML, юзал десяток кейсов...
фигня это всё
реляционная модель - вот это вещь

Лучше бы в 1С было что-то типа JavaDoc - генерация пакета документации кода по комментариям. А то сидишь пишешь велосипед, а потом выясняется что в каком то общем модуле это уже реализовано

Если процесс сложный, то обязательно.