Liczenie linii kodu

Nurtuje mnie pewna kwestia - w jaki sposób liczycie linie kodu w (niekoniecznie) swoich projektach?
Bierze się pod uwagę komentarze, puste linie itd?

Istnieją jakieś narzucone standardy co do tego?

Linia kodu nie jest tym samym czym linia tekstu.
Definicja zależy od języka gdyż są takie których składnia wymusza formatowanie tekstu oraz takie którym to obojętne.
Komentarz nie jest kodem, tak samo puste linie. Kawałek kodu zawierający przykładowo same końće bloków linią kodu bym nie nazwał.

Gdy kod jest formatowany wedle jakiegoś standardu uznawanego przez ogół można podać po prostu ilość lini tekstu, nie powinno to doprowadzić do dziwnych sytacji a oszczędza kombinacji z tłumaczeniem jak te lnie zostały policzone.

Trzeba liczyć średniki. :)

Ogólnie tak, ale jak już dokładnie liczyć linijki kodu to ja też bym nie brał pod uwagę dyrektyw, które uwzględniają jakiś nagłówek/bibliotekę - co z tego, że ktoś napierdzieli tego, i nie wykorzysta.

W Lispie można by było liczyć nawiasy :)

@O_o - jak dla mnie komentarz jak najbardziej jest kodem, w szczególności wymaga przemyślenia, napisania i utrzymywania.

A gdybym cały kod napisał w jednej linii?
czemu po prostu nie liczyć znaków, wyłączając komentarze?

Z tymi średnikami to dobry pomysł :) Cyba najbardziej idiotoodporny.
Ja natomiast liczę każdą linię kodu która coś wnosi. Trudno to sprecyzować, bo np NIE liczę klamer, a przecież one coś wnoszą. Liczę po prostu linie kodu w których znajdują się pewne instrukcje.
Nie licze także kodu generowanego przez IDE np wygenerowanego szkieletu procedury, nie mówiąc już o pustych liniach.

To paktycznie tyle. Według mnie intuicyjnie z tym trzeba iść, ale te średniki to dobry pomysł. No oczywiście biorąc pod uwagę dany język programowania.

edit: no w sumie średniki da się oszukać kodem " ;;;;;" bądź co bądź takie coś też się skompiluje :P

Równie sensowne zajęcie jak liczenie źdźbeł trawy na łące.

Jasne, że sensowne i przydatne. Wręcz nie rozumiem nieco jak można się dziwić, że programista liczy ile linijek kodu zajmuje mu np procedura. W algorytmice jest to jeden z etapów wręcz.

Ciekaw jak mówią, że jądro linuksa ma 10+ mln linijek, albo Winda ileś tam, jak to podali czy z pustymi linijkami? ;D

Ja nie liczę sam, używam SLOCCount.

polaczek17 napisał(a)

Jasne, że sensowne i przydatne.

Przy masturbacji klonem Painta może tak. Jak dotychczas jesteś chyba jedynym użytkownikiem 4p, który chwalił się ilością linii w swoim projekcie.

polaczek17 napisał(a)

Wręcz nie rozumiem nieco jak można się dziwić, że programista liczy ile linijek kodu zajmuje mu np procedura.

Funkcja powinna mieć tylko tyle linii, ile musi mieć. Najlepiej żeby miała ich tylko kilka, jasno realizując konkretne zadanie. Co tu liczyć?

polaczek17 napisał(a)

W algorytmice jest to jeden z etapów wręcz.

Powiedz, że to irionia, proszę... W algorytmice pojęcie "linijki kodu" nie istnieje wcale, algorytmy to koncepcje, kod jest specyficzny dla danego języka. Co tu porównywać? Quicksort w C na trzydzieści linii i ten sam algorytm w Haskellu na jedną albo dwie? Jakie to użyteczne informacje daje?

Klepacze rozkręcają wątek o przedłużaniu penisa kodem.

A nie słyszałeś ani nie czytałeś o ludziach którzy fanatycznie zmniejszają algorytmy do granic możliwości. Chociażby wspomniany przez Ciebie Quicksort był na wszystkie strony przerzucany, aż chyba skrócono go do 3 linijek. (dwie funkcje plus trzecia wywołanie rekurencji). Tak czy owak są ludzie którzy tym się zajmują.
Funkcja powinna mieć linijek jak najmniej, ale jak się dowiesz ile ma skoro nie policzysz ich? Nie musisz? No owszem, ale mi np daje wewnętrzny spokój gdy wiem, że funkcja ma mniej niż 15 linijek.
Co innego oceniać cały projekt. Taka informacja jest tylko "dla zabawy" bo przecież ilość linii kodu nie odzwierciedla jakości.

polaczek17 napisał(a)

A nie słyszałeś ani nie czytałeś o ludziach którzy fanatycznie zmniejszają algorytmy do granic możliwości. Chociażby wspomniany przez Ciebie Quicksort był na wszystkie strony przerzucany, aż chyba skrócono go do 3 linijek. (dwie funkcje plus trzecia wywołanie rekurencji). Tak czy owak są ludzie którzy tym się zajmują.

To się nazywa choroba psychiczna. Nie ma to ani zastosowania, ani związku z algorytmiką.

polaczek17 napisał(a)

Funkcja powinna mieć linijek jak najmniej, ale jak się dowiesz ile ma skoro nie policzysz ich? Nie musisz? No owszem, ale mi np daje wewnętrzny spokój gdy wiem, że funkcja ma mniej niż 15 linijek.

Jejku, a jak ma 16 to co, uciekać? Jak Ci to daje wewnętrzny spokój to może czas zmienić leki. Nie muszę niczego liczyć bo ilość linii to tylko pochodna sposobu zapisu. Ma najmniej wtedy, kiedy nie ma w niej niczego zbędnego. Czy po ilości linijek ocenisz, czy jest coś zbędnego? Czy po ilości linii ocenisz, ile zadań dana funkcja realizuje? Nie?

Popadasz w skrajności. 16, 14, 20. To nie ma znaczenia i dobrze o tym wiesz. Gorzej jak ma 25. Wtedy z pewnością da się coś skrócić lub inaczej napisać lub po prostu oddzielić na kolejne funkcje. To ma sens i zwiększa czytelność kodu mimo, że nie odczytasz przez to ile zadań funkcja realizuje. Zresztą wydaje mi się naturalne, że skraca się funkcje, chyba nikt przy zdrowych zmysłach nie pisze tasiemców co? O_o

Sensowne czy nie... Raczej tak z ciekawości, żeby wiedzieć ile się już tego kodu wyprodukowało. No i dobrze zmierzyć np. przed refaktoryzacją projektu i po niej, żeby wiedzieć o ile udało się kod zmniejszyć. Można też napisać ten sam projekt np. w C i Javie, a potem sprawdzić, który wyszedł dłuższy.

A jeśli np. ja bym dał kod funkcji na 100 linijek z czego 98 to są polecenia assemblera to jest to dużo czy nie? Tak się tylko pytam bym wiedział czy zbesztać twórców GMP, że nie potrafią pisać optymalnych i szybkich algorytmów bo ich funkcje są takie rozlazłe.

Tak więc pytanie, który z tych kodów jest wydajniejszy:

int my_abs(int a) {
   return a < 0 ? -a : a;
}

czy

int my_abs(int a) {
   int mask = (a >> (sizeof(int) * CHAR_BIT - 1));
   return (a + mask) ^ mask;
}

Pierwszy jest krótszy i bardziej intuicyjny, ale drugi ma pewną istotną cechę, może powiesz mi jaką.

Chodzi Ci o CHAR_BIT i operacje bitowe?
Po 1.) Nigdzie nie napisałem, że mniejszy bardziej zwięzły kod jest zawsze szybszy.
po 2.) Kod w pierwszej kolejności powinien być czytelny a nie szybki.

polaczek17 napisał(a)

Przecież zarówno w ASM-ie jak i w każdym innym języku można pisać algorytmy rozległe i zwięzłe. Wydajne i nie.

Tak polaczku, tak. Quicksort w C siłą rzeczy będzie dłuższy niż insertion sort, będzie bardziej rozwlekły. W Haskellu natomiast quicksort będzie krótszy od insertion sorta. Jak to się ma do wydajności? Ach, wydajność... Wiele technik optymalizacji pod względem wydajności powoduje wydłużenie kodu. Znowu rzucasz puste frazesy.