> Zasada jest taka że jeśli kod
> kontrolujący stan miałbym mieć więcej linijek niż goły algorytm to
> *zaciemnia* kod

Tak, to ważna obserwacja. Może da się te rzeczy rozdzielić? Tak jak rozdziela się
interfejs od implementacji? Zwłaszcza wtedy, gdy jakieś warunki faktycznie należą do
interfejsu? Akurat niezmienniki pętli należą do implementacji (i potrafią pięknie
zaciemnić kod), ale takie rzeczy jak "parametr powinien być między 0 a 20" albo
"wartość zwracana powinna być w zakresie indeksów tablicy" to intefejs. I może da się
to wtedy zapisać gdzieś w okolicy deklaracji tak, żeby użytkownik to widział (i mógł
się pod to sprawdzić)? Tak działa SPARK i przyznam, że podoba mi się.

> Po jakiś 20 latach stukania w klawisze
> widziałem kod opakowany DbC po brzegi i wymagał on niesłychanie dużo
> czasu aby zorientować się gdzie jest algorytm a gdzie checkery.

Czy czytelność kodu nie jest też kwestią umiejętności piszącego? Nie zawsze sama
koncepcja programistyczna musi ją przekreślać. Tzn. to nie musi być wina DbC, że kod
jest nieczytelny.

> Znacznie
> bardziej ufam unit testom i coverage niż ręcznie pisanym DbC.

W porządku. Testy też są potrzebne. A co jeśli część DbC można sprawdzić statycznie?
Wtedy ich wartość jest inna, niż testów. A co jeśli wtedy można by niektórych testów
w ogóle nie mieć? Unit testy to też koszt. Jeśli można tego kosztu nie mieć, to jest
to wartość dodana.

> Być może
> to jednak efekt języka, czyi w moim przypadku C++, nie wykluczam że
> można to czytelniej zapisać gdzie indziej.

A może wtedy należy odwrócić kolejność i zamiast szukać języka, gdzie to jest
czytelne (albo zamiast doklejać DbC do używanego języka), można taki język zrobić? W
sensie - zamiast rezygnować z DbC, bo jest nieczytelny, zróbmy język tak, żeby to
było czytelne.
To nie są zupełnie teoretyczne pytania.

--
Maciej Sobczak * http://www.inspirel.com