Interpretowanie kodu źródłowego innych osób [zamknięte]

Uwaga: mam świadomość tego pytania. To pytanie jest nieco bardziej szczegółowe i dogłębne, koncentruje się jednak na czytaniu rzeczywistego kodu, a nie na debugowaniu go lub pytaniu autora.

Jako student na wstępnych zajęciach z informatyki moi przyjaciele czasami proszą mnie o pomoc w ich zadaniach. Jestem bardzo dumny z programowania, dlatego zawsze chętnie się zobowiązuję. Jednak zwykle mam trudności z interpretacją kodu źródłowego.

Czasem wynika to z dziwnego lub niespójnego stylu, czasem z dziwnych wymagań projektowych określonych w zadaniu, a czasem z mojej głupoty. W każdym razie wyglądam jak idiota wpatrujący się w ekran przez kilka minut, mówiąc „Eee…”

Zazwyczaj najpierw sprawdzam typowe błędy - brakuje średników lub nawiasów, używając przecinków zamiast operatorów ekstraktorów itp.

Problem pojawia się, gdy to się nie powiedzie. Często nie mogę przejść przez debugger, ponieważ jest to błąd składniowy, i często nie mogę zapytać autora, ponieważ on / ona on / ona nie rozumie decyzji projektowych.

Jak zazwyczaj odczytujesz kod źródłowy innych osób? Czy czytasz kod z góry na dół, czy postępujesz zgodnie z każdą wywoływaną funkcją? Skąd wiesz, kiedy powiedzieć „Czas na refaktoryzację”?

Pierwsza wskazówka: użyj IDE (lub bardzo dobrego edytora :)), aby wykryć błędy składniowe, źle umieszczone nawiasy i inne trywialne błędy.

Drugi krok: Autoformatuj cały kod w formacie, w którym czujesz się komfortowo. Można by pomyśleć, że to nie ma większego znaczenia, ale zadziwiające, że tak.

Nie bój się zmieniać nazw lokalnych zmiennych, jeśli są one źle nazwane. (Jeśli masz dostęp do pełnego systemu, możesz zmienić nazwę cokolwiek i powinieneś.)

Dodaj do siebie komentarze, gdy odkryjesz, co robi dana funkcja / metoda.

Bądź cierpliwy. Zrozumienie kodu obcego nie jest łatwe, ale zawsze jest moment przełomowy, gdy większość kawałków układanki nagle wpada na miejsce. Do tego momentu obawiam się, że to ciężka praca i znój. Dobrą wiadomością jest to, że wraz z praktyką ten eureka nadejdzie wcześniej.

Chciałbym powiedzieć, że myślę, że podchodzisz do tego niewłaściwie. Jeśli ludzie zwracają się o pomoc do swojego kodu, myślę, że masz obowiązek odwrócić się i powiedzieć im, aby przeprowadzili cię przez ich kod. Możesz naprawić ich błędy, a oni mogą się czegoś nauczyć (na pamięć), jeśli zauważą własne błędy (z twoją pomocą), prawdopodobnie dowiedzą się więcej. Dodatkowo zyskasz szersze doświadczenie z tym, jak różne osoby podchodzą do kodowania (co z kolei pozwoli ci odczytać / zrozumieć więcej kodu) - cnotliwy cykl ...;)

Wierzę, że ta umiejętność jest mieszanką doświadczenia i talentu. Mieliśmy pracowników, którzy mogliby rozwiązać mniej więcej wszystko, gdybyśmy poprosili ich o zrobienie czegoś od zera, a jednocześnie nie byliby w stanie znaleźć oczywistych błędów w fragmentach kodu, których nie napisali. Jednocześnie mieliśmy pracowników, którym nie ufalibyśmy niczego, co wykraczałoby poza podstawową konstrukcję, ale którzy mogliby zanurzyć się w innych kodach i śledzić problemy w mgnieniu oka.

To powiedziawszy, sposobem na to jest zmiana kodu. Sformatuj to, do czego przywykłeś, zmień nazwy zmiennych na coś, co ma dla ciebie sens, dodaj komentarze, jeśli kod nie jest jasny. Jeśli poprosi cię o pomoc, powinieneś po prostu iść naprzód i zmieniać rzeczy, dopóki nie zauważysz problemu. Następnie pozostaw znajomemu, czy chcesz poprawić oryginalny kod, czy użyć własnego.

Po pierwsze, jeśli występują błędy składniowe, musisz po prostu uważnie przeczytać błędy kompilatora. Często wiersz jest podświetlony jako błąd, ale tak naprawdę poprzedni wiersz zawierał błąd.

Pamiętaj, że dla ucznia wprowadzającego mogą istnieć pewne artefakty edycyjne, które uniemożliwiają kompilację programu, którego nie można zobaczyć. Na przykład kiedyś widziałem studenta (nie mojego), który zamiast spacji użył spacji: jego kod wyglądał normalnie na edytorze, który zawinął po 80 kolumnach (student był bardzo cierpliwy), a kod działał nawet do momentu dodania //komentarz w stylu „ ”, który skomentował resztę programu. Podobnie, jeśli kopiujesz próbki kodu ze strony internetowej, często kopiowane są również znaki niedrukowalne (w zależności od tego, jak strona sformatowała kod). W razie wątpliwości wpisz ponownie wiersz bez kopiowania i wklejania. [To trochę niesamowite, ale ostatnio widziałem, że zdarza się to znacznie częściej.]

W przypadku paskudnych błędów kompilatora może być konieczne rozwinięcie programu przez utworzenie nowego pliku i wpisanie całego kodu w miarę postępów. Pamiętaj, aby kompilować po każdym ważnym kroku, zanim przejdziesz do następnego.

OK, a co jeśli nie ma błędów składniowych? Czas przejść przez kod! Możesz użyć do tego debuggera, ale wywoływanie printfcałego kodu jest również bardzo skuteczne. Na przykład, jeśli istnieje forpętla, dodaj instrukcję print dla licznika pętli. W przypadku zagnieżdżonych forpętli może się okazać, że zwiększana jest niewłaściwa zmienna.

Zaletą używania printfs jest jego zdolność do „kompresji” w czasie / przestrzeni tego, co aktualnie oglądasz. Po przejściu przez debugger widzisz również wiele nieistotnych stanów i może to być bardziej nużące. Ponadto, nie widząc historii tego, co zostało wydrukowane na konsoli, możesz przeoczyć niektóre wzory. Chodzi o to, że debugger i printfs są uzupełniającymi się technikami i żadna z nich nie zawsze jest lepsza od drugiej.

Na koniec po prostu zapytaj znajomego, co się dzieje! Zamiast patrzeć na to i mówić „uh”, zapytaj ich, co robią: „co teraz robi n?” Rozpoczynając dialog, mogą oni odpowiedzieć na własne pytanie lub możesz zdać sobie sprawę ze sposobu, w jaki konceptualizowali program, który ma wadę, która może doprowadzić cię do rozwiązania.

Jak skomentowano w innym miejscu, wszystko to staje się lepsze wraz z doświadczeniem. Mimo że programuję od 20 lat, dopiero w ciągu ostatnich 5 lat pracowałem ze studentami, aby lepiej pomagać im w ich błędach.

Nienawidzę tego mówić, ale tutaj nie ma srebrnej kuli.

Szczerze mówiąc, gdybym był wystarczająco jasnowidzący, aby zrozumieć, co mieli na myśli inni , pisząc, co robili nawet w 10% przypadków, bez cienia wątpliwości zarabiałbym do tej pory miliony.

Bardziej praktyczna uwaga: użycie inteligentnego IDE to krok 1.

Krok 2 polegałby na uruchomieniu doxygen lub czegoś podobnego w celu ustalenia hierarchii kodu źródłowego.

Krok 3 polega na znalezieniu funkcji lub obiektów zakotwiczenia, które przetwarzają wiersz poleceń lub plik, a następnie wykonują logikę.

Równolegle do kroku 3 śledź globale, jeśli ich używasz. Zapytaj również swoich kolegów, czy używają jakiegoś znanego konkretnego algorytmu - przeczytanie algorytmu (jeśli taki istnieje) przed spojrzeniem na kod jest zawsze korzystne.

Jednym słowem: Doświadczenie, im więcej zdobywasz doświadczenia, tym więcej uczysz się najlepszych praktyk i potrafisz oceniać / rozumieć kod innych ludzi. Nie przychodzi automatycznie, zamiast tego często pochodzi tylko od popełnienia tego samego błędu!

To powiedziawszy, bardzo ważne jest, aby programiści nauczyli się poprawnie komentować swój kod, ponieważ kiedy patrzysz na kod, często jest to wynik poważnego procesu myślowego, który często jest bardzo trudny do ekstrapolacji z kodu. Kilka komentarzy, plik tekstowy z przemyśleniami projektowymi może zrobić różnicę między zrozumieniem kodu a całkowitym niezrozumieniem go.

Często pytano mnie o to samo w laboratorium w szkole. Zwykle pytanie zaczynało się od „Jak naprawić ten błąd kompilatora?” więc całkiem nieźle zauważyłem zwisające litery else, brakujące średniki i tym podobne. (Makra też są fajne do debugowania - #define CUBE(x) x * x * xto błąd, który wszyscy powinniśmy popełnić.) Zaletą było to, że przechodziłem te same zajęcia z tymi samymi nauczycielami, więc znałem już wymagania.

Proces, który uważam za najlepszy, to prowadzenie dialogu. Nie chcesz dla nich pisać programu, ponieważ to oni muszą się uczyć. Oznacza to, że musisz być z nimi na tym samym komputerze. W laboratorium przyjdę do ich komputera. Spróbuję nakłonić ich do wykrycia błędu, zaczynając od komunikatu kompilatora. (Używaliśmy C.) Zacznij od numeru wiersza i wskaż, gdzie odpowiada komunikat i błąd. Jeśli występuje więcej niż jeden ten sam błąd, zapytałbym ich, co jest podobne w tych dwóch błędach.

Cały pomysł polega na tym, aby pomóc drugiemu uczniowi. Przepisanie im kodu nie pomoże im się uczyć.

Błędy składniowe są o wiele łatwiejsze do znalezienia niż błędy logiczne. Jeśli większość ich problemów dotyczy składni, znajdź IDE, skopiuj i wklej do niego swój kod oraz napraw błędy. Błędy logiczne są znacznie trudniejsze. Nie jestem pewien, dlaczego mówisz, że nie możesz poprosić ich o wyjaśnienie ich kodu. Znalazłem wiele błędów logicznych, tłumacząc kod komuś innemu.