Witam,
Jaka jest różnica pomiędzy kodem:
if(warunek) instrukcja;
```
a
if(warunek)
{
instrukcja;
}
```
Fajnie jakby ktoś wytłumaczył.
0
0
Zastanów się, której wersji użyjesz, gdy będziesz chciał wykonać wiele instrukcji w zależności od spełnienia danego warunku?
0
W drugim możesz mieć więcej instrukcji niż jedną. Nawiasy wąsate określają zasięg zmiennych, jak zawsze. Poza tym różnic żadnych. Gdybyś zmienił wszystkie wystąpienia pierwszej konstrukcji na wzór drugiej to kod wynikowy powinien być identyczny (modulo informacje dla debuggera czyli numery linii w kodzie dla poszczególnych instrukcji oczywiście).
0
Dzięki za odpowiedź, jednak wasza odpowiedź mnie nie zadowala(zadowala w połowie). Może podam bardziej konkretny przykład.... Mam taki fragment:
if ((e.KeyChar < 48 | e.KeyChar > 57) && e.KeyChar != 8 && e.KeyChar != 13)
{
e.Handled = true;
}
if (e.KeyChar == 13)
{
applySize(txt.Text);
this.richTextBox.Focus();
}
i taki:
<code class="c#">
if ((e.KeyChar < 48 | e.KeyChar > 57) && e.KeyChar != 8 && e.KeyChar != 13)
e.Handled = true;
if (e.KeyChar == 13)
applySize(txt.Text);
this.richTextBox.Focus();
Jest to fragment kodu który zmienia rozmiar czcionki w richBoxie. W drugim kodzie usunąłem tylko nawiasy szpiczaste, jednak zachowanie programu diametralnie się zmienia. Oczywiście pierwszy kod działa tak jak powinien. Moje pytanie: dlaczego tak się dzieje? Czy faktycznie chodzi o ilość instrukcji?
1
wasza odpowiedź mnie nie zadowala.
Inaczej mówiąc: masz problemy z czytaniem ze zrozumieniem naprawdę prostych rzeczy.
1
Wcięcia w kodzie nic w C# nie znaczą (dla kompilatora oczywiście). Tak samo jak w C, C++, Javie, itp itd
1
Mały offtop, bo chyba w tym temacie to i tak nic więcej do dodania nie ma.
Wibowit napisał(a)
Nawiasy wąsate
Paul87 napisał(a)
W drugim kodzie usunąłem tylko nawiasy szpiczaste
Czy nie można powiedzieć po prostu nawiasy klamrowe? :)
0
To oczywiście wiem, ja jednak nie pytam o wcięcia, tylko o klamry.
2
jeśli Ci działa coś nie tak, to może przeinstaluj kompilator i inne rzeczy począwszy od windowsa. przynajmniej będziesz miał jakieś bardziej odpowiednie dla Ciebie zajęcie niż programowanie.
1
if(a) b; c; wykonuje najpierw "b" jeśli zachodzi warunek "a", a potem wykonuje "c". Proste i logiczne, podstawy na poziomie żłobka.
0
Albo prościej...
jak wykonujesz tylko jedną instrukcje dla warunku to wtedy if() a jak więcej linii to już if(){} :)
proste jak budowa całka :P
0
Aha czyli c; jest wykonywane nawet bez warunku. Teraz rozumiem! Wibowit, dzięki za odpowiedź!
0
a wiecie, że w C# można zrobić
try
{
Console.WriteLine("ala ma kota");
}
finally
{
Console.WriteLine("ala ma psa");
}
(co jest oczywiste), ale nie można zrobić
try
Console.WriteLine("ala ma kota");
finally
Console.WriteLine("ala ma psa");
?
w porównaniu z if, while czy for to nielogiczna niekonsekwencja.
EDIT: wygląda na to, że zasadą jest: jeśli instrukcja przyjmuje coś w nawiasach okrągłych (np. warunek) to można pominąć klamry.
Tak jest przynajmniej z if, while, for i fixed.
Natomiast try, finally, checked, unchecked, get, set, add, remove nie przyjmują żadnych nawiasów (), i wymagają zawsze {} nawet dla jednej instrukcji.
Wyjątkiem jest catch, w którym nawiasy () są opcjonalne. Klamer wymaga nawet gdy nawiasy występują.
0
To dość ciekawe bo to by oznaczalo ze na poziomie gramatyki języka instrukcja po try i po finally jest traktowana inaczej niż jakakolwiek inna instrukcja.
0
To teraz zastanówmy się, co miałby oznaczać taki zapis:
try
abc();
try
def();
catch (SthException ex)
ghi();
catch (OtherException ex)
jkl();
finally
mno();
Opcja 1:
try
{
abc();
try
{
def();
}
catch (SthException ex)
{
ghi();
}
}
catch (OtherException ex)
{
jkl();
}
finally
{
mno();
}
Opcja 2:
try
{
abc();
try
{
def();
}
catch (SthException ex)
{
ghi();
}
catch (OtherException ex)
{
jkl();
}
}
finally
{
mno();
}
No nie, że zamotane?
Przy for czy while jest jeden blok, a przy if góra dwa, więc nie ma aż takich problemów. Chociaż brak klamerek przy if też może zaciemniać kod, prawie zawsze lepiej ich używać.
Wydaje mi się, że opcjonalne klamerki zrobili dlatego, że ludzie są do nich przyzwyczajeni jeszcze z czasów C.
0
IMO najlepiej byłoby gdyby klamry zniknęły całkowicie ze składni c-podobnych języków a zastąpić je tabulatorami i odpowiednimi wcięciami. Zaoszczędziło by to problemów tego typu że niektórzy piszą np. tak
if (cos==ktos) bar;
lub tak
if (cos==ktos) {bar;}
lub tak
if (cos==ktos) {
bar;
}
lub tak
if (cos==ktos)
{
bar;
}
a później jeśli pracuje się z kodem kogoś innego trzeba stosować "klamrowanie" w poprzednim stylu i się do niego przyzwyczajać lub przekonwertować na swoje.
O ile lepiej było by gdyby to wyglądało tak:
if (cos==ktos)
foo
bar
else
foobar
można by zrezygnować ze średników na końcach instrukcji pojedynczo umieszczonych oraz z nawiasów zunifikować stosowanie wcięć które każdy przyzwoity programista i tak stosuje.
0
nobody napisał(a)
IMO najlepiej byłoby gdyby klamry zniknęły całkowicie ze składni c-podobnych języków a zastąpić je tabulatorami i odpowiednimi wcięciami. (...)
można by zrezygnować ze średników na końcach instrukcji pojedynczo umieszczonych oraz z nawiasów zunifikować stosowanie wcięć które każdy przyzwoity programista i tak stosuje.
Wtedy nie byłyby to już c-podobne języki.
0
Można by zapisywać kod jako AST, a nie jako czysty tekst i wtedy formatowanie byłoby w kwestii IDE :]
0
if (warunek)
instrukcja1;
instrukcja2;
Po ifie jezeli warunek zostanie spelniony zostanie wykonana tylko jedna instrukcja. Instrukcja2 wykona sie zawsze niezalenie od warunku.
jezeli chcesz wykonac kilka instrukcji to musisz użyć klamer { }
{ } - klamry oznaczają BLOK instrukcji.
if (warunek) { }
i w te klamry mozesz wrzucic ile tlyko chcesz instrukcji.
3
2 strony o if'ie, wy nie macie co robić?:P
0
Wibowit napisał(a)
Można by zapisywać kod jako AST, a nie jako czysty tekst i wtedy formatowanie byłoby w kwestii IDE :]