@kretopir: @wytrzzeszcz czytelne tylko jak masz 10 linijek kodu, jak jest więcej to nie widać wtedy dobrze tego co istotne (a jak masz troche wiecej rozgalezien w postaci ifów/petli, to już w ogole, wiekszość ekranu to białe znaki). Do tego przesunięty nienaturalnie w drugą stronę else w wypadku wersji 2 (bo w prawo, wygląda jakby był na innym poziomie niż if). Tylko w przypadku 1 trzeba sie pilnować odnośnie wcięć, w
@Tril: Brrr, jestem kompletnie odwrotnego zdania, ten brak klamr i opieranie się na znakach białych przyprawia mnie o raka. I jak dla mnie wersja 2 jest czytelniejsza i nie wiem o co ci chodzi z else? jest na normalnym poziomie o.O I zawsze jest dla mnie czytelne, ale też zawsze unikam robienia masy ifów w sobie, bo to zawsze źle wygląda...
@GotoFinal: Dokładnie. Klamry na końcu każdej linii są bardzo nieczytelne w większym codebase i analizując czyjeś kody (code review) musisz sprawdzać czy aby dana linia nie kończy się { bo może ktoś zapomniał o wcięciu poniżej i się wszystko dalej rozjedzie albo przy merge z repozytorium coś się rozjechało w tabulacji. Te klamerki to taki sam rak jak goto i implementowanie metod klas w c++ headerze. TBH wystarczy jakiś czas popracować
@GotoFinal: Może mi sie #!$%@?ło z tym else i to nie w gnu tak jest, tylko w innym coding style. Ogólnie gdzieś widziałem w jakimś stylu pisanie jak na obrazku tutaj http://images.slideplayer.com/26/8425702/slides/slide_15.jpg, ale z elsem przesuniętym o taba w prawo, co wygląda słabo i generalnie zaburza światopogląd :P Co do pythona - wymusza przynajmniej używanie tych wcięć, i po chwili przyzwyczajenia (w przypadku osoby która normalnie robi wcięcia) nie stanowi żadnego
@GotoFinal: Jeszcze co do tego opierania sie na białych znakach, taki w miarę fajny, krótki dokument (też jest fajny przykład z C pokazujący czemu to ma plusy): http://www.secnetix.de/olli/Python/block_indentation.hawk Generalnie podoba mi się w tym to, że parser twojego kodu opiera się prawie dokładnie na tym co od razu widzi człowiek patrząc na strukturę, a nie na klamrach, które mogą wymuszać inny przepływ niż na pierwszy rzut oka widać.
@Tril: No za mnie IDE robi wcięcia i wszystko, więc python by mnie tylko wkurzał, że czasami coś przenosząc/wklejając mam dodatkową robotę. A robienia ifa bez klamer to też rak, i za to powinno się ludzi na stos wrzucać, u mnie IDE automatycznie dodaje klamry jeśli ich brakuje :D Ogólnie mam ustawione formatowanie tak ostro że nie ma szans by coś było źle, formatuje przy każdej okazji, a i ja mam
@Tril: Może ma jakieś plus w czytaniu, ale za bardzo denerwuje podczas pisania bym używał, nie potrafię się przyzwyczaić, zawsze mnie denerwuje, więc wole klamerki :D
@Najkon: Mnie zaczął nieziemsko drażnić ich niesamowity nadmiar (oraz zwykłych nawiasów) i to jak bardzo nieczytelny kod można napisać i będzie on działał. W Pythonie nie ma takiego problemu - zawsze wiadomo jak bardzo zagnieżdżona jest dana linijka kodu i w której funkcji/pętli się znajduje
@Ragnarokk: No rzeczywiście wyższość, że #!$%@?. Tak samo jak można okazać swoją wyższość w setnej kłótni, który sposób zapisu klamer lepszy albo który język programowanie lepszy xDDDDDDDDDD
@kretopir: ale pierniczysz. Konwencja mocno jest uzależniona od trendów i języka. Przetestuj sobie domyślnie ustawienia formatterów dla najpopularniejszych ide (i nie ograniczaj się do c++, bo rakiem jest ograniczać się do trendów tylko 1 języka programowania).
void funkcja() { if(cus){ if(drugiecus){ } } } Zwyczajnie jak mam dwa fory wewnątrz dwa ify wszystko zagnieżdżone to pisanie drugim sposobem nawaliłoby jedynie niepotrzebnych pustych linii. Ale drugi jest ładniejszy
1.
if () {
}
2.
if ()
{
}
#naukaprogramowania #programowanie
który?
2. jedyne prawilne i czytelne
czytelne tylko jak masz 10 linijek kodu, jak jest więcej to nie widać wtedy dobrze tego co istotne (a jak masz troche wiecej rozgalezien w postaci ifów/petli, to już w ogole, wiekszość ekranu to białe znaki). Do tego przesunięty nienaturalnie w drugą stronę else w wypadku wersji 2 (bo w prawo, wygląda jakby był na innym poziomie niż if). Tylko w przypadku 1 trzeba sie pilnować odnośnie wcięć, w
@Tril: Brrr, jestem kompletnie odwrotnego zdania, ten brak klamr i opieranie się na znakach białych przyprawia mnie o raka.
I jak dla mnie wersja 2 jest czytelniejsza i nie wiem o co ci chodzi z else? jest na normalnym poziomie o.O
I zawsze jest dla mnie czytelne, ale też zawsze unikam robienia masy ifów w sobie, bo to zawsze źle wygląda...
Co do pythona - wymusza przynajmniej używanie tych wcięć, i po chwili przyzwyczajenia (w przypadku osoby która normalnie robi wcięcia) nie stanowi żadnego
Generalnie podoba mi się w tym to, że parser twojego kodu opiera się prawie dokładnie na tym co od razu widzi człowiek patrząc na strukturę, a nie na klamrach, które mogą wymuszać inny przepływ niż na pierwszy rzut oka widać.
A robienia ifa bez klamer to też rak, i za to powinno się ludzi na stos wrzucać, u mnie IDE automatycznie dodaje klamry jeśli ich brakuje :D Ogólnie mam ustawione formatowanie tak ostro że nie ma szans by coś było źle, formatuje przy każdej okazji, a i ja mam
Komentarz usunięty przez autora
Komentarz usunięty przez autora
3
if() {}
@Najkon: O #!$%@?
#abap
ENDIF.
a nie jakies tam c++ pierdoły (⌐ ͡■ ͜ʖ ͡■)
Przetestuj sobie domyślnie ustawienia formatterów dla najpopularniejszych ide (i nie ograniczaj się do c++, bo rakiem jest ograniczać się do trendów tylko 1 języka programowania).
if x == 420 {
blaze_it()
} else {
dont_blaze()
}
void funkcja(){
if(cus){
if(drugiecus){
}
}
}
Zwyczajnie jak mam dwa fory wewnątrz dwa ify wszystko zagnieżdżone to pisanie drugim sposobem nawaliłoby jedynie niepotrzebnych pustych linii. Ale drugi jest ładniejszy
if warunek
____cośtam
@raven4444: i bardzo dobrze. Nie marnuje się niepotrzebnie miejsca i zwiększa czytelność kodu ( ͡° ͜ʖ ͡°)