Почему пустой указатель == myVar вместо myVar == пустой указатель? [дубликат]
Почему не C-M-V? Вы начинаетесь с вызовом к методу контроллера, метод на этом контроллере решает, какое представление возвратиться к Вам (даже если это представление по умолчанию) и это может или не может консультироваться с моделью для данных и функциональности для создания того просмотра страницы. Следовательно C-M-V Тогда, когда представление отправляет назад его, является V-C-M-V.
Во всяком случае, я - много довольное MVC. Символ был распознан и понят.
6 ответов
Это старая привычка избегать случайной опечатки myVar = null (упс). Он по-прежнему полезен для некоторых языков, но C # защитит вас от этого, поэтому в нем нет необходимости.
Это пережиток C, где старые компиляторы этого не поймают:
if (foo = null)
когда вы имеете в виду это:
if (foo == null)
Классический Пример шутки - это ошибка:
if (fireTheNukes = true)
fireTheNukes();
Это общепринято как архаичный шаблон, так как любой достойный компилятор поймает присваивание в условном операторе. Я бы избегал этого шаблона в вашем коде, поскольку в наши дни он не имеет никакого смысла.
Это старая защитная привычка. Если вы поместите константу слева, то потеря второго знака равенства приведет к ошибке компиляции. В более нормальном формате, если забыть второй знак равенства, переменной будет присвоено значение null.
Другими словами,
myVar = null
вредно и неожиданно, тогда как
null = myVar
перехватывается компилятором.
Это привычка программистов C, которая в данном случае была перенесена на C #, но на самом деле в ней совершенно нет необходимости.
Учтите, что если вы случайно наберете , если (myVar = null) , компилятор выполнит присвоение и не будет жаловаться. Переключение порядка myVar и null гарантирует, что сгенерирована ошибка компилятора, если == случайно ошибочно введено как = . Однако C # в любом случае генерирует предупреждение компилятора, так что эта особенность не нужна.
Это происходит из C / C ++, чтобы отловить пропуск одного знака равенства:
myVar = null
Но в C # это не требуется.
Как уже упоминалось другими, это ' тактика защиты от проблем, которые могут возникнуть из-за того, что в C и некоторых производных от C (включая C #) выражение присваивания оценивается как значение этого присваивания. Вот что позволяет вам делать:
if (a = true) { /* This will always get done, as "a = true" evals to true */ }
и
int a = b = c = d = 10;
Поскольку присваивание является правоассоциативным, это эффективно
int a = (b = (c = (d = 10)));
, когда каждое выражение внутри пары скобок будет оценивать значение присваивания, которое в данном случае равно 10 и , b, c и d, таким образом, будут равны 10.
Чтобы избежать потенциальных ошибок - путаницы операторов присваивания и равенства - некоторые программисты предпочитают всегда помещать константу слева, как если бы оператор присваивания использовался случайно. компилятор будет жаловаться на то, что вы не можете присвоить константу.
Это, однако, меньшая проблема в C # по двум причинам. Во-первых, в отличие от C, C # не позволяет интерпретировать произвольные значения как логические.
Это было необходимо в C, поскольку у него не было истинного логического типа, он просто полагался на интерпретацию других значений, таких как целые числа (где 0 - ложь, а ненулевое верно) или указатели (где NULL - ложь). Это означало, что затем вы могли сделать что-то вроде
if (10) { /* This will always get done */ }
if (0) { /* This will never get done */ }
if (p) { /* This will get done is p is not null */ }
if (NULL) { /* This will never get done */ }
. Однако, поскольку C # не позволяет интерпретировать произвольные выражения как логические, они не будут работать в C #. Это также означает, что
if (a = 10) { }
не будет компилироваться в C #, поскольку выражение «a = 10» оценивается как значение выражения, 10, которое затем не может быть интерпретировано как требуемое логическое значение.
Вторая причина, по которой оно является меньшая проблема заключается в том, что в теперь намного меньшем