[s.....n]

Cobyście nie mówili, jakbyście dobrze nie nazywali metod, funkcji i zmiennych to komentarze do kodu powinny być zawsze ponad wszystko, nawet termin projektu. W miłości do komentarzy tak zostałem wychowany.

A wy jak tam? Komentarze czy YOLO? ( ͡° ͜ʖ ͡°)

Wymyśliłem nawet koderską wersję yolo: YOCO - You Only Code Once - a później niech się dzieje co chce XD

#programowanie #javascript

[epi]

@silon: kod powinien byc dobrze utrzymany, na tyle prosty i czytelny, by nie byly potrzebne komentarze co druga linijke ;)

same komentarze powinny byc w miejscach, ktore tego wymagaja, przy jakichs dziwnych workaroundach czy innych skomplikowanych rozwiazaniach, ktore z jakiegos powodu musza takie byc ;)

[V.....l]

@silon dobrze napisany kod sam w sobie jest komentarzem

[s.....a]

@epi: dałbym ci plusa ale masz już 5 co za dużo to niezdrowo

[Marmite]

komentarze do kodu powinny być zawsze ponad wszystko

@silon: Tak widzę osoby, które wyznają taką zasadę:

var pathToTheFile; //path to the file

[KurtRussell]

Tak, szczególnie lubię takie komentarze, które mówią jedno a kod robi drugie. Takich komentarzy z reguły przybywa wprost proporcjonalnie do liczby zmian wprowadzonych do kodu.
Dlatego trzeba pisać prozę a nie kod, który wymaga komentarzy.

[s.....n]

@epi: @Vontariel: @slucham-psa-jak-gra: No nie zgodzę się. Każda metoda powinna być opisana chociażby w 3 słowach a jeśli przyjmuje nietypowe argumenty które są np. obiektami to i one powinny znaleźć się jako @params w komentarzu odpowiednio opisane. Tworzy to mega estetyczny kod a co za tym idzie zwiększa się kultura pracy dlatego wasze argumenty do mnie nie przemawiają.

@Marmite: To spójrz inaczej:

active: fasle // Jest wartośćią warunkującą

[Marmite]

@silon: to może zamiast pisać komentarz nazwij to inaczej niż active? xD

[s.....n]

@Marmite: #!$%@?żdymMożliwymPrzypadkuZdecydowanieNieUłatwiaRozczytywaniaKodu
||
nie

[Marmite]

@silon: isSectionVisible elo
no ale lepiej pisać 60-znakowe komentarze i wracać do nich za każdym razem jak widzisz nic nie mówiącą nazwę active

[s.....n]

@Marmite: W kontekście jaki mam active jest dużo lepsze i czytelniejsze.

[Marmite]

@silon: Zwłaszcza widać to po tym, że musisz napisać komentarz, żeby wiedzieć co ono oznacza.

[s.....n]

@Marmite: Nie muszę, chcę. Bo oprócz tego, że warunkuje czy sekcja jest widoczna, zmienna oznacza, że ta sekcja jest aktywna i to ona jest teraz zajebista a wszystkie pozostałe nie. Ta zmienna nie jest po to żeby określić czy sekcja ma być widoczna, ona to tylko warunkuje. Uniknąłem w ten sposób czegoś typu: shouldBeVisible: this.active i kilku innych podobnych pierdół bo zawsze będą one przybierały tą samą wartość, a zrobiły by

[Kaczus2B]

@silon: Komentarze tylko tam, gdzie niestandardowe rzeczy się robi, w innych momentach, co najwyżej opis metody/funkcji co ma robić - nic poza tym, resztę programista powinien zrozumieć

[biwalencik]

@silon: u mnie zawsze docstring to podstawa.

[Uszatyy]

@silon: Polecam lekturę clean code. To co napisał colega @epi - nic dodać, nic ująć.

[larvaexotech]

@Marmite:

a = a + 2; // add two to variable a

( ͡° ͜ʖ ͡°)

[alex-fortune]

@silon: Komentarze są dla ludzi, których kod sam siebie nie tłumaczy ;)