Blog infomatyka z pasją poświęcony językom komputerowym

@jarekr000000: w kodzie, w którym podałeś jest forEach, więc nie mów, że nie ma pętli. Podobnie są też drabinki ifów, np. https://github.com/javaFunAgain/lagomPong/blob/master/game-api/src/main/java/pl/setblack/pongi/game/impl/Ball.java#L44 (jeszcze przynajmniej jedno coś podobnego znalazłem). Nie żebym się czepiał, ale sam rzuciłeś wyzwanie, żeby przejrzeć repo.

to zmienne globalne powodują, że one nie są tworzone kolejny raz przy wywołaniu funkcji

No to tak.

1. Przecież nic nie cachujesz. Spojrzysz do tego kodu. Za każdym razem przy wywołaniu funkcji tworzysz obiekty:

function SzerokoscMenu()
{	
	nawigacja=document.getElementById("nawigacja");
	listaMenu=document.getElementsByClassName("menuLink");
	menu=document.getElementById("listaMenu");
	szerokoscNawigacji=nawigacja.clientWidth;

To, że napiszesz sobie var przed funkcją ma takie znaczenie mniej więcej, jak to, że upadła ci jednogroszówka na podłogę jak płaciłeś za kawior w restauracji.

1. jeśli faktycznie chcesz zrobić to co mówisz, to poczytaj o IIFE. I o domknięciach (closures):

var abcdef = (function () {
    var zmiennaKtoraBylaGlobalna = document.getElementById('costam');
    return function abcdef() {
     console.log(zmiennaKtoraBylaGlobalna);
    }
})();

tym sposobem unikniesz zmiennych globalnych (co prawda nie jestem purystą, w pewnych ograniczonych sytuacjach uważam, że można je stosować, ale wtedy gdzie faktycznie dzięki temu można osiągnąć jakiś zysk, np. ułatwioną komunikację między różnymi częściami programu przez wystawienie jakiegoś obiektu globalnego. No ale jak zmienna globalna jest tylko fanaberią, wypadkiem przy pracy, to w sumie po co?).

. A listaMenu[i].style jest tylko w for. Jeśli za każdą iteracją miałbym przypisać ją do zmiennej, to bardziej spowolniłoby JS

No nie. JS jest szybkie, komputery są szybkie, dzisiaj takie mikrooptymalizacje zwykle nie mają znaczenia. A JS spowalnia zwykle dostęp do DOM, który robisz i tak, i tak, chociaż cachując przynajmniej style być może nawet zwiększyłbyś szybkość o tyle, żebyś nie musiał pobierać właściwości style z obiektu 3 razy co być może przyśpieszyło by program.

Piszę być może, bo to nie jest sednem - żeby naprawdę sprawdzić czy coś szybciej czy wolniej działa trzeba to sprawdzić praktycznie mierząc czas wykonania (ręcznie, albo patrząc w profilerze, np. tym z Chrome Dev Tools) - natomiast chodziło mi o to, że taki zapis byłby po prostu czytelniejszy.

@LukeJL: Wczoraj grzebiąc w sieci, znalazłem artykuł o symulacji statycznych zmiennych w Javascript - jeszcze bardziej się sprawdza niż domknięcia

Nie rozumiem. Czy na pewno chodzi o symulację statycznych zmiennych? A nie o prywatnych?

Bo tworzenie statycznych zmiennych to kompletnie nieistniejący problem w JS, więc nie trzeba ich nawet symulować, tylko należy utworzyć zmienną, która będzie statyczna (rozumiem, że masz na myśli statyczność w sensie zmiennych widocznych w metodach obiektów, które jednak będą istniały niezależnie od tworzonych obiektów? No to po prostu trzeba utworzyć jakąś zmienną poza obiektem i już).

Również w JS można bez problemu tworzyć prywatne zmienne (chociażby w domknięciach). To czego nie ma to prywatne właściwości obiektów (i to faktycznie można symulować w różny sposób).

jeśli faktycznie chcesz zrobić to co mówisz, to poczytaj o IIFE. I o domknięciach (closures):

dodałbym do swojej wypowiedzi jeszcze to, że teraz się stosuje zwykle moduły (CommonJS albo moduły z ES6) i IIFE często nie jest nawet potrzebne, żeby się pozbyć zmiennych globalnych (bo zmienne zadeklarowane w module X są widoczne tylko do tego pliku, chyba że moduł sam je wyeksportuje).

Z drugiej strony IIFE jest prostą metodą, którą można zastosować zawsze (a do modułów w przeglądarce potrzebne jest obecnie budowanie przez Webpacka czy Browserify).

Widze, że wątek strasznie urósł.

Goto bardzo w C się przydaje. Negatywne komentarze, jakoby to wyglądało jak lata 90 etc. można zignorować. jak ktos wierzy w rzeczy totalne w stylu globalne są zawsze złe, czy brednie z czystego kodu żeby nie komentować nic najlepiej. To należy go pozostawić w jego świecie.

Zasadniczo jednak strona internetowa jest bardzo niewygodna w korzystaniu, brak czegoś w rodzaju spisu treści, jest mało przyjazna dla oka i nieprzejrzysta.. Zbytnie skupianie się na podstawach. Wypadałoby by zacząć bardziej oryginalnie. Albo wręcz napisać coś niepopularnego wtedy taki tekst jest interesujący.

Nie powinieneś też bronić się w sposób, że "ale patrzcie tu jest w książce tak". Musisz wiedzieć i mieć swoje zdanie. Ksiązką możesz się podeprzeć ale nie bronić.

Osoba która zaczyna zawsze ma problem z pomysłem na program. Jezeli jesteś w stanie wymyslić oryginalne pomysły przy okazji dostarczyć wiedzę potrzebną do napisania programu. To już wygrałeś, reszta może być nawet z błedam etc, [ok drobnymi błędami ;]

jak ktos wierzy w rzeczy totalne w stylu globalne są zawsze złe, czy brednie z czystego kodu żeby nie komentować nic najlepiej

Oh dear.

Albo wręcz napisać coś niepopularnego wtedy taki tekst jest interesujący.

Nooooo na przykład to, że goto ma jakieś sensowne uzasadnienie w kodzie? ;-D

wujnia napisał(a):

Goto bardzo w C się przydaje. Negatywne komentarze, jakoby to wyglądało jak lata 90 etc. można zignorować. jak ktos wierzy w rzeczy totalne w stylu globalne są zawsze złe, czy brednie z czystego kodu żeby nie komentować nic najlepiej. To należy go pozostawić w jego świecie.

Może sie przydaje w jakiś małych programach; bo mając duży program, pełno instruckcji sterujących i imperatywnych zmiennych, które przyprawiją cię o ból głowy, dodawanie sobie jeszcze goto, to czyste szaleństwo. Osobiście goto mi przypomina polibudę i Fortran, acha no i Basic:)

xpeye napisał(a):

Tyle pisaliście o goto, że zamieszczam Wam skan z książki - może wtedy uwierzycie. A drugi jest o typie char - tam słowo "znaków" naprawdę istnieje. Jeśli chodzi o responsywne menu, to napisałem w pierwszym zdaniu, że sam CSS, przedstawiony wpis wcześniej, nie wystarczy i wyjaśniłem dlaczego
Za używanie goto w kodzie produkcyjnym (jak również return poza początkiem kodu funkcji, lub na jej końcu, powinno się mocno połapkach trzaskać. Przykład z kodu któray poprawiałem:
Jeden programista napisał dość niechlujnie kod (dlatego użył return, ale zasada działania ta sama). Konstrukcja standardowa

 funkcja
  zagnieżdzone warunki i pętla
 w jednym miejscu nagle występuje return w funkcji
dalsza część funkcji
return konczący

okazało się, że kod wykorzystywany w urządzeniu potrzebował w jednym z tych warunków dostępu do zasobu współdzielonego, totez kolejny programista wstawił semafor. Niestety nie zauważył tego returna... Ponieważ akurat waunek, kiedy return ze środka był wołany był rzadko, toteż trudno wyłapywalny błąd. Obserwowano tylko dziwne zachowanie systemu, raz na jakis czas watchdog wywalał program. Czyli sytuacja, gdzie dopiero review kodu pozwoliła znaleźć przyczynę, ponieważ zdarzało się to rzadko i w losowych przypadkach.

Dlatego - używanie goto, returna do wychodzenia z bardzo zagłębionych pętli i warunków, to zła metoda programowania. Tego należy oduczać.

Nie napisałem o goto, aby ludzie tę instrukcję nadmiernie wykorzystywali, tylko po to, aby czytelnik wiedział, że ona istnieje i w jakich sytuacjach dopuszczone jest skorzystanie z niej. Zresztą na początku tego wpisu zawarłem informację, że korzystanie z niej świadczy o złym stylu i braku odpowiedniej wiedzy programisty