Ja tam lubie i nie mam problemu pre-commit ogarnia

@damw - wystarczy linter i formatter kodu - i problem znika

Poza tym sam Python dokładnie pokazuje w której lini jest złe wcięcie

@damw w devopsie i je⁎⁎⁎ym jamlu jest identycznie ( ͠° ͟ʖ ͡°)

@WujekAlien kalendarz lepszy

@vrkr - za duck.ai:

Oto lista "głupich" rzeczy związanych z operatorami porównywania w JavaScript:

1. **Używanie `==` zamiast `===`**: Operator `==` wykonuje konwersję typów, co może prowadzić do nieoczekiwanych wyników. Zawsze lepiej używać `===`, aby porównywać zarówno wartość, jak i typ.

2. **Porównywanie różnych typów bez zrozumienia**: Porównywanie wartości różnych typów (np. liczby i stringi) może prowadzić do zaskakujących wyników, np. `0 == '0'` zwraca `true`, ale `0 === '0'` zwraca `false`.

3. **Używanie `!=` zamiast `!==`**: Podobnie jak w przypadku `==`, operator `!=` wykonuje konwersję typów, co może prowadzić do błędów. Zawsze lepiej używać `!==`.

4. **Porównywanie obiektów**: Porównywanie obiektów za pomocą operatorów porównania (np. `obj1 == obj2`) porównuje referencje, a nie zawartość obiektów, co może prowadzić do nieporozumień.

5. **Używanie `Object.is()` bez zrozumienia**: `Object.is()` ma swoje specyficzne zasady porównywania (np. `NaN` jest równe `NaN`, a `-0` nie jest równe `+0`), co może być mylące.

6. **Porównywanie wartości `null` i `undefined`**: Używanie `==` do porównania `null` i `undefined` zwraca `true`, co może prowadzić do niejasności, gdy nie jest to zamierzone.

7. **Zbyt skomplikowane wyrażenia porównawcze**: Tworzenie złożonych wyrażeń porównawczych, które są trudne do zrozumienia, może prowadzić do błędów i utrudniać czytelność kodu.

8. **Ignorowanie kontekstu logicznego**: Używanie operatorów porównania w kontekście logicznym (np. w instrukcjach warunkowych) bez zrozumienia, jak działają, może prowadzić do błędnych założeń.

9. **Porównywanie z `NaN`**: `NaN` nie jest równe żadnej wartości, w tym samemu sobie, co może prowadzić do nieoczekiwanych wyników w porównaniach.

10. **Używanie operatorów porównania w pętlach bez zrozumienia**: Używanie operatorów porównania w pętlach (np. `for`) bez zrozumienia ich działania może prowadzić do nieskończonych pętli lub błędów logicznych.

Unikanie tych pułapek może pomóc w pisaniu bardziej niezawodnego i przewidywalnego kodu w JavaScript.

@vrkr Tak na oko to obstawiłbym C. Myślę, że A zwraca true, B jest ciekawszym przypadkiem bo bez podania argumentów Math.min() będzie infinity, a Math.max() będzie -infinity także również będzie to true. NaN nie jest równy innemu obiektowi NaN i dalej nie muszę myśleć.

Metodą wykreślania poprawnych odpowiedzi:

A - w JS prawie wszystko jest obiektem więc to zwróci true

B - funkcja do zwracania najmniejszej wartości z podanych zwróci domyślnie największą możliwą liczbę a ta przeciwna odwrotnie więc też true

D - koncepcja truthy/falsy w JS gdzie przy takim porównywaniu wartości są "konwertowane" na true albo false, zero jest false a pusty string jest falsy więc zwróci true

No i pozostaje to C, gdym rozwiązywał jakiś test i nie miał dostępu od internetu to bym zaznaczył tę odpowiedź. A teraz podczas pisania tego zdania sprawdziłem na internecie dlaczego NaN != NaN i jak się nad tym pomyśli to ma to sens (jak wszystko w JS gdy zna się odpowiednio ten język, ale wtedy wszelkie te memy przestają bawić).

Dla ciekawskich tutaj są odpowiedzi:

https://www.reddit.com/r/ProgrammerHumor/comments/sh1ji1/stop_pretending_nan_nan_was_a_good_idea_it_wasnt/

https://stackoverflow.com/questions/10034149/why-is-nan-not-equal-to-nan

Bez foreign keys

@vrkr Bool nie ma warunku definicji rozmiaru, ponieważ rozmiary typów całkowitych też nie mają gwarancji być zawsze takie same. Ma tylko następujące wytyczne:

• wartości boolean są tego samego rozmiaru przy porównywaniu
  

• jest prawdą jeśli wartość jest niezerowa
  

Taka minimalna logika pozwala różnym językom implementować to jak chcą, dając użytkownikowi tryb "tak bardzo wyjebane" ja tylko używam true i false i am w d⁎⁎ie jak kompilator robi.

Sorry, ale tzw padding istnieje nie bez powodu, baba jak zwykle robi problem z niczego.

Ale struktura 8 booli nie musi zajmować 8 bajtów.

Ludzie mają windowsa tylko dlatego że trzeba uruchomic grę.

Change my mind

@damw Preferuję lepszy trolling:

Tu Twoja rodzina. Od pięciu lat pozostajesz w śpiączce. Próbujemy nowej metody by do Ciebie dotrzeć. Nie wiemy czy i gdzie zobaczysz tę wiadomość. Błagamy, wybudź się!

@damw czas na plan H. Bo plany od A do G nigdy nie działają.

Nie rozumiem

@vrkr Ahhh.. preprocesor C, czyli jak za pomocą 10 linii kodu wygenerować 10k linii błędów.

Dopiero template'y w C++ miały równie wielkie możliwości w dziedzinie generowania niezrozumiałych błędów.

@damw to jest 10 / 10 Serial też był dobry!

Na szczęście współczesne płyty główne potrafią już w technologie typu podwójne biosy, przywracanie biosa przyciskiem itp.

@fadeimageone BIOS… stare dzieje. U mnie to już druga czy trzecia płyta główna z UEFI na pokładzie.

@fadeimageone chyba w PKO czy PZU

@entropy_ - mam swoją implementację którą wgrałem w mój firmware lata temu

@entropy_ 25 powodów na powiedzenie nie wpakowane w json na 1000 linijek xD

@entropy_ Idę o zakład, że większość z tych 1000 powodów była pisana przez AI. W sumie cały ten "projekt" mógł być.