Cod mai bun, fără niciun efort, chiar și fără AI

Ne confruntăm cu o revoluție a programării, cu democratizarea inteligenței artificiale, dar de asemenea, cu crearea și îmbunătățirea unor instrumente software mai tradiționale pentru a vă îmbunătăți codul: local, gratuit, determinist.

În această postare, vă vom prezenta

📦 lintr, de Michael Chirico și mulți alții, un pachet R care detectează multe modalități de a-ți îmbunătăți codul;
💻$ Air, de Lionel Henry și Davis Vaughan, un CLI rapid (interfață de linie de comandă) pentru formatarea codului R automat și aproape instantaneu;
💻$ jarl, de Etienne Bacher, un alt instrument rapid CLI (interfață de linie de comandă) pentru a găsi și a remedia automat scame;
📦 flir, de Etienne Bacher, un pachet R pentru a rescrie eficient modelele de cod, fie cele încorporate, fie personalizate.

Cu aceste patru instrumente minunate, vă puteți îmbunătăți fără efort codul, codul colegilor… și chiar codul propus de AI. Cu puțin mai mult efort, s-ar putea chiar să interiorizați cele mai bune practici și să scrieți cod mai bun de la început în viitor!

Un exemplu de script

Să începem cu un script care conține câteva probleme… Le poți identifica?

lleno <-!any(is.na(x))
ok<- !(x(1) == y(1))
if (ok) z<- x + 1
if (z>3) stop("ouch")

Consola R vs terminal

Rețineți că în această postare, unele instrumente sunt folosite în consola R, dar altele sunt folosite în terminal, pe care le puteți cunoaște și ca linie de comandă sau shell.

Aflați ce să îmbunătățiți cu pachetul {lintr} R 📦

Un prim instinct ar putea fi să rulați pachetul lintr pe script. The lint() funcția efectuează o analiză statică și evidențiază probleme potențiale din codul dvs. R, inclusiv sugestii de formatare și programare.

lintr::lint("test.R", linters = lintr::all_linters())

#> index.Rmd:148:32: warning: (nonportable_path_linter) Use file.path() to construct portable file paths.
#> flir::fix("test.R", linters = "flir/rules/custom/stop_abort.yml")
#> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#> test.R:1:7: style: (infix_spaces_linter) Put spaces around all infix operators.
#> lleno <-!any(is.na(x))
#> ^~
#> test.R:1:10: warning: (any_is_na_linter) anyNA(x) is better than any(is.na(x)).
#> lleno <-!any(is.na(x))
#> ^~~~~~~~~~~~~
#> test.R:2:3: style: (infix_spaces_linter) Put spaces around all infix operators.
#> ok<- !(x(1) == y(1))
#> ^~
#> test.R:2:6: warning: (comparison_negation_linter) Use x != y, not !(x == y).
#> ok<- !(x(1) == y(1))
#> ^~~~~~~~~~~~~~~
#> test.R:2:11: style: (implicit_integer_linter) Use 1L or 1.0 to avoid implicit integers.
#> ok<- !(x(1) == y(1))
#> ~^
#> test.R:2:19: style: (implicit_integer_linter) Use 1L or 1.0 to avoid implicit integers.
#> ok<- !(x(1) == y(1))
#> ~^
#> test.R:3:10: style: (infix_spaces_linter) Put spaces around all infix operators.
#> if (ok) z<- x + 1
#> ^~
#> test.R:3:19: style: (implicit_integer_linter) Use 1L or 1.0 to avoid implicit integers.
#> if (ok) z<- x + 1
#> ~^
#> test.R:4:6: style: (infix_spaces_linter) Put spaces around all infix operators.
#> if (z>3) stop("ouch")
#> ^
#> test.R:4:8: style: (implicit_integer_linter) Use 3L or 3.0 to avoid implicit integers.
#> if (z>3) stop("ouch")
#> ~^
#> test.R:4:10: warning: (condition_call_linter) Use stop(., call. = FALSE) not to display the call in an error message.
#> if (z>3) stop("ouch")
#> ^~~~~~~~~~~~

Prin urmare, primim alerte despre

stil: spațiu în jurul operatorilor infix, de exemplu; întreg implicit.
performanţă: anyNA(x) este mai bun decât any(is.na(x)).

Deoarece lintr există de mult timp, are o colecție impresionantă de reguli, „linters”. Chiar și citirea documentației lor vă poate învăța multe, mai ales că lista crește în timp!

Acum, pe baza acestor alerte, cum am putea îmbunătăți codul?

Format cu Air 💻$

Air este un software care formatează automat codul dvs. R conform unui set de reguli.

În terminal:

air format test.R

Si asta revine:

lleno <- !any(is.na(x))
ok <- !(x(1) == y(1))
if (ok) {
 z <- x + 1
}
if (z > 3) {
 stop("ouch")
}

Acum, spațierea în cod este obișnuită! The if condiția este, de asemenea, formatată pe trei linii în loc de doar una. În general, codul este mai ușor de citit, deoarece acum respectă convențiile populare.

Rețineți că lintr și Air ar putea avea sfaturi contradictorii cu privire la stil: puteți dezactiva regulile legate de stil ale lintr dacă utilizați Air.

Îmbunătățiți-vă cu noul jarl CLI! 💻$

CLI-ul jarl îți lasă și repară codul și, ca și lintr, identifică probleme potențiale, dar spre deosebire de lintr, jarl aplică și remedieri!

În terminal:

jarl check test.R --fix

lleno <- !anyNA(x)
ok <- !(x(1) == y(1))
if (ok) {
 z <- x + 1
}
if (z > 3) {
 stop("ouch")
}

any(is.na(x)) a fost înlocuit automat cu anyNA(x)!

Jarl CLI este la fel de rapid pentru verificarea și fixarea scamelor ca și Air pentru coafare. În plus, deoarece este un simplu binar care nu are nevoie de R pentru a rula, este mai rapid de instalat pe integrare continuă decât un pachet R (care are nevoie de R pentru a fi instalat, de exemplu).

Cu toate acestea, deoarece jarl este mai nou decât lintr, acceptă mai puține reguli pentru moment.

Îmbunătățiți-vă cu pachetul {flir} R 📦

Puteți completa utilizarea lintr, Air și jarl cu flir, care este mai bine reguli personalizate. De exemplu, ce se întâmplă dacă preferați să utilizați baza de cod rlang::abort() în loc de stop()?

Mai întâi alergăm

flir::setup_flir(getwd())

Salvăm fișierul de mai jos sub flir/rules/custom/stop_abort.yml.

id: stop_abort-1
language: r
severity: warning
rule:
 pattern: stop($$$ELEMS)
fix: rlang::abort(paste0(~~ELEMS~~))
message: Use `rlang::abort()` instead of `stop()`.

Fugim apoi

flir::fix("test.R", linters = "flir/rules/custom/stop_abort.yml")
#> ℹ Going to check 1 file.
#> ✔ Fixed 1 lint in 1 file.

lleno <- !anyNA(x)
ok <- !(x(1) == y(1))
if (ok) {
 z <- x + 1
}
if (z > 3) {
 rlang::abort(paste0("ouch"))
}

Apelul la stop() a fost înlocuit automat. Acum, s-ar putea să dorim apoi să eliminăm manual cele inutile paste0()dar suntem deja mai aproape de un scenariu ideal.

Integrarea acestor instrumente în fluxul dvs. de lucru

La nivel local, puteți utiliza aceste instrumente după cum este necesar. De exemplu, atunci când moștenesc un proiect mai vechi, primul lucru pe care îl fac este să renovez proiectul aplicând aceste instrumente. Un adevărat schimbător de joc este utilizarea integrarii acestor instrumente cu IDE-ul tău. De exemplu, am configurat Positron astfel încât Air să ruleze pe scripturile mele când le salvez. Jarl CLI oferă, de asemenea, integrări cu IDE-uri.

De asemenea, puteți utiliza aceste instrumente pentru integrarea continuă. De exemplu, un flux de lucru util ar putea fi sugerarea modificărilor de formatare a solicitărilor de extragere. Folosirea sugestiilor mai degrabă decât a unui commit direct înseamnă că contribuitorul are șansa de a afla despre îmbunătățiri.

Un alt aspect de luat în considerare este dacă doriți să flir și jarl face schimbările spre deosebire de alertând tu despre ei. Ceea ce alegeți depinde de context, de exemplu, puteți afla mai multe făcând modificările dvs. În orice caz, este important să analizați corect modificările înainte de a le efectua!

Dar inteligența artificială?

Inteligența artificială poate fi utilă în aplicațiile de codare, dar…

Cele mai bune LLM nu sunt locale;
Costă bani și sunt mai lente;
Nu sunt deterministe, așa că nu obțineți neapărat același rezultat de fiecare dată când utilizați unul dintre ele;
Utilizarea lor poate atrage unele probleme ideologice și etice care pot fi îngrijorătoare sau neatractive.

În cele din urmă, pentru astfel de alerte și remedieri, pur și simplu nu trebuie să utilizați un LLM… Air, flir, jarl și lintr fac deja o treabă excelentă, sunt mai rapide și sunt gratuite (ca să nu mai vorbim de FOSS)!

Concluzie

Vă puteți îmbunătăți codul fără efort, fără chiar AI, folosind:

{lintr} pentru a semnala modele „rele”, inclusiv cele personalizabile;
Air, pentru a reformata eficient codul;
jarl, pentru a detecta și remedia tipare „rele”;
{flir}, pentru a refactori eficient codul cu reguli personalizate.

Ca și în cazul tuturor instrumentelor care vă modifică codul, utilizarea lor este completată cel mai bine de o analiză umană.