Когда бы я использовал псевдокод вместо блок-схемы?

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

1. Когда я буду использовать псевдокод для планирования и когда я буду использовать блок-схемы? Или лучше сделать и то, и другое перед программированием. Особенно для небольшой аркадной игры в JAVA, так как это мой следующий проект.
2. Я заметил, что псевдокод очень похож на реальный код, а не на блок-схемы. Может ли это сделать псевдокодирование лучше, потому что вы по сути копируете / вставляете псевдокод в свою программу (конечно, вы должны изменить его, чтобы он соответствовал языку. Я понимаю эту часть).
3. Практично ли использовать оба из них при программировании? Особенно та же игра, упомянутая ранее. Спасибо.

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

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

Ваши вопросы подробно:

1. Для действительно сложной проблемы вы должны сначала использовать блок-схемы, а затем псевдокод. И то и другое не обязательно, когда вы чувствуете себя в безопасности.
2. Да, псевдокод имеет то преимущество, что его можно объединить с реальным кодом. Стив Макконнелл, например, настоятельно рекомендует сначала писать методы в псевдокоде, а затем оставлять псевдокод в коде в качестве комментариев.
3. Я всегда чувствовал, что необходимость рисовать блок-схему во время проектирования показывает недостаточное разделение вашей проблемы. Нетривиальные блок-схемы указывают на запутанную логику, которой следует избегать при больших затратах.

По псевдо-коду

Честно говоря, я не использую псевдокод много. Как правило, быстрее просто написать код, поэтому, когда я закончу с моим кодом, это будет настоящий код. В некоторых случаях псевдокод может быть полезен, но вы обычно работаете над чем-то очень сложным и просто пытаетесь сломать структуру метода или чего-то еще. В этих случаях я использую комментарии в своей IDE, чтобы выложить структуру, пока я не получу правильные вещи. Затем я вхожу и пишу фактический код в комментариях. Это помогает мне сделать несколько вещей:

• Я могу видеть области, которые у меня есть и которые не реализованы, читая комментарии и видя очевидные пробелы в них.
• Когда я заполняю реальный код, у меня есть комментарии, объясняющие на английском, что я делаю. (Возможно, он им понадобится, если он настолько сложен, что мне нужно сначала написать псевдокод).

На блок-схемах

Код обычно изменяется настолько, что блок-схемы бесполезны, за исключением более масштабной, более системной архитектуры или документации. В этих случаях я просто нарисую схему, чтобы понять суть вещей или показать кому-то еще в команде. Если вам действительно не нужна блок-схема, чтобы помочь вам понять, тогда вам не нужны они, чтобы «делать» программное обеспечение правильно. В настоящее время существует множество плагинов для IDE, которые будут генерировать потоковые диаграммы из самого кода, а также диаграмм классов и других (и наоборот `). Единственное реальное время, которое вам потребуется для создания действительно точной блок-схемы, - это если вы не можете сохранить всю архитектуру и то, как все работает в вашей голове, и вам нужно обсудить что-то визуальное, чтобы поймать изломы.

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

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

Я бы порекомендовал вам писать псевдокод и UML-диграммы, так как эти инструменты помогут вам найти более совершенные классы, методы и т. Д. Иногда при написании псевдокода вы найдете другие и более эффективные способы решения программы.

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

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

Блок-схемы представляют собой высокий уровень абстракции, они позволяют вам планировать, как все должно происходить, например

если х умрет, то победит

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

if (isdead (s)) y.win ()

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

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

Я хотел бы рассмотреть природу кода, который вы пишете. Если это:

1. Очень итеративный / рекурсивный
2. Филиалы сложными способами
3. Реализовано в нескольких системах, которые вы хотите представить

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

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

1. Вы должны использовать все, что вам удобно. Тем не менее, у меня сложилось впечатление, что блок-схемы не очень используются для того, чтобы наметить управление программой в эти дни; с одной стороны, они обычно неструктурированы по сравнению с псевдокодом. Для описания вашей архитектуры на гораздо более высоком уровне чаще используются диаграммы зависимостей классов, такие как UML. Кроме того, если ваше приложение имеет конечный автомат, необходимо нарисовать (похожую на блок-схему) диаграмму конечного автомата.
2. Я думаю, что вы правы здесь. Один из способов работы - это записать свой псевдокод в виде комментариев в исходном файле и начать вставлять фактические строки реализации между ними.
3. Опять же, используйте то, что вам удобно. Если вы не уверены, попробуйте оба варианта; Я ожидаю, что ваша практика быстро сойдет с того, что для вас наиболее полезно. Лично я не нахожу блок-схемы полезными, если я не пытаюсь распутать особенно сложный порядок выполнения.

Зачем писать псевдокод, если вы можете писать на Java? Я нашел Java, хорошую IDE и Javadoc - самый простой способ понять проблему программирования - по крайней мере, объектно-ориентированную . (И аркадная игра должна быть ОО.) Язык был разработан с нуля для этого. Это просто и понятно. (Возможно, это слишком просто для многих целей, но лучшее, что я видел для этого.) Гипертекст в Javadoc и, через IDE, в самом коде создает более понятную «диаграмму», чем вы могли бы нарисовать даже большой лист бумаги. Java-код так же прост, как и любой псевдокод, и намного более строг. И после того, как вы его «наметили» и «псевдо» закодировали, программа действительно запустится!

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

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

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

Итак, полезно для себя.

Они также могут быть использованы для общения с другими.