Zatem weź fragment kodu, który chcesz sprawdzić i:
- Operatory zamień na słowa
- Klamerkę "{" po ifie zamień na "then"
- Rozbij nazwy camel case na pojedyncze wyrazy
- Z wyrażeń przypisania bierz pod uwagę tylko prawą stronę, lewą ignoruj
- Każdy wiersz kodu traktuj jako osobne zdanie zakończone kropką.
- Tak powstały tekst wklej do syntezatora mowy ivona.com
- Jeśli to, co słyszysz (bez patrzenia na kod), jest w pełni zrozumiałe, to kod jest czytelny :)
Weźmy taki przykład na przykład:
public class List {
private final static int DEFAULT_SIZE = 10;
private Object[] elements;
private boolean readOnly;
private int size;
public List() {
elements = new Object[DEFAULT_SIZE];
size = DEFAULT_SIZE;
}
public void add(Object element) {
if (!readOnly) {
int newSize = size + 1;
if (newSize > elements.length) {
Object[] newElements = new Object[elements.length+10];
for (int i = 0; i < size; i++) {
newElements[i] = elements[i];
}
elements = newElements;
}
elements[size++] = element;
}
}
}
Dla metody
add
tekst będzie następujący:If not read only.
Size plus one.
If new size greater than elements length then.
New objects size of elements length plus one.
For each elements: i of elements.
New elements.
Element.
No, a teraz wklej do ivona.com i słuchaj :) Ma sens?
A teraz niewielki refaktoring metody
add
związany przede wszystkim nazywaniem i pierwszymi dwoma krokami Naturalnego Porządku Refaktoryzacji. Metoda przybiera następującą postać:
public void add(Object anElement) {
if (readOnly) {
return;
}
if (atCapacity()) {
grow();
}
put(anElement, into(elements));
}
private Object[] into(Object[] elements) {
return elements;
}
private void put(Object anElement, Object elements[]) {
elements[size++] = anElement;
}
private boolean atCapacity() {
return size + 1> elements.length;
}
private void grow() {
Object[] newElements = new Object[elements.length + 10];
for (int i = 0; i < size; i++) {
newElements[i] = elements[i];
}
elements = newElements;
}
Tym razem tekst dla Ivony jest następujący:
If read only then return.
If at capacity then grow.
Put an element into elements.
Ponownie odsłuchaj, co Twój kod ma Ci do powiedzenia. Lepiej? :)
Swietne!!!
ReplyDeleteFajny pomysł
ReplyDeleteZgadzam się z Kubą, ale sam nie zastosuję, jeszcze by po drodze, Ivona sama nauczyła się kląć :(
ReplyDeleteZ miesiąca na miesiąc zmierzasz coraz bliżej do Domain Driven Design:P
ReplyDeleteDzięki DDD kodzik czyta się niczym prozę...
@Sławek Sobótka
ReplyDeleteMaj frend. Czytelność kodu była tematem szeroko dyskutowanym na długo przed tym zanim ewangeliści DDD zauważyli, że istnieje świat poza Smalltalk :)
@Sławek
ReplyDeletei nie dzięki DDD tylko dzięki: Malvinowi Conway'owi, Steve'owi McConnellowi, Kentowi Backowi i innym, których nazwisk niestety teraz nie pamiętam.
Ehh za szybko pochwaliłem:P
ReplyDeleteDDD idzie o krok dalej: czytelność (czyli forma) to jedna rzecz, ale co z treścią? Innymi słowy co nam po czytelności, jeżeli wyczytamy z tego bełkot...