Czy powinniśmy szukać kłamliwego kodu?

Odnosi się to do dyskusji w odpowiedzi i komentarzy do tego pytania: Co jest związane z awersją do dokumentacji w branży? . W odpowiedzi twierdzono, że „kod nie może kłamać”, a zatem powinna być lokalizacją docelową zamiast dokumentacji. Kilka komentarzy wskazuje, że „kod może kłamać”. Po obu stronach jest prawda, przynajmniej częściowo ze względu na to, jak słabo i niewłaściwie traktowana jest dokumentacja.

Czy powinniśmy szukać kłamliwego kodu, porównując go z istniejącą dokumentacją? Czy jest to zwykle najlepsze źródło tego, co musi robić? Jeśli jest to zwinny kod, to czy jest mniej prawdopodobne, że kłamie, czy może ten kod wcale nie kłamie?

Słowami laika:

Tak , powinieneś poszukać kłamliwego kodu i sprawić, by mówił prawdę. Ale nie przez porównanie go z dokumentacją. To byłby sposób na wykrycie kłamliwej dokumentacji.

Kod może kłamać na kilka sposobów, o których wspomnę tylko kilka:

• Bloki kodu, które nigdy się nie uruchamiają, ponieważ warunki, które nigdy nie są spełnione. Kod kłamie o tym, ile to robi.
• Kod, który dodaje niepotrzebną złożoność, polega na tym, jak skomplikowany jest naprawdę problem.
• Kod bez konwencji nazewnictwa jest kłamstwem, ponieważ wprowadza w błąd, myśląc, że robi coś innego niż to, co naprawdę robi.

Im krótszy, tym mniej kłamie. To oczywiste.

Im mniej skomplikowany kod, tym bardziej przejrzysty. Więc leży mniej.

Wiele tajemnych sztuczek składniowych. Preferuj przejrzyste algorytmy krok po kroku. Kłamią mniej.

Dobre narzędzie do analizy kodu statycznego może pomóc Ci znaleźć kod, który kłamie.

Również dobra zautomatyzowana bateria testowa zmusza kod do mówienia prawdy.

Kod nie może kłamać.

To, co jest w kodzie, jest tym, co obecnie robi Twój program - bez względu na dokumentację, kontrolę jakości lub klient. Zwłaszcza jeśli Twój kod został zwolniony i był przez jakiś czas w terenie, tego oczekiwanego zachowania nie należy ignorować.

Kod z pewnością może być niepoprawny . Z pewnością może wprowadzać w błąd co do nazewnictwa lub organizacji. Z pewnością może być nieczytelny.

Ale jeśli chcesz źródła prawdy na temat tego, co robi Twój kod , a nie tego, co ma robić, a nie tego, do czego został zaprojektowany, a nie tego, co myślałeś, że robi ... jeśli chcesz wiedzieć, co on właściwie robi, idź do kodu.

Zadajesz kilka pytań.

Czy powinniśmy szukać kłamliwego kodu?

Oczywiście!

Czy powinniśmy porównywać [kod] z istniejącą dokumentacją?

To nigdy nie może zaszkodzić, chociaż jak wspomniano w innych odpowiedziach, częściej prowadzi to do problemów w dokumentacji , a nie w kodzie .

Czy też [kod] jest zwykle najlepszym źródłem tego, co musi robić?

To jest zawsze najlepszym źródłem do tego co się robi. Najlepszym źródłem tego, co powinien robić kod, mogą być (kombinacje) różnych rzeczy, z których najważniejsze to:

• Sam kod;
• Kod telefoniczny;
• Komentarze w tym kodzie;
• Dokumentacja;
• Testy jednostkowe;
• Testy integracji i regresji;
• Programista;
• Użytkownik końcowy;

To, które jest „najlepszym” źródłem (lub ich kombinacją), zależy od twojej sytuacji.

Jeśli jest to zwinny kod, to czy jest mniej prawdopodobne, że kłamie, czy może ten kod wcale nie kłamie?

Nie jestem pewien, co rozumiesz przez „zwinny kod”, AFAIK „zwinny” zwykle odnosi się do procesu kodowania. Przypuśćmy, że masz na myśli „kod utworzony w zwinnym procesie programowania”, więc myślę, że można bezpiecznie powiedzieć, że wciąż może kłamać. To, jak prawdopodobne jest, że kłamie, w porównaniu do kodu stworzonego np. W projektach w stylu wodospadu, jest kwestią subiektywną (osobiście nie sądzę, żeby istniało duże powiązanie).

Przypis
Wszystkie powyższe założenia zakładają, że kod może kłamać i że jest to podstawowy (choć nieco wymyślony) przykład:

public int DivideByTwo(int input) 
{
    return input / 3;
}

To tylko jeden przykład, w którym powiedziałbym, że „kod leży”, @ user61852 ma jeszcze kilka innych (nieosiągalny kod, złożoność kodu niepasująca do złożoności problemu, złe nazewnictwo) i myślę, że jest ich o wiele więcej. Wikipedia ma dość przyzwoite podsumowanie kłamstw , wiele z nich można znaleźć kod.

Zauważ, że jeśli kłócisz się z kimś, bądź pewien, że druga osoba nie rozumie przez „kod nie może kłamać”, że „kod robi to, co robi”. Zasadniczo druga osoba tutaj definiuje za pomocą definicji „kłamstwa”, która jest tak wąska, że ​​może zadeklarować stwierdzenie „kod nie może kłamać” jako aksjomat / podstawowa prawda. W takim przypadku prawdopodobnie najlepiej jest zgodzić się z jego / jej axioma.

if (x > 5) {
  doSomething();
} else {
  doADifferentThing();
}

Możesz spierać się o to, czy słowo „kłamstwo” jest technicznie właściwe, ale ten kod sugeruje dość wyraźnie, że czasami x będzie większe niż 5, a czasem nie. Jeśli spojrzysz na pełny program i odkryjesz, że ta funkcja jest zawsze wywoływana tylko w jednym miejscu i że x jest zawsze ustawione na stałą 6, to kłamstwo.

Co więcej, kompilator mógł to zauważyć i zastąpił ten blok kodu po prostu

doSomething()

Jeśli doADifferentThing nie jest wywoływany nigdzie indziej w twoim programie, może zostać całkowicie usunięty z programu.

Jeśli twój język obsługuje assertjakiś rodzaj, który jest wyłączony w kompilacjach produkcyjnych, każde assertzdanie jest potencjalnie kłamstwem. Rzutowanie to kolejne stwierdzenie, które może być kłamstwem.