> Tak się zastanawiam ile czasu Ci zajmuje realizacja jakiegoś
> zadania/projektu, czy sa to projekty rozwojowe czy jednorazowe
> zadania, które po realizacji nie są dalej rozwijane.
>
> --
> Marek
Nawyk dokumentowania kodu mam już od 15 roku życia.
Wtedy na ZX81 pisałem w asm (nie było innego wyjścia - miał 1kB)
i komentowałem kod.
Po kilkunastu latach praktyki odwróciłem metodę.
Rysuję sobie w zwykłym edytorze bloczki logiczne,
używając koloru. Jest w PC, jest w drukarce, dlaczego ma być czarne?
Dzięki temu od razu widzę, że jak jest na czerwono, to zmienna,
Jak na niebiesko to stała, jak na seledynowo to bit.
Po lewej stronie bloczka piszę sobie komentarz, a po prawej kod - już w asm.
Na końcu po prostu kopiuję kod z prawej i komentarz z lewej, bloczek po
bloczku.
Wklejam do IDE, choć może faktycznie nie ma to znaczenia, że jest to IDE.
Raczej używany tylko do kompilacji.

Jak widać musi być to szalenie żmudny proces- wydawać by się mogło.
Jednak wyrobienie sobie takiego nawyku przez kilkanaście lat pracy,
powoduje, że teraz to idzie szybko.
Wiadomym jest, że jak stukasz w klawiaturę wpisując ~destruktory w C++,
czy inne konstrukcje, nie dodając żadnych komentarzy zawsze będzie to
szybsze,
niż rysowanie algorytmu, dokładanie opisu słownego po polsku czy angielsku,
kopiowanie tekstu, czy tworzenie historii zmian.
Oszczędności czasu przychodzą później:
a) przyjemność zabrania się za analizę kodu przedstawionego na kolorowym
algorytmie,
przyspiesza pracę wykładniczo, wraz z jakością dokumentacji
b) poprawianie, czy adaptacja kodu nie zabiera już tyle czasu, a wręcz
przyspiesza.
c) uruchamianie jest już formalnością i czasem jest tak, że rysujesz/piszesz
program 3 dni,
a samo uruchamianie z oscyloskopem czy analizatorem stanów - kilka godzin.
Gdy znajdziemy błąd, często pada od razu po spojrzeniu w dokumentację
zdania:
" No tak... śmieszny błąd"
Dzieje się tak, gdyż poświęcając dużo czasu na przygotowanie kodu, zanim
zacznie się pisać słowa w dowolnym języku programowania, już wcześniej
korygujemy wiele błędów natury logicznej, składni, nazwy, czy zwykłych
pomyłek.
Po wpisaniu kodu - jest on już niemal pewny.
Zmiany zwyczajowo dokonują się poprzez poprawę kilkunastu znaków w kodzie.
A w większości pewnie w komentarzach i historii zmian.
Samo wpisanie daty 2013103 to już 7 znaków :-)

Odpowiadając na Twoje zapytanie - tak kod jest zawsze rozwojowy.
I tak miało być w założeniu.
Jednak czy faktycznie nastąpi jego rozwój - nie wiem, gdyż zależy to od
popytu.
Wszystkie są tak przygotowywane. Nie rozróżniam, czy coś ma być jednorazowe
czy nie.

Mam na dysku kilkaset algorytmów na różne procesory, LCD, termometry,
ultradźwięki
i wiele innych.
Jest też tego zaleta taka, że doskonale się rozumiemy z żoną, co do zasad
dokumentacji.
W związku z tym czasem podrzucam żonie mój algorytm sprzed nastu lat na
8051,
a żona przerabia go na PIC32 zmieniając (bardzo optymalnie zresztą) kod.

Uczę tej pracy też dzieci, więc już trójka z mojej całej piątki opanowała
rysowanie algorytmów,
choć są dopiero na poziomie <liceum.


Wielokrotnie wracam, do swoich projektów sprzed kilku, kilkunastu lat
i zmieniam. Wtedy zmienia się tylko kod najczęściej i czasem coś
optymalizuję,
gdy dziwie się, jak kiedyś taki "młodzik" nie widział prostrzej metody :-)

W razie potrzeby mogę przesłać gdzies próbki, ale raczej nie publicznie,
gdyż
nie mam zbyt wiele czasu (w ujęciu masowym) nad przekonywaniem do moich
metod działań :-)

--
-- .
pozdrawiam
Sylwester Łazar
http://www.alpro.pl Systemy elektroniczne.
http://www.rimu.pl -oprogramowanie do edycji schematów
i projektowania PCB.