Andrzej Jarzabek wrote:

>>> Powiedzmy
>>> masz licznik czegośtam w postaci inta, który musi być podbijany z
>>> kilku różnych wątków, więc dodajesz mutex i komentarz, że ten mutex
>>> służy do zabezpieczania licznika, który jest podbijany z kilku wątków.
>>> A może zamiast tego lepiej zrobić klasę i nazwać ją ThreadSafeCounter,
>>> to komentarz przestanie być potrzebny.
>>
>> Ten przykład jest bezsensowny.
>> Jeśli jest użyty mutex, to wiadomo że jest synchronizacja między wątkami
>> i nie trzeba tego dodatkowo komentować.
>
> Ale nie wiadomo, co konkretnie dany mutex synchronizuje.

Synchronizuje ten fragment, wokół którego jest użyty. To w kodzie widać.

>> Swoją drogą... jaki interfejs do ThreadSafeCounter uznałbyś za właściwy:
>> atomic_inc(counter) / synchronized_inc(counter), czy ++counter ?
>
> Z zasady nie lubię skrótów typu 'inc'. Zrobiłbym ++counter albo
> counter.increment(), ale raczej nie traciłbym czasu na zastanawianie się
> nad tym zbyt długo.

Wg mnie słówko atomic, bądź synchronized jest konieczne - aby wyraźnie
oznaczyć, że to jest operacja z synchronizacją między wątkami. I że w razie
problemów z wydajnością na wielu procesorach, należy się przyjrzeć także
temu fragmentowi.

>> Czasem zdarza mi się (nie w ramach pracy) używać jakichś bardzo
>> specyficznych algorytmów, np. z zakresu przetwarzania sygnałów. Robię to
>> bardzo rzadko i bez komentarzy absolutnie nie domyśliłbym się dlaczego
>> jest tak a nie inaczej, bo czasem ciężko zrozumieć jakim cudem dany
>> algorytm w ogóle działa i kroki do osiągnięcia celu wydają się na prawdę
>> dziwne (polecam np. "band edge component maximization").
>
> Ale co ci tutaj dają komentarze? Czy może są to komentarze typu:
> /* Wiem, że to wygląda bez sensu, ale uwierz mi, tak właśnie ma być */
> ?

Np. "Filtr pasmowo-przepustowy wokół częstotliwości 2400Hz, ale ze
współczynnikami zespolonymi, tak aby w jego widmie częstotliwościowym były
niezerowe wartości wyłącznie dla częstotliwości dodatnich".