Narzędzia użytkownika

Narzędzia witryny


ewdrstyle

Różnice

Różnice między wybraną wersją a wersją aktualną.

Odnośnik do tego porównania

Both sides previous revision Poprzednia wersja
Nowa wersja
Poprzednia wersja
Ostatnia wersja Both sides next revision
ewdrstyle [2015/06/30 13:32]
t.zoltak [Weryfikacja poprawności argumentów funkcji (run-time testing//)]
ewdrstyle [2015/07/01 15:36]
t.zoltak [Metody weryfikacji argumentów funkcji]
Linia 1: Linia 1:
-======Zasady formatowania kodu R w projekcie EWD======+======Dobre praktyki tworzenia kodu====== 
 + 
 +=====Zasady formatowania kodu R w projekcie EWD=====
  
   * Zasadniczo trzymamy się zasad z [[https://​google-styleguide.googlecode.com/​svn/​trunk/​Rguide.xml|Google'​s R Style Guide]]   * Zasadniczo trzymamy się zasad z [[https://​google-styleguide.googlecode.com/​svn/​trunk/​Rguide.xml|Google'​s R Style Guide]]
Linia 75: Linia 77:
       * za regułę kciuka przyjmujemy,​ że nadmiernie długa linia to linia o więcej niż 80 znakach.       * za regułę kciuka przyjmujemy,​ że nadmiernie długa linia to linia o więcej niż 80 znakach.
  
-======Weryfikacja poprawności argumentów funkcji (//run-time testing//​)======+=====Weryfikacja poprawności argumentów funkcji (run-time testing)===== 
 + 
 +====Ogólne zasady weryfikacji argumentów funkcji==== 
 + 
 +  * Generalnie przyjmujemy zasadę, że **funkcje powinny weryfikować poprawność przekazywanych do nich argumentów**. W przypadku tworzenia pakietów zasada ta powinna być bezwzględnie przestrzegana w odniesieniu do funkcji, które są eksportowane. 
 +  * Jeżeli w funkcji implementowana jest opcjonalna konwersja typów argumentów (np. jeśli argument powinien być wektorem liczb całkowitych,​ ale jest wektorem logicznym, można skonwertować go na wektor liczb całkowitych),​ to **dokonanie konwersji typów powinno wiązać się z wygenerowanie ostrzeżenia widocznego dla użytkownika**. 
 +  * Minimalny zakres weryfikacji obejmuje: 
 +    * Zgodność typów (w przypadku argumentów o bardziej złożonej strukturze, ale posiadających przypisane klasy - zgodność klas). 
 +    * Zakres dozwolonych wartości - jeśli dotyczy. 
 +    * Długość (liczba elementów) - jeśli dotyczy (odnosi się to głównie do parametrów sterujących procesem, które z założenia mają być skalarami). 
 +  * Ewentualne rozszerzanie zakresu weryfikacji ponad wyżej wymienione (typowo bardziej szczegółowe sprawdzanie struktury złożonych argumentów) należy rozważać w odniesieniu do: 
 +    * Skutków niewykrycia niezgodności. 
 +    * Szacowanego prawdopodobieństwa wystąpienia niezgodności. 
 +    * Złożoności kodu weryfikującego w stosunku do złożoności całej funkcji. 
 +    * Obciążenia obliczeniowego związanego z weryfikacją. 
 + 
 +====Metody weryfikacji argumentów funkcji==== 
 + 
 +Spośród opisanych niżej metod **preferowane jest wykorzystanie funkcji pakietu ​//assertive//​** w rozsądnym połączeniu z użyciem warunków do obsługi bardziej skomplikowanych sytuacji (w szczególności ostrzeżeń i konwersji typów, jeśli funkcja takowe wykonuje)
 + 
 +[[pakietassert|Przewodnik po funkcjach pakietu assertive.]] 
 + 
 +===Stosowanie warunków=== 
 + 
 +  * **Zalety:​** 
 +    * Elastyczne. 
 +    * Umożliwia zwracanie czytelnych komunikatów o błędach i/lub ostrzeżeń. 
 +  * **Wady:** 
 +    * Wymaga pisania bardzo dużo kodu, co jest uciążliwe i często czyni kod nieczytelnym. 
 +  * **Przykład:​**<​code>​moja_funkcja = function(x) { 
 +  if (any(is.na(x)) { 
 +    stop("​Argument '​x'​ nie może zawierać braków danych!"​) 
 +  } else { 
 +    return(x) 
 +  } 
 +}</​code>​ 
 + 
 +===Stosowanie funkcji stopifnot()=== 
 + 
 +  * **Zalety:​** 
 +    * W typowych, niezbyt złożonych sytuacjach, krótki i czytelny kod. 
 +  * **Wady:** 
 +    * Niezbyt przyjazne użytkownikowi komunikaty o błędach. 
 +    * Obsługa wyłącznie błędów (ale ostrzeżeń już nie). 
 +  * **Przykład:​**<​code>​moja_funkcja = function(x) { 
 +  stopifnot(all(!is.na(x)) 
 +  return(x) 
 +}</​code>​ 
 + 
 +===Stosowanie funkcji pakietu assertive=== 
 + 
 +[[pakietassert|Przewodnik po funkcjach pakietu assertive.]] 
 + 
 +  * **Zalety:​** 
 +    * Krótki i czytelny kod w szerokim zakresie zastosowań (nieco szerszym niż //​stopifnot()//​). 
 +      * Wiele warunków i formatów, z którymi można sprawdzać zgodność. 
 +      * Automatyzacja najbardziej typowych kombinacji warunków w pojedynczych funkcjach. 
 +    * Przyjazne użytkownikowi komunikaty o błędach. 
 +  * **Wady:** 
 +    * Nic nie będzie równie elastyczne, jak używanie //if//. 
 +    * Wymaga trochę czasu, żeby zorientować się w mnogości funkcji udostępnianych przez pakiet. 
 +  * **Przykład:​**<​code>​moja_funkcja = function(x) { 
 +  assert_all_are_not_na(x) 
 +  return(x) 
 +}</​code>​
ewdrstyle.txt · ostatnio zmienione: 2016/10/03 21:16 przez t.zoltak