Что происходит, когда у Вас есть условный оператор и постфиксное условное выражение в том же операторе Perl?
Я думаю, что проблема глубоко связывается с доменом проблемы, которую Вы пытаетесь решить с классом.
В некоторых случаях, конструктор с 7 параметрами может указать на плохую иерархию классов: в этом случае структура/класс помощника, предложенная выше, обычно является хорошим подходом, но тогда Вы также склонны заканчивать с загрузками структур, которые являются просто наборами свойств и не делают ничего полезного. Конструктор с 8 аргументами мог бы также указать, что Ваш класс слишком универсален / слишком универсальный, таким образом, требуется много опций быть действительно полезным. В этом случае можно или осуществить рефакторинг класс или реализовать статических конструкторов, которые скрывают настоящих сложных конструкторов: например, Shniz. NewBaz (нечто, панель) мог на самом деле вызвать настоящего конструктора, передающего правильные параметры.
3 ответа
Постфикс «if» означает, что оператор return выполняется только в том случае, если условие истинно, поэтому
return $y < 0 ? - pip2 : pip2 if $x == 0;
то же самое, что
if ($x == 0)
{
return $y < 0 ? - pip2 : pip2 ;
}
Если вас озадачивает тернарный оператор?: , который также можно переписать как обычный оператор if, чтобы получить это
if ($x == 0)
{
if ($y<0)
{
return -pip2;
}
else
{
return pip2;
}
}
это то же самое, что и
if($x == 0){
if($y<0){
return -pip2;
}else{
return pip2;
}
}
Вся функция тогда становится:
sub _atan {
my( $y, $x ) = @_;
if($x == 0){
if($y<0){
return -pip2;
}else{
return pip2;
}
}else{
return atan( $y / $x );
}
}
Это хороший пример трудно читать код.
Давайте сравним несколько различных способов переписать образец кода и посмотрим, как мы это делаем, сохраняя краткость и улучшая читаемость.
Эта троичная версия выигрывает для краткости, но ее все еще трудно читать:
sub _atan {
my( $y, $x ) = @_;
return $x == 0 ? ($y < 0 ? -pip2 : pip2)
: atan( $y / $x );
}
Я обнаружил, что связанные условные операторы (? :) доступны для чтения только тогда, когда последующие операторы попадают в позицию else:
sub _atan {
my( $y, $x ) = @_;
return $x != 0 ? atan( $y / $x ) :
$y < 0 ? -pip2 : pip2;
}
Все еще кратко, но читаемость улучшена.
Но как насчет использования if и если только ? Можем ли мы кратко, читаемый код, тоже использующий их?
По своей природе прямой подход if / else будет более подробным:
sub _atan {
my( $y, $x ) = @_;
my $atan;
if( x == 0 ) {
if( $y < 0 ) {
$atan = -pip2;
}
else {
$atan = pip2;
}
}
else {
$atan = atan( $y / $x )
}
return $atan;
}
Легко проследить все вышесказанное и посмотреть, каков будет результат. Таким образом, удобочитаемость выигрывает, но страдает краткость.
Я считаю, что использование модификаторов операторов форм , если только и if не обеспечивают чистый способ добавления логики короткого замыкания в кусок кода :
sub _atan {
my( $y, $x ) = @_;
return atan( $y / $x )
unless $x == 0;
return -pip2 if $y < 0;
return pip2;
}
Это краткое и удобочитаемое, но мне кажется, что мы получили больше возвратов, чем нам нужно.
Так что, если мы введем в смесь условный оператор, мы получим
sub _atan {
my( $y, $x ) = @_;
return atan( $y / $x )
unless $x == 0;
return $y < 0 ? -pip2 : pip2;
}
Эта форма столь же лаконична как и любая из вышеперечисленных форм, но намного проще для понимания:
sub _atan {
my( $y, $x ) = @_;
return atan( $y / $x )
unless $x == 0;
return $y < 0 ? -pip2 : pip2;
}
Вложенные предложения if / else могут быть трудными для понимания. Небольшая осторожность при структурировании кода решения может значительно улучшить читаемость и, следовательно, ремонтопригодность, при сохранении краткого выражения лежащей в основе логики.
Запах кода, который необходимо исправить здесь, заключался в причудливой комбинации условного оператора (?: ) с формой модификатора оператора if . Изменив порядок тестов и тщательно выбрав способ представления условной логики, мы смогли сохранить краткость и прояснить код.