Короткий пост посвящается всем любителям ЗВ и Java / JavaRush в честь 40-летия выхода V эпизода звёздной саги!Порой на просторах интернета можно встретить много интересных вещей, вот и на днях мне на глаза попалась довольно забавная на первый взгляд программистская практика по названием Yoda conditions.
Если вкратце, условия Йоды (также нотация Йоды) - это такой стиль программирования, при котором две части привычного нам выражения сравнения в условных операторах перевернуты:
if (5 == a) {
// do something
}
Такой стиль может использоваться в языках с С-подобным синтаксисом, чаще всего в выражениях с if и while.
if (0 == variable) {
// do something
}
while (false == endingCondition) {
// do something
}
Зачем же сдвигать константное выражение в левую часть от оператора сравнения?
Предположим гипотетическую ситуацию, при которой после марафона-просмотра всех девяти шести частей Саги, мы, не выспавшись, сели писать какой-то код для своего pet-проекта и написали следующее:
void checkNumber(int a)
{
if (a = 13) // Здесь-то и появляется так называемый unexpected behavior!
{
printf("Number is 13");
}
}
В данном случае, при каждом запуске программы у вас будет выдаваться строка Number is 13", вне зависимости от переданного аргумента а в метод checkNumber(int a). Это не то, что мы ожидали!
Логические ошибки довольно часто могут встречаться у начинающих программистов (believe me, I KNOW). Но на этапе компиляции код типа 13 = а будет выдавать ошибку, которую мы уж никак не проглядим, так как целочисленное значение является константой и, соответственно, не может меняться (превратиться в "а").
В применении условий Йоды есть как свои плюсы, так и свои минусы
Light Side:
Предотвращение присваивания значения переменной, когда нашей целью является сравнение.
Разрешение проблемы небезопасного "Нулевого поведения" (NullPointerException) // примеры из Википедии
Без Йоды:
String myString = null;
if (myString.equals("foobar")) { /* ... */ }
// This causes a NullPointerException in Java
С Йодой:
String myString = null;
if ( "foobar".equals(myString) ) { // Результат - Ложь
/* не выполняется */
}
Dark Side:
Читаемость кода для людей, которые будут смотреть твой код, усложняется, увеличивая нагрузку для восприятии кода.
Узкая область применения, употребляется только сравнение на равенство или сравнение с константой, проверка на null.
Многие компиляторы уже "видят" ошибки подобного рода и заранее предупреждают о наличии потенциальной ошибки.
Альтернативой нотации Йоды могут быть unit-тесты. Во времена Старой Республики поговаривали, что проведение качественного тестирования даст гарантию того, что код будет без ошибок и будет делать только то, для чего он писался.
А какие полезные практики знаете вы? Поделитесь знаниями в комментариях! А также напишите ваш любимый эпизод!
And may the Force be with you!
Да, есть такая штука, для джавы первый пункт не подойдет, присваивание вместо сравнения никак не получится заменить, а вот относительно null pointer safety то Джошуа Блох такой способ описывал на примерах со стрингом, но в джава (как и в большинстве языков) подобная нотация не применяется.
Ибо, как говорит Анкл Боб:
Code that protects the author at the expense of the reader is flawed code.
такой прием есть, он забавный, знать что это такое нужно, статья актуальная и полезная.
Чтобы прочитать, узнать что такое есть и никогда не применять :)
Язык программирования это прежде всего язык.
Мы не говорим как Йода. И программный код поэтому так тоже не пишется. Качество кода, его читабельность это характеристика которая гораздо важнее наллпойнтеров.
Наллпойнтер как вылезет так и залезет, для этого есть тесты и эксепшен хендлеры, а плохо написанный и плохо читабельный код это может быть катастрофа для проекта.
Попытаюсь объяснить простым языком один из методов null pointer safety описанный здесь. Всегда вызывать метод equals() у известной строки, про которую мы знаем, что она не null.
String myString = null;
if ( "foobar".equals(myString) ) {
// NPE не будет
//Результат - Ложь
/* не выполняется */
}
Можем схватить NullPointerException, в случае если метод вызывается у null.
Как условный метод с условной книжки про условный foobar - ок.
В реальной жизни встретить захардкодженные строковые литералы вместо констант с перевернутым сравнением без проверок на налл аргументов не так уж и легко.
Порой на просторах интернета можно встретить много интересных вещей, вот и на днях мне на глаза попалась довольно забавная на первый взгляд программистская практика по названием Yoda conditions.
Если вкратце, условия Йоды (также нотация Йоды) - это такой стиль программирования, при котором две части привычного нам выражения сравнения в условных операторах перевернуты:
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ