Читаем Программирование на языке Ruby полностью

<p>1.5.1. Синтаксис</p>

Синтаксический анализатор Ruby сложен и склонен прощать многие огрехи. Он пытается понять, что хотел сказать программист, а не навязывать ему жесткие правила. Но к такому поведению надо еще привыкнуть. Вот перечень того, что следует знать о синтаксисе Ruby.

• Скобки при вызове методов, как правило, можно опускать. Все следующие вызовы допустимы:

foobar

foobar

foobar(a,b,c)

foobar a, b, с

• Коль скоро скобки необязательны, что означает такая запись: x у z? Оказывается, вот что: «Вызвать метод y, передав ему параметр z, а результат передать в виде параметра методу x.» Иными словами, x(y(z)). Это поведение в будущем изменится. См. обсуждение поэтического режима в разделе 1.6 ниже.

• Попробуем передать методу хэш:

my_method {а=>1, b=>2}

Это приведет к синтаксической ошибке, поскольку левая фигурная скобка воспринимается как начало блока. В данном случае скобки необходимы:

my_method({а=>1, b=>2})

• Предположим теперь, что хэш — единственный (или последний) параметр метода. Ruby снисходительно разрешает опускать фигурные скобки:

my_method(а=>1, b=>2)

Кто-то увидит здесь вызов метода с именованными параметрами. Это обманчивое впечатление, хотя никто не запрещает применять подобную конструкцию и в таком смысле.

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

x = y + z

x = y+z

x = y+ z

x = y +z

Но фактически эквивалентны лишь первые три. В четвертом же случае анализатор считает, что вызван метод у с параметром +z! И выдаст сообщение об ошибке, так как метода с именем у не существует. Мораль: пользуйтесь пробелами разумно.

• Аналогично x = y*z — это умножение у на z, тогда как x = y *z — вызов метода у, которому в качестве параметра передается расширение массива z.

• В именах идентификаторов знак подчеркивания _ считается строчной буквой. Следовательно, имя идентификатора может начинаться с этого знака, но такой идентификатор не будет считаться константой, даже если следующая буква прописная.

• В линейной последовательности вложенных предложений if применяется ключевое слово elsif, а не else if или elif, как в некоторых других языках.

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

• Ключевое слово then (в предложениях if и case) необязательно. Если вам кажется, что с ним программа понятнее, включайте его в код. То же относится к слову do в циклах while и until.

• Вопросительный и восклицательный знаки не являются частью идентификатора, который модифицируют, — их следует рассматривать как суффиксы. Таким образом, хотя идентификаторы chop и chop! считаются различными, использовать восклицательный знак в любом другом месте имени не разрешается. Аналогично в Ruby есть конструкция defined?, но defined — ключевое слово.

• Внутри строки символ решетки # — признак начала выражения. Значит, в некоторых случаях его следует экранировать обратной косой чертой, но лишь тогда, когда сразу за ним идет символ {, $ или @.

• Поскольку вопросительный знак можно добавлять в конец идентификатора, то следует аккуратно расставлять пробелы в тернарном операторе. Пусть, например, имеется переменная my_flag, которая может принимать значения true или false. Тогда первое из следующих предложений правильно, а второе содержит синтаксическую ошибку:

x = my_flag ? 23 : 45 # Правильно.

x = my_flag? 23 : 45  # Синтаксическая ошибка.

• Концевой маркер для встроенной документации не следует считать лексемой. Он помечает строку целиком, поэтому все находящиеся в той же строке символы не являются частью текста программы, а принадлежат встроенному документу.

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

• Не забывайте, что ключевые слова BEGIN и END не имеют ничего общего с begin и end.

• При статической конкатенации строк приоритет конкатенации ниже, чем у вызова метода. Например:

str = "Первая " 'second'.center(20)     # Примеры 1 and 2

str = "Вторая " + 'second'.center(20)   # дают одно и то же.

str = "Первая вторая".center(20)        # Примеры 3 and 4

Перейти на страницу:

Похожие книги

Основы программирования в Linux
Основы программирования в Linux

В четвертом издании популярного руководства даны основы программирования в операционной системе Linux. Рассмотрены: использование библиотек C/C++ и стан­дартных средств разработки, организация системных вызовов, файловый ввод/вывод, взаимодействие процессов, программирование средствами командной оболочки, создание графических пользовательских интерфейсов с помощью инструментальных средств GTK+ или Qt, применение сокетов и др. Описана компиляция программ, их компоновка c библиотеками и работа с терминальным вводом/выводом. Даны приемы написания приложений в средах GNOME® и KDE®, хранения данных с использованием СУБД MySQL® и отладки программ. Книга хорошо структурирована, что делает обучение легким и быстрым. Для начинающих Linux-программистов

Нейл Мэтью , Ричард Стоунс , Татьяна Коротяева

ОС и Сети / Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

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

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT