Должно ли пустое выражение «if» в C # приводить к ошибке или предупреждению? - PullRequest
4 голосов
/ 23 августа 2010

Позвольте мне начать с примера из реальной жизни:

Клиент: Алекс, только что заметил что-то странное в RemovalProcessor в строке 138:

if (Session.Handler.ExecutePrefetchTasks()==null); 
  Session.ExecuteDelayedQueries(); 

Если точка с запятой за«если» там?

Я: Упс ... Я отправлю это нашим парням для проверки, но, скорее всего, вы правы.

Хотя это редкий случай, я допускаю, что почти у любого крупного проекта есть подобная проблема.

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

Мало кто имеет в виду Q / AI:

  • Почему в этом случае должно генерироваться предупреждение или ошибка?

    Поскольку ошибка разработчика с вероятностью 99%.

  • Почему в этом случае предпочтительнее ошибка?

    Во многих случаях предупреждения игнорируются разработчиками.

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

    Наконец, ошибка в этом случае не будет «ограничивать» разработчика, так как такой код может (искорее всего, обязательно) всегда следует переписывать без оператора if.

  • Почему в этом случае предпочтительнее предупреждение?

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

Так что я был бы рад услышать ваше мнение по этому поводу.

Ответы [ 2 ]

12 голосов
/ 23 августа 2010

Уже выдается предупреждение:

Возможно ошибочное пустое утверждение

Я согласен с вами, что ошибка была бы предпочтительнее (если вы действительно хотите пустое выражение, всегда можете записать его как { }, что более явно), но они не собираются менять язык C # в этом путь. Это было бы серьезным изменением, и я подозреваю, что их оправдание (читай: Эрика Липперта) будет «выгода не перевешивает стоимость».

0 голосов
/ 23 августа 2010

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

if ( DoSomething() || SolveEquation() ) ;  // Intentional - compiles and  runs as expected.

Если ключевое слово if будет удалено, вы получите ошибку компиляции.

DoSomething() || SolveEquation();  // Compile ERROR.

Логика короткого замыкания C # определяет: если DoSomething () возвращает true, то SolveEquation () не оценивается; в противном случае это оценивается.

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

if ( ! DoSomething() )
    SolveEquation();

или (Спасибо Алекс за это из комментариев)

bool result = DoSomething() || SolveEquation(); 

.. а зачем грабить пользователя первым способом?

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

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

...