Много отрицаний - Философия программирования

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

if (str != null && str != "test")
    // ...

рекомендуется привести к

if ( !(str == null || str == "test") )
    // ...

ИМХО, первый вариант несколько более читаем — не равно нул и не равно строке "test". Все ясно и понятно. Смысл же второго (по крайней мере мне) уже не так очевиден.
Понятно, что когда условие сложное, то большое количество отрицаний реально замедляет понимание кода. Но зачастую классики приводят примеры аналогичные моему и говорят, что второй вариант лучше.
Это именно особенности моего восприятия, или классики ошибаются, или я что-то недопонимаю?

... << RSDN@Home 1.1.4 beta 7 rev. 463>>

Здравствуйте, SiAVoL, Вы писали:

SAV>Ведущие собаковеды рекомендуют не использовать много отрицаний в условиях и уменьшать их, используя теоремы Моргана
SAV>Т.е. например код
SAV>

SAV>if (str != null && str != "test")
SAV>    // ...
SAV>

SAV>рекомендуется привести к
SAV>

SAV>if ( !(str == null || str == "test") )
SAV>    // ...
SAV>

SAV>ИМХО, первый вариант несколько более читаем — не равно нул и не равно строке "test". Все ясно и понятно. Смысл же второго (по крайней мере мне) уже не так очевиден.

Согласен. Первый вариант более читабельный

Здравствуйте, SiAVoL, Вы писали:

SAV>Ведущие собаковеды рекомендуют не использовать много отрицаний в условиях и уменьшать их, используя теоремы Моргана
...
А, если не секрет, кто они эти загадочные "ведущие собаковеды", проповедующие сие?

SAV>if (str != null && str != "test")
SAV>    // ...
SAV>

Имхо, много отрицаний было бы в случае:

if( !(str == null) && !( str == "test" ) )
    // ...

А так это всего лишь несколько неравенств.

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

Здравствуйте, korzhik, Вы писали:

K>Согласен. Первый вариант более читабельный

Более того, первый вариант еще и в общем случае быстрее работает

Здравствуйте, eao197, Вы писали:

>Имхо, много отрицаний было бы в случае:
E>

E>if( !(str == null) && !( str == "test" ) )
E>    // ...
E>

E>А так это всего лишь несколько неравенств.

E>)

согласен, пример в начальном посте выбран неудачно

SAV>if (str != null && str != "test")
SAV>    // ...
SAV>

SAV>рекомендуется привести к
SAV>

SAV>if ( !(str == null || str == "test") )
SAV>    // ...
SAV>

SAV>ИМХО, первый вариант несколько более читаем — не равно нул и не равно строке "test". Все ясно и понятно. Смысл же второго (по крайней мере мне) уже не так очевиден.
SAV>Понятно, что когда условие сложное, то большое количество отрицаний реально замедляет понимание кода. Но зачастую классики приводят примеры аналогичные моему и говорят, что второй вариант лучше.
SAV>Это именно особенности моего восприятия, или классики ошибаются, или я что-то недопонимаю?
Хомяковеды таким не заморачиваются.

И вообще, на основании чего такие выводы? Кто эти собаководы?

С уважением, Gleb/

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

Здравствуйте, SiAVoL, Вы писали:

// скип

У меня есть такой код

if (nat_enabled && !(nat_except && nat_addr == ApplyMask(ip_dst, nat_mask))){}

и помоему он более читабелен, чем

if (nat_enabled && (!nat_except || nat_addr != ApplyMask(ip_dst, nat_mask))){}

SiAVoL,

> Ведущие собаковеды рекомендуют не использовать много отрицаний в условиях и уменьшать их, используя теоремы Моргана

Обычно речь идет о множественных отрицаниях, т.е. об отрицаниях отрицаний:

if ( !( !(str == null) && str != "test" ) )
     // ...

Posted via RSDN NNTP Server 2.0 beta

Здравствуйте, SiAVoL, Вы писали:

SAV>Ведущие собаковеды рекомендуют не использовать много отрицаний в условиях и уменьшать их, используя теоремы Моргана

Кроме того, ведущие собаковеды советуют использовать рефакторинги
1) Декомпозиция условного оператора.
2) Консолидация условного выражения
3) Консолидация дублирующихся условных фрагментов
4) Замена вложенных условных операторов граничным оператором

Фаулер — форева!

Здравствуйте, eao197, Вы писали:

E>Имхо, много отрицаний было бы в случае:
E>

E>if( !(str == null) && !( str == "test" ) )
E>    // ...
E>

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

if (!firstCondition && !secondCondition)

... << RSDN@Home 1.1.4 beta 7 rev. 463>>

X>Более того, первый вариант еще и в общем случае быстрее работает
ровно на 1 такт

))

Hello, SiAVoL!
You wrote on Wed, 22 Jun 2005 12:25:55 GMT:

S> Ведущие собаковеды рекомендуют не использовать много отрицаний в
S> условиях и уменьшать их, используя теоремы Моргана Т.е. например код
S>

 S> if (str != null && str != "test")
 S>  // ...
 S>

S> рекомендуется привести к
S>

 S> if ( !(str == null || str == "test") )
 S>  // ...
 S>

S> ИМХО, первый вариант несколько более читаем — не равно нул и не равно
S> строке "test".

Не знаю как на C#, а на C эти два варианта одинаковы по производительности.
Что же касается нюансов обобщенного программирования, то имеет смысл предпочесть 2-й
Смысл в том что тип к которому принадлежит str может не иметь оператора '!=' и иметь оператор '=='.
Конечно, концепция 'Equality Comparable' требует наличия и того и другого оператора,
но зачастую лентяи-программисты ограничиваются реализацие только оператора '=='...

Posted via RSDN NNTP Server 1.9

Здравствуйте, 0xDEADBEEF, Вы писали:

DEA>Смысл в том что тип к которому принадлежит str может не иметь оператора '!=' и иметь оператор '=='.
DEA>Конечно, концепция 'Equality Comparable' требует наличия и того и другого оператора,
DEA>но зачастую лентяи-программисты ограничиваются реализацие только оператора '=='...

Не лентяи программисты предпочитают определять всего один оператор '<'. А затем через него выводить и равенство, и неравенство и т.д.

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

Здравствуйте, SiAVoL, Вы писали:

SAV>

SAV>if (str != null && str != "test")
SAV>    // ...
SAV>

SAV>рекомендуется привести к
SAV>

SAV>if ( !(str == null || str == "test") )
SAV>    // ...
SAV>

Я бы рекомендовал код типа таких:

if( (pointer != null) && (используем выражения с pointer зная что он точно не null) )

if( (array != null) && (array.Length >= N) && (используем выражения с array зная что он точно не null и что его длина точно >= N) )

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

Здравствуйте, eao197, Вы писали:

E>Не лентяи программисты предпочитают определять всего один оператор '<'. А затем через него выводить и равенство, и неравенство и т.д.

Неправда. Лентяи не знают что через '<' можно вывести равенство

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

Здравствуйте, 0xDEADBEEF, Вы писали:

DEA>Здравствуйте, eao197, Вы писали:

E>>Не лентяи программисты предпочитают определять всего один оператор '<'. А затем через него выводить и равенство, и неравенство и т.д.

DEA>Неправда. Лентяи не знают что через '<' можно вывести равенство

.
DEA>А те кто знает, знает также и тот факт что вывод равенства через '<' требует двух сравнений вместо одного, а этого программистская совесть так легко не позволит.

А как же STL?

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

Hello, eao197!
You wrote on Mon, 27 Jun 2005 15:38:44 GMT:

e> Здравствуйте, 0xDEADBEEF, Вы писали:

DEA>> Здравствуйте, eao197, Вы писали:

E>>> Не лентяи программисты предпочитают определять всего один оператор
E>>> '<'. А затем через него выводить и равенство, и неравенство и т.д.

DEA>> Неправда. Лентяи не знают что через '<' можно вывести равенство

.
DEA>> А те кто знает, знает также и тот факт что вывод равенства через '<'
DEA>> требует двух сравнений вместо одного, а этого программистская совесть
DEA>> так легко не позволит.

e> А как же STL?
Ты это про rel_ops? Так там мухи и котлеты подаются отдельно. В том смысле что
'!=' реализуется через '==' а отношения порядка — через '<'. И это, кстати, требуется стандартом (20.2.1)

Posted via RSDN NNTP Server 1.9

Здравствуйте, 0xDEADBEEF, Вы писали:

DEA>>> Неправда. Лентяи не знают что через '<' можно вывести равенство

.
DEA>>> А те кто знает, знает также и тот факт что вывод равенства через '<'
DEA>>> требует двух сравнений вместо одного, а этого программистская совесть
DEA>>> так легко не позволит.

e>> А как же STL?
DEA>Ты это про rel_ops? Так там мухи и котлеты подаются отдельно. В том смысле что
DEA>'!=' реализуется через '==' а отношения порядка — через '<'. И это, кстати, требуется стандартом (20.2.1)

Не, я про то, что для использование своих классов в set или map не нужно определять ничего, кроме '<'.

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

Hello, eao197!
You wrote on Mon, 27 Jun 2005 15:56:23 GMT:

e> Не, я про то, что для использование своих классов в set или map не нужно
e> определять ничего, кроме '<'.
Эти контейнеры являются упорядоченными. Для того чтобы они были такими, достаточно предиката порядка — по умолчанию std::less, который в свою очередь использует '<'.

ЗЫ. А вот "неупорядоченные" контейнеры (из TR1) unordered_(map|set) требуют чтобы были определены и предикаты эквивалентности и предикаты порядка...

Posted via RSDN NNTP Server 1.9

	От:	SiAVoL
	Дата:	22.06.05 12:25
	Оценка:

	От:	korzhik
	Дата:	22.06.05 12:27
	Оценка:	+7

От:	Курилка	http://kirya.narod.ru/
Дата:	22.06.05 12:31
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	22.06.05 12:38
Оценка:	12 (1) +2

От:	xvost	http://www.jetbrains.com/company/people/Pasynkov_Eugene.html
Дата:	22.06.05 12:45
Оценка:	+2

	От:	Павел Кузнецов
	Дата:	22.06.05 15:56
	Оценка:	12 (1) +1

От:	Airat Burganov	http://www.burganov.com
Дата:	22.06.05 21:03
Оценка:	9 (1) +4

От:	qxWork	http://www.jetbrains.com/company/people/Coox_Sergey.html
Дата:	23.06.05 10:33
Оценка:

От:	Сергей Губанов	http://sergey-gubanov.livejournal.com/
Дата:	27.06.05 14:07
Оценка:	1 (1) +1