Wpis z mikrobloga

@sylwke3100: Musisz jeszcze pamiętać o jednej rzeczy. Takiego sortowania nie należy wykonywać jeśli jesteś w jakimś projekcie gdzie nad kodem pracuje więcej niż jeden człowiek. Jedna taka akcja sortowania albo formatowania i osobie postronnej, a nawet Tobie po jakimś czasie ciężko będzie stwierdzić jakie zmiany wystąpiły w konkretnej rewizji kodu.

No chyba, że program jest malutki lub pracujesz nad nim sam.
@anonim1133: Lista jest posortowana ale kod nie ;/

@archlinuxuser: Przeiceż nawet jeśli ktoś w najgorszym wypadku takie corż zrobił to duży projekt raczej bez Gita czy w ostateczności SVNa nie powinien wg pracować a wtedy odnalezienie rewizji było by pewnie łatwiejsze/
@sylwke3100: Odnalezienie rewizji nie jest problemem. Problemem jest porównanie co się zmieniło między wersjami. Narzędzia typu diff w żaden sposób się nie połapią, że poprzenoszone zostały linijki. W przypadku plików o nietrywialnym rozmiarze kod "przed" i "po" będzie wyglądał jakby został napisany od nowa i nie da się zauważyć rzeczywistych zmian.
@archlinuxuser: Ciekawe czy są jakieś cwane diffy, które zamiast standardowego algorytmu znajdowania najdluższego wspólnego podciągu porownują rzeczywiste fragmenty kodu, takie jak konkretne zmiany w klasie i jej metodach czy tym podobne.
@sylwke3100: nie rób tego, potem jak zrobisz blame-a to 99% linijek będzie miało ostatnią zmianę w tej rewizji, w której poprawiałeś kolejność, numery linijek będą zupełnie inne, więc połapanie się, kto kiedy zmienił logikę w tej linijce i w związku z jakim zadaniem będzie bardzo utrudnione. A to jeden z lepszych sposobów komentowania kodu - pisanie numeru zadania w messagu przy commicie i można za 5 lat zrobić blame i widać
@sylwke3100: Tak na szybko to nie widzę potrzeby - masz maksymalnie 8 metod w klasie, zwykle koło 5, nie ma w czym się pogubić.

Jeśli już coś refaktoryzować, to IMHO można by podzielić metodę

CristallParser::parseData(string RawData)
bo jest dość długa - można by zrobić prywatne metody boolowskie na warunki w tej metodzie i nazwać je jakoś opisowo, i prywatne metody na kod w gałęziach tego if then elsa.

Jeszcze zastanawiam się,
@tell_me_more: searchinvoke() będzie wywalona bo po pewnych zmianach wcześniej utraciła swoje zastosowanie i będą te brzydkie informacje zamienione na ładne (bo już mam napisane typy)

Co do podzielenia na mniejsze metody to sam nie mam pomysłu ani na nazwy ani na jako tako organizacje tego choć fukcja parseData sama się rozrosłą tak jakoś)
@sylwke3100: może np tak

if (isSingleRule(element) && ruleStartsAt(element, RawData, pos)) {

handleSingleRule(element, RawData, pos);

} else if (isMultiRule(element) && ruleStartsAt(element, RawData, pos)) {

handleMultiRule(element, RawData, pos);

} else if (isSpecialRule(element, pos) && jakToNazwac(element, RawData, pos)) {

handleSpecialRule(element, RawData, pos);

}

Albo można w ogóle pójść we wzorzec obiektowy i utworzyć klasy SingleRule, MultiRule i SpecialRule, którę dziedziczą po abstrakcyjnej Rule, i mają wirtualne metody

bool Rule::matches(element, RawData, pos) // sprawdzającą warunek
@tell_me_more: RawData to jest zwykły string tak swoją drogą, element to kolejny Obiekt w vectorze Operacji. pos to aktualna pozycja stringa. Poprawiłem wcześniej o czym mówiłeś i zarazem jeszcze jeden błąd który przy okazji znazłem z tym że jak ktoś by się ustawił zamiast kropi przecinek to funkcja wykrywająca liczby zmiennoprzecinkowe by mu tego ie wykryła