Java: “xx” .equals (переменная) лучше, чем variable.equals (“xx”), TRUE?
Я рассматриваю руководство лучших практик и рекомендацию, кодирующую Java, я думаю, сомнительно.
Recomendation:
String variable;
"xx".equals(variable) // OK
variable.equals("xx") //Not recomended
Поскольку предотвращает появление NullPointerException, которыми не управляют
Действительно ли это верно?
7 ответов
Это очень распространенный метод, при котором тест возвращает false, если переменная имеет значение NULL, вместо того, чтобы генерировать исключение NullPointerException . Но я думаю, что буду другим и скажу, что не буду рассматривать это как рекомендацию, которой вы всегда должны следовать.
- Я определенно думаю, что это то, о чем должны знать все Java-программисты, поскольку это обычная идиома.
- Это также полезный метод, позволяющий сделать код более кратким (вы можете обрабатывать нулевой и ненулевой регистры одновременно).
Но:
- Это затрудняет чтение вашего кода: «Если небо голубое ...»
- Если вы только что проверили, что ваш аргумент не равен нулю в предыдущей строке, то это ненужный.
- Если вы забыли проверить значение NULL, и кто-то пришел с аргументом NULL, которого вы не ожидали, то исключение
NullPointerExceptionне обязательно будет худшим из возможных результатов. Притворяться, что все в порядке, и носить с собой до тех пор, пока это в конечном итоге не выйдет из строя, - на самом деле не лучшая альтернатива. Быстро потерпеть неудачу - это хорошо.
Лично я не думаю, что использование этой техники необходимо во всех случаях. Я думаю, что это следует оставить на усмотрение программиста в индивидуальном порядке. Важно убедиться, что вы обработали нулевой случай надлежащим образом, и то, как вы это делаете, зависит от ситуации. Проверка правильности обработки нулевых значений может быть частью рекомендаций по тестированию / обзору кода.
Это правда. Если переменная будет null в вашем примере,
variable.equals("xx");
выдаст NPE, потому что вы не можете вызвать метод (equals) на объекте null. Но
"xx".equals(variable);
просто вернет false без ошибки.
Это правда, что использование любого свойства объекта таким образом помогает избежать NPE.
Но именно поэтому у нас есть исключения, чтобы обрабатывать такие вещи.
Возможно, если вы используете "xx".equals(variable), вы никогда не узнаете, является ли значение переменной null или просто не равно "xx". IMO лучше знать, что вы получаете нулевое значение в вашей переменной, чтобы вы могли переназначить его, а не просто игнорировать.
Если вам нужно проверить null , я считаю, что это лучше читается, чем
if (переменная! = Null && variable.equals ("xx")) . Это больше вопрос личных предпочтений.
На самом деле, я думаю, что первоначальная рекомендация верна. Если вы используете variable.equals ("xx") , то получите NullPointerException , если переменная имеет значение NULL. Размещение постоянной строки в левой части позволяет избежать этой возможности.
Вам решать, стоит ли эта защита страданий от того, что многие люди считают неестественной идиомой.
Это распространенный метод, используемый в программах Java (и C #). Первая форма позволяет избежать исключения нулевого указателя, потому что метод .equals () вызывается для постоянной строки «xx» , которая никогда не бывает нулевой. Непустая строка по сравнению с нулевой ошибкой.
Если вы знаете, что переменная никогда не будет иметь значение NULL (и ваша программа некорректна в другом случае, если она когда-либо будет нулевой), тогда используйте variable.equals ("xx") Это хорошо.
Вы правы насчет порядка проверки - если переменная равна null, вызов .equals для строковой константы предотвратит NPE - но я не уверен, что считаю это хорошей идеей; лично я называю это "слоп".
Слоуп - это когда вы не обнаруживаете ненормальное состояние, но на самом деле создаете привычки, чтобы лично избежать его обнаружения. Передача нуля в качестве строки в течение длительного периода времени в конечном итоге приведет к ошибкам, которые могут быть неясными и трудно обнаруживаемыми.
Кодирование для небрежности - это противоположность принципу "Fail fast fail hard".
Использование нуля в качестве строки может иногда дать отличное "специальное" значение, но тот факт, что вы пытаетесь сравнить его с чем-то, указывает на неполноту вашего понимания системы (в лучшем случае) - чем раньше вы обнаружите этот факт, тем лучше.
С другой стороны, делать все переменные конечными по умолчанию, использовать Generics и минимизировать видимость всех объектов/методов - это привычки, которые уменьшают неаккуратность.