Częste błędy (mistakes) w kodowaniu

Słyszałem że np. wiele osób początkujących ma problem z typami undefined i null oraz operatorami porówniania == i === w JavaScript.
Mówcie z jakimi błędami się spotkaliście, i jak ich unikać oraz obowiązkowo, język którego to dotyczy.

= zamiast == w C/C++

== zamiast equals przy porównywaniu stringów w javie.

• zamiast . przy złączaniu stringów w PHP

w C# nie zapomnieć "break;" po komendzie "default:" w switchu ;)

#edit dla niekumatych :P
Kurde - napisałem wyraźnie - "w C# nie zapomnieć słowa break po instrukcjach, które obejmuje default w switchu".
w case`ach to chyba logiczne, że break trzeba nawet w C++. Ale C++ nie wymaga, żeby break dawać po default a C# tak... czyli jak ktoś jest do składni switcha z C++ przyzwyczajony to może mieć zonka.
Tylko o to mi chodziło ;)

float/double.Parse w .NET na liczbach z kropkami jako separatorem dziesiętnym na polskich regionalnych ustawieniach.

Zapominanie, że w C/C++ literał tekstowy jest const.

Java, napisanie (w klasie Foo) metody o sygnaturze public void Foo i przekonanie, że się napisało konstruktor.

Ja notorycznie pisząc w Razorze wstawki C# stawiam średnik na końcu linijki. A potem strona jest najeżona średnikami. ;)

Indeksowanie elementów tablic od 1 do n, zamiast od 0 do n-1, gdzie n to ilość elementów :D znany błąd w prawie wszystkich językach numerujących od 0 :D

Zapomnienie " ; " ?

Po długim kodowaniu w C# i przerzuceniu się na chwilę do C++ zonk dlaczego pojawia się błąd przy this.xxx, po minucie odkrywam, że w C++ jest to wskaźnik i potrzeba po prostu operatora ->.

mto9 napisał(a):

Indeksowanie elementów tablic od 1 do n, zamiast od 0 do n-1, gdzie n to ilość elementów :D znany błąd w prawie wszystkich językach numerujących od 0 :D

Uogólnienie problemu: http://en.wikipedia.org/wiki/Off-by-one_error

Często prześladuje ludzi na ASD.

Nigdy nie mogę spamiętać, czy prawidłowa jest kolejność

typedef int costam;

czytypedef costam int;

• Czeste jakie znajdywalem w czyims kodzie to srednik po warunku w if'ie (zwlaszcza takim dluzszym)... nie rzuca sie na pierwszy rzut oka, dopiero podczas debugowania wychodzi, zwlaszcza jak ktos dodatkowo z tabulacja w pliku namieszla.

• Zle join'y w sql'u ktore w okreslonych warunkach zwracaja wynik null'owy (a powinny przynajmniej jeden)

• Ogolnie brak zabezpieczenia się przed null'ową wartością to chyba najczestrzy błąd na jaki trafiam w projektach - a wychodzi dopiero w określonych warunkach.

• statyczne metody/zmienne w aplikacji z której korzysta wielu użytkowników naraz często zauważyłem, że bywają problemem - jak ktoś nie umie ich poprawnie używać i miesza tym sposobem konteksty wykonywania.

• puste catch'e! W wielu projektach już zauważyłem, że istnieje coś takiego jak puste catch'e, co prowadzi do sytuacji, że błąd jest rzucany zawsze ale aplikacja działa dalej - ot ktos z ulanska fantazja napisze cos co moze zadziala, a moze nie, z reguly to jakas pieerdoła niewazna dla calego systemu. Najbardziej to denerwuje gdy, mam zdebugować jakąś część systemu, w visualu włączam sobie Debug/Exceptions/Common Language Runtime Exceptions - throw, a tu wychodzi, że zanim dojde do problematycznego fragmentu to mi łapię kilka innych 'normalnych' exceptionów, co normalne nie jest.

1. Noobowską lecz jakże popularną pomyłką jest sprawdzanie EOF przed próbą odczytu wartości z pliku zamiast po próbie.
2. Kolejna noobowska pomyłka - konsola, pozostawianie w buforze znaku nowej linii (np. po pobraniu od użytkownika liczby) i dziwienie się czemu getline zwraca pusty łańcuch.
3. Bardziej pro - niedoszacowanie czasu realizacji zadania/projektu :)

Brak konstruktorów kopiujących przy obiektach alokujących pamięć.

Czeste u mnie (praca przy duzych systemach stojacych na kilku maszynach, masz np w jednym momencie 20 serwerow na ktorych cos zestawiasz).

1. Zmieniasz cos na innym pliku/serwerze, niz myslisz, a potem sie dziwisz ze zmiany nie odnosza skutku i czemu to nie dziala.

2. Okazuje sie ze nie zenablowales serwera/uslugi itp. I dziwisz sie ze cos sie wywala.

Częstym też błędem u nowicjuszy jest sytuacja tego typu:

int *tab = new int[99999];
(...);
delete tab; // powinno być delete [] tab;

a ja ostatnimi czasy odkąd coraz częściej piszę jakieś małe moduły w erlangu przełączając się na C# zaczynam switcha od case

Ja z przyzwyczajenia nie używam switcha bo... najpierw nie pamiętałem jego składni (bo go nie używałem) cały czas wierząc, że nie ma dowolności typów w C#.
Szczerze mówiąc, wole else..ify, choć czytałem, że bywają wolniejsze, ale jakoś wygodniej mi się pisze. Switch, case, nawiasy zabierają sporo miejsca (mówie o wcięciach), i trzeba pisać breaka, że nie chce mi się tego używać specjalnie.

Często zdarza mi się zapomnieć odkomentować wywołania funkcji, albo dopisać do eventhandlera coś, i myśle że nie działa, kombinuje w funkcji a starczy podpiąć zdarzenie..
Dotyczy to przypadku gdy zmienie nazwę kontrolki a potem chce też zmienić nazwę obsługi zdarzenia konrolki w kodzie.

Miałem kiedyś problem ze zwalnianiem pamięci w c#

Korzystałem z:

Object.Dispose();

i myślałem, że wszystko ok.

Powinno być:

using (object o = new object())
{
{...}
}

Zonk ekstremalny:

class C { /*...*/ };

int main() {
  C c();     // declares a function c taking no arguments returning a C,
             // not, as intended by most, an object c of type C initialized
             // using the default constructor.
  c.foo();   // compiler complains here.

  //...
}

http://stackoverflow.com/questions/1034606/is-there-any-use-for-local-function-declarations

Inne:

• (side effect) wymóg stosowania "Yoda conditions" bo jakiś (#!@%^!@%) wymyślił "==" (w C) a jeszcze większy (!@$%!) wymyślił "===" (w PHP)

if (2 == a) { ... }

• zdefiniowanie makra funkcyjnego C/C++ bez nawiasów wokół argumentów

#define add(x,y) x+y

• definiowanie deklaracji wskaźnika do funkcji w C jest jednym wielkim zonkiem
• nie zastosowanie "virtual" w destruktorze w C++ (na pytanie po co mam o tym pamiętać dostałem odpowiedź od BS - dość enigmatyczną - ze względu na jakieś optymalizacje) - powoduje wycieki
• porównanie ("==") dwóch wartości (char *) w C/C++ nie daje oczekiwanych efektów...

W VBA popularnym błędem jest przekazywanie parametrów do funkcji przez referencję, zamiast przez wartość... VBA przekazuje przez referencję domyślnie, wystarczy więc spojrzeć sobie na przykładowy kod nooba (milion takich poprawiałam):

Sub Main()
    dim s, tmp_s, ret

    tmp_s = s
    ret = RobCosTamNaPodstawie(s)

    s = tmp_s
End Sub

Function RobCosTamNaPodstawie(s)
    'cos tam co zmienia s
    RobCosTamNaPodstawie = costam
End Function

Jeżeli programista zastosuje myk z tmp to jeszcze pół biedy, idiotycznie, ale przynajmniej działa.
A wystarczyłoby po prostu deklarować zmienne i opisywać argumenty funkcji prawidłowo....

Public Function RobCosTamNaPodstawie(ByVal s As String) As String

Namolnie popełniam błąd w C# przy inicjowaniu pól/właściwości obiektu w sposób:

var foo = new Foo()
{
    Bar = 1; //średnik zamiast przecinka
    Bar2 = 2
}

var foo = new Foo()

Już samym błędem, który karany powinien być obcinaniem jaj jest pisanie "var" zamiast konkretnego typu.

Sterylizator napisał(a):

Już samym błędem, który karany powinien być obcinaniem jaj jest pisanie "var" zamiast konkretnego typu.

Ktoś tu nie dorósł do inferencji typów.

1. pozostawienie w kodzie wpisów dupa-debbug.
2. w niektórych starszych językach ważna jest kolejność pól w "klasie". W javie jest to ważne w przypadku enumów po przepuszczeniu przez "sort member" okazuje się, że nasz enum jest posortowany alfabetycznie i nie działają operatory <,>.
3. użycie double w obliczeniach finansowych.
4. settery:

void setA(A a){
   a = a; // pomijanie this
}

5. Przy przenoszeniu zapytań SQL z konsoli do kodu:

connection.prepareStatement("Select * from A;"); // dodatkowy średnik w zapytani

mapowanie enumów w Hibernate jako liczby, a później dodanie kolejnego enuma gdzieś w "środku".

adf88 napisał(a):

3. Bardziej pro - niedoszacowanie czasu realizacji zadania/projektu :)

Ale to chyba nie jest błąd w kodowaniu. :)

vpiotr napisał(a):

• (side effect) wymóg stosowania "Yoda conditions" bo jakiś (#!@%^!@%) wymyślił "==" (w C)

To nie jest chyba kwestia porównania tylko if.

porównanie ("==") dwóch wartości (char *) w C/C++ nie daje oczekiwanych efektów...

Efekt jest oczekiwany, tyle, że nieintuicyjny.

Sterylizator napisał(a):

Już samym błędem, który karany powinien być obcinaniem jaj jest pisanie "var" zamiast konkretnego typu.

Jaką nazwę podasz dla typu anonimowego?

To jak wyżej z inicjalizacją obiektu było to mi się przypomniało z enumami to samo:

enum Days
{
    Monday; // przecinek zamiast średnika :/
    Tuesday;
    // itd.
}