12 komentarzy

Do Adam.Pilorz
"Jest to jedna instrukcja i nikt nie pisze czegoś takiego:
If Warunek then
Procedurka;
Tylko:
If Warunek then Procedurka"
Mylisz sie. Po pierwsze - to nie jest jedna instrukcja if...then to jedna, a Procedurka to druga instrukcja. A idąc Twoim tokiem rozumowania, to powinienes pisać tak:
If Warunek then begin Procedurka1; Procedurka2; Procedurka3; end;
...bo to przecież "jedna instrukcja" ;-)
begin powinno się pisać w nowej linii, a end z tym samym wcięciem co begin. Dlaczego? Bo wyznaczają one BLOK instrukcji. Spójrz na wizualizację dowolnego pliku XML w IE - każdy tag wyznacza jakiś blok danych. Gdybyś tag rozpoczynający umieścił na końcu linii innego bloku, to analizowanie takiego dokumentu byłoby znacznie utrudnione.
Czlowiek czyta blokami. Patrząc na kod nie widzisz pojedynczych instrukcji tylko identyfikujesz całe ich grupy. Zobacz o ile łatwiej jest przeczytać coś takiego:

To jest jakiś
text o niczym,
który powstał
jako przykład.

niż to samo zapisane w jednej linijce:

To jest jakiś text o niczym, który powstał jako przykład.

Dlatego też zapis
if Warunek then
begin
instrukcja1;
instrukcja2;
instrukcja3;
end;
jest bardziej przejrzysty i łatwiejszy do czytania.
Ja osobiście stosuje begin i end nawet gdy w warunku występuje tylko jedna instrukcja. Po pierwsze z powodu konsekwencji. Po drugie dlatego, że od razu widzę blok instrukcji. Po trzecie dlatego, że unikam w ten sposób tworzenia jednoinstrukcyjnych warunków wielokrotnych tzn. czegoś tak obrzydliwego ;) jak:
if warunek1 then
if warunek2 then
if warunek3 then
for i:=0 to 3 do
if warunek 4 then
instrukcja;

Ja do tego stosuję 4 spacje wcięcia (łatwiej analizować duże if'y, pętle itp., w dodatku przy wielokrotnych warunkach szybko kończy się ekran ;) co wymusza grupowanie kodu w funkcjach), grupuje kod w małe funkcje (góra dwa ekrany ale zazwyczaj jeden) i stosuję samoopisujący się kod tzn. nazwy zmiennych i procedur, które od razu mówią mi o co chodzi i nie mieszam nazw polskich z angielskimi.
Pozdrawiam

No to i ja się wypowiem. Po pierwsze, to jak ktoś pisze nieczytelny kod, to może i nie świadczy o tym, że jest amatorem, ale przynajmniej częściowo. No bo dobry programista, a konkretniej - doświadczony programista, wie, że niechlujny kod nawet pisany na własny użytek, to jest nóż, który sami wbijamy sobie w plecy. Pisanie ładnego kodu wcale nie trwa dłużej, a potem w razie jakiegoś błędu albo coś mocno pomaga. Natomiast nie do końca zgodzę się z paroma z tych standardów. Moim zdaniem najważniejsze jest, by pisać JEDNOLICIE, nie koniecznie akurat tak, jak sobie Borlandowcy wymyślili. Powiedzmy przykładowo, jak ktoś pisze z jedną spacją wcięcia zamiast dwóch, to od razu będzie źle? No nie przesadzajmy. Podobnie jest z if warunek then begin... Ja na przykład piszę w jednej linii i nie zamierzam tego zmieniać. Moim zdaniem jest to zgodne z ZASADĄ DZIAŁANIA tej instrukcji. Jest to jedna instrukcja i nikt nie pisze czegoś takiego:
If Warunek then
Procedurka;
Tylko:
If Warunek then Procedurka
No i tak samo jest z end;. Piszę go z takim samym wcięciem jak blok, który kończy, nie takim jak begin rozpoczynające blok. No bo jak mam na przykład w programie:
If Warunek then begin
Procedura1;
Procedura2;
end;
Procedura3;
To analizując kod jadę kursorem na poziomie wcięcia If. No i patrzę, że tutaj ten warunek w rozpatrywanym przypadku nie będzie spełniony, to jadę do najbliższej linii rozpoczynającej się takim wcięceim i dochodzę do następnej po tym warunku instrukci. Proste, nie?

Zgadzam się, że pisanie estetycznie jest ważne. Kiedyś pisałem byle jak i nic nie mogłem znaleść w kodzie, ale od kiedy piszę z tymi zasadami, to znalezienie czegokolwiek nie stanowi problemu. Mam tylko jedno pytanie:
Cytuję " Wyjątkiem są słowa kluczowe, które Delphi pogrubia - powinny być one wyświetlane małymi literami." - Dlaczego? Nie wiedziałem o tym wcześniej i do tąd pisałem wielkimi. Nie rozumiem czemu mają być pisane małymi literami.

No i właśnie o to chodzi \"pomaga zrozumieć kod po dłuższym czasie\". Programista to ktoś kto myśli a nie gość, który potrafi ściągnąć z internetu parę przykładów i lepiej lub gorzej skleić je w jeden program, którego potrzebuje.

\"nie sposób pisania kodu, tylko efektywność kodu świadczą o zaawansowaniu programisty\"
To też nie prawda, dobry programista to taki, który ma doświadczenie więc napisał już wiele programów a jeśli tak siłą rzeczy musi \"ładnie\" pisać! Spróbuj napisać program z kilkoma modułami jednymciagiembezwciec i zobaczysz jak szybko szlag Cie trafi przy pierwszej próbie poprawienia/dopisania czegokolwiek...

Podsumowując DOBRY programista pisze nie tylko dobrze ale i ładnie to wymóg pragmatyczny a nie estetyczny...

Pozdrawiam
[email protected]

Bo takie słowo jak if w C++\'ie jest małymi literami :D
Właśnie C++ jest właśnie do pisania estetycznych programów, tam nie przejdzie napisanie pRiNtf(\"ss\"); ;)

Dodałbym jeszcze, że podczas ustawiania opcji menu, dodawania podmenu i tak dalej powinno się pisać, powiedzmy Caption := Opcje..., niż Opcje, bo użytkownik wie, że przejdzie do nowego okna z jakimś wyborem/konfigiem.

Ja, jak coś piszę, to zawsze poprawnym stylem, nawet gdy nie myślę o opublikowaniu (a nie myślę nigdy). Bo jak piszesz skomplikowane programy niepoprawnym stylem, to potem próbój dojść, o co w ogóle chodzi w tym caym kodzie.

Zgadzam się z artykułem całkowicie. Tzn. prawie całkowicie:) to że kod jest napisany niechlujnie nie oznacza, że programista jest amatorem! Np. piszę sobie program i nagle, już pod koniec pisania stwierdzam że opublikuję go wraz ze źródłem. I co? będe poprawiał wszystkie literki, dodawał spację, itd? Oczywiście że nie!.
Ale i tak uważam że "piękne" pisanie kodu jest bardzo dobrym nawykiem.
PS: tak samo jak sądzę że kod jest przejrzysty nie wtedy kiedy jest piękny, tylko kiedy ma odpowiednie rozplanowane wcięcia.

Fajne, really fajne, jest tylko parę ale... "NIE SZATA ZDOBI CZŁOWIEKA". Naprawdę nawet najpiękniej napisany kodzik nie pomoże jeśli program się sypie. To są tylko kosmetyki. Jeśli programista nie może namierzyć czegoś w programie to uważam, że też jest amatorem. Kod ma być zwięzły i efektywny a nie piękny :) Z wcięciami to można pisać faktycznie jak autor nawiązuje to na języku polskim

Tak, ale czy nie moze byc efektywny, zwiezly a zarazem piekny?

Będę musiał chyba zmienić stare nawyki ;-)

Nie, żebym marudził, czy coś... ale: "I wierzcie mi, że właśnie po tym w jaki sposób człowiek pisze kod można rozpoznać, czy jest to początkujący, czy zaawansowany programista."
No bez przesady, mili państwo, bez przesady... nie sposób pisania kodu, tylko efektywność kodu świadczą o zaawansowaniu programisty.
Ale zgodzę się z tym, że trzeba w miarę przejrzyście pisać ;) Nie dlatego, że jest to zaawansowane, tylko dlatego, że pomaga zrozumieć kod po dłuższym czasie.