-
Opušteno
(
http://www.devprotalk.com/forumdisplay.php?f=16)
| Gruja |
28. 02. 2006. 10:51 |
Programiranje nema veze ni sa jednom drugom inzenjerskom disciplinom. Ne postoje striktna pravila koja uvek vode do uspeha. Samo preporuke, iskustvo i osecaj.
|
| kaizen |
28. 02. 2006. 11:20 |
Citat:
Originalno napisao Gruja
Programiranje nema veze ni sa jednom drugom inzenjerskom disciplinom. Ne postoje striktna pravila koja uvek vode do uspeha. Samo preporuke, iskustvo i osecaj.
|
Lepo rečeno. |
| dinke |
28. 02. 2006. 11:25 |
Evo i ja da se ukljucim u ovu nadasve interesantnu diskusiju :)
Da budem iskren, ne slazem se sa vecinom "saveta" koje je ovaj lik naveo. Ajmo redom:
10) Use exceptions
Slazem se sa svim navedenim. Uopste ne razumem sta je Joel sa onim tekstom hteo da kaze.
9) (Don't) Use unsigned integers for values that can only be positive
Neki jezici zaista ne omogucavaju definisanje unsigned vrednosti (PHP, Java), ali tamo gde je to jezikom omoguceno (C/C++) treba ga koristiti. Ne samo da se tako kreira robusniji kod, vec se stedi i memorija. Mozda nebitno za danasnje programe, ali kod baza nije isto koristiti big int kada recimo int unsigned zavrsava posao (veca tabela = sporija tabela).
8) (Don't) Design classes parallel to their physical counterparts
Takodje se apsolutno slazem sa ovom tvrdnjom, narocito sa delom da je inheritance "overrated". Licno sam vidjao neke PHP bibliotete gde je klasa koju koristim "10-to koleno" od osnovne klase. Mislim da bi svi pocetnici u OOP dizajnu trebalo da malo citaju Bruce Eckela, koji jednostavno savetuje koriscenje kompozicije kad god niste sigurni da li koristiti nasledjivanje ili kompoziciju. car have engine, car is not engine.
7) (Don't)Make sure your team shares a common coding standard
Ocigledno da autor teksta nikada nije morao da edituje fajl na kome su radila 3 programera gde je svako koristio sopstveni koding standard. Sto se mene tice pravila su sledeca:
- Postoji definisan koding standard za celu kompaniju ili je deo specifikacije projekta
ili
- (losije resenje) Svaki developer koristi svoj stil ali se prilikom izmena vec napisanog koda postuje standard koriscen u fajlu (na taj nacin barem nemas 3 stila u jednom fajlu)
6) (Don't)Write lots of comments
Komentare treba pisati, tamo gde je to potrebno. Dakle ne:
//incrementing i
i++;
nego
//moving to next element
i++;
i sl.
Inace, ja narocito insistiram na kreiranju API dokumentacije, pa je phpdocumentor stil komentara (pandan javadoc kod Jave) standardni deo koding specifikacije koju sam pominjao gore.
5) (Don't)Use accessors or properties rather than public fields
Ovo je vec jeres :) Necu ni da komentarisem :)
|
| Milos Vukotic |
28. 02. 2006. 11:38 |
Citat:
Originalno napisao Gruja
Programiranje nema veze ni sa jednom drugom inzenjerskom disciplinom. Ne postoje striktna pravila koja uvek vode do uspeha. Samo preporuke, iskustvo i osecaj.
|
To se moze reci i za sve discipline koje se ticu rjesavanja problema. Sve izuzev prava. |
| Ilija Studen |
28. 02. 2006. 11:38 |
Poenta saveta br1 je da se ne trudiš da sve živo smisliš unapred, već da razmisliš, nažvrljaš neke osnovne beleške sebe radi na papir i kreneš da radiš. To je mnogo brže nego da razmisliš i posvetiš X dana na razradu kompletnog dizajna na papiru (koji može i da ne radi jer si propustio nešto izuzetno bitno).
Ako si disciplinovan programer i imaš kvalitetne igračke lako možeš da izađeš na kraj i sa izuzetno kompleksnim promenama na sistemu za relativno kratko vreme. Samo su od toga napravili bauk...
---------------
Što se 5tice tiče meni se izuzetno sviđa Ruby koji polja maskira sa accessorima. Npr:
Kôd:
car.max_speed = 250;
print car.max_speed;
Iza ovga stoje sledeći accessori:
Kôd:
class Car
def max_speed
@max_speed
end
def max_speed=(new_value)
@max_speed = new_value
end
end
Postoji i pojednostavljenje za pisanje accessora, ali ovo je samo kao primer. |
| ivanhoe |
28. 02. 2006. 15:23 |
po meni accessori imaju smisla samo ako se unutar njih vrse neke provere vrednosti, formatiranje podataka, hvataju exceptioni ili tako nesto.. ako imas setter koji samo uradi property=value i nista drugo, koji mu je onda smisao? (a to se vrlo cesto vidja po raznim bibliotekama...)
|
| Petar Marić |
28. 02. 2006. 15:33 |
Amen.
Accessor abstrahuje pristup class member-u da se objekat ne bi doveo u nedozvoljeno/neodređeno stanje.
|
| Ilija Studen |
28. 02. 2006. 16:25 |
Svež primer. Imam reklamnu kampanju koja ima vlasnika. Tokom prvog dela razvoja owner_name je bio varchar polje koje je sadržalo samo ime jer je to bilo dozvoljno da bi se zadovoljila prva specifikacija (owner_name je korišćen samo za statistike). Međutim, tokom rada sam došao do toga da mi owneri trebaju odvojeno pošto se na osnovu njih vrše neke druge kalkulacije (potreba da se globalni cenovnik zameni cenovnikom na nivou vlasnika i slične stvarčice). Izmena je bila veoma jednostavna:
PHP kôd:
// Stari kod
class Campaign {
/**
* Return owner name
*
* @return string
*/
function getOwnerName() {
return $this->columnValue('owner_name');
}
}
// Novi kod, sitna izmena
class Campaign {
/**
* Return owner object
*
* @return CampaignOwner
*/
function getOwner() {
return CampaignOwners::findById($this->getOwnerId());
}
/**
* Return owner name
*
* @return string
*/
function getOwnerName() {
if($this->getOwner() instanceof CampaignOwner) {
return $this->getOwner()->getName();
} else {
throw new Exception('Owner is missing');
}
}
}
Da sam sve vreme tretirao owner_name kao klasično polje i pristupao mu sa $this->owner_name postojeći kod bez većih izmena ne bi mogao da odgovori na nove zahteve.
Accessori? Uvek! |
| bojan_bozovic |
04. 03. 2006. 14:28 |
Citat:
On kaže:
"You should think before you code. Go ahead, but think for hours, not days."
Pošto se ti ne slažeš sa njim da li to znači da ti danima dizajniraš?
|
Tako moze u perlu da se zvrlja. Molim, program u C++ ne mozes da napravis a da prvo ne dizajniras sve. Najobicniji search&replace u tekst editoru da napises - algoritam za search&replace moras da imas gotov. Sto se saveta tice, veze nemaju sa zivotom. |
| kaizen |
04. 03. 2006. 18:00 |
Citat:
Originalno napisao bojan_bozovic
program u C++ ne mozes da napravis a da prvo ne dizajniras sve.
|
Ma daj. Je si li ti uopšte c++ programer?
Citat:
Originalno napisao bojan_bozovic
Sto se saveta tice, veze nemaju sa zivotom.
|
Zašto nemaju veze sa životom? |
| Vreme je GMT +2. Trenutno vreme je 10:27. |
|
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.
