jakie macie zboczenie

moim zboczeniem jest pisanie do każdego warunku if klamr {}

E, pornografia i pończochy.

A ja mam zupełnie na odwrót.. Nie stawiam nigdy klamry, gdy nie jest potrzebna do działania programu. i nie potrafię patrzeć na takie formatowanie w C++:

void fun a(){
};

w C++ klamrę muszę stawiać w nowej linii, bo się spawiuję inaczej..

Ja jestem przyzwyczajony do wyglądu kodu po wciśnięciu Alt+Shift+F w NetBeansie na domyślnych ustawieniach :) NetBeans właśnie dodaje wszędzie klamry i jest spoko :P

Teraz siedzę na Eclipsie i przeklinam (co chwilę lecą ku*wy). Autouzupełnianie i podpowiadanie w Eclipsie jest skopane w porównaniu do NetBeansa. A jestem zmuszony się tymczasowo przenieść, bo (wierzcie lub nie) NetBeans wysypuje się na kodzie który tworzę - co chwilę stopuje, zapełnia stertę obiektami typu AmbiguityError (czy jakoś tak), następnie włącza się GC i mieli przez minutę, a na koniec siada kolorowanie składni i NetBeans wyrzuca błąd GC overhead exception. Potem znowu coś piszę i znowu się zapycha sterta. Tragedia. Eclipse też czasem zamula w podobny sposób co NetBeans (też zapycha stertę, a potem zarzuca ostatnie działanie) jednak objawy nie są tak drastyczne, kolorowanie nie siada, przerwy (freezy) są krótsze i w miarę da się pisać.

Edit:
Założyłem bug reporta do tego buga: http://netbeans.org/bugzilla/show_bug.cgi?id=196134 i już go nie będzie :)

( . ) ( . )

:D

Nie lubię notacji węgierskiej (sz_napis).

Nie lubię tzw. pisania warunków w stylu Yody:

if (2 === numberOfItems) { // BLEE!
  ...
}

Wg mnie, najpierw powinna być zmienna, a potem stała.
Te warunki rozumiem jedynie gdy stosuje się coś takiego:

if ("blue".equals(colorName)) { // Ujdzie. Rozumiem.
  ...
}

^^Ten kod przynajmniej nie wysypie się, gdy colorName będzie równe null.

Nienawidzę eval, w tym -- w JavaScripcie -- użycia setTimeout('funkcja()', 10) (zamiast: setTimeout(funkcja, 10)).

Budując layouty HTML/CSS, nie lubię elementów prezentacyjnych. Nie lubię dorzucania elementów tylko dlatego, że potrzebuje punktów zaczepienia dla stylów CSS. Odczuwam pewną pogardę do elementów prezentacyjnych. Co gorsza, czasem muszę ich użyć.

Rażą mnie powtórzenia w kodzie.

W JavaScripcie, nauczyłem się pisać pętle po wszystkich elementach tablicy items ten sposób (zwróćcie uwagę na zmienną n):

for (var i = 0, n = items.length; i < n; i++) { // Pętla bswierczynskiego :(
  ...
}

To zwiększa wydajność. Dla mnie wygląda to już całkowicie naturalnie -- taki idiom -- ale obawiam się, że kogoś innego mogłoby dziwić. A jeśli taki zapis pętli jest nieczytelny, to stanowi przedwczesną optymalizację jeśli używamy go zawsze.

Nie lubię wykonywania ciągle takich samych operacji na komputerze. Problem w tym, że pracuję pod Windowsem i wzbraniam się przed cygwinami itp., więc piszę... skrypty batch (pliki .bat). Stosuję tam pętle, warunki, podprocedury itp. Mało kto tego używa, co mnie zupełnie nie dziwi.

To, gdzie są klamry, nie rusza mnie za bardzo. Sam stosuję styl K&R, czyli robię tak, jak nienawidzi Carlos Spicy-Weener. Co ciekawe, pisząc w C klamrę otwierającą stawiałem w nowej linii.

Klamry stawiam (gdzieś) zawsze -- dla bezpieczeństwa.

Rażą mnie wypowiedzi w języku ludzkim, które mają brzmieć fajnie/mądrze, a w rzeczywistości są błędami. Np. "wysłałem Tobie maila" (tu można użyć jedynie nieakcentowanego "Ci"). Albo gdy ktoś przychodzi do ciebie do domu i w progu mówi "Witam!" -- ktoś cię wita w twoim własnym domu :D (do tego już się przyzwyczaiłem i czasem też niezbyt mądrze tego użyję). A propos zaimków osobowych: szczególnie razi mnie, gdy ktoś napisze "To byli Ci sami, co kiedyś..." -- tutaj pisanie "Ci" wielką literą jest ewidentnie błędne.

Do oznaczenia wtrąceń i niektórych podkreśleń w tekście używam dwóch znaków minusa/dywizu (czyli piszę --), a nie jednego. Typograficznie, dywiz czy myślnik jest dalece za krótki do takich celów, więc gdy piszę w ASCII, to wciskam klawisz dwa razy. Trudno nie zauważyć.

Prawie zawsze rażą mnie moje własne teksty, chyba że się do nich specjalnie przyłożę. Nie potrafię czytać płynnie swoich tekstów pisanych na szybko. Często brzmią dla mnie koślawo i niezgrabnie.

Jestem ciągle niezadowolony z tego, co robię. Rzadko piszę kod, którego po np. roku nie napisałbym inaczej, "lepiej". Żeby nie popaść w paranoję, w sztuczny, aktywny sposób tłumaczę sobie, że nie jest tak źle. Albo że jest nawet całkiem dobrze. Dotyczy to dziedzin, w których wiem, że jestem mocny. To nie jest skromność, tylko niezadowolenie z siebie i marudzenie.

Czytam DUŻO książek branżowych, często po kilka naraz, rotacyjnie, zależnie od humoru. Gdzieś ze 2 tygodnie temu skończyłem czytać "Kod doskonały". Potem skończyłem "Przetestuj ją sam!", której pierwszą połowę przeczytałem 2 miesiące wcześniej. Wreszcie, skończyłem "Thinking in Java", które czytałem dla sportu, bo w Javie prawie w ogóle obecnie nie piszę. Została mi tylko jedna książka do dokończenia i niemal wpadłem w panikę. Wczoraj gorączkowo biegałem po księgarniach i orientowałem się w ofercie. Dziś miałem napięty harmonogram i fuksem zdążyłem podbiec po książkę o mikroformatach, a w poniedziałek kupuję kolejną, którą mam na oku.

Lista nie jest bynajmniej wyczerpująca. Tu ograniczyłem się do zboczeń związanych z programowaniem (a i tak nie wymieniłem wszystkich).

Lubię zaczynać program od GUI. Dopiero jak ładnie wszystko co do piksela poustawiam, i mi się to podoba to mam motywacje żeby zrobić coś żeby buttony działały.

b

@Qyon:
To window.funkcja można rzecz jasna skrócić po prostu do funkcja. Ale mi chodzi o to, że ludzie nie potrafią korzystać z prostej, skutecznej funkcyjności JavaScriptu i przepisują bezwiednie fragmenty kodu z netu. Które to fragmenty jakością zwykle nie grzeszą.

@unikalna_nazwa:
Nie powinno się używać for (prop in items) do iterowania po tablicach. Nie chodzi o wydajność. W takim wypadku, prop wbrew pozorom nie robi za indeks tablicy. prop przyjmuje wartość kolejnych nazw własności, które są wyliczane (ang. enumerable). W przypadku tablic, w wielu przypadkach wszystko zadziała OK, bo wyliczanymi wartościami będą tylko indeksy. Ale jeśli dodasz cokolwiek do prototypu Array, to ta własność BĘDZIE wyliczana. Czyli for..in wyłapie nie tylko indeksy, ale i Twoje rozszerzenia Array. To samo dotyczy wszystkich for..inów, nie tylko tych przy tablicach.

Żeby tego uniknąć, musiałbyś napisać pętlę tak:

for (var prop in obj) {
  if (obj.hasOwnProperty(prop)) {
    // Tu właściwy kod pętli
  }
}

Można się spytać, kto właściwie rozszerza prototypy obiektów wbudowanych? Cóż, ja praktycznie nie rozszerzam. Ale to dlatego, że dbam o maksymalną niezależność kodu i o to, by mój kod działał w różnych środowiskach. W niektórych "środowiskach" mogą istnieć skrypty programistów, którzy nie wiedzą o problemach z for..in.

Teraz uważam to za błąd z mojej strony i mam zamiar zmienić.

Wspomniałeś o array.forEach. To jest super. W ogóle nowe funkcje tablicowe są super (map, filter, reduce, indexOf...). Używa się tego bardzo wygodnie i zwięźle. Tyle że nie wszystkie przeglądarki to implementują.

Ekspresyjność JavaScriptu pozwala na sprawienie, by te nowe funkcje działały idealnie nawet w gorszych przeglądarkach. Funkcje są dość proste. Wystarczy zaimplementować je samodzielnie i dodać do prototypu Array (jeśli prototyp ich już nie zawiera).

I tu dochodzimy do problemu z for..in. Programiści muszą się przed tym zabezpieczać.

Więcej o (nie)używaniu for..in dla iteracji po tablicach można znaleźć na MDC: https://developer.mozilla.org/en/JavaScript/Reference/Statements/for...in

W sumie to z tą pętlą uważam za swoje zboczenie, bo rzadko widzę, żeby ktoś z tego korzystał. Zaznaczę jednak: jeśli mój kod ma z definicji być przez kogoś przerabiany/czytany, to zwykle tego nie używam. Po prostu we własnym kodzie mam tego pełno. Piszę to odruchowo.

Jeśli chodzi o wydajność, to różnica lepiej się uwidacznia, gdy items jest kolekcją DOM. Wtedy odniesienie do items.length jest kosztownym zapytaniem do DOM. Ale odwołanie do items[i] też jest takim zapytaniem. Iterowanie po kolekcjach DOM można jeszcze bardziej zoptymalizować, zmieniając dynamiczną kolekcję na tablicę.

Samo odniesienie się do array.length może być wyraźnie kosztowne, ale nie musi. Zależy od przypadku.

Miałem kilka sytuacji, w których było to wąskim gardłem, bo pętla występowała w najczęściej używanych funkcjach w programie. I jakoś tak, dla spójności, zacząłem zapisywać tak każdą pętlę for. Nie jest to SUPER nieczytelne i można traktować to jako idiom, ale... Może być nieoczekiwane. W takim wypadku nie jest to dobrą, naturalną optymalizacją, jak zapisywanie obiektów jQuery w zmiennych (one robią wtedy za zmienne objaśniające -- dobre dla czytelności). Jeśli wprowadza się udziwnienie kodu niby ze względów wydajnościowych, to najpierw trzeba zrobić pomiary i sprawdzić, czy w konkretnej sytuacji faktycznie coś to da.

Pętli iterującej do zera praktycznie nie używam. Nie uważam jej za refaktoryzację. W końcu czasem kolejność przetwarzania... się liczy. W moich aplikacjach wąskimi gardłami często są funkcje iterujące, które przyjmują za argument jakąś funkcję callback i wywołują ją dla każdego elementu. Wręcz dziwnie wyglądałoby w dokumentacji jakbym napisał "Aha: funkcja iteruje od tyłu, coby szybciej chodziła" ;). W określonych przypadkach, gdy wydajność jest krytyczna, a kolejność nieważna, użycie pętli iterującej do zera może naturalnie być najlepszym rozwiązaniem.

A ja tą moją pętlę będę chyba musiał zapisywać tak:

var itemsCount = items.length;
for (var i = 0; i < itemsCount; i++) {
  ...
}

To już nikogo nie zdziwi. Zadziała tak samo szybko. I jest równoznaczne z poprzednim, bo JavaScript nie ma zakresu blokowego, więc n i itemsCount mają ten sam zakres.

Używam conio.h :P

1. Mam manię na punkcie formatowania kodu, jedna spacja z złym miejscu sprawia że nie mogę patrzeć na kod. Już nie mówiąc o nowych liniach, przecinkach, etc, etc...

2. Zawsze wywalam wszystkie usingi (import w Javie, #include w C++ itd) jakie IDE mi dodaje. Nawet jeśli za chwilę je sobie sam muszę dopisać.

3. [C#] Jeśli nie spodziewam się żeby ktoś oprócz mnie miał używać mojego kodu (a często się nie spodziewam) nadaje interfejsom nazwy NIEzaczynające się od I. Jest to moje główne (jeśli nie jedyna) odstępstwo od zasad formatowania kodu proponowanych i stosowanych przez MS.

4. [C# bo tylko w nim piszę większe projekty] Dzielę kod na pełno małych przestrzeni nazw, 10 typów w jednej to już dużo.

5. [C] świadomie piszę w jakiejś archaicznej odmianie standardu żeby nie musieć dołączać stdio.h do printf-a. Ofc tylko w małych programach

6. Sporą część programów (oprócz C# bo VS jest po prostu idealne, Pythona bo jego kolorowanie jest beznadziejne, Javy, Prologa i... Befunge. ) piszę w Vimie :D Większe teksty - jak ten post - tak samo. Mniejsze w systemowym notatniku.

7. Z jednej strony gdzie się da i nie psuje to czytelności zwijam funkcję / property do jednej linijki...

8. A z drugiej wystarczy że jeden znak wystaje i nie mieści się w polu tekstowym, od razu rozbijam linijkę na kilka.

To te które mi od razu przychodzą do głowy, być może jest ich więcej...

1. Czasem gdy muszę coś poprawić w Javie, nie mogę się przemóc, i zamiast poprawić, przepisuję na C# i takie oddaję...

2. Nie toleruję niedeklarowania zmiennych. Oburza mnie to, denerwuje, rozprasza. A że piszę często w VBA to i znajduje różne takie funkcje/procedury, z których na dodatek czasem muszę skorzystać. Całe jestestwo się wtedy we mnie buntuje i nie zaznaję spokoju, póki każda zmienna nie dostanie jakiegoś typu, póki każdy parametr nie zostanie opatrzony ByVal/ByRef i póki każda funkcja nie będzie czegoś zwracać, co też ma mieć określony typ. Nawet jak typ ma być Variant, to ma to być do jasnej Anieli, zdeklarowane!

3. Nie jest dla mnie niczym dziwnym mieć otwarte jednocześnie 3-5 instancji Visual Studio, Ideę, SQLMSE jest praktycznie cały czas uruchomiony... A komputer nie jest żadną tam rakietą, ale nie potrafię zdecydować, które okienko będzie mi potrzebne później. Cały czas mam wrażenie, że wszystkie są mi potrzebne, albo za chwilę będą, więc nie ma sensu wyłączać, żeby włączać... Przez to też nie wyłączam komputera, póki jakiś admin nie przyjdzie z młotkiem i żądaniem zainstalowania aktualizacji... Chyba czas na restart... albo i reinstal.

aa i zapomniał bym o pulpicie.. Jak patrzę na te zapchane pulpity, gdzie nie wiadomo w co kliknąć to mnie strzela! Ja mam tylko to nad czym pracuje a skróty do programów które są mi do tego potrzebne mam na pasku szybkiego uruchamiania.
Według mnie pulpit powinien służyć do wygodnej pracy a nie do tego abyśmy sami nie mogli się połapać co gdzie jest.

edit:

jak widzę taki pulpit, to nóż w kieszeni się otwiera.. To jest typowy pulpit dziecka neo. Rozumiem jakby były 2 ikonki gier w które gra(osobiście nie gram już w gry), skrót do download(a nie całe paczki rara), jakaś playlista a nie całe mp3. Skrót do folderu z filmami a nie całe pliki i przede wszystkim te ikony z których nigdy w życiu nie skorzysta..
Bo kto powiedzcie mi otwiera sam program AdobeReader( i parę innych ) a nie jakiś plik pdf, który jest powiązany z tym rodzajem pliku..

1. Lubię dawać funkcję-tasiemce. Tzn np: Funkcja1(Funkcja2(Funkcja3(5,3,4)), Funkcja4(Funkcja5(5,6,7)));
   To oczywiście skrajne przypadki, ale lubie pakować funkcję tak jakby w jednej linii (oczywiście tego typu funkcje dziele na parę linii).

2. Co do klamerek po ifach i pętlach to zawsze je daje, a po skończonej robocie przeglądam kod i sprawdzam gdzie one są potrzebne. Tam gdzie nie są to usuwam. Dzięki temu zawsze co najmniej 2 linijki uciekają z funkcji.

3. Dziele kod na kilka części. Tzn takie jakby rozdziały gdzie mam:

• deklaracje
• metody do klasy tej i tej
• komentarz do tej klasy na kilka linijek
• komentarz stworzony z "=" lub "-" kilku linijkowy(najczęściej 2,3 lub 4)
• kolejne metody innej klasy
  Robię to oczywiście dla porządku w kodzie, ale czasami jest to moją manią i pół godziny poświęcam na takie ułożenie wszystkiego.

4. Nie lubię tego co było już omówione czyli takiego formatowania:

Funkcja(3,5,6) {
}

jeśli klamerki mają być po ifach, pętlach itd to już tylko i wyłącznie w jednej kolumnie. Duuuuuużo bardziej zwiększa to czytelność według mnie.

5. Lubię pisać w końcowej klamerce komentarz do czego ona jest np:

if (a == b)
{
 if (c == d)
 {

 } // do c == d
} // do a == b

Też według mnie zwiększa czytelność

6. Wszystkie pliki nagłówkowe oddzielam od reszty kodu za pomocą 3 linijkowego komentarza, po czym daje różne define, pragmy i inne, i także oddzielam je od reszty kodu 3 linijkami komentarza :) np:

#include<iostream.h>
#include<conio.h>
#include<stdlib.h>
//------------------------------------------------------
//------------------------------------------------------
//------------------------------------------------------
#pragma hdrstop
#pragma package(smart_init)
#pragma resource "*.dfm"
//------------------------------------------------------
//------------------------------------------------------
//------------------------------------------------------

7. Wcięcia w kodzie oparte na zasadzie, że funkcje/metody i ogólnie kod o jedną kolumnę dalej niż klamerki.
   np:

if (a == 5)
{
 metoda(2,5);
}

nie lubię natomiast tego:

if (a == 5)
{
metoda(2,5);
}

Jak coś sobie przypomnę to dopiszę :)

@up: Hue hue, też mam na pulpicie tylko to, nad czym pracuję... co daje łącznie 88 elementów...
Dla mnie to podobna historia jak z otwieraniem zakładek w przeglądarce (a potem szkoda zamknąć, bo może zaraz się przyda) czy uruchamianiem programów, szczególnie długo otwierających się projektów...
Ja po moim pulpicie klawiaturą się przemieszczam, żeby coś znaleźć, ale co mi za różnica czy to wszystko na pulpicie będzie, czy w innym folderze?

co do formatowania:

if(...)
{
}

też wole tą wersje, jednak z jedną różnicą. Przy deklarowaniu klas, struktur i wyliczeń stosuję:

 class Example { 
    ...
}; 

Tak samo mam manie stawiania spacji za nawiasem otwierającym i przed zamykającym przy definiowaniu funkcji:

void foo(int, bool);
void foo( int a, bool b ) {}

polaczek17:
Jakiś czas temu ktoś polecał tu książkę Clean Code. Przeczytałem jak do tej pory około 100 pierwszych stron. Na stronach tych opisywane są niemal wszystkie Twoje 'zboczenia' jako typowy szum informacyjny, niepotrzebne komplikowanie kodu i zmniejszanie jego czytelności. Gratuluję i polecam książkę ;)

Zawsze stawiam nawiasy klamrowe tak:

void funkcja()
{
}

Jak widzę tak:

void funkcja(){
}

to martwie się o autora tego kodu. Serio. Co to za przyjemność utrudniać sobie życie? ;)

Jak deklaruje kilka zmiennych w osobnych linijkach to muszą być ładnie wyrównane:

private   int    a;
public    float  b;
protected double c;

Podobnie z metodami.

Ostatnio zacząłem zawsze pisać nawiasy klamrowe. Nawet tam gdzie po if jest jedna instrukcja. Gdzieś przeczytałem, że tak się powinno i zacząłem sie tego trzymać. Nie chcę znów zmieniać nawyku.

Nie cierpię zbyt dużej ilości komentarzy. Co za tym idzie, nie lubię komentarzy XML. Zdecydownie preferuję: /* komentarz */ z nie // komentarz

Polecam "Czysty kod" naprawdę warto przeczytać

Metody piszę UperCamelCase.

@Kunai:
"Piękny kod" i "Czysty kod" to dwie, zupełnie inne książki :P. Ja czytałem tylko "Czysty kod". "Piękny kod" olałem, chociaż przeglądałem. Nie podobało mi się chyba to, że było tam sporo kodu napisanego w nie interesujących mnie językach programowania i sporo równie powiewających mi algorytmów.

Ale jak teraz spojrzałem na spis treści, to książka wydaje mi się atrakcyjna. Dziwne, bo w księgarni podchodziłem do niej ze trzy razy. Tylko to było dwa lata temu. Może i się za nią rozejrzę.

@Kunai:
@polaczek17:
@byku_guzio:
"Czysty kod" nie raz już tu polecałem. UWażam tę książkę za jedną z najważniejszych pojedynczych książek, jakie powinien przeczytać każdy programista. O pierwsze miejsce bije się właśnie "Czysty kod" oraz "Kod doskonały" ("Code Complete"). W "Czystym kodzie" nietypowym bonusem są dłuższe, praktyczne, dogłębnie omówione przykłady.

Ale do tej książki trzeba podchodzić z pewnym dystansem. Pokazuje tylko jeden punkt widzenia i jeden styl. Nie jest to zły styl, ale... Promuje bardzo małe funkcje z bardzo opisowymi nazwami. Niektóre zmienne mają tam NAPRAWDĘ długie nazwy. Taki kod faktycznie niemal nie wymaga komentarzy. Nie mam nic do standardu kodowania, w którym kod pisze się troszkę wolniej. Problemem tutaj jest coś innego: fragmenty kodu, gdzie zbiega się kilka dłuższych identyfikatorów, po prostu ciężkawo mi się czyta.

W "Code Complete" przedstawiają wiele punktów widzenia.

Co do standardów polaczka, to wg mnie funkcje tasiemce są raczej be. Lepiej rozbić to na parę linii, a wyniki funkcji "wewnętrznych" przypisać do zmiennych opisowych. No ale np. w "Refaktoryzacji" Martin Fowler ma awersję do zmiennych (mimo że w pewnym miejscu książki sugeruje użycie zmiennych opisowych) i w takich wypadkach raczej ich nie używa.

Z usuwaniem klamer ja tam się nie zgadzam. Liczy się tak naprawdę logiczna liczba linii kodu w funkcji. Staram się, żeby funkcje raczej nie miały więcej niż 10 linijek. Jak przez klamrę w jakimś ifie rozciągną się do 11 lub (o zgrozo!) 12, to nic się nie stanie. Miejsca na ekranie wciąż pozostanie bardzo dużo. Klamry wprowadzają naturalne puste linie kodu i dzięki nim kod bardziej oddycha. Nie przepadam ściśniętego w pionie kodu -- dlatego nie podobało mi się formatowanie w paru miejscach w "Thinking in Java", gdzie autor trochę oszczędzał.

Dziwi trochę, że polaczek stosuje klamry K&R przy deklaracjach funkcji i umieszcza klamry w nowej linii we wszystkich innych przypadkach. Pierwsze słyszę o takim podejściu. Słyszałem sporo razy, że ktoś robił dokładnie odwrotnie ;).

Komentarzy w klamrach zamykających Wujek Bob w "Clean Code" faktycznie chyba odradza, bo wg niego sama potrzeba takiego komentarza oznacza, że funkcja jest za długa. Ale wg jego szkoły, funkcja powinna mieć ze 3 linie, max 5. Uważam, że jest to czasem przesadą. W "Code Complete" z kolei zalecają użycie komentarzy przy klamrach zamykających tam, gdzie trzeba. Ostrzegają, że to sygnał ostrzegawczy mówiący o zbytniej złożoności kodu, ale nie wykluczają, że czasami może to mieć sens.

W "Code Complete" natomiast odradzają korzystania z kilku linii oddzielających pod rząd. Popieram ich w 100%. Nigdy nie robię tak, jak polaczek. Stosuję linię oddzielającą, ale tylko jedną. MAX dwie, gdy potrzebuję aż tylu poziomów komentarzy.

@andrzej1982pl:
A czemu klamry w tej samej linijce uważasz za "utrudnianie sobie życia"? To może być nawet jeden klawisz mniej niż wymaga umieszczenie klamry w następnej linii. Chociaż raczej mało kto pisze tak, jak to napisałeś:

void funkcja(){
}

Zamiast tego, wstawiają po liście argumentów funkcji jedną spację:

void funkcja() {
}

Ten styl jest równie rozsądny jak inny. Javę praktycznie zawsze tak się pisze, bo Sun narzucił taki standard kodowania.

andrzej1982pl napisał(a)

Gdzieś przeczytałem, że tak się powinno i zacząłem sie tego trzymać.

Chodzi po prostu o to, że trudniej wtedy o pomyłkę. Czasami dodaje się kolejną linię do kodu wykonywanego gdy warunek zachodzi i wtedy, jeśli klamer nie ma, może wyjść taki kwiatek:

if (foo.isBar())
  instr1();
  instr2();
instrPozaWarunkiem();

Chociaż w sumie nie wiem na ile często takie pomyłki się zdarzają. Nie przypominam sobie, żeby mi się zdarzyły, ale też sam zawsze używam klamer.

Odnośnie pulpitu, to czasem robię na nim porządek i prawie nic tam nie mam. Kiedyś cały czas utrzymywałem bardzo minimalistyczny pulpit. Doszedłem jednak do wniosku, że to totalne marnotrawstwo miejsca. Mam rozdzielczość HD i jakbym miał tylko 10 ikon, to wykorzystywałbym ile? Kilka procent tego miejsca?

bswierczynski napisał(a)

@andrzej1982pl:
A czemu klamry w tej samej linijce uważasz za "utrudnianie sobie życia"?

Wg mnie łatwiej odnaleźć klamrę otwierającą jeśli znajduje się w tej samej kolumnie co klamra zamykająca. Zwłaszcza jeśli kod przegląda się w czystym notatniku, co czasem się zdarza.

bswierczynski napisał(a)

To może być nawet jeden klawisz mniej niż wymaga umieszczenie klamry w następnej linii.

Bez przesady aż taką oszczędnością bajtów. Mamy dość szybkie łącza i spore dyski w tych czasach. Jeśli ceną za tą oszczędność ma być mniejsza czytelność (a moim zdaniem tak jest), to wybieram czytelność, nawet jeśli plik z kodem ma być ciut większy.

Ja kiedyś miałem zboczenie na punkcie pisania czytelnego kodu, czytałem ksiązki o których mówi bświerczyński itd. Wyleczyła mnie pierwsza praca. Gdy zobaczyłem ludzi, którzy srają na jakość kodu byle by działał i robią na tym karierę (że działa) stwierdziłem że czytelność to raczej najmniej ważny aspekt tworzenia oprogramowania. Gdy skończy się development twórcy najczęściej i tak odchodzą więc wali ich to ile ekipie, która przyjdzie po nich, zajmie zrozumienie jak działa produkt. Czy ktoś pisze czytelny kod na rozmowie kwalfikacyjej też raczej ciężko sprawdzić więc to umiejętność bardzo niedoceniana. Natomiast dużo bardziej doceniana jest znajomość konkretnych zagadnień, konkretnych technologii i na nauce takich rzeczy właśnie się skupiłem.
I zamiast książki "Czysty Kod" polecam książkę "Piękny Kod", gdyż właśnie w niej są pokazane różne triki, algorytmy, koncepcje projektowe, które sprawiają, że jesteś w stanie zaprogramować więcej od gościa który skupia się głównie na pisaniu czytelnego kodu

Hehehe... Ja mam swój standard, a do tego praca mnie nie wyleczyła z odpowiedzialnego formatowania kodu.

co do problemu opisanego przez endless_loop: sterroryzowanie 8 / 10 studentów na praktykach w firmie w której pracowałem o to żeby pisali lepiej oraz wywieranie presji na tych z którymi współpracuje aby trzymali standard jednak wychodzi na dobre. Ba, nawet mój szef +/- przyjął mój styl i w tych projektach w których ja robię jest on trzymany przez wszystkich. Może po prostu przy projektach gdzie pracuje 3 lub więcej osób możliwość odczytania kodu drugiej osoby też jest ważna.

"Czysty kod" nie raz już tu polecałem. UWażam tę książkę za jedną z najważniejszych pojedynczych książek, jakie powinien przeczytać każdy programista.

Dzisiaj spędziłem, zachęcony Twoimi oraz kilku innych osób opiniami, około 1.5 latając jak dureń po znanych mi księgarniach żeby kupić tą książkę. Niestety, misja nie została wykonana bo 2 ksiągarnie były zamknięte a w trzeciej wszystkie wykupiono mimo że tydzień temu były co najmniej dwie ;)

Tak mi się jeszcze przypomniało że mam zboczenie nie do końca związane z pisaniem kodu - zdarza mi się zatrzymać podczas siedzenia przy komputerze i zachwycić się tym co ta maszyna wyczynia żebym ja mógł robić to co robię.
Np. zminić rozmiar okna albo przesunąć scrollbara i liczyć w myślach przetwarzane komunikaty. Albo uruchomić byle jaki program i starać się po kolei wyobrazić co system robi. Albo zastanawiać się nad warstwamia abstrakcji. Albo podziwiać "animację" po najechaniu myszką na czerwony przycisk zamknij w prawym górnym rogu. etc, etc. To chyba niezbyt normalne ;)

Ja mam jeszcze zboczenia używania skracaczy linków za każdym razem jak daję gdzieś link. Jakoś tak zacząłem używać i weszło mi to w krew.

Dobra, to i ja się pochwalę programistycznym zboczeniem - przez długi czas miałem silną tendencję do stosowania czteroliterowych nazw zmiennych w Pythonie (niech żyje symetria...).

...z nie-programistycznych zboczeń - testuję Google Chrome.

ja mam takie zboczenie że jak coś długo robię trudniejszego i w końcu zacznie to działać to zamiast pracować dalej to się tym podniecam przez pare godzin i "testuję" na trzysta sposobów : X

Co do wątku:

1. Klamerki daję w nowej linii w C i C#, w Javie i JS nie. Trzymam się konwencji i standardów.
2. To samo dotyczy nazewnictwa funkcji wielkimi literami, chociaż w JS nie zawsze robię to spójnie. (Może tu dobrym rozwiązaniem byłyby globalne funkcje wielkimi literami, a lokalne małymi?)
3. Co do wydajnego operowanie na tablicach w JS - kogoś to w ogóle obchodzi?
4. Dawanie klamerek do każdego ifa jest niby dobre, ale w takiej sytuacji, to byłaby przesada:

private bool CompareBuffers(byte[] a, byte[] b)
{
    if (a == b)
        return true;

    if (a == null || b == null || a.Length != b.Length)
        return false;

    return RtlCompareMemory(a, b, (uint)a.Length) == a.Length;
}

Z drugiej strony, jeśli taki return byłby w ifie w pętli, to dałbym klamerki.

5. Staram się, żeby funkcja po prostu mieściła się na ekranie. Jakieś sztuczne podziały typu 3 czy 10 linii maks zalatują perwersją.
6. Fajnie jest też, gdy funkcja robi jedną rzecz, ale to też nie zawsze ma sens. Na przykład: pod keypress w textboxach A i B jest podpięta funkcja, która:
   a) Na podstawie pól A, B oraz tylko do odczytu C i D wylicza wartość dla pola E.
   b) Jeśli któreś z pól A lub B jest puste to wyświetla gwiazdkę i podświetla je na czerwono.
   c) Jeśli wartość w polu E przekracza zakres zdefiniowany w hiddenach F i G, to podświetla na czerwono.
   d) Jeśli wszystkie wartości są prawidłowe, oraz hiddeny H i I zawierają odpowiednie wartości, to wyświetlany jest przycisk Z.
   Niby należałoby to podzielić na 5 funkcji, jedna z nich znajdowałaby kontrolki i odpalała 4 następne. Każda z nich byłaby bardzo krótka, za to miałaby długą listę parametrów. Sztuka dla sztuki - już lepiej napisać jedną dłuższą funkcję, podzieloną podwójnymi enterami na sekcje z ewentualnym komentarzem po co, dlaczego i do czego ona służy.
7. Komentarze przy klamrze zamykającej - WTF? Wystarczy, że postawię kursor za nią, to obie klamry podświetlą się oczojebną zielenią.
8. Mam pusty pulpit, jeśli coś na nim umieszczam, to tylko coś co mam zrobić natychmiast i wyrzucić albo coś co mam do zrobienia, a nie mogę o tym zapomnieć.

Co do zboczeń:

1. Piszę komentarze.
2. Piszę dokumentację.
3. Zamiast poczytać książkę czy czegoś się nauczyć, to tracę czas na głupich forach w necie.
4. Tak naprawdę nie lubię większości programistów z pracy.
5. Podoba mi się Helena Bonham Carter

Konie.

Moje zboczenie to przykładanie kartki do wylotu subwoofera jak się napiję. :>