a = b = c стандарты кодирования

Question

Я отвечаю за создание стандартов кодирования и проверку кода в моей организации.

Я наткнулся на что-то в нашем исходном коде, как это:

object.Property = myVar1 = myVar2;

Лично я этого не делаю, потому что нахожу это в замешательстве. Я вижу это, и я хочу прочитать это так:

object.Property = myVar1 == myVar2;

Теперь я знаю, что он делает: он присваивает myVar myVar2, а затем object.Property для myVar2. В документе о стандартах кодирования прямо не указано, можете ли вы сделать это. Однако в нем утверждается, что переменные внутри оператора if не назначаются.

Полагаю, мой вопрос в том, достаточно ли плох стиль, чтобы рисовать как практику кодирования, чтобы не делать этого? Я не люблю делать стандартные политики кода "только потому, что я так сказал"

Отредактировано, чтобы лучше объяснить моё понимание

Answer 1

Я всегда заключаю выражения равенства в скобки:

object.Property = (myVar1 == myVar2);

Это привлекает внимание к тому факту, что это не задание.

Answer 2

Это так называемое «цепочечное присваивание» действительно противоречиво, и есть много вопросов по SO, которые его касаются.

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

На многих языках это несколько опасно для новичков.В языках, где [] является конструктором для пустых объектов массива, запись

a = b = []

делает a и b ссылкой на один и тот же объект.Новички склонны считать, что он создает два отдельных пустых массива, которые можно заполнять независимо.Не так!Эквивалент C #,

a = b = new SomethingOrOther();

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

Хорошее обоснование для введения запрета на это в три раза:

1. Это совершенно не нужно.
2. Это подвержено ошибкам (как в массивепример выше).

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

Answer 3

Так как я сталкиваюсь со временем, когда я хочу a = b = c очень редко Я просто пишу это как два отдельных утверждения. (Для меня это часто бывает так же хорошо, потому что мне нравится не переустанавливать переменные , когда это возможно, делая присваивание только в объявлении, и я объявляю только одну переменную для каждого объявления переменной.)

Тогда, если я делаю сталкиваюсь с a = b == c, я просто воспринимаю это как "присваиваю результат равенства a" и даже не думаю дважды об этом (как мой стиль кодирования не a = b = c).

Однако эта ошибка минимизирована в C #, потому что, за исключением случаев, когда речь идет о булевых типах (для a, b, и c), компилятор будет жаловаться, потому что типы будут неправильными.

Удачного кодирования.

Answer 4

Прежде всего, спасибо вам за то, что вы не приняли «мой путь - правильный путь». Этот вопрос очень субъективен, и у разработчиков будут разные (и обычно сильные) мнения.

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

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

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

Answer 5

Это (обычно) не о чем беспокоиться, в C #.

Если ваша переменная не равна bool (в этом случае вы должны разделить ее на два оператора в любом случае), то неподверженный ошибкам - только один из двух будет работать правильно, поэтому нет опасности «случайно» пропустить или набрать дополнительный =.

Вывод: не беспокойтесь ологические случаи.

Answer 6

Поскольку речь идет о стиле кодирования, это очень много, ИМХО

Практически любая языковая функция может показаться запутанной или замечательной в зависимости от разработчика.Некоторые люди думают, что перегрузка операторов (или обобщений, замыканий, функций высшего порядка и т. Д.) - это дорога в ад, другие видят в этом хороший инструмент для создания лаконичного и читаемого кода.

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

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

Answer 7

Теперь я знаю, что он делает: он присваивает myVar myVar2, а затем object.Property для myVar1

Ваше понимание неверно, компилятор этого не делает.Поскольку assignment expressions возвращает значение, поэтому в вашем примере object.Property присваивается возвращаемое значение выражения присваивания myVar1 = myVar2. НЕ присвойте myVar2 myVar1, а затем n myVar1 object.Property

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

object.Property = myVar1 == myVar2;