печально быть антисоциальным - Nedrošības zīmes

09:50 am - Nedrošības zīmes

Kad redzu setterus, getterus vai komentārus, sāku uztraukties, jo tā ir zīme sliktam kodam. No sākuma nesapratu kapēc, jo šie pričendāļi ir radīti labai koda uzturēšanai.

Mēģinot tos attaisnot, sapratu, ka lietošana ir vēlama un pieļaujama divās vietās:
- Noteikti to jādara pie moduļu interfeisu apraksta. Vietās, kur tevis radīto kodu izmantos programmētāji no citām komandām vai organizācijām.
- Ja jau rakstīšanas laikā jūt, ka neskaidrība ir liela; ka kāds koda gabals būs tūlīt jāpārraksta, tad tā ir vieta komentāriem. Var uzmest skici un iet gulēt, tad otrā dienā ar skaidru galvu satīrīt. Tāpat arī dažreiz izmanto setterus, getterus, ja ir skaidrs, ka no primitīvajiem tipiem pāries uz klasēm, bet nemaz nav skaidrs kā tas tiks darīts.

Šīs nedrošības zīmes parasti ir sliktam kodam.

---

Par aksesoriem:

- Enkapsulāciju nevajadzētu uztvert kā likumu, ka nevienam objekta atribūtam nedrīkst piekļūt pa tiešo. Ja ir nepieciešamība mainīt kādu noteiktu atribūtu, tad jāļauj to darīt. Lielākoties tie ir datu objekti, kuri grupē datus, bet neko daudz ar tiem neveic.

- Tell, don't ask. Ja ir kas jādara ar datiem, kas atrodas citā objektā, tad liec tam objektam veikt darbu. Ja viņam šīs funkcionalitātes nav, bet Tev ir - atdod to viņam.

class LittleGnome:
  def __init__(self):
    self.pouch = Coins(10)

class Troll:
  def howMuch(self, gnome):
    self.pouch = gnome.pouch
    return self.countCoins(self.pouch)
  def countCoins(self, pouch):
    return pouch.ammount()

class LittleGuy:
  def __init__(self):
    self.pouch = Coins(10)
  def howMuch(self):
    return self.countCoins(self.pouch)
  def countCoins(self, pouch):
    return pouch.ammount()

class GoodCop:
  def howMuch(self, guy):
    return guy.howMuch()

- Mūsdienu valodās, jau ir iebūvēta property iespēja, kas automātiski rada aksesorus, ja vēlāk būs nepieciešams mainīt to funkcionalitāti.

Par komentāriem

- Komentāru vietā jāraksta saprotams kods.

- Objektu nosaukumiem jānorāda uz to lomu konkrētajā vietā. Data, Info, Manager, Stuff nav sakarīgi nosaukumi. Dodot nosaukumus nav jābūt formāliem, ja kāds piedauzīgs vārds palīdzēs atcerēties jēgu - jo labāk.

- Funkciju (metožu) nosaukumiem jāizskaidro to rīcība. Ja f-ja sākās ar get, tad tai nav blakusefektu, ja tā sākas ar is, tad tā atgriež boolean vērtību. Arī funkciju argumentiem jāpalīdz saprast, kādā secībā tie jānodod, kuri ir obligāti un kuri izmaina nodoto objektu.

Šeit gan jāatgriežās pie Tell, don't ask. Labāk englarge(something, by=3) vietā something.enlarge(by=3).

- Kontroles struktūras jāraksta skaidri un saprotami:

//nevis
if (++a)
{
  a <<= 1;
}
else
{
  a = 0; 
}
return a;

//bet 

a = a + 1;

if (a == 0)
  return 0;

return a*2;

Kur komentāri ir nepieciešami:

- Ja tiek sagaidīts, ka kods tiks tikai saukts. Piemēram no bibliotēkas.
- Ja tiek saukts svešs, slikti dokumentēts kods.
- Ja tiek izmantots sarežģīts, komplekss algoritms. Vēlams ielikt atsauci uz literatūru/dokumentāciju, kur tas ir izskaidrots. Ja ir atkāpes no kāda klasiska algoritma, tad arī to jāieliek komentāros.
- Ja ir veikta optimizācija un upurēta koda skaidrība. (Kas ir jādara praktiski Nekad!)
- Ja pašam nav skaidrs, kā tika panākts rezultāts. Piemēram, prototips bez testiem.
- Komentāri ir jauki valodās/vidēs, kas atbalsta docstringus.
- Zema līmeņa valodās kā assembly, kur ir grūti lasāmi komandu nosaukumi. Tomēr arī tur var izvēlēties gana saprotamus mainīgo un apakšprogrammu nosaukumus.

Tāda ir mana pieredze galvenokārt strādājot nelielā komandā un sadarbojoties koda līmenī ar programmētājiem citās valstīs. Lielākoties izmantoju C++ un Python.

return ++a*2; // cik ir 0*x? ;p

obj.doTheMagicTrick(); // if it works, don't touch it!