Чи залишаєте ви в Ruby дужки або не в них? [зачинено]


86

Коли це можливо .. Ви залишаєте дужки в Ruby чи не в них?

Відповіді:


95

З елементів стилю рубін

Ruby дозволяє вам залишити дужки, взагалі протистояти цій спокусі.

Дужки полегшують використання коду. Загальний стиль Ruby полягає у використанні їх, за винятком таких випадків:

  • Завжди залишайте порожні дужки
  • Дужки можна залишити за допомогою однієї команди, яка оточена роздільниками ERb - маркери ERb переконуються, що код все ще читається
  • Рядок, який є однією командою та одним простим аргументом, можна записати без дужок. Особисто я вважаю, що роблю це все рідше і менше, але все одно це прекрасно читається. Мені, як правило, не подобаються окремі рядки в звичайному рубіновому коді, які мають кілька аргументів і не мають дужок.
  • Багато мов, заснованих на домені, на основі Ruby (таких як Rake), не використовують дужки, щоб зберегти природніші мовні відчуття своїх висловлювань.

27

Я використовую паренси як коментарі, щоб допомогти майбутньому мені ... у кого, ймовірно, буде менше клітин мозку, ніж у поточного мене :-)

Нічого гіршого, ніж дивитися на якийсь код, який ви написали 2 роки тому, і нерозуміти його, щоб ви щось зламали, змінюючи його.

Якщо parens врятує майбутнє мене на кілька хвилин (або годин) у майбутньому, я вкладу стільки, скільки потрібно, щоб твердження стало кристально чистим.


2
+1 "Я використовую паренси як коментарі, щоб допомогти майбутньому мені ... у кого, ймовірно, буде менше клітин мозку, ніж у поточного мене :-)" Це ТАК вірно, і саме тому я це роблю. Також слід бути милосердним до кожного, хто слідує за мною, хто повинен використовувати мій код. Коротше кажучи, це річ з обслуговування.
Олов'яна людина,

9

Я залишаю їх поза увагою, коли я роблю DSL-іш, наприклад, t.column або has_many у рейках. В інший час це, як правило, зводиться до ясності, і це, мабуть, рівномірний розкол.


8

Думаю, я роблю і те, і інше, але я точно їх тримаю, якщо це додає читабельності та уникає тверджень, які виглядають неоднозначними.


8

Якщо ви маєте на увазі у викликах функцій, я завжди ставлю дужки, тому що це завжди легше читати. Якщо ви маєте на увазі в умовах (якщо, поки), я ставлю дужки лише тоді, коли вони необхідні.


2
Я згоден. Наприклад, у php я можу швидко визначити var за префіксом $ .. у javascript я можу розпізнати функцію за дужками (). У Ruby різницю між var і func (без дужок) не завжди легко побачити.

7

Я намагаюся залишити їх осторонь, якщо це можливо. Я думаю, це полегшує читання коду (загалом кажучи).


4

Зазвичай, що більше читається.

Але я завжди використовую дужки, коли вкладаю виклики функцій всередині параметрів інших


2

Я схильний залишати їх поза увагою, коли роблю твердження, такі як assert_equal. Можливо, це для того, щоб зробити це мовно-специфічним для домену.


1

Якщо ви давно програмуєте, можливо, у вас з’явиться «свербіж», щоб додати дужки, і в багатьох випадках для цього є вагомі причини.

На мій погляд, код простіший для очей, і я ще не стикався з проблемою - якщо вам потрібні дужки, ви знаєте це заздалегідь, перш ніж вам доведеться запускати сценарій налагодження.


4
"Мій учитель каже мені, що це неминуче". Це, і може бути важко налагодити. Я рекомендую використовувати їх, щоб уникнути неоднозначного призначення параметрів.
Олов'яна людина,

IMO вважається "легшим для очей" - це паршива причина залишати дужки навколо аргументів функції.
Марчелло Романі

2
розмовляючи з натовпом не-парен, я наткнувся на цю проблему днями, if owner.is_a? thing //worked fine if owner.is_a? thing && x > 1 //not fine я вивчаю рубін лише пару тижнів, і коли я працюю, використовую найменшу кількість символів, і якщо ви походите з будь-якої іншої мови, є навчання крива, щоб знати, коли ви передаєте імплікативний хеш, масив символів, передаєте символи функції ... я не фанат.
Mega Man

@MegaManif owner.is_a? thing and x > 1
anna328p

1
@DmitryKudriavtsev andне має того самого пріоритету оператора, який &&мав
Mega Man
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.