The name 'createDirectory' does not exist in the current context

Cześć.
Mam problem z sam w sumie nie wiem czym. Oto kod metody:

private void button3_Click(object sender, EventArgs e)
        {
            var savePath = textBox1.Text;
            if (checkBox1.Checked){
                var createDirectory = 1;
            } else {
                var createDirectory = 0;
            }
            var appDataFolder = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
            MessageBox.Show(createDirectory);
        }

Jak widzicie zmienna createDirectory jest deklarowana trochę wyżej, w tej samej metodzie. Dodatkowo co ciekawe oprócz błędu z tematu dostaję również ostrzeżenie że zmienna ta nie jest nigdzie używana. Mógłby mi ktoś wyjaśnić czemu dostaję taki błąd jak i jak go wyeliminować?

Deklarowana jest w bloku if, albo else. Po wyjściu z tego bloku już nie istnieje.

Bo deklarujesz ją w ifie. Zakres tej zmiennej kończy się zaraz po przypisaniu. Poza tym deklarujesz tutaj nie jedną, a dwie o tej samej nazwie.

Powinieneś to zrobić mniej więcej tak:

private void button3_Click(object sender, EventArgs e)
        {
            var savePath = textBox1.Text;
            var createDirectory = 0;
            if (checkBox1.Checked){
                createDirectory = 1;
            }
            var appDataFolder = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
            MessageBox.Show(createDirectory);
       }

lub

var createDirectory = checkbox1.Checked ? 1 : 0;

Ok, w takim razie, jak rozumiem mam ją zadeklarować przed blokiem a w ifie tylko przypisać do niej wartość?
A z tego co wiem (nacodzień jestem programistą php i python'a) Chyba nie ma możliwości aby w tym samym czasie zmienna pasowała do if i elsa.
BTW Bo nie mogę tego zrozumieć. Po co kompilator unsetuje zmienne które są w ifach?

Co robi?

some_ONE napisał(a):

Co robi?

unset to pehapowa funkcja do zwalniania pamięci tj. usuwania zmiennych.

Zmienna nie jest unsetowana. Kończy się jej zakres. Z nadrzędnego zakresu nie możesz zobaczyć zmiennych zadeklarowanych w wewnętrznych. Kropka. Kiedy pamięć będzie zwolniona, to jedynie GC (Garbage Collector) wie ;)

Sarrus napisał(a):

Zmienna nie jest unsetowana. Kończy się jej zakres. Z nadrzędnego zakresu nie możesz zobaczyć zmiennych zadeklarowanych w wewnętrznych. Kropka. Kiedy pamięć będzie zwolniona, to jedynie GC (Garbage Collector) wie ;)

Ok, rozumiem. Ale nie pojmuję po co? Mógłbyś podać jakiś przykład w którym się to przydaje?

@NickOver zadaj konkretne pytanie to dostaniesz konkretna odpowiedz
co po co ma sie robic?
co sie na co przydaje?

NickOver napisał(a):

Ok, rozumiem. Ale nie pojmuję po co? Mógłbyś podać jakiś przykład w którym się to przydaje?

Normalne języki mają coś takiego jak zakres widoczności zmiennej. To się przydaje, żeby nie mieć burdelu w kodzie i globalnego kontekstu zaśmieconego tysiącami niepotrzebnych zmiennych.
Nie uwierzę, że PHP jest taż tak upośledzony, że tego nie ma.

fasadin napisał(a):

@NickOver zadaj konkretne pytanie to dostaniesz konkretna odpowiedz
co po co ma sie robic?
co sie na co przydaje?

Chodziło mi po co zakres zmiennej przy ifie, patrząc na to że jest on w metodzie.

somekind napisał(a):

NickOver napisał(a):

Ok, rozumiem. Ale nie pojmuję po co? Mógłbyś podać jakiś przykład w którym się to przydaje?

Normalne języki mają coś takiego jak zakres widoczności zmiennej. To się przydaje, żeby nie mieć burdelu w kodzie i globalnego kontekstu zaśmieconego tysiącami niepotrzebnych zmiennych.
Nie uwierzę, że PHP jest taż tak upośledzony, że tego nie ma.

Ma. Jeśli stworzę zmienną która nie będzie polem klasy w metodzie "A" to nigdzie indziej nie będzie ona dostępna. Ale zakres zmiennych przy np. ifie już jest trochę bez sensu. Bo większy burdel w kodzie zrobi deklarowanie zmiennej, potem na podstawie ifa przypisywanie wartości a następnie sprawdzanie czy wartość zmiennej jest taka jaką była bez przypisywania w ifie.
BTW Nie piszę że c# jest zjebany i w ogóle głupi, więc proszę też tak nie rób :)

Zakres zmiennych powoduje porzadek w funkcjach (nie mozesz odwolac sie do "niestworzonej" zmiennej)
Do tego kompilator moze lepiej optymalizowac kod wynikowy

Moim zdaniem problem lezy gdzie indziej. Nie, dlaczego jest lokalny zasieg zmiennych tylko "Czy rozumiem OOP".

Poczytaj wiecej o programowaniu obiektowym

a Ty zapewne mylisz pojecia i robiles wszedzie zmienne globalne. Co jest dosc duzym bledem jezeli nie wie co sie robi.

Zgodzę się z Tobą że zakres zmiennych generuje porządek w funkcjach czy metodach. Wychodzę również z założenia że metody powinny być krótkie. Dlatego nie widzę sensu w zasięgu zmiennej ograniczonej do ifa. Ale widzę że wszcząłem niepotrzebną dyskusję. Przepraszam i proszę o zamknięcie tematu.
A zmiennych globalnych nie używałem chyba nigdy. Po prostu w języku w którym pisze na codzień zasięg jest ograniczony przez metody lub funkcję. Stąd było też moje pytanie ponieważ nie rozumiałem idei zasięgu tylko na ifa.

Nie zastanawiałem się dlaczego tak jest. Dla mnie jest oczywistym fakt, że nie możesz deklarować, ani tym bardziej definiować zmiennych w podrzędnych zakresach i używać w nadrzędnych.
W PHP jest inaczej, ale to zapewne dlatego, że tam nie deklarujesz zmiennych, tylko od razu definiujesz. Poza tym typy są dynamiczne, więc nie za bardzo miałbyś co zadeklarować przed ifem, który przypisuje int, a w else string, a w kolejnym else obiekt.

Źle zadajesz pytanie. Nie powinieneś pytać dlaczego tak jest w C#, tylko dlaczego tak nie jest w PHP. Na to pytanie jest prosta odpowiedź - bo się inaczej nie da :P

Napisze sprostowanie dlaczego powinienes poczytac o OOP
To co w php masz robione, to jest dynamiczne typowanie danych. Tutaj (w C#) masz mocne typowanie danych. Jezeli robisz cos takiego (tu na zasadzie pythona, powinno w php dzialac podobnie)

if costam == true:
    zmienna1 = "zaraz nie bede istniec"
    this.zmienna2 = "a ja bede istniec bo teraz naleze do danego kontekstu (zapewne klasy)"
else
    zmienna1 = "hej, jestem nowa zmienna1"
    this.zmienna2 = "ja tez jestem nowa jezeli zostlao to wywolane po raz pierwszy (czyli od razu do else)"
zmienna1 = "znowu jestem nowa!"
this.zmienna2 = "jestem jedna z zadeklarowanych poprzednio zmiennych"

czyli jak widzisz, poprzez this dodaje do klasy (danego kontekstu). Jezeli tego nie zrobie, to zmienna ma zasieg lokalny i zaraz za blokiem danych bedzie usunieta (zaznaczona do usuniecia). To samo na 99% jest robione w php
Dlaczego OOP? Bo wlasnie to sie dzieje na dobra sprawe. A zeby nie miec balaganu w kodzie, to warto znac lepiej OOP zeby napisac dobrze zbudowana klase.

C# jak jezykiem silnie typowanym. Czyli nie moze deklarowac zmiennych w locie (tak jak robi to php czy python), ale dzieki temu jest szybszy, bo kompilator moze zaoptymalizowac kod zanim zostanie uruchomiony (bo wie wszystko o typach oraz gdzie beda uzyte te zmienne[sa wyjatki, ale to nie o tym])

slabe typowanie daja dwie mozliwosci

• do zmiennej mozesz wpisac co chcesz (tutaj za pomoca przychodzi dynamic z c#)
• mozesz odwolac sie do zmiennej. Jezeli jej nie bedzie to Ci po prostu skrypt sie wywali w kosmos. (C# na to nie pozwala i dlatego Ci nie pozwala sie skompilowac)

NickOver napisał(a):

Ale zakres zmiennych przy np. ifie już jest trochę bez sensu. Bo większy burdel w kodzie zrobi deklarowanie zmiennej, potem na podstawie ifa przypisywanie wartości a następnie sprawdzanie czy wartość zmiennej jest taka jaką była bez przypisywania w ifie.

Nie jest bez sensu, bo dzięki temu możesz sobie wewnątrz bloku if zadeklarować zmienną tymczasową i ją użyć bez zaśmiecania scopu całej metody.

W Twoim konkretnym przypadku wystarczyłoby to zrobić w ogóle bez else:

var createDirectory = 0;
if (checkBox1.Checked){
    createDirectory = 1;
} 

a nawet bez if:

var createDirectory = checkBox1.Checked ? 1 : 0;

No, a tak ogólnie to przepisywanie wartości logicznej na liczbę dziwnie wygląda. W jakim celu to robisz?

BTW Nie piszę że c# jest zjebany i w ogóle głupi, więc proszę też tak nie rób :)

Ok, obiecuję, że nie będę tak pisał o C#.