Проверка на верное количество скобок [ < ( ) >]
Задача следующая, написать код, который проверяет, верно ли расставлены скобки в выражении т.е.
Выглядит стремно и неуклюже, если у Вас будет возможность и время, расскажите как сделать его более «красивым» с пояснениями. Спасибо!
5 ответов 5
Проверка на пустую строку уже была. Почему она тут второй раз? И почему вообще ожидается, что тут произойдёт исключение? Сто-то тут надо переделать, наверное.
Если я правильно понимаю, это удаление из середины списка? Да ещё и дважды (по разу на каждую скобку). Обычно это крайне неэффективно, хотя про питон сказать не могу.
А зачем скобки в отдельном списке? Можно проходить по строке и сразу обрабатывать.
Предлагаю такое решение:
Используйте проверку правописания
Заодно имя типа ( list ) здесь не обязательно. brackets почти в каждой строчке используется и само по себе достаточно читаемо.
Возвращайте булевы выражения напрямую
Можно писать просто:
пустые коллекции в Питоне рассматриваются False в булевом контексте
Эта конструкция перехватывает даже KeyboardInterrupt ( Ctrl+C ) и SystemExit (выход из скрипта, реализация sys.exit() )—это нежелательно. Ловите только те типы исключений, которые вы ожидаете, иначе вы можете проигнорировать ошибки во вводе или ошибки, вызванные багом в коде—неожиданные ошибки должны прекращать скрипт в данном случае.
В Питоне иногда позволительно использовать исключения для управлением потока кодом, но фактически использование следует ограничить случаями, когда это заметно упрощает код улучшает его читаемость, эффективность.
В коде в вопросе, использование перехвата исключений указывает на проблему с организацией цикла. Следует переорганизовать код, чтобы вообще исключить try/except в данном случае.
Сравнение целого числа с range() это баг
Избегайте управление переменной цикла в ручную. Обходите коллекции напрямую.
Ваш алгоритм требует управления переменной цикла, что делает его менее понятным и (в данном случае) менее эффективным (выглядит как квадратичный алгоритм). Для сравнения, вот линейный алгоритм, который обходит коллекцию напрямую.
Используйте # вместо // для комментариев в Питоне
Избегайте излишнего дублирования кода
В данном случае все скобки представлены одним символом. Чтобы поддерживать скобки из нескольких символов, можно в кортеж положить:
Небольшое повторение кода может быть полезно. В крайности впадать не следует. Смотрите по ситуации, какой код более понятен и легче изменять, не поломав, через полгода, когда детали забудутся.
Проверка расстановки скобок в строке
Проверить правильность расстановки в строке скобок (баланс открывающих и закрывающих скобок)
помогите с решением задачи. Запросить у пользователя ввод значений согласно варианту. Выполнить.
Проверка на правильность расстановки скобок
Дан текст. Проверить, правильно ли в нем расставлены круглые скобки (т. е. находится ли справа от.
Проверка правильности расстановки скобок
Помогите с заданием Строка содержит арифметическое выражение, в котором используются круглые.
Проверка кода
На вход подаётся одна строка с кодом программы, нужно проверить правильность расстановки парных скобок.
Возможные пары скобок: [], <>, ().
Кроме скобок в строке могут содержаться цифры, символы английского алфавита, знаки препинания.
Если парные скобки расставлены в коде корректно, то на выход подайте одну строку Success, иначе Not Success.
Эту задачу следует решить с использованием структуры данных stack.
Если на Python, то с использованием методов списка append и pop.
Sample Input 1:
Success
Sample Input 2:
Success
Sample Input 3:
Success
Sample Input 4:
e = [i for i in range(5])
Sample Output 4:
Решение
Возможные пары скобок: [], <>, ().
Кроме скобок в строке могут содержаться цифры, символы английского алфавита, знаки препинания, пробелы.
Если парные скобки расставлены в коде корректно, то на выход подайте одну строку Success, а иначе на выход подайте индекс первого неправильного символа (счёт символов в строке идёт с нуля). Например, для строки ‘x = (f]’ на выход подайте 6.
Обратите внимание на эти примеры:
и внимательно изучите открытые ниже тесты.
Эту задачу следует решить с использованием структуры данных stack.
Если на Python, то с использованием методов списка append и pop.
Sample Input 1:
Success
Sample Input 2:
x = [0>
Sample Output 3:
e = [i for i in range(5])
Sample Output 4:
Arduino
Оформление программного кода
В больших организациях, в которых работают десятки и сотни программистов, всегда есть документ, который содержит список правил оформления кода. Обычно он включает такие пункты:
И еще много другого. Это позволяет легче читать и дорабатывать чужой код. Однако, даже если вы работаете в небольшой команде или один, определение таких правил позволит вам намного проще читать и дорабатывать свой старый код и улучшать его.
С появлением сторонних редакторов кода и IDE, таких, как PlatformIO, следить за соблюдением стилистики кода стало намного проще.
Отступы
Первое и самое важное правило: отступы нужно использовать. Обязательно. Давайте сравним такой код:
Даже такой небольшой пример показывает, что код с отступами гораздо проще читать. А когда в коде будет в несколько раз больше уровней вложенности и гораздо больше строк, что прочитать и понять код без отступов будет ну очень сложно.
Размер отступа, а также то, какой символ использовать (пробел или табуляция) выбирается исходя из личных предпочтений. Однако есть устоявшаяся рекомендация: использовать всегда пробелы и не использовать символ табуляции. Это связано с тем, что отображение символа табуляции может быть разным в разных редакторах кода, что делает неудобным чтение кода при открытии его в другом редакторе, не где он был написан. Многие редакторы по-умолчанию конвертируют символ табуляции в символы пробелов.
Пробелы
Пробелы делают код более читаемым. Например сравните:
Второй вариант явно удобнее читать. Есть еще такой вариант:
Каждый решает сам. Но именно второй вариант наиболее распространен и чаще принято использовать именно его.
Фигурные скобки
Фигурные скобки определяют начало и конец блока кода функции или таких операторов, как условный оператор или оператор цикла. Если есть открывающаяся скобка, то должна быть и закрывающаяся, иначе код не будет скомпилирован.
Если для функции фигурные скобки являются обязательным элементом, то для многих операторов их можно опустить. Например:
Все три вариант равносильны. Но при отсутствии скобок отработает только первая строчка, следующая за оператором, поэтому если в блоке кода несколько строчек, то использование скобок становится обязательным. Именно по этой причине настоятельно рекомендуется всегда использовать фигурные скобки, так как легко допустить ошибку например при доработке кода.
Комментарии
Использование комментариев сильно упрощает чтение кода программы, а также используется например, чтобы оставить пометку доработать что-то в будущем. В скетчах часто в самом начале оставляют комментарий с кратким описанием программы, а также с перечислением подключенных к Arduino устройств и способов их подключения.
Объясните мне пожалуйста, зачем нужно всегда ставить
Здравствуй, я не понимаю зачем все говорят что нужно всегда использовать < и >
Вот например код:
Зачем тут писать скобки?
Многие говорят что для читаемости, но любой программист знает о таком написании, зачем же увеличить код?
Так же лично я не понимаю зачем открытие скобки писать на новой строке, что бы занять ещё одну лишнюю строку?
На мой взгляд это неправильно, возможно вы меня сможете в этом переубедить?
Лично мне намного быстрее и удобнее разобрать вот такой код:
12 ответов 12
Практика всегда ставить скобки избавляет вас от досадных глупых ошибок.
Страшилка 1. Жил-был метод с guard condition:
В один прекрасный день вы собираетесь домой, вас просят быстренько добавить логгирование туда. Ткнули по кнопкам (может быть даже по хоткею для live template), закоммитили:
И ушли. А кто-то потом тратит пару часов, чтобы найти эту невзрачную ошибку.
Страшилка 2. Жил был код:
Однажды джуниора попросили временно убрать обработку Очень Редкого Случая. Он смело закомментировал соответствующую строку и ушел играть в кикер с коллегами.
А потом вдруг Что-то Очень Важное перестало работать кроме редких случаев.
PS. Все совпадения не случайны, а действующие лица не выдуманы.
Ответ на самом деле зависит от языка.
Некоторые языки (javascript, I’m looking at you) практически требуют специальной расстановки скобок, в их отсутствие код может распарситься неочевидным образом.
В остальных языках-с-фигурными-скобками (C/C++/Java/C#/. ) расстановка скобок — личное дело каждого, вопрос вкуса. Я лично стараюсь опустить скобки где только возможно, например, в коде
Другим, наоборот, нравится наличие скобок, так как это позволяет коду
Мой совет — пишите код так, чтобы форматирование подчёркивало вашу мысль. Например, симметрию внутренних структур кода. Это самое главное. Наличие или отсутствие скобок не сделают вас плохим программистом, отсутствие стиля вполне может.
Важный отдельный случай — это наличие общего стиля команды. Если во всей команде принято ставить (или не ставить) дополнительные скобки, вам придётся придерживаться общего стиля.
Лично я не понимаю зачем открытие скобки писать на новой строке, что бы занять ещё одну лишнюю строку?
Наличие скобок и способ их расстановки это не просто вопрос стиля или личных предпочтений. Сейчас многие удивяться, но в javascript код в зависимости от расстановки скобок выполняется по разному. Смотрите фокус:
это от языка программирования зависит. В с/с++ скобки можно не писать, если дальше будет один оператор. А в от в перл в подобной конструкции скобки нужно писать (если только не инфиксный оператор), потому что там такой синтаксис.
Так же лично я не понимаю зачем открытие скобки писать на новой строке, что бы занять ещё одну лишнюю строку?
тут нужно отталкиваться от стандартов, принятых в Вашей компании или личных предпочтений (для своего кода).
На мой взгляд это неправильно, возможно вы меня сможете в этом переубедить?
на мой взгляд, правильнее писать указанный код так:
Многие говорят что для читаемости, но любой программист знает о таком написании, зачем же увеличить код?
Дело в том, что такие выражения как правило идут среди другого кода, а не сами по себе. Соответственно, скобки явно выделяют блок, который относится к условию. Например:
С какой вероятностью, радактируя этот код, можно случайно неправильно внести строчку в if или закомментировать имеющуюся там? Мне тоже рассказывали про реальные случаи, что комментировали логирование и следующая команда попадала в if.
Как же пытаются решить эту проблему? Говорят, всегда ставим скобки. В таком случае получеается такой код:
Да, здесь уже значительно сложнее ошибиться и как-то не так поступить с этим блоком. Но написан ли этот код красиво? На мой взгляд, нет. Это по прежнему мешанина вызовов методов и проверки условия. Причём, блок кода мы выделили, но таким образом мы ещё и отдалили вызываемый метод от условия.
А вот как бы я отформатировал этот же код:
Здесь нет скобок, но я потратил те же две строки, чтобы сделать вертикальные отступы. При редактировании такого кода, по сравнению с первым, гораздо сложнее ошибиться при его изменении, блок с условием заметно отделяется от остального кода, а содержимое блока идёт рядом с условием, а не отодвингается от него при помощи скобок.
зачем все говорят что нужно всегда использовать
Сейчас почти для всех языков IDE имеют автоформатирование. Для чего? Для того ли, чтобы было быстрее писать код? Или всё-таки для того, чтобы более или менее читаемый код мог писать кто угодно? Почему чем язык распространённее (и, в некоторой мере, проще), тем строже правила автоформатирования? Посмотрим на дефаултные настройки в Visual Studio. Для C++ (если я не ошибаюсь) нет автоматического добавления пробелов вокруг бинарных операторов. В C# есть. В VB.NET принудительное жёсткое форматирование отступов при уходе со строки. Случайность ли это? Вот мне кажется, что вряд ли.
Ну и ещё примерчик. Что лучше?
но мне бы как-то не хотелось увидеть
потому что тут сложно зацепиться глазами за блоки.
Кстати, как вариант, тут может быть
Но с этим подходом надо быть осторожным и использовать только тогда, когда это имеет смысл.
Кстати, с этим вариантом могут быть проблемы с автоформатированием в IDE. Потому что я бы однозначно не хотел увидеть
такой вариант вообще нечитаемый.
Так же лично я не понимаю зачем открытие скобки писать на новой строке
Скобки на новой строке удобны тем, что видно, к какому блоку они относятся.
Следующий код читаем. Он читаем даже если скобки по какой-то причине съедут.
А как насчёт варианта со скобкой на той же строке? А если по какой-то причине скобка окажется не там где надо?
Раньше в VS были проблемы с автоформатирование отступов в Си++, если нет скобок. Кстати, это ещё одна возможная причина, почему скобки надо ставить.
В языках, где скобки расставляются подобным образом (открывающая на той же строке), я всегда ставлю скобки. И скобки, и отступы, если непонятно.
Например, вот что станет с кодом выше, если в коде в табами (у просматривающего в 2 пробела) добавили 2 строки (и скобки) с отступами в 4 пробела:
Благодаря пустой строке после вложенных конструкций, первый код легко читается даже в таком не слишком приглядном виде. А теперь посмотрим на второй вариант:
И ни одной хорошей мысли при взгляде на это чудо.
чтобы занять ещё одну лишнюю строку?
Занятые строки должны быть далеко не на первом месте. Так можно и весь код в одну строку написать. Но вот нужно ли?
Лично мне намного быстрее и удобнее разобрать вот такой код:
Во-первых, если понадобится просматривать структуру кода, то это не слишком удобно читать. В смысле, если ты детально просматриваешь метод и читаешь полностью каждую строку, то всё хорошо. Но если ты просто бегло смотришь код, пытаясь понять, где и что используется, то совмещение условия с вызываемым методом может оказаться неудобным.
Во-вторых, здесь нельзя поставить breakpoint на вызов метода. Так что отладке может помешать.
Сам использую запись в одну строку только иногда в VB, где есть синтаксис однострочного if.
А вот такой стиль я виду впервые. Видел такое:
Советы по стилю кода
Код должен быть максимально читаемым и понятным.
Это и есть искусство программирования – взять сложную задачу и написать такой код для её решения, который и правильно работает, и легко читается, понятен для людей. Для этого нужен хороший стиль написания кода. В этой главе мы рассмотрим составляющие такого стиля.
Синтаксис
Шпаргалка с правилами синтаксиса (подробнее смотрите ниже по тексту):
Не всё здесь однозначно, так что разберём эти правила подробнее.
Здесь нет железных правил. Это стилевые предпочтения, а не религиозные догмы.
Фигурные скобки
В большинстве JavaScript проектов фигурные скобки пишутся в так называемом «египетском» стиле с открывающей скобкой на той же строке, что и соответствующее ключевое слово – не на новой строке. Перед открывающей скобкой должен быть пробел, как здесь:
Вот различные варианты расстановки скобок с комментариями, посмотрите сами, какой вам кажется самым читаемым:
Длина строки
Никто не любит читать длинные горизонтальные строки кода. Лучше всего разбивать их, например:
Максимальную длину строки согласовывают в команде. Обычно это 80 или 120 символов.
Отступы
Существует два типа отступов:
Горизонтальные отступы: два или четыре пробела.
Горизонтальный отступ выполняется с помощью 2 или 4 пробелов, или символа табуляции (клавиша Tab ). Какой из них выбрать – это уже на ваше усмотрение. Пробелы больше распространены.
Одно из преимуществ пробелов над табуляцией заключается в том, что пробелы допускают более гибкие конфигурации отступов, чем символ табуляции.
Например, мы можем выровнять аргументы относительно открывающей скобки:
Вертикальные отступы: пустые строки для разбивки кода на «логические блоки».
Даже одну функцию часто можно разделить на логические блоки. В примере ниже разделены инициализация переменных, основной цикл и возвращаемый результат:
Вставляйте дополнительный перевод строки туда, где это сделает код более читаемым. Не должно быть более 9 строк кода подряд без вертикального отступа.
Точка с запятой
Точки с запятой должны присутствовать после каждого выражения, даже если их, казалось бы, можно пропустить.
Есть языки, в которых точка с запятой необязательна и редко используется. Однако в JavaScript бывают случаи, когда перенос строки не интерпретируется, как точка с запятой, что может привести к ошибкам. Подробнее об этом – в главе о структуре кода.
Если вы – опытный разработчик на JavaScript, то можно выбрать стиль кода без точек с запятой, например StandardJS. В ином случае, лучше будет использовать точки с запятой, чтобы избежать подводных камней. Большинство разработчиков их ставят.
Уровни вложенности
Уровней вложенности должно быть немного.
Например, две нижеследующие конструкции идентичны.
Второй вариант является более читабельным, потому что «особый случай» n обрабатывается на ранней стадии. После проверки можно переходить к «основному» потоку кода без необходимости увеличения вложенности.
Размещение функций
Если вы пишете несколько вспомогательных функций, а затем используемый ими код, то существует три способа организации функций.
Объявить функции перед кодом, который их вызовет:
Сначала код, затем функции
Смешанный стиль: функция объявляется там, где она используется впервые.
В большинстве случаев второй вариант является предпочтительным.
Это потому, что при чтении кода мы сначала хотим знать, что он делает. Если сначала идёт код, то это тут же становится понятно. И тогда, может быть, нам вообще не нужно будет читать функции, особенно если их имена хорошо подобраны.
Руководства по стилю кода
Руководство по стилю содержит общие правила о том, как писать код, например: какие кавычки использовать, сколько пробелов отступать, максимальную длину строки и так далее – в общем, множество мелочей.
Когда все участники команды используют одно и то же руководство по стилю, код выглядит одинаково, независимо от того, кто из команды его написал.
Конечно, команда всегда может написать собственное руководство по стилю, но обычно в этом нет необходимости. Существует множество уже готовых.
Некоторые популярные руководства:
Если вы – начинающий разработчик, то начните со шпаргалки в начале этой главы. Как только вы освоитесь, просмотрите другие руководства, чтобы выбрать общие принципы и решить, какое вам больше подходит.
Автоматизированные средства проверки (линтеры)
Автоматизированные средства проверки, так называемые «линтеры» – это инструменты, которые могут автоматически проверять стиль вашего кода и вносить предложения по его улучшению.
Самое замечательное в них то, что проверка стиля может также найти программные ошибки, такие как опечатки в именах переменных или функций. Из-за этой особенности использовать линтер рекомендуется, даже если вы не хотите придерживаться какого-то конкретного «стиля кода».
Вот некоторые известные инструменты для проверки:
Все они, в общем-то, работают. Автор пользуется ESLint.
Большинство линтеров интегрированы со многими популярными редакторами: просто включите плагин в редакторе и настройте стиль.
Например, для ESLint вы должны выполнить следующее:
Здесь директива «extends» означает, что конфигурация основана на наборе настроек «eslint:recommended». После этого мы уточняем наши собственные.
Кроме того, возможно загрузить наборы правил стиля из сети и расширить их. Смотрите https://eslint.org/docs/user-guide/getting-started для получения более подробной информации об установке.
Также некоторые среды разработки имеют встроенные линтеры, возможно, удобные, но не такие гибкие в настройке, как ESLint.
Итого
Все правила синтаксиса, описанные в этой главе (и в ссылках на руководства по стилю), направлены на повышение читаемости вашего кода. О любых можно поспорить.
Когда мы думаем о написании «лучшего» кода, мы должны задать себе вопросы: «Что сделает код более читаемым и лёгким для понимания?» и «Что может помочь избегать ошибок?». Это – основные моменты, о которых следует помнить при выборе и обсуждении стилей кода.
Чтение популярных руководств по стилю позволит вам быть в курсе лучших практик и последних идей и тенденций в стилях написания кода.