Witam,
Jaka jest różnica pomiędzy kodem:
if(warunek) instrukcja;
```
a
if(warunek)
{
instrukcja;
}
```
Fajnie jakby ktoś wytłumaczył.
C# 
- Rejestracja:prawie 20 lat
- Ostatnio:około 24 godziny
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).
edytowany 1x, ostatnio: Wibowit
- Rejestracja:prawie 15 lat
- Ostatnio:około 6 lat
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?
edytowany 2x, ostatnio: Paul87
- Rejestracja:prawie 15 lat
- Ostatnio:prawie 6 lat
- Postów:162
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? :)
Wibowit
A to są jakieś sztywne terminologie?
piternet
szpiczaste, a już tym bardziej wąsate brzmi naprawdę śmiesznie :)
Wibowit
akurat to mam centralnie w odbycie, ważne że ludzie rozumieją o co chodzi. ATSD spiczaste to bardziej pasują do ostrych nawiasów, a nie wąsatych.
- Rejestracja:ponad 21 lat
- Ostatnio:około 8 godzin
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ą.
edytowany 2x, ostatnio: Azarien
- Rejestracja:około 21 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Space: the final frontier
- Postów:26433
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.
- Rejestracja:około 17 lat
- Ostatnio:około godziny
- Lokalizacja:Wrocław
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.
edytowany 1x, ostatnio: somekind
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.
- Rejestracja:około 17 lat
- Ostatnio:około godziny
- Lokalizacja:Wrocław
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.
- Rejestracja:ponad 18 lat
- Ostatnio:ponad 13 lat
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.
edytowany 1x, ostatnio: Kisiol
- Rejestracja:ponad 14 lat
- Ostatnio:ponad 11 lat
3
2 strony o if'ie, wy nie macie co robić?:P
+1 :D
Nie o ifie, bo jeszcze musiałem wyjaśnić niektórym, dlaczego z try-catch-finally nie można wyrzucić klamerek, jak z if-else, a potem Wibowit musiał napisać, że Scala jest najlepsza.
idźmy dalej - dlaczego wszystkie definicje funkcji muszą być w klamrach ;)
Nie muszą, w Pascalu przecież nie są. ;)
Bo w tamtych czasach to na klawiaturze nie było nawiasów klamrowych :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 :]