Diskuze: konzole cheaty
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.

Tvůrce

Zobrazeno 29 zpráv z 29.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
Bodejď by ne" Nemáš to v
závorce... A ty co tam máš, jsou zbytečné...
if (jmeno_1 == "high five" || jmeno_1 == "suit up" || jmeno_1 == "legendary")
Ale tyhle prasárny nedělej! Použij switch:
switch (jmeno_1)
{
case "high five":
//sem přidej příkazy
break;
case "suit up":
//sem přidej příkazy
break;
case "legendary":
//sem přidej příkazy
break;
}
jo díky nenapadlo mě to, ještě jsem o podmínkách skoro nic nečetl
Vnitřní závorky jsou sice zbytečné, ale často je lepší je tam mít kvůli přehlednosti. Programátor si nemusí vždy přesně vybavit třeba rozdíl priorit mezi '|' a '||'.
JJ - pročti si větvení programu a v něm switch. A zde se hodí přímo ukázkově...
Ale zde není žádná priotita - zde je to v jedné lajně... Navíc zde se ukázkovně hodí switch...
Uvedený switch je výhodný, pokud každé slovo má vyvolat jinou akci. Pokud mají všechna dělat totéž, tak to bude vypadat mnohem lépe a jednodušeji:
switch (jmeno_1){
case "high five":
case "suit up":
case "legendary":
//sem přidej příkazy
break;
}
Pokud však každé slovo má vyvolat jinou akci, což z původního dotazu
není patrné, bude lepší tvůj switch
.
Každé rozhodování by se mělo dělat pouze 1×. Podmínky typu "nejprve se podívám, jestli je to některé ze slov a pak je teprve rozliším" by se dělat neměly.
To je přeci jasné - svůj switch bych nepoužil, kdyby se měl vykonávat jeden blok příkazů, to by pak byla výhodnější podmínka hoře...
Ale zde je to použito rovnoměrně. není zde třeba toto:
if (Y == 7 && ((X > 5 && X < 10) || (X == 25)))
Je tam jen jednoduchý výčet možností - proto se zde hodí switch - není-li to myšleno pro jeden blok příkazů...
doufal jsem že to bude dost jasné když se vybírá z podmínek který maj stejný účinek, proto mi přišlo zbytečný použít
if
else if
else if
else
ale nepochopil jsem jestli je teda lepší switch nebo if ( pod1 || pod2) ?(pod_no = podmínka)
Pokud by se měl vykonávat jeden blok příkazů, byl by výhodnější můj
switch
než kombinovaná podmínka nahoře.
Pokud to máš takto = tvoje podmínka a pod ní jen jeden blok příkazů, tak bych to nechal u podmínky...
A to je právě to zmatení. Proč máš 3 různé výrazy, které mají jeden účinek?
... a já bych to dal do switch
kvůli přehlednosti a snadné
rozšiřitelnosti. Co programátor, to názor. Oba přístupy jsou
správné.
chtěl jsem udělat víc možností pro cheat v tomto případě se jedná o hlášky Neila Patricka Harrise v seriálu HIMYM a má to ten účinek že se v aréně zobrazí textový obázek obleku, který je Neila hlavní charakteristika v tom seriálu
Nechápu, co na tom nechápeš.
Jeli na vstupu Mánička, nebo Anička, nebo Maruška, tak pohlaví =
ženské;
Jinak pohlaví = mužské;
V čem je switch
lepší?
možná je lepší, ale je zbytečný na jednorázovej příkaz při zadání jména, v takovém případě mi opravdu přijde ten if (...) jednodušší
Já switch nemám rád, o hodně lepší mi přijde:
string[] moznosti = {'suit up', 'high five', 'legendary', ...};
if (moznosti.contains(vyber))
...
Nerozumím pojmu "zbytečný". Jako kanón na vrabce? To je. Ale také je to
efektivní nástroj. Pokud jmeno_1
není jen jednoduchá
proměnná, ale je to třeba položka pole nebo výsledek volání funkce, beru
použití switche jako nezbytné. A to je hodně často.
Už označení proměnné jmeno_1
mi říká, že vznikla
nejspíš takto:
jmeno_1=jmeno[1];
Použitím switch
je tato pomocná proměnná zbytečná.
To je také dobré řešení, které bude výhodné zejména v kompilovaných jazycích. V interpretovaných už méně. Pokud by těch možností mělo být víc nebo by se měly průběžně měnit, bude výhodné použití nějaké databáze.
tohle mě ani nenapadlo, a je to vážně dobrý řešení, aspoň nemusim kopírovat podmínku pro jména obou hráčů
V interpretech mi to přijde také fajn, používám to velmi často v PHP, tam se dají s poli dělat psí kusy a velmi mi tento způsob programování vyhovuje.
Zobrazeno 29 zpráv z 29.