JS – czytelna rekurencja

Powiemy sobie co nieco o czytelności funkcji rekurencyjnych. Tę samą funkcję napiszemy w sposób mniej i bardziej czytelny. Do dzieła.

Oto nasz przykład, dodam że pochodzi z ogólnie bardzo dobrego kursu:

function flatten(oldArr){
  var newArr = []
  	for(var i = 0; i < oldArr.length; i++){
    	if(Array.isArray(oldArr[i])){
      		newArr = newArr.concat(flatten(oldArr[i]))
    	} else {
      		newArr.push(oldArr[i])
    	}
  } 
  return newArr;
}

Pytanie pierwsze – czy ten kod jest czytelny dla interpretera JavaScript? Dlaczego/dlaczego nie?

Cóż, to już czepialstwo, ale do końca nie jest. Brakuje średników. JavaScript ma natomiast mechanizm ASI (automatic semicolon insertion). Aczkolwiek pamiętać należy, że wielolinijkowy return + brak średnika = średnik brutalnie wsadzony w koniec pierwszej linijki returna.

Cóż, coś za coś, albo sami zawsze te średniki stawiamy, albo robi to interpreter za nas, ale tworzy to edge-cases, które musimy znać, zanim sobie kiedykolwiek na niedbalstwo zaczniemy pozwalać.

Dobra, czy funkcja flatten jest czytelna dla człowieka?

Jest, nie jest, zobaczmy sobie inne podejście:

const flatten = (nestedArr) => {
    
    const flatArr = [];

    const _flatten = (arr) => {

      let counter = 0;

      while (counter < arr.length) {

        const val = arr[counter];

        if (Array.isArray(val)) 
          _flatten(val);
        else 
          flatArr.push(val);
        
        counter++;
      }
    
    }

    _flatten(nestedArr);

    return flatArr;
  }

• Tablica przechowywana w funkcji wyższego rzędu dostępna poprzez domknięcie
• Funkcja pomocnicza
• Czytelna pętla
• Czytelny warunek, wiadomo o co chodzi
• Same nazwy też są czytelne co znacząco ułatwia zrozumienie algorytmu kryjącego się za funkcją

Czysty kod ułatwia jego zrozumienie. Tak, jest wiele „miskoncepcji”. Że trzeba wszędzie pisać komentarze, że do wszystkiego wzorce projektowe stosować (nawet gdy nie trzeba) i tak dalej…

Natomiast jeżeli ktoś dotychczas pisał komentarzowe elaboraty i właśnie zdał sobie sprawę z głupoty tego, niech poprzestanie na pisaniu sygnatur (co przyjmuje, co zwraca funkcja) i absolutnie nie zarzuca idei czystego kodu tylko dlatego, że coś się tam okazało głupotą.

Bo z doświadczenia wiem, że ucząc się, na samym początku łatwo z jednej skrajności w drugą popaść.