GoldenLine
Zaloguj się
Mateusz Berezecki

Mateusz Berezecki no fluff, just stuff

Temat: Rynek IT z C C++

tak mi sie jakos przypomnialo o IOCCC, a ze pasuje on klimatem do tej dyskusji zamieszczam ten oto link :-)

http://www.ioccc.org/2004/arachnid.c :)

Update:

ewentualnie to: http://www.ioccc.org/2004/sds.c :-)Mateusz Berezecki edytował(a) ten post dnia 03.10.08 o godzinie 11:18
Link do wypowiedziLink
Jakub L.

Jakub L. Programista

Temat: Rynek IT z C C++

Szymon Kubisiak:
Spacja : )
int *piCostam;
int* piCostam;

To tylko moja rada dla ludzi którym trudno jest pojąć ideę pointerów.

int* pierwszy, drugi;

Czym jest drugi?
Definiowanie dwóch zmiennych w jednej linijce nie jest najlepszym zwyczajem, ale akurat w tym przypadku spcja pomaga.
Link do wypowiedziLink
Piotr B.

Piotr B. development engineer

Temat: Rynek IT z C C++

hm, ja jakoś wolę trzecią opcję - int *costam :)
ech.... nie doczytałem dokładnie tamtego postu ;) ok. Ale i tak jakoś wolę właśnie taki zapis.Piotr Borys edytował(a) ten post dnia 31.10.08 o godzinie 23:37
Link do wypowiedziLink

konto usunięte

Temat: Rynek IT z C C++

Jakub L.:
Szymon Kubisiak:
Spacja : )
int *piCostam;
int* piCostam;

To tylko moja rada dla ludzi którym trudno jest pojąć ideę pointerów.

int* pierwszy, drugi;

Czym jest drugi?
Definiowanie dwóch zmiennych w jednej linijce nie jest najlepszym zwyczajem, ale akurat w tym przypadku spcja pomaga.

Powinno brzmieć: "Definiowanie dwóch wskaźników w jednej linijce nie jest najlepszym zwyczajem".

Bo chyba nie ma sensu:


int i;

int j;

int c;
Link do wypowiedziLink
Szymon Kubisiak

Szymon Kubisiak Developer aplikacji
mobilnych Android

Temat: Rynek IT z C C++

Dobrym zwyczajem jest inicjowanie zmiennych, zatem

int i = 0;
int j = 0;
int c = 1;

wg mnie jest lepsze niż

int i = 0, j = 0, c = 1;

: )

To pierwszy argument, drugi to łatwość późniejszej zmiany typu, np na unsigned czy innej wielkości.

Trzeci (i najsłabszy) argument to osobisty styl, ja np staram się trzymać zasady "1 operacja - 1 lina".

Kwestia preferencji, jak wszystko w C/C++.

PS : Zauważam że skupiliście się na samym zapisie, a mi chodziło przede wszystkim o myśleniu o wskaźniku jako oddzielnym typie a nie gwiazdce przed typem. typedef i naprzód : D
Link do wypowiedziLink

konto usunięte

Temat: Rynek IT z C C++

Szymon Kubisiak:
PS : Zauważam że skupiliście się na samym zapisie, a mi chodziło przede wszystkim o myśleniu o wskaźniku jako oddzielnym typie a nie gwiazdce przed typem. typedef i naprzód

typedef to zdecydowanie zbyt mało doceniana konstrukcja w C++.
W Delphi redefinicja to podstawa.

Dla mnie chore jest:


void display_info(std::tr1::shared_ptr<Environment> env);

skoro można:


void display_info(EnvironmentTransporter env);

lub wręcz:


void display_info(Environment::transporter env);
Link do wypowiedziLink
Szymon Kubisiak

Szymon Kubisiak Developer aplikacji
mobilnych Android

Temat: Rynek IT z C C++

Otóż to!
Niestety, intelisense i doxygen się często gubią na typedefach : (
Link do wypowiedziLink
Jakub L.

Jakub L. Programista

Temat: Rynek IT z C C++

Piotr Likus:
Jakub L.:
int* pierwszy, drugi;

Czym jest drugi?
Definiowanie dwóch zmiennych w jednej linijce nie jest najlepszym zwyczajem, ale akurat w tym przypadku spcja pomaga.

Powinno brzmieć: "Definiowanie dwóch wskaźników w jednej linijce nie jest najlepszym zwyczajem".

Ale tam nie ma dwóch wskaźników?
http://www.tenouk.com/Module8.html 8.2 się ze mną zgadza.
Bo chyba nie ma sensu:


int i;

int j;

int c;

Dla mnie ma. Łatwośc modyfikacji i można sobie zmienną jeszcze skomentować.
Link do wypowiedziLink

konto usunięte

Temat: Rynek IT z C C++

Jakub L.:
int* pierwszy, drugi;
Ale tam nie ma dwóch wskaźników?
http://www.tenouk.com/Module8.html 8.2 się ze mną zgadza.

Nie ma. Zerknij na ostatni przykład w 8.2 - masz tam wskaźnik do floata i float.
Link do wypowiedziLink
Mateusz Berezecki

Mateusz Berezecki no fluff, just stuff

Temat: Rynek IT z C C++

fajna dyskusja o tym czy wiazac sznurowke zaczynajac od lewej czy od prawej... :P
Link do wypowiedziLink
Piotr B.

Piotr B. development engineer

Temat: Rynek IT z C C++

Mateusz Berezecki:
fajna dyskusja o tym czy wiazac sznurowke zaczynajac od lewej czy od prawej... :P

niby tak... ale gdyby nomenklatura była faktycznie zbędna, to by firmy nie tworzyły polityki stylu programowania... chodzi o to, żeby kod tworzony przez grupę ludzi był czytelny dla wszystkich :)
Natomiast fakt, że spieranie się, który zapis jest _lepszy_, hmmm.... ;)
Link do wypowiedziLink
Maciej Siniło

Maciej Siniło Programista

Temat: Rynek IT z C C++

Piotr Borys:
Mateusz Berezecki:
fajna dyskusja o tym czy wiazac sznurowke zaczynajac od lewej czy od prawej... :P

niby tak... ale gdyby nomenklatura była faktycznie zbędna, to by firmy nie tworzyły polityki stylu programowania... chodzi o to, żeby kod tworzony przez grupę ludzi był czytelny dla wszystkich
Sensowne konwencje powinny raczej uwzgledniac sprawy powazne, dotyczace konkretnych zasad (np. nie rzucamy wyjatkow), a nie kosmetyke (czyli ktory nawias w ktora strone).
Link do wypowiedziLink
Szymon Kubisiak

Szymon Kubisiak Developer aplikacji
mobilnych Android

Temat: Rynek IT z C C++

Maciej Siniło:
Sensowne konwencje powinny raczej uwzgledniac sprawy powazne, dotyczace konkretnych zasad (np. nie rzucamy wyjatkow), a nie kosmetyke (czyli ktory nawias w ktora strone).

Przypominam ze zaczelo sie od sposobu patrzenia na wskazniki dla początkujących - i zapis MA tu spore znaczenie.

A ktory nawias w ktora strone tez jest dosc wazne; roznica pomiedzy rozumieniem za 1 rzut oka a analiza znak po znaku.
Kazda czesc konwencji ma znaczenie, choc oczywiscie "rzygnięcie eksepszonem" znienacka lub nie stoi o wiele wyzej :)
Link do wypowiedziLink
Piotr B.

Piotr B. development engineer

Temat: Rynek IT z C C++

Maciej Siniło:
Sensowne konwencje powinny raczej uwzgledniac sprawy powazne, dotyczace konkretnych zasad (np. nie rzucamy wyjatkow), a nie kosmetyke (czyli ktory nawias w ktora strone).

też nie tak do końca... niby to mało ważne i banalne, ale jak czytasz kod, w którym raz klamra otwiera się w tej samej linii, co instrukcja, a dwie linijki niżej w linii osobnej, to to się naprawdę ciężko analizuje... chodzi o tempo analizy kodu.
Link do wypowiedziLink
Maciej Siniło

Maciej Siniło Programista

Temat: Rynek IT z C C++

Piotr Borys:
Maciej Siniło:
Sensowne konwencje powinny raczej uwzgledniac sprawy powazne, dotyczace konkretnych zasad (np. nie rzucamy wyjatkow), a nie kosmetyke (czyli ktory nawias w ktora strone).

też nie tak do końca... niby to mało ważne i banalne, ale jak czytasz kod, w którym raz klamra otwiera się w tej samej linii, co instrukcja, a dwie linijki niżej w linii osobnej, to to się naprawdę ciężko analizuje... chodzi o tempo analizy kodu.
Nie wplywa to jednak w zaden sposob na poprawnosc kodu. Kwestia czy dla wygody czytajacego ja mam poswiecac wygode i predkosc pisania.
[Edit] Generalnie w moim zespole staralem sie zawsze unikac narzucania ludziom konkretnego stylu "kosmetycznego". Kazdy ma jakies przyzwyczajenie i poki kod dziala i nie ma bledow, to nie bede ganial za to, ze ktos gdzies nie postawil spacji za przecinkiem.Maciej Siniło edytował(a) ten post dnia 03.11.08 o godzinie 15:51
Link do wypowiedziLink
Piotr B.

Piotr B. development engineer

Temat: Rynek IT z C C++

Maciej Siniło:
Nie wplywa to jednak w zaden sposob na poprawnosc kodu. Kwestia czy dla wygody czytajacego ja mam poswiecac wygode i predkosc pisania.

zależy, ile czasu nad nim spędzają revisorzy kodu. Jeśli niewiele - faktycznie, lepiej dać wolną rękę programistom.
Link do wypowiedziLink

konto usunięte

Temat: Rynek IT z C C++

Piotr Borys:
Maciej Siniło:
Nie wplywa to jednak w zaden sposob na poprawnosc kodu. Kwestia czy dla wygody czytajacego ja mam poswiecac wygode i predkosc pisania.

zależy, ile czasu nad nim spędzają revisorzy kodu. Jeśli niewiele - faktycznie, lepiej dać wolną rękę programistom.

Albo ludzie ze wsparcia...
Bo pisze się łatwo i przyjemnie, ale jeśli kod ma być kiedyś poprawiany - za 5, 10 lat - to warto pisać w podobny sposób (lub używać automatycznego formattera przed oddaniem softu).

Ja często mam do czynienia z softem sprzed 20 lat. Osiwiałbym jeszcze bardziej, gdyby każdy programista pisał "wcięcia" w inny sposób. W C/C++ jest to szczególnie ważne, bo jest to język bardzo elastyczny składniowo.
Link do wypowiedziLink

konto usunięte

Temat: Rynek IT z C C++

Piotr Likus:

Ja często mam do czynienia z softem sprzed 20 lat. Osiwiałbym jeszcze bardziej, gdyby każdy programista pisał "wcięcia" w inny sposób. W C/C++ jest to szczególnie ważne, bo jest to język bardzo elastyczny składniowo.

Sam podsunąłeś rozwiązanie: będąc czytelnikiem cudzego kodu, używaj formattera. Wtedy programista cały i reviser syty.
Link do wypowiedziLink
Piotr B.

Piotr B. development engineer

Temat: Rynek IT z C C++

A może jeszcze przed rozpoczęciem maintenance'u przeprowadzać refactoring, żeby także jednolite standardy nazewnictwa wprowadzić, hm? Ludzie, nie dajmy się zwariować, po to lider projektu czy kto tam inny wprowadza reguły, żeby programiści się tego trzymali... ja wiem - programista to artysta :P sam nim jestem...
ech.
Link do wypowiedziLink

konto usunięte

Temat: Rynek IT z C C++

Tomasz Krzal:
Piotr Likus:

Ja często mam do czynienia z softem sprzed 20 lat. Osiwiałbym jeszcze bardziej, gdyby każdy programista pisał "wcięcia" w inny sposób. W C/C++ jest to szczególnie ważne, bo jest to język bardzo elastyczny składniowo.

Sam podsunąłeś rozwiązanie: będąc czytelnikiem cudzego kodu, używaj formattera. Wtedy programista cały i reviser syty.

a) to skutecznie wydłuża proces zmian
b) chyba nigdy nie robiłeś zmian "punktowych". Punktowych ze względu na potrzebę śledzenia zmian oprogramowania, a nie ze wzlgędu na swoją sprytność...

Formattera można użyć raz - przed oddaniem oprogramowania.
Bo i tak po nim zwykle trzeba poprawiać ręcznie.
Piotr Borys:
A może jeszcze przed rozpoczęciem maintenance'u przeprowadzać refactoring, żeby także jednolite standardy nazewnictwa wprowadzić, hm?

"Po nas choćby potop"?
Chyba nie po to się pisze oprogramowanie, żeby je za miesiąc refaktorować? Oczywiście spotkałem się takim podejściem w kilku wersjach, m.in.:
a) "fire and forget" - piszesz kod i po miesiącu udajesz że to nie twój. umożliwia to szybkie tworzenie oprogramowania które niedługo trzeba będzie poprawiać. Ważna jest przy tym technika wycofywania się ze swojego autorstwa.

b) "unmaintable code" - piszesz kod specjalnie w taki sposób, aby nikt z maintenance'u nie mógł czasami poprawić Twojego oprogramowania. Dzięki temu ciągle masz pracę. Ta technika jest szeroko stosowana, nawet doczekała się kilku esejów:

freeworld.thc.org/root/phun/unmaintain.html
http://tlug.org.za/old/htwuc/unmain.html
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Co sie dzieje w Polsce (ryn...




Wyślij zaproszenie do
Anuluj