Комментарии 77
Я скобки всегда ставлю, чтобы с приоритетами не облажаться
Дело вкуса конечно, мне кажется что код без скобок как-то чище.
Так же стараюсь всегда ставить скобки, уже как привычка и разобраться потом легче. Хотя иногда в условие, случайно, как поставишь вместо "==" символ "=", а потом сидишь на измене от непонятного бага =)
скобки дополнительная операция, вы тормозите и так тормозной ruby ;)
>> А вы не смотря под cut можете внятно объяснить разницу между 'and' и '&&' в Ruby?
Да, главное не только в руби, во многих языках так.
Да, главное не только в руби, во многих языках так.
а я просто никогда не использую or и and — гораздо проще написать || и && :)
А если мне нужно именно and и я знаю как его использовать? Вопрос не вполне корректный
Главное не забывать, что ваш код кто-нибудь будет читать.
Меня когда то спросили разницу " и '
К сожалению, я тогда не знал…
И про && и and узнал только что :)
Спасибо!
К сожалению, я тогда не знал…
И про && и and узнал только что :)
Спасибо!
ага, давайте руби вей сюда по главам перепишем
Говорили мне в 2006 году: в Руби слишком много магии. Хорошо, что прислушался.
Магия эта очень приятная. И чем больше её изучаешь, тем более приятной она становится.
Говорили парни, которые работали на PHP? Вам соврали.
В PHP, если я не ошибаюсь, с and и && точно такая же «магия».
А с комментатором выше не согласен, думаю, напрасно Вы тогда прислушались:)
А с комментатором выше не согласен, думаю, напрасно Вы тогда прислушались:)
В PHP ровно эти же конструкции, ровно с теми же приоритетами.
Хорошие парни говорили, грамотные, которые сейчас не пишут на PHP очень давно и работают в Яндексе. А дело не в том соврали ли нет, а в том, что я с ними согласен.
[...] не пишут на PHP очень давно и работают в Яндексе.
Тут закрадывается подозрение на причинно-следственную связь (не удержался).
А дело не в том соврали ли нет, а в том, что я с ними согласен.
Любая точка зрения имеет право на существование.
нет в ruby магии, вас обманули
Вообще не понимаю зачем нужна поддержка 'and' и 'or' в языках — разница в приоритетах только ухудшает понимание между разработчиками одного кода и с течением времени. Имхо это пример того, как малюсенькая свобода в языке увеличивает шансы сделать багу.
ДААА… ХАБР УЖЕ НЕ ТОТ!
Нет, ну нельзя такие вещи постить на Хабре. Что будет если каждый будет писать о новых классных операторах? А в руби много магии о которой можно писать :)
Это же не дневник!
Это же не дневник!
Никогда не писал на Ruby, и мне его хвалили (хотя синтаксис не совсем в моем вкусе).
Но сдается мне, что это некоторая избыточность языка, которая может привести к ошибке. Хотя, вполне возможно, что есть у каждого оператора своя область применения, но я ее не вижу.
Но сдается мне, что это некоторая избыточность языка, которая может привести к ошибке. Хотя, вполне возможно, что есть у каждого оператора своя область применения, но я ее не вижу.
В руби много дублирующихся методов. Это сделано для того, что, чтобы разные люди с разными предпочтениями чувствовали себя комфортно.
Оно, конечно, похвально. Но когда дойдет до момента «читать чужой код» станет тяжело — не факт, что ты будешь чувствовать себя комфортно.
Но осуждать не берусь, очень хитрый метод заманивания разработчиков :) Саму идею одобряю.
Но осуждать не берусь, очень хитрый метод заманивания разработчиков :) Саму идею одобряю.
Принципе наименьшего удивления — часть «пути Руби». Конечно, это может раздражать некоторых пользователей, но для них есть другие отличные языке, где «только один способ сделать что-то».
В общем нужно принимать руби таким каков он есть и придерживаться здравого смысла при написании программ :)
В общем нужно принимать руби таким каков он есть и придерживаться здравого смысла при написании программ :)
Любой код, написанный на Руби более-менее здравомыслящим человеком читается очень просто, даже если язык видишь в первый раз.
Я до этого немного писал на перле, и меня сильно раздражал его чрезмерно лаконичный синтаксис — слишком много возможностей для ошибки и, главное, когда читаешь свой же код через полгода, приходится вспоминать что и зачем ты сделал так, как следствие, при командной работе нужно очень четко договариваться о стандартах кодирования. Собс-но одна из причин из-за чего я захотел расстаться с перлом.
Посмотрел на руби — увидел похожу вольницу — поэтому как-то сразу охладел к нему.
Хотя язык толковый. Иногда возникает желание за него взяться.
Посмотрел на руби — увидел похожу вольницу — поэтому как-то сразу охладел к нему.
Хотя язык толковый. Иногда возникает желание за него взяться.
вроде бы это идиома от perl'а, там достаточно часто бывает что-то вроде:
a = do_something or die('все плохо')
Это обходится правильным стилем кодирования в котором прописано, что 'and' и 'or' использовать нельзя без утверждения другим разработчиком. То же и про глобальные переменные в rails, например.
a = do_something or die('все плохо')
Это обходится правильным стилем кодирования в котором прописано, что 'and' и 'or' использовать нельзя без утверждения другим разработчиком. То же и про глобальные переменные в rails, например.
Или курсами по языку для разработчика. Я всё удивляюсь, если кто-то считает язык слишком сложным для себя, то может и не надрываться? Изучить что полегче.
Судя по Ваши постам вы явно отлично знаете Супер Сложные Языки аля PHP и Ruby, которые не в состоянии осилить ни один смертный разработчик… Прошу прощения за сарказм, не сдержался.
Вопрос-то не в том, что те, кто не знает таких подробностей — недочеловеки и им надо закрыть доступ к написанию кода, пока не выучат. А в том, что чем больше нюансов должен держать в голове программист — тем тяжелее ему делать свое дело и, следовательно, больше вероятность чего-то забыть и неправильно сделать. Имхо гораздо лучше, если разработчик будет держать в голове нюансы, связанные с задачей, которую ему надо сделать, а не с премудностями языка, который он использует.
Вопрос-то не в том, что те, кто не знает таких подробностей — недочеловеки и им надо закрыть доступ к написанию кода, пока не выучат. А в том, что чем больше нюансов должен держать в голове программист — тем тяжелее ему делать свое дело и, следовательно, больше вероятность чего-то забыть и неправильно сделать. Имхо гораздо лучше, если разработчик будет держать в голове нюансы, связанные с задачей, которую ему надо сделать, а не с премудностями языка, который он использует.
Зря не сдержались. У меня опыт программирования на Perl был несколько лет. Три ассемблера в совершенстве за плечами. И так далее.
Чтобы делать своё дело легко, надо это «дело» хорошо знать, чему способствует регулярное перечитывание учебников и методичек. Тогда все эти «премудрости языка» будут помогать, а не мешать решению задачи.
Поставить диагноз программисту, не знающему досконально своего основного языка, очень просто — дизартрия и общее недоразвитие речи.
Поставить диагноз программисту, не знающему досконально своего основного языка, очень просто — дизартрия и общее недоразвитие речи.
Зачем обходить то, что отлично работает? Как сказали выше, если вам не нравится берите то, что попроще.
use Perl or die;
use Perl or die;
Меня еще в школе, на уроках программирования, учитель (выходец из Индии) учил, что скобки — наше все! Ни разу это правило не подводило.
Похожая фигня в РНР. На RSDN'е выяснили, что приоритет операторов пришел из Perl'а. В Ruby, по всей видимости, тоже
irb(main):005:0> total = false and 10
=> false
irb(main):006:0> total = false && 10
=> false
irb(main):007:0> total = true and 10
=> 10
irb(main):008:0> total = true && 10
=> 10
что я делаю не так, где разница-то?
=> false
irb(main):006:0> total = false && 10
=> false
irb(main):007:0> total = true and 10
=> 10
irb(main):008:0> total = true && 10
=> 10
что я делаю не так, где разница-то?
я в основном пользую && и ||
а «and» и «or» только в следующих конструкциях:
do_something and return…
do_something or return…
в первом варианте возврат в случае успеха (вернули тру) во втором в случае если вернули фолс
второй вариант иногда так:
do_something or raise…
а «and» и «or» только в следующих конструкциях:
do_something and return…
do_something or return…
в первом варианте возврат в случае успеха (вернули тру) во втором в случае если вернули фолс
второй вариант иногда так:
do_something or raise…
Такой приоритет операторов пришел из Perl. Многие современные скриптовые языки так или иначе многое почерпнули из Perl :) PHP, Ruby и Python не исключение.
Кстати, в Perl логические операторы && и || (а теперь еще и //) на самом деле не чисто логические. Конструкция вида $a || $b вернет значение первой переменной, которое будет истиной. Например $a = 0 || 5 присвоит $a = 5, но не $a = true :)
Это дает дополнительную гибкость языку. Многие этого почему-то не любят, но это их право всего бояться и писать конструкции вида if (1 == $a) {...}
Возможности и особенности языка надо знать, без этого иногда становится грустно :)
Кстати, в Perl логические операторы && и || (а теперь еще и //) на самом деле не чисто логические. Конструкция вида $a || $b вернет значение первой переменной, которое будет истиной. Например $a = 0 || 5 присвоит $a = 5, но не $a = true :)
Это дает дополнительную гибкость языку. Многие этого почему-то не любят, но это их право всего бояться и писать конструкции вида if (1 == $a) {...}
Возможности и особенности языка надо знать, без этого иногда становится грустно :)
А почему нельзя вместо этого:
написать это:
total = user_messages.empty? and user_messages.totalнаписать это:
total = user_messages.total unless user_messages.empty?
Аналогично и для PHP.
Это учат на первом курсе программирования.
Use &&/|| for boolean expressions, and/or for control flow. (Rule of thumb: If you have to use outer parentheses, you are using the wrong operators.)
Use &&/|| for boolean expressions, and/or for control flow. (Rule of thumb: If you have to use outer parentheses, you are using the wrong operators.)
# boolean expression
if some_condition && some_other_condition
do_something
end
# control flow
document.saved? or document.save!
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Операторы '&&' и 'and' в Ruby