Ten bajer sprawdza nam czy piszemy “idiomatic code”.
A co to ten cały “idiomatic code”?
Jest to kod który osiąga założony cel przy wykorzystaniu odpowiednich funkcji języka, w sposób jaki inni programiści, zaznajomieni z ów językiem, będą w stanie go zrozumieć.
W skrócie: czy kod który piszemy spełnia “good practices” danego języka.
Dla przykładu:
Zarówno Java jaki i C# mają swoje “good practice” dla formatu klamr okalających funkcje:
Java:
public static void main(String args[]){
...
}
C#:
public static void Main(string[] args)
{
...
}
W clojure kitbit będzie nam podpowiadał zmiany pokroju:
Consider using:
(zero? x)
instead of:
(= 0 x)
Eastwood
Tutaj mamy do czynienia z większym narzędziem.
Ciężko wymienić wszystko co sprawdza Eastwood więc tylko kilka:
Misplaced docstrings
Function or macro doc strings placed after the argument vector, instead of before the argument vector where they belong.
Poprawnie:
(defn my-function
"Do the thing, with the stuff. Fast."
[thing stuff]
(conj stuff thing))
Niepoprawnie:
(defn my-function [thing stuff]
"Do the thing, with the stuff. Fast."
(conj stuff thing))
Suspicious Test
Tests using clojure.test that may be written incorrectly.
Jak widać z przykładów, Eastwood zajmuje się konkretnymi błędami w przeciwieństwie do Kibita który sprawdza stylistykę.
Warto posiadać oba!
Skoro mamy już narzędzia to czemu by ich nie wcisnąć w istniejący proces ciągłej integracji?
Tutaj z pomocą przyjdzie nam Codeclimate.
Codeclimate
Jest to serwis działający w podobie do opisywanego wcześniej CodeCov.
Integruje się z githubem i przy commicie do głównej gałęzi wyszukuje problemy w kodzie.
Dla clojure wykorzystywany jest kitbit – więc problemy ze stylistyką będziemy mogli śledzić na bieżąco.
Niestety brakuje wsparcia dla Eastwooda – pozostaje uruchamiać go ręcznie.
Kitbit w Codeclimate dla RL-EngineKitbit w Codeclimate dla RL-Engine
Jarkeeper
Taka wisieńka na torcie.
Sprawdza czy wszystkie zależności w naszym projekcie są aktualnie.
Udostępnia raport dla dowolnego repozytorium (publicznego ofc) na githubie w formie przycisku.
RL-Engine
Myślę, że na tym zamkniemy temat Continous Integration w RL-Engine…
Przynajmniej na jakiś czas 🙂
Be First to Comment