No co zwracać uwagę by kod był czytelny dla innych

No co zwracać uwagę by kod był czytelny dla innych
Z8
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 76
0

Witam
Piszę w sprawie tematu który mnie ostatnio interesuję ,to sprawa jak pisać kod aby był czytelny dla innych programistów takich języków jak : Java, C# ,C++ . Moje doświadczenie opiera się na czytanie postów innych użytkowników z kodem i własnym programowaniu.

I chciałbym się dowiedzieć z chęcią od ludzi doświadczonych , na co szczególnie zwracać uwagę , czym się kierować by kod był jak najbardziej czytelny dla innych .

  • Rejestracja: dni
  • Ostatnio: dni
0

Kod jest czytelny zazwyczaj jak jest czytelny. Dość prosta sprawa.

Podpowiem Ci: Jak kod jest nieczytelny, to przestaje być czytelny.

niezdecydowany
  • Rejestracja: dni
  • Ostatnio: dni
  • Lokalizacja: Bieszczady
0

@up wypowiedź totalnie bez sensu... jak coś piszę to nawet jak jest "nieczytelne" to dla mnie będzie czytelne.

  • Rejestracja: dni
  • Ostatnio: dni
0

Jeśli napiszesz kod nieczytelny, to po nawet tygodniu będzie problem.

Nie ma głupich odpowiedzi, są tylko głupie pytania.

rincewind
  • Rejestracja: dni
  • Ostatnio: dni
3

Na tak ogólne pytanie mogę odpowiedzieć tylko w jeden sposób: http://www.tud.ttu.ee/material/kallik/JOOP/Clean_Code_-_A_Handbook_of_Agile_Software_Craftsmanship.pdf

Shalom
  • Rejestracja: dni
  • Ostatnio: dni
  • Lokalizacja: Space: the final frontier
  • Postów: 26433
5

Książka: Clean Code.

KO
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 519
2

Nawet jeżeli kod jest niezbyt czytelny, to dobra dokumentacja z pewnością ułatwi czytanie nawet największego ścierwa..

rincewind
  • Rejestracja: dni
  • Ostatnio: dni
0

Z mojego doświadczenia zawsze poziom_dokumentacji <= poziom_kodu. Nie spotkałem się nigdy z dobrą dokumentacją do syfiastego kodu. :P

  • Rejestracja: dni
  • Ostatnio: dni
0

Trudno osobie piszącej śmieciowy kod zrobić dobrą dokumentacje :)

Z8
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 76
0

A jak pisać komentarze w jakich sytuacjach są szczególnie widziane u was ? Z tego co słyszałem nadmiar komentarzy nie poprawia czytelności kodu . W C# metody komentuję "XML Documentation Comments" ale czy go częściej stosować od zwykłych komentarzy , mniej czy zawsze ?

VarrComodoo
  • Rejestracja: dni
  • Ostatnio: dni
  • Lokalizacja: Bk
  • Postów: 480
2

W sprawie komentarzy to nawet jest udostępniony rozdział na Helionie z ksiązki "Czysty Kod" - http://helion.pl/eksiazki/czysty-kod-podrecznik-dobrego-programisty-robert-c-martin,czykod.htm

Najbardziej mi się podobało z całego tego rozdziału stwierdzenie, że lepiej pisać kod tak aby komentarze w ogóle nie były potrzebne. A jak to osiągnąć? Odpowiednio nazywając klasy, obiekty, metody, zmienne ;) Czytając kod z dobrze dobranymi nazwami dla metod i zmiennych nic nie trzeba komentować, wszystko staje się czytelne bez komentarzy.

n0name_l
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 2412
0

Podchodzisz do pierwszej lepszej poleczki z ksiazkami w swoim domu. Wybierasz dowolna z nich i otwierasz na losowej stronei. Jesli latwiej Ci czytac kod niz to co tam jest napisane, wtedy mozesz smialo powiedziec. "Udalo sie! Moj kod jest czytelny".

davemajster
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 18
1

Jednolite wcięcia(nie za duże!), odpowiednie nazwy, odstępy przy operatorach(irytuje mnie jak ich nie ma!), jednolite posługiwanie się klamrami(umieszczać w wierszu gdzie jest np. nagłówek funkcji albo pod nim i tego się trzymać w całym kodzie) to powinno składać się na czytelny kod.

pozdrawiam.

Azarien
  • Rejestracja: dni
  • Ostatnio: dni
3

W C# metody komentuję "XML Documentation Comments" ale czy go częściej stosować od zwykłych komentarzy , mniej czy zawsze ?

Przy metodach publicznych - TAK, bo fajnie jak potem komentarze pojawiają się w podpowiedziach IntelliSense.
Przy prywatnych – NIE, bo staje się to uciążliwością.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.