Каковы некоторые примеры того, где использование скобок в программе снижает читабельность?

Question

Я всегда думал, что круглые скобки улучшают читабельность, но в моем учебнике есть утверждение, что использование круглых скобок значительно снижает читаемость программы. У кого-нибудь есть примеры?

Answer 1

Я могу найти множество контрпримеров, в которых отсутствие круглых скобок снизило читабельность, но единственный пример, который я могу придумать для того, что мог иметь в виду автор, это что-то вроде этого:

if(((a == null) || (!(a.isSomething()))) && ((b == null) || (!(b.isSomething()))))
{
   // do some stuff
}

В вышеприведенном случае () вокруг вызовов методов не требуется, и этот тип кода может извлечь выгоду из разделения терминов на переменные. Со всеми этими близкими значениями в середине условия трудно понять, что именно с чем сгруппировано.

boolean aIsNotSomething = (a == null) || !a.isSomething();  // parens for readability
boolean bIsNotSomething = (b == null) || !b.isSomething();  // ditto
if(aIsNotSomething && bIsNotSomething)
{
   // do some stuff
}

Я думаю, что выше это более читабельно, но это личное мнение. Возможно, именно об этом говорил автор.

Некоторые хорошие примеры использования паренов:

• чтобы различать порядок действий при изменении поведения без символов
• чтобы различать порядок операций, когда поведение не затронуто, но кто-то, кто недостаточно хорошо знает правила привязки, собирается прочитать ваш код. Правило добропорядочного гражданина.
• , чтобы указать, что выражение в скобках должно быть оценено перед использованием в большем выражении: System.out.println("The answer is " + (a + b));

Возможно запутанное использование паренов:

• в местах, где оно не может иметь другого значения, например перед a.isSomething() выше. В Java, если a является Object, !a само по себе является ошибкой, поэтому ясно, что !a.isSomething() должно отрицать возвращаемое значение вызова метода.
• , чтобы связать воедино большое количество условий или выражений, которые были бы более понятными, если бы их разбили. Как и в приведенном выше примере кода, разбиение большого парантетического оператора на более мелкие порции может позволить более просто проходить код в отладчике, и если условия / значения необходимы позже в коде, вы не заканчиваете повторяю выражения и делаю работу дважды. Однако это субъективно и, очевидно, бессмысленно, если вы используете выражения только в одном месте, а ваш отладчик в любом случае показывает промежуточные вычисленные выражения.

Answer 2

Видимо, ваш учебник написан кем-то, кто ненавидит Лисп.

В любом случае, это дело вкуса, для всех нет единой правды.

Answer 3

Скобки уменьшают читабельность, когда они явно избыточны . Читатель ожидает, что они будут там по причине, но нет никакой причины. Отсюда и когнитивный икота.

Что я имею в виду под «очевидно» избыточным?

• Круглые скобки являются избыточными, когда их можно удалить без изменения смысла программы.

• Скобки, которые используются для устранения неоднозначности инфиксных операторов, не «явно избыточны», даже если они избыточны, за исключением, возможно, особого случая операторов умножения и сложения. Причина: многие языки имеют от 10 до 15 уровней приоритета, многие люди работают на нескольких языках, и никто не может вспомнить все правила. Часто лучше избавиться от неоднозначности, даже если скобки излишни.

• Все остальные избыточные скобки явно избыточны.

Избыточные скобки часто встречаются в коде, написанном кем-то, кто изучает новый язык; возможно, неопределенность в отношении нового синтаксиса приводит к защитным скобкам. Вычеркни их!

---

Вы просили примеры. Вот три примера, которые я неоднократно вижу в коде ML и коде на Haskell, написанном новичками:

• Скобки между if (...) then всегда избыточны и отвлекают. Они делают автора похожим на программиста на Си. Просто напишите if ... then.

• Скобки вокруг переменной глупые, как в print(x). Круглые скобки никогда не нужны вокруг переменной; приложение функции должно быть написано print x.

• Скобки вокруг приложения функции являются избыточными, если это приложение является операндом в выражении инфикса. Например,

  (length xs) + 1
  

  всегда должно быть написано

  length xs + 1
  

Answer 4

Ну, рассмотрим что-то вроде этого:

Result = (x * y + p * q - 1) % t и

Result = (((x * y) + (p * q)) - 1) % t

Лично я предпочитаю первое (но это только я), потому что второе заставляет меня думать, что парантезы существуют, чтобы изменить фактический порядок операций, хотя на самом деле они этого не делают. Ваш учебник может также указывать, когда вы можете разделить свои вычисления на несколько переменных. Например, у вас, вероятно, будет что-то подобное при решении квадратичного ax^2+bx+c=0:

x1 = (-b + sqrt(b*b - 4*a*c)) / (2*a)

Что выглядит некрасиво. Это выглядит лучше, на мой взгляд:

SqrtDelta = sqrt(b*b - 4*a*c);
x1 = (-b + SqrtDelta) / (2*a);

И это всего лишь один простой пример, когда вы работаете с алгоритмами, которые включают в себя множество вычислений, все может стать действительно уродливым, поэтому разбиение вычислений на несколько частей поможет удобочитаемости больше, чем искажает паратезы.

Answer 5

Я думаю, что круглые скобки - не лучший способ улучшить читабельность вашего кода.Вы можете использовать новую строку, чтобы подчеркнуть, например, условия в операторе if.Я не использую скобки, если это не требуется.

Answer 6

Вы должны пойти слишком далеко с ними, чтобы действительно повредить читабельности, но из личного вкуса я всегда находил;

return (x + 1);

и аналогичные в коде C и C ++ очень раздражают.

Answer 7

Все, что доходит до крайности и / или чрезмерно используется, может сделать код нечитаемым. Было бы сложно сделать то же самое заявление с комментариями. Если вы когда-либо просматривали код, содержащий комментарий практически для каждой строки кода, вы сказали бы, что его трудно читать. Или вы могли бы иметь пробелы вокруг каждой строки кода, которые облегчили бы чтение каждой строки, но обычно большинство людей хотят, чтобы похожие связанные строки (которые не требуют метода разбивки) были сгруппированы вместе.

Answer 8

Если метод не принимает параметры, зачем требовать пустую () для вызова method()? Я верю в отличный, вам не нужно это делать.