Heh 10 saveta koje ne treba da pratite

[Gruja]

Programiranje nema veze ni sa jednom drugom inzenjerskom disciplinom. Ne postoje striktna pravila koja uvek vode do uspeha. Samo preporuke, iskustvo i osecaj.

[kaizen]

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]

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]

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]

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:

car.max_speed = 250;
print car.max_speed;

Iza ovga stoje sledeći accessori:

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]

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ć]

Amen.
Accessor abstrahuje pristup class member-u da se objekat ne bi doveo u nedozvoljeno/neodređeno stanje.

[Ilija Studen]

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]

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]

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?

Originalno napisao bojan_bozovic

Sto se saveta tice, veze nemaju sa zivotom.

Zašto nemaju veze sa životom?