R Calitatea pachetului: Calitatea codului

Aceasta este partea a patra a unei serii de cinci părți de postări conexe cu privire la validarea pachetelor R. Alte postări din serie sunt:

În această postare, vom arunca o privire mai atentă asupra calității codului și a modului în care putem folosi instrumente automate pentru a obține rapid o idee pentru un pachet. Verificarea evidentă a pachetului este R CMD check. Oricine a creat un pachet, este familiarizat cu alergarea constantă R CMD check pentru a se asigura că pachetul lor este notat, avertizare și fără erori. Cu toate acestea, acesta nu este singurul instrument pe care îl putem desena. Dimensiunea Codebase, vulnerabilitățile de securitate și numărul de funcții exportate toate oferă un indiciu calității pachetului.

La validarea pachetelor R, calitatea codului contribuie cu aproximativ 50% la total. Nu uitați să consultați tabloul de bord pentru a obține o imagine de ansamblu.

Scorul 1: trecerea r cmd verificare

Partea de bază a tuturor pachetelor R bune! Pachetele sunt descărcate, instalate și standardul R CMD check este efectuat. Scorul este suma ponderată a erorilor (1) și avertismente (0,25), cu un scor maxim de 1 (fără erori sau avertismente) și un scor minim de 0. În esență, metrica va permite până la 1 eroare sau 4 avertismente înainte de a returna cel mai mic scor de 0.

Lucrăm la a fi mai discernant la note și avertismente, dar tocmai acum, este o metrică relativ simplă care evidențiază pachetele cu probleme potențiale.

Scorul 2: dimensiunea codului de cod

Acest scor se bazează pe dimensiunea R Codebase, determinată de numărul de linii de cod R. Ideea generală este că bazele de cod mai mari sunt mai greu de întreținut. Desigur, întrebarea evidentă este „Ce este o bază R mare”?

În loc să venim cu numere arbitrare, am analizat toate pachetele de pe CRAN (2025/03). Dacă un pachet este în quartile inferioare pentru dimensiunea codului, pachetul este notat 1. În caz contrar, se folosește CDF empiric.

Pentru cei interesați, cel mai mare pachet R de pe CRAN a avut 100.000+ linii de cod R!

Scorul 3: vulnerabilități de securitate

Dacă un pachet are o vulnerabilitate de securitate cunoscută, acesta primește un scor de 0. Aceasta folosește {oysteR} Pachet pentru a detecta problemele.

Scorul 4: Eliberare

Acesta este un scor binar, dacă pachetul aflat în evaluare este cea mai recentă versiune, este marcat 1. În caz contrar, un 0 este returnat. Am investigat folosind un sistem de notare mai sofisticat bazat pe versiuni minore și majore. Dar în cadrul comunității R, versiunea semantică nu este urmată în mod constant, așa că am optat pentru o regulă mai simplă.

Scorul 5: dimensiunea spațiului de nume exportat

Scor un pachet pe baza numărului de obiecte exportate. Mai puține obiecte exportate înseamnă că suprafața de risc este mai mică, iar erorile sunt potențial mai puțin probabile. Similar cu dimensiunea Codebase, întrebarea este ce este mare? Analizând toate pachetele de pe CRAN, ne-a oferit decupaje adecvate. Dacă un pachet se află în quartile inferioare pentru numărul de exporturi, pachetul este notat 1. În caz contrar, se folosește CDF empiric.

Analiza noastră despre CRAN sugerează că majoritatea pachetelor exportă relativ puține obiecte. Un pachet modest care exportă 11 obiecte scor 0,5. Exportul în jur de 26 de obiecte reduce acest lucru la aproximativ 0,25.

Scorul 6: Acoperirea testului unitar

Scor pe baza fracției de linii de cod care sunt acoperite de un test unitar. Pentru validarea pachetelor din sectorul farmaceutic, oferim, de asemenea, teste unitare suplimentare (acoperire de cod remediată) și investigăm acoperirea testului funcției exportate.

Scorul 7: dependențe

Scor pe baza numărului de dependențe pe care un pachet îl are, presupunând un scor mai mic pentru mai multe pachete. „Sugerează”, „Îmbunătățirile”, pachetele de bază sau recomandate nu sunt considerate dependențe atunci când se calculează acest scor.

Acesta este un scor bazat pe date, bazat pe toate pachetele din CRAN (2025/03). Dacă un pachet este în quartile inferioare pentru numărul de dependențe de pachete, pachetul este notat 1. În caz contrar, se folosește CDF empiric. În practică, acest lucru înseamnă că pachetele cu aproximativ 5 dependențe sunt notate 0,5, ceea ce scade la 0 în jur de douăzeci de dependențe.

Dependențele pot fi un subiect emotiv! La fel ca în cazul tuturor celorlalte scoruri, această metrică nu este „să fie totul și să se încheie toate”, în schimb este doar o indicație a fragilității pachetului.

Exemple

Pentru simplitate, am eliminat coloanele pe vulnerabilități, verificarea și eliberarea R CMD, ca pentru toate pachetele, scorul a fost 1.

Scorurile de mai sus indică faptul că {tibble} şi {tsibble} sunt pachete relativ mari, complexe. Aceste pachete exportă multe funcții și au mai multe dependențe. În mod liniștit, au o acoperire ridicată a testelor.

{shinyjs} Pachetul are o acoperire îngrijorător de scăzută. Cu toate acestea, inspecția codului arată că există multe teste manuale care nu sunt capturate. Acest lucru evidențiază un aspect cheie, automat nu este suficient, în special în setarea validată. O parte din Litmus este ca o persoană calificată să evalueze pachetul.

Pentru actualizări și revizii la acest articol, consultați postarea originală