Witam,

Czy taka konstrukcja narusza jakieś zasady/sty dobrego projektowania lub
jeszcze innego wzorca projektowego? Chodzi mi o drabinkę if..else

if (preserveR)
{
if (oldW >= oldH && !fit)
{
if (!onlyG || width < oldW)
{
newW = width;
newH = (oldH * newW) / oldW;
}
}
else if (!fit)
{
if (!onlyG || height < oldH)
{
newH = height;
newW = (oldW * newH) / oldH;
}
}
else
{
//...
}
}
else
{
newW = width;
newH = height;
}

do góry

On Thu, 4 Aug 2011 23:40:37 +0200, <g...@h...com> wrote:

>Czy taka konstrukcja narusza jakieś zasady/sty dobrego projektowania

Nazewnictwo prosi sie o poprawe.

--
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/

do góry

> Witam,

>

> Czy taka konstrukcja narusza jakieś zasady/sty dobrego projektowania lub

> jeszcze innego wzorca projektowego? Chodzi mi o drabinkę if..else

>

> if (preserveR)

> {

>    if (oldW >= oldH && !fit)

>    {

>        if (!onlyG || width < oldW)

>        {

>            newW = width;

>            newH = (oldH * newW) / oldW;

>        }

>    }

>    else if (!fit)

>    {

>        if (!onlyG || height < oldH)

>        {

>            newH = height;

>            newW = (oldW * newH) / oldH;

>        }

>    }

>    else

>    {

>        //...

>    }

> }

> else

> {

>    newW = width;

>    newH = height;

> }

>

trudno powiedziec (przynajmniej mi trudno powiedziec) trzebaby sie
zastanowic czy jest jakis sposob by robic takie rzeczy lepiej - osobiscie
nie przychodzi mi do glowy teraz jakis lepszy sposob (ani nie mam tez sily sie
zastanawiac) i owiedzialbym ze jest raczej ok
- co do nazewnictwa to takie 'krotkie' konwencje nazewnicze maja w sobie
cos fajnie technicznego, algebraicznego (sklaniaja by patrzec na ten kod
bardziej jak na wzory czy rownania) ale obecny trend (do ktorego sam niejako
tez zostalem przekonany - choc nie wiem czy sie kiedys nie zbuntuje albo
co by poprobowac pisania 'krotkimi' nazwami) z tego co wiem sklania sie
raczej po temu by uzywac dlugich nazw (wogole nie uzywac skrotow itp) czyli
nie 'newH = height' tylko 'newHeight = height' - taki kod czyta sie bardziej
jak tekst a nie jak wzory
Z poczatku zauwazylem rozbicie ifow ktore mozna by skompensowac, teraz jak
patrze to widze ze moze warto by chodzic w dokladnie odwrotna strone tj
porozdzielac je by staly sie bardziej 'wyrazalne'; jak mi przejdzie ten lekki
bol glowy to moze pozniej pomysle chwile nad lekko poprawiona wersja i zapostuje



--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

Dnia 04-08-2011 o 23:40:37 <g...@h...com> napisał(a):

> Witam,
>
> Czy taka konstrukcja narusza jakieś zasady/sty dobrego projektowania lub
> jeszcze innego wzorca projektowego? Chodzi mi o drabinkę if..else

Jeśli zaprzeczylibyśm sensowności tego rozwiązania, to na dobrą sprawę
należałoby odrzucić również konstrukcję switch/case, która przecież
spełnia praktycznie tą samą rolę. Różnica jest taka, że drabinka if..else
pozwala uwzględnić kilka różnych warunków (a także - na przykład -
odrzucić warunki, które w danym momencie są zbędne), gdy switch z czymś
takim sobie nie radzi.

Poza tym - jaką alternatywę zaproponowałbyś dla takiej drabinki? Wyciąć
else nie możesz, bo często ma ono kluczowe znaczenie. Co najwyżej możesz
każdy warunek pakować do kolejnego bloku w else, tzn.

if (war1)
{

}
else if (war2)
{

}
else S;

na

if (war1)
{

}
else
{
if (war2)
{

}
else S;
}

Wydaje mi się jednak, że na dłuższą metę drugie rozwiązanie jest znacznie
mniej czytelne - szczególnie, gdy warunków masz dużo.

Pozdrawiam -- Spook.

--
Używam klienta poczty Opera Mail: http://www.opera.com/mail/

do góry

W dniu 2011-08-05 10:25, g...@p...onet.pl pisze:
> - co do nazewnictwa to takie 'krotkie' konwencje nazewnicze maja w sobie
> cos fajnie technicznego, algebraicznego (sklaniaja by patrzec na ten kod
> bardziej jak na wzory czy rownania) ale obecny trend (do ktorego sam niejako
> tez zostalem przekonany - choc nie wiem czy sie kiedys nie zbuntuje albo
> co by poprobowac pisania 'krotkimi' nazwami) z tego co wiem sklania sie
> raczej po temu by uzywac dlugich nazw (wogole nie uzywac skrotow itp) czyli
> nie 'newH = height' tylko 'newHeight = height' - taki kod czyta sie bardziej
> jak tekst a nie jak wzory

Zdaje mi się, że te zalecenia projektowe dotyczą raczej nazewnictwa
metod/funkcji/parametrów itd, a nie ciała funkcji. W tym przypadku IMHO
x, y, w, h, nx, ny, nw, nh są tak samo dobre (bo to chyba nie żaden
tutorial?)

artur

do góry

> W dniu 2011-08-05 10:25, g...@p...onet.pl pisze:

> > - co do nazewnictwa to takie 'krotkie' konwencje nazewnicze maja w sobie

> > cos fajnie technicznego, algebraicznego (sklaniaja by patrzec na ten kod

> > bardziej jak na wzory czy rownania) ale obecny trend (do ktorego sam niejako

> > tez zostalem przekonany - choc nie wiem czy sie kiedys nie zbuntuje albo

> > co by poprobowac pisania 'krotkimi' nazwami) z tego co wiem sklania sie

> > raczej po temu by uzywac dlugich nazw (wogole nie uzywac skrotow itp) czyli

> > nie 'newH = height' tylko 'newHeight = height' - taki kod czyta sie bardziej

> > jak tekst a nie jak wzory

>

> Zdaje mi się, że te zalecenia projektowe dotyczą raczej nazewnictwa

> metod/funkcji/parametrów itd, a nie ciała funkcji. W tym przypadku IMHO

> x, y, w, h, nx, ny, nw, nh są tak samo dobre (bo to chyba nie żaden

> tutorial?)

>

nie wiem jak ogolnie zalecenia, ale jesli o mnie chodzi to ta uwaga
'by nie uzywac skrotow' (bo zwykle skracac mozna na wiele sposobow i robi
sie to trudne do spamietania) dotyczy raczej wszelkich nazw

ja albo uzywam dlugich nazw (wiekszosc - od jedno do nawet kilkuwyrazowych)
albo bardzo krotkich podrecznych zwykle jednoliterowych jak i,j na
'bardzo ulotne' zmienne lokalne

tj takie nazewnictwo mi sie obecnie wyszkolilo i uzywam go gdy pisze cos
staranniej bo zwykle jak jestem w jakims trybie kreacyjnym to robie 'ciezki
balagan' zreszta te nazewnictwo tez nie tak zupelnie do konca jeszcze mi sie
wyksztalcilo


> artur

>



--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

A ja spytam o coś podobnego. Bardziej Wam się zdarza pisać A czy B?

A:
foo()
{
if (warunek)
{
...
}
}

B:
foo()
{
if(!warunek)
return;

...
}

Powiem szczerze, że mnie tak naturalnie przychodzi zawsze A, jednakże
tych warunków czasami może być więcej i wtedy wygląda to np. tak.

if (warunek1 && warunek2 && warunek3)
{
if(warunek4 && warunek5)
{
...
}
}

Dwa ify z tego powodu, że warunki odnoszą się do innej "logiki".

--
Mateusz Bogusz

do góry

> Powiem szczerze, że mnie tak naturalnie przychodzi zawsze A, jednakże
> tych warunków czasami może być więcej i wtedy wygląda to np. tak.
W malym kodzie, w malej procedurze, to jest wszystko jedno. Problem jest
gdy procedura sie rozrasta. Gdy mam kod ktory:
1) moze wykonywac sie rownolegle na wielu watkach,
2) do systemu zalogowanych jest jednoczesnie kilku uzytkownikow
3) zdarza sie uzytkownik ktorzy wysle specjalnie zlosliwe dane
4) uzytkownicy pracuja na wspolnych danych
5) wazna jest wydajnosc
to procedura z testujacymi if-ami czasami ma 2tys linii kodu.
Jesli jeden if zaczyna sie na poczatku procedury i konczy gdzies
przy jej koncu to dla mnie jest totalne bagno.
Dlatego wlasnie zawsze daze do takiego wygladu procedury:

// Bogaty komentarz_1
if( warunek_1 ) {
return kod_bledu_1; // albo wyjatek zamiast return
}
// Bogaty komentarz_2
if( warunek_2 ) {
return kod_bledu_2; // albo wyjatek zamiast return
}

Pozdrawiam


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

On Sat, 06 Aug 2011 18:34:25 +0200, m...@t...pl wrote:

>
>> Powiem szczerze, że mnie tak naturalnie przychodzi zawsze A, jednakże
>> tych warunków czasami może być więcej i wtedy wygląda to np. tak.
>W malym kodzie, w malej procedurze, to jest wszystko jedno. Problem jest
>gdy procedura sie rozrasta. Gdy mam kod ktory:
>1) moze wykonywac sie rownolegle na wielu watkach,
>2) do systemu zalogowanych jest jednoczesnie kilku uzytkownikow
>3) zdarza sie uzytkownik ktorzy wysle specjalnie zlosliwe dane
>4) uzytkownicy pracuja na wspolnych danych
>5) wazna jest wydajnosc

A co ma wielowatkowosc do rzeczy? I co ma wydajnosc do rzeczy? I co ma
"zlosliwosc uzytkownika" do rzeczy?...

>to procedura z testujacymi if-ami czasami ma 2tys linii kodu.
>Jesli jeden if zaczyna sie na poczatku procedury i konczy gdzies
>przy jej koncu to dla mnie jest totalne bagno.
>Dlatego wlasnie zawsze daze do takiego wygladu procedury:
>
>// Bogaty komentarz_1
>if( warunek_1 ) {
> return kod_bledu_1; // albo wyjatek zamiast return
>}
>// Bogaty komentarz_2
>if( warunek_2 ) {
> return kod_bledu_2; // albo wyjatek zamiast return
>}
>

Pzrepraszam, ale to nonsens. Oryginalny Poster nic nie mowli o "kodach
bledu"

A.L.

do góry

> A co ma wielowatkowosc do rzeczy? I co ma wydajnosc do rzeczy? I co ma
> "zlosliwosc uzytkownika" do rzeczy?...
Kod programu z wymienionymi przeze mnie cechami jest bardziej
skomplikowany. Takie drobiazgi jak estetyka kodu w prostym
programie sie nie licza, natomiast w duzym i skomplikowanym moga miec
kluczowe znaczenie.

> Pzrepraszam, ale to nonsens. Oryginalny Poster nic nie mowli o "kodach
> bledu"
A czy ja gdzies pisalem ze Oryginalny Poster cos mowil o kodach bledow?
Padlo pytanie na temat:

if(!warunek)
return;
kod();

VS

if( warunek ) {
kod();
}

W malej procedurze nie ma najmniejszego znaczenia jaki styl wybierzemy.
W duzej, jesli klamra otwiera sie w linii nr. 100, a zamyka w linii nr
1000 kod staje sie bardzo nieczytelny. Dlatego odmiana z return jest
duzo lepsza. Nie ma tu zadnego nonsensu.
Pozdrawiam


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry