Portál AbcLinuxu, 2. května 2025 07:20
Tenhle zapisek je o nejhorsi veci na programovani, trivialni chyby s fatalnimi dusledky.
Prepisy ve jmenech promennych pri vhodne zvoleny pojmenovaci konvenci jsou v pohode (tzn ze nejsou u sebe moc blizko a taky se jejich jmena nedaji snadno splest). Proste kompilator rekne pomerne srozumitelnou hlasku, ale jsou horsi veci, kdy se objevi v zdnalive bezproblemovym kodu podivna hlaska.
Podobna se mi stala nedavno:
for(i=0;i<10;i++);
{
    pthread_join(thread[i],NULL);
    pthread_join(thread[i+10],NULL);
}
Takovy jednoduchy kod, ktery ceka az vsechny thready(20) zpracuji svoji ulohu. No a program obcas zatuhne, obcas hodi SIGSEG a ted kde ladit, kdyz to pise ze ta chyba je v pthread_join. No je to na infarkt najit chybu, ktera je fakt trivialni a vznikla obycejnou nepozornosti, pri vimovskym vkladani.Kdyz sme u toho nevite o nejakym unixovym programu pro refactoring C/C++ kodu??? Presne pro tohle by se to hodilo, protoze by to znovu zformatovalo text a prikaz by pekne sel na samostatnou radku.
A zrovna dneska dalsi takova trivialitka co dokaze poradne otravit. K programu sem si chtel v ramci uspory mista udelat jednoduchy zipovani dat se kterymi se pracuje. Jen jednoduchej fork + exec. a potreboval sem to umistit jako pruchodovy. Kod na par radek a staci prohodit parametry v dup2 a hned zacne bzip2 hazet podivny hlasky o i/o error, z kterych se toho moc nepozna. Nastesti jeste ze existuje funkce fstat, ale stejne cloveka takovyhle veci otravi, kdyz musi v gdb overovat i to co vidi ze je dobre.
Pouzivate neco(program, programovaci technika) proti takovymhle otravnym chybam, ktery zbytecne zabiraj cas pri debugovani?
no zaverem jen poprat vsem co nejmin podobnych chyb.
Tiskni
Sdílej:
:set autoindent
btw, odporúčam začať používať (x)emacs kto nevyskúša, nepochopí
Prepisy ve jmenech promennych pri vhodne zvoleny pojmenovaci konvenci jsou v pohode (tzn ze nejsou u sebe moc blizko a taky se jejich jmena nedaji snadno splest). Proste kompilator rekne pomerne srozumitelnou hlasku,…To je ten šťastnější případ. Vzhledem k masivnímu skriptování webových stránek na straně klienta se nyní ukazuje JavaScript jako dynamický jazyk bez nutnosti deklarace proměnných jako ne příliš šťastná volba pro klientské skriptování. Resp. pro několika řádkové skripty by stačil, ale to co se píše dnes… O nějaké srozumitelné hlášce se může programátorovi jenom zdát, a chybu v tom, že proměnnou
elements
jednou jedinkrát napíšete jako element
můžete hledat klidně několik hodin (protože co je to platné vyvíjet primárně ve Firefoxu, když ta chyba je zrovna v kódu, který obchází nějaký nedodělek MSIE)… Doufám, že se dožiju renesance Java Appletů v prohlížečích, byť by i byly skryté a pouze manipulovali s DOMem prohlížeče, jako to dnes dělá JavaScript.
imho za väčšinou chýb stojí nevhodne zvolený postup vývoja
A vami spomínaný príklad s obchádzaním chýb? To je také ťažké vytvoriť si jednu medzivrstvu s rovnakým interface, implementovanú pre každý browser zvlášť? Pravda, medzivrstvovať či nemedzivrstvovať, to otázka.
Při trochu složitějších skriptech bohužel hlášky MSIE o typu chyby a jejím místě jsou zcela nezávislé na tom, kde chyba skutečně je
Podle mne je za vším ta zpropadená zpětná kompatibilita. Tahle tradice pochází už z dob CP/M, která měla pro všechny chyby celkem tři různé hlášky… :-)
for (int i =
...
for(int i=0;i<lines;i++)
matice.c:32: error: ‘for’ loop initial declaration used outside C99 mode
gcc
v C99 určitě, respektive, bez --std=c99
se mi podobná konstrukce nepovedla přeložit. Horší je Visual Studio, které vyžaduje příponu .cpp
, jinak to nahlásí jako chybu.
<stdint.h>
1>------ Build started: Project: test002, Configuration: Debug Win32 ------ 1>Compiling... 1>test5 1>Build log was saved at "file://d:\Projects\test002\test002\Debug\BuildLog.htm" 1>test002 - 0 error(s), 0 warning(s) ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.