Laravel programmētāji

[jurchiks]

>No frontenda tev tāpat nāk stringi, arī skaitļiem. Tad ko, tu katru skaitli salīdzini ar (int)$_POST['id'] === $id ?

$request->getData->getInt('foo'/*, $default = 0*/);

 

>Vai arī tu noselektē no db datus, un arī vienmēr casto tos uz int pirms salīdzināšanas?

Ja izmanto mysqlnd un PDO::ATTR_EMULATE_PREPARES => false, tad int arī atgriežas kā int, nevis string.

 

>Tad if`ā tu arī salīdzini if($obj === null) vai tomēr if($obj)? Es ceru, ka === null, jo if($obj) tomēr casto uz boolean, kas basically ir double equals.

Kas tas par stulbu jautājumu? Tikko taču teicu, ka vienmēr salīdzinu ar ===.

 

>nav jādrukā vienkārši lieki simboli...

Ja tie liekie simboli nozīmē, ka es 100% zinu, kā darbojas mans kods, nevis paļaujos uz "PHP magic", tad jā, es drukāšu tos "liekos" simbolus.

[daGrevis]

> Vienkārši, ja tu salīdzini ar ===, tad rezultāts ir daudz paredzamāks

 

This.

 

> No frontenda tev tāpat nāk stringi, arī skaitļiem. Tad ko, tu katru skaitli salīdzini ar (int)$_POST['id'] === $id ?

 

Kad dati nāk no frontenda, mēs viņus padodam formas klasei, kas viņus novalidē un atgriež jau normālos tipos. Lielākā daļa koda jau stradā ar pareiziem tipiem, jo pareizais tips tiek uzlikts ASAP.

 

> Vai arī tu noselektē no db datus, un arī vienmēr casto tos uz int pirms salīdzināšanas?

 

Datubāzē arī datiem ir pareizi tipi. Pēc selecta es dabūju jau visu kā nākas.

 

> instanci no db, un tur var būt divi varianti rezultātam - objekts vai null, ja neeskistē ieraksts. Tad if`ā tu arī salīdzini if($obj === null) vai tomēr if($obj)?

 

Bieži vien uzraksu “liekos simbolus“ for clarity:

 

> if x is None:

 

Bet nu normālā gadījumā tas būtu expcetion, kuru uzreiz tu arī nohandlēju

 

> nevis paļaujos uz "PHP magic", tad jā, es drukāšu tos "liekos" simbolus.

 

This. Manā gadījumā tas ir JavaScript, bet no thanks, negribu paļauties, ka JavaScript castos kko — cik bieži nav redzēts kas notiek, kad tipi nav vienādi un JavaScript mēģina darīt kko “sensible“.

[Kavacky]

Ja tie liekie simboli nozīmē, ka es 100% zinu, kā darbojas mans kods, nevis paļaujos uz "PHP magic", tad jā, es drukāšu tos "liekos" simbolus.

Tas ir kā? Tu esi pats pārlasījis PHP binary mašīnkodu un pats salodējis mikroshēmas, uz kā tas izpildās?

 

Ja nē, tad tu tāpat neko nezini, attiecīgi - plika diršana.

[F3llony]

Kā tas ir nezini? Kerneļi nav testēti, syscalls nav testēti, CPU instrukcijas nav testētas, pašas VM uz kurām darbojas aplikācijas nav testētas? Kas tas par matiem pievilktu argumentu?

[jurchiks]

Ja nē, tad tu tāpat neko nezini, attiecīgi - plika diršana.

Es zinu pietiekami daudz.

[Kavacky]

PHP ķipa nav testēts?

[F3llony]

Protams, ka ir. Un kā tas ir arguments diskusijā par user-space kodu? :D

[Mr.Key]

Kad tu atlasi ActiveRecord instanci no db, un tur var būt divi varianti rezultātam - objekts vai null, ja neeskistē ieraksts. Tad if`ā tu arī salīdzini if($obj === null) vai tomēr if($obj)? Es ceru, ka === null, jo if($obj) tomēr casto uz boolean, kas basically ir double equals.

Varētu par šo sīkāk? Kāds ir tas gadījums, kad DB row objekts var tikt castots uz boolean false, ja eksistē tas ieraksts?

Edited July 3, 2016 by Mr.Key

[briedis]

Varētu par šo sīkāk? Kāds ir tas gadījums, kad DB row objekts var tikt castots uz boolean false, ja eksistē tas ieraksts?

 

nē, es tieši par to, ka ja neeksistē.

 

Consider this: 

$profile = UserProfile::find($id); // atgriež null neeksistējoša ieraksta gadījumā

 

Sanāk, ka === lietotājiem šajā gadījumā jāsalīdzina šādi, lai pārbaudītu vai ir tieši tāds tips:

 

if($user instanceof UserProfile)

 

Lietot !== null nedrīkst, jo tas negarantē konkrētu tipu, bet gan tikai izslēdz null.

 

Es sāku, ka pilnīgi bezjēdzīgi visur piekopt ===, tīri lai "drošāk justos".

[Mr.Key]

Skaidrs, piekrītu.

 

Man gan liekas, ka stilistiski labāk ir likt atstarpi pirms iekavas, kas seko valodas konstrukcijai. Vieglāk acīm, kad jāatšķir no funkcijām.

[jurchiks]

Lietot !== null nedrīkst, jo tas negarantē konkrētu tipu, bet gan tikai izslēdz null.

 

Es sāku, ka pilnīgi bezjēdzīgi visur piekopt ===, tīri lai "drošāk justos".

Kā tas ir jāsaprot - negarantē? Vai ir pierādīti gadījumi, kad atgriež ko citu?

[briedis]

Skaidrs, piekrītu.

 

Man gan liekas, ka stilistiski labāk ir likt atstarpi pirms iekavas, kas seko valodas konstrukcijai. Vieglāk acīm, kad jāatšķir no funkcijām.

 

Lietoju PSR1/2standartu auto formatēšanu, pats nedomāju par atstarpēm, IDE pati saliek, kur vajag.

 

Kā tas ir jāsaprot - negarantē? Vai ir pierādīti gadījumi, kad atgriež ko citu?

 

Nu figviņzin, tu taču kodē "strikti", un koda atkarības var mainīties, tāpēc tev taču jāpārbauda pret tipu, kuru sagaidi, nevis to, kuram nevajadzētu būt... Sāk jau pretrunas parādīties :)

[jurchiks]

Nu pagaidi, ja tu raksti metodi, kura atgriež konkrētās klases instanci vai null, tad tur nekas cits nedrīkst būt. Tur pēc būtības nekas nedrīkst mainīties, un ja mainītos, tad uzreiz visa sistēma aizietu pa pieskari anyway.

Strikti kodēt nenozīmē visur izmantot instenceof, nesāc te tagad murgot.

[Mr.Key]

Lietoju PSR1/2standartu auto formatēšanu, pats nedomāju par atstarpēm, IDE pati saliek, kur vajag.

Control structure keywords MUST have one space after them; method and function calls MUST NOT.

 

Bet ok, sapratu, ka forumā raksti bez atstarpes, kodā to atstarpi ieliek autoformatētājs.

Edited July 3, 2016 by Mr.Key

[Mr.Key]

Nu pagaidi, ja tu raksti metodi, kura atgriež konkrētās klases instanci vai null, tad tur nekas cits nedrīkst būt. Tur pēc būtības nekas nedrīkst mainīties, un ja mainītos, tad uzreiz visa sistēma aizietu pa pieskari anyway.

Strikti kodēt nenozīmē visur izmantot instenceof, nesāc te tagad murgot.

Ja jau neuzticies tam, ka pietiek ar "if ($obj)", tad kāpēc uzticies, ka $obj būs vajadzīgā tipa?