Приходилось слышать мнение, что блок-схемы строятся по программному коду для каких-либо целей, например, объяснения алгоритма работы программы заказчику.

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

Какое ваше мнение?

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

Так что только:

Гы! насмешил   И самые наглядные коды - коды графических языков, т.е. коды, представляющие собой блок-схемы  

Если разобраться в блок-схеме, становиться понятен общий принцип работы программы, не зависимо от того на каком она языке написана. сейчас используются в основном в учебных целях.
Существует язык, который в принципе и основан на блок-схемах. Называется ДРАКОН. Если кто заинтересуется, у мя есть учебник...

Блок схемы нужны для наглядности.  Нужны для объяснения структуры крупной программы при этом на них выделяют главные интерфейсы и блоки. 

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


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


Так тем более не делают лишняя трата времени. 

Это сообщение отредактировал(а) Pavia - 20.1.2010, 22:56

Заказчику, за частую, в лучшем случае либо откровенно наплевать на квадратики и стрелочки, в худшем он тупой и просто не поймет что к чему... Возможности не исключают друг друга )))))

Откровенно говоря мне совершенно не удобно писать код/псевдокод по блоксхеме, особенно если схема не маленькая, то скорее в ней запутаешься, чем непосредственно в коде...

Если мне не изменяет память лицензирование ПО и ЕСПД требуют наличия блоксхемы главного алгоритма...

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

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

Поэтому- только для сдачи зачетов в универе.

ИМХО. Пинайте меня в зубы, всего вон два осталось   

Это где ты столько работаешь?   

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

Вариант №3, но с поправкой - для сдачи зачетов в плохом универе.

в любом случае, двумерное представление алгоритма нагляднее чем одномерное представление
кто реверсил большие функции в IDA - тот знает)

Во-первых, это. 

Во-вторых, далеко не всегда написание программы - это запись алгоритма решения. Не всякий язык программирования является императивным.   

Прямо даже и не знаю. Ваши аргументы против блоксхем показывают что вы либо гении, либо просто не умеете пользоваться тем, чему в универе учили. Извините, но  указывает именно на это. А потом в теме "Aлгоритмы" возникают посты типа "Дайте, пожалуйста, пример на C++, Java, или-еще-каком-конкретном-языке-известном-именно-вопрошающему".

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

Здесь куча информации, к алгоритму отношения не имеющей: это и декларирование списка dataArray  и служебной переменной str, и путь к файлу, и способ чтения именно с помощью FileReader и BufferedReader, и способ выхода из цикла, и метод обработки ошибок. В общем, куча общеизвестных операций, затрудняющих восприятие. Алгоритм же должен сообщать только Ввести данные или Прочитать файл в dataArray - не больше. Максимум что нужно на схеме:

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

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

Имеется, кстати, незаслуженно пнутый в этой ветке, язык UML. В нем куча вариантов схематических представлений. Ни один человек, видимо, не пользуется всеми. Каждый пользуется только парой-тройкой, но выбор этой пары-тройки разнится. Мы, например, широко пользуемся диаграммами классов. Нужны они для того, чтобы делить задания внутри команды разработчиков, а потом без проблем собирать код воедино. Наши менеджеры используют диаграммы взаимодействий - для работы с клиентами. Ну и т.д. Но это ОФФ поскольку обсуждаем именно блок-схемы.

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

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

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

НО
Рисовать условные схемы(а не программный код) - это совсем другое. Например связи между компонентами, их зависимостями. Также просто идеально чтоб скомпоновать мысли на коленке(грубо - прямоугольники со стрелочками). В таком формате удобно с коллегами обсуждать опять же общий вид какой либо проблеммы.

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

+ добавление например пары условий приводит к сильному изменению внешнего вида блок-схемы. Код же при этом остаётся такой же читаемый