"]" это какой-то импостор а не птица
для потенциальной ошибки в коде достаточно того факта что последняя скобка расположена не в начале строки (можно предположить, одной закрывающей не хватает)
для потенциальной ошибки в коде достаточно того факта что последняя скобка расположена не в начале строки (можно предположить, одной закрывающей не хватает)
А зачем если это говно без задач? Если ты пишешь в нормальной IDEшке, а не в блокноте ручкой, то необходимый минимум визуализации тебе предоставляет сама IDEшка, а читаемость кода у тебя сохраняется за счет архитектуры. Может я чего то не понимаю и ты приведешь примеры где это (ДРАКОН) может быть действительно необходимым?
я погуглил, что за хуйню ты предлагаешь
выглядит как пиздец
и даже в вебе найдется сразу куча примеров, для которых это пиздец усложняющий понимание структуры кода
выглядит как пиздец
и даже в вебе найдется сразу куча примеров, для которых это пиздец усложняющий понимание структуры кода
Там, где это возможно, пользуются - matlab/simulink, LabView и всякие vissim. Там тоже косячат, и выискать ошибку бывает труднее чем в текстовом языке программирования. Потому что достаточно сложная логика не может быть размещена в пределах одного экрана, ни текстом, ни блок-схемой, никак.
Почитал внимательнее статью про ДРАКОН на хабре (https://habr.com/ru/articles/345320/) - выглядит хорошо, чтобы учить базовому программированию - более наглядно, больше дисциплины.
Нас в школе все время заставляли сначала блок-схему в тетрадке рисовать, только потом к компам с BASICом пускали - тогда не понимал почему, и жутко бесило. А когда сам стал кому-то объяснять, то стало понятно: с блок-схемой проще разобраться с самим алгоритмом и не запутаться, а когда получилась схема, то в текст перевести ее уже совсем легко. ДРАКОН для таких целей очень подходит.
А вот для серьезных задач кажется уже неудобным, когда много вложенности и ветвлений. Как ООП с ним реализовывать - тоже непонятно - возможно, что описать и получится, но навигации по коду, как в современных IDE (типа деревьев и переходов по "использование", "реализация", "переопределение"...), вряд ли в нем есть. Современные IDE уже давно не просто редактор, они берут на себя много текстовой рутины, серьезно помогают в навигации и в контроле за качеством кода.
Нас в школе все время заставляли сначала блок-схему в тетрадке рисовать, только потом к компам с BASICом пускали - тогда не понимал почему, и жутко бесило. А когда сам стал кому-то объяснять, то стало понятно: с блок-схемой проще разобраться с самим алгоритмом и не запутаться, а когда получилась схема, то в текст перевести ее уже совсем легко. ДРАКОН для таких целей очень подходит.
А вот для серьезных задач кажется уже неудобным, когда много вложенности и ветвлений. Как ООП с ним реализовывать - тоже непонятно - возможно, что описать и получится, но навигации по коду, как в современных IDE (типа деревьев и переходов по "использование", "реализация", "переопределение"...), вряд ли в нем есть. Современные IDE уже давно не просто редактор, они берут на себя много текстовой рутины, серьезно помогают в навигации и в контроле за качеством кода.
Dev - > test - > release - > prod. А если нагруженный сервис, то между test и release добавляется нагрузочное тестирование. Тест включает в себя автотесты, а если что то большое релизим, то еще и регресс тесты
Всё верно, бывают баги из серии "компания такая-то привыкла работать со старой программой Х, в которой используется древний ископаемый формат .YZ; при работе с нашей программой конвертация выдаёт неверное значение"
Бывают ещё ситуации из серии "с деталью работает, без детали работает, с изношенной деталью не работает": батарея в ноутбуке ASUS 10-ых годов, если износилась, будет аппаратно делать ноутбуку глюки.
Вынул батарею - глюки пропали.
Бывают ещё ситуации из серии "с деталью работает, без детали работает, с изношенной деталью не работает": батарея в ноутбуке ASUS 10-ых годов, если износилась, будет аппаратно делать ноутбуку глюки.
Вынул батарею - глюки пропали.
Чтобы написать коммент, необходимо залогиниться
}
}
]
}
}