dicht timmeren?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: 1 2 3 4 5 volgende »

Ozzie PHP

Ozzie PHP

29/02/2012 09:53:54
Quote Anchor link
Ik vraag me af in hoeverre jullie de invoer van parameters controleren / dicht timmeren.

Stel je hebt een functie:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
<?php
public function setPath($key, $path) {
  // hier komt wat code
}
?>


Nu moeten zowel $key als $path een string bevatten. Deze functie wordt uitsluitend gebruikt door de programmeur. Mensen van buitenaf kunnen deze functie niet aanroepen (bijvoorbeeld d.m.v. een formulier).

Nu vraag ik me af of ik moet controleren of zowel $key als $path een string zijn. Of gaat dat te ver? Anders moet je namelijk bij heel veel functies dit soort controles uitvoeren. Enerzijds veel controle structuren / overhead en extra code, anderzijds. De input klopt wel altijd.

Graag jullie meningen!
 
PHP hulp

PHP hulp

22/02/2025 00:56:21
 
Wouter J

Wouter J

29/02/2012 10:09:09
Quote Anchor link
Ik doe dat altijd, ik gebruik voor al mijn properties typecasting:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
<?php
public function setPath( $key, $path )
{

  $key = (string) $key;
  $path = (string) $path;
  // of als je ze ergens in gebruikt of opslaat in een property dan
  // gebruik ik daar typecasting

}
?>

Behalve natuurlijk als ik ze in een PHP functie gooi en zeker weet dat die altijd een string returned.
 
Ozzie PHP

Ozzie PHP

29/02/2012 10:29:42
Quote Anchor link
Maar Wouter, dat is niet helemaal wat ik bedoel. Ik bedoel echt een controle in de zin van... "hé, $path moet een string zijn en jij geeft een boolean op!".

Ik wil niet (zoals in jouw voorbeeld) dat een boolean wordt geconverteerd naar een string "1".

Mijn vraag is dus echt of je dit moet doen:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
<?php
public function setPath($key, $path) {
  if (!is_string($key) || !is_string($path)) {
    // Bericht tonen dat $key en $path een string moeten zijn.
  }
}

?>


Mijn vraag is of je dit soort controles moet inbouwen. Wel gebruiksvriendelijk, maar het betekent ook een hoop extra code en dus meer werk.
 
Kris Peeters

Kris Peeters

29/02/2012 10:56:16
Quote Anchor link
Wat ik belangrijker vind, is dat je de parameters en return goed documenteert.

Vertel de programmeur wat de functie doet, wat elke parameter is, ... en daar ga je uiteraard vertellen wat het type is.

En denk ook eens na wat je zou doen indien iets gebeurt wat je niet verwacht.
Wat zou je effectief doen binnen die if() ?

Een return false terug geven, gebeurt wel vaker.
Maar een echo $error ...
Tja, wat heb je daar echt aan?
 
Wouter J

Wouter J

29/02/2012 11:01:42
Quote Anchor link
@Kris, ik denk dat Ozzie een Exception gaat throwen in de if.

Maar inderdaad, die controlles lijken mij onnodig. In elk geval wel voor types. Andere dingen zou je natuurlijk wel kunnen checken, of het bepaalde waardes bevat en wel is wat je verwacht. En een array controleren is ook nog handig, maar of iets een bool, string of int is zou ik niet controleren.
 
Ozzie PHP

Ozzie PHP

29/02/2012 11:02:12
Quote Anchor link
Ik ben zelf niet zo van het "lange" documenteren eerlijk gezegd. Ik geef altijd alleen aan wat de functie doet.

In die if zou ik een exception willen gooien die een bericht toont dat de variabele van het verkeerde type is.

(hoe geef jij aan wat voor type de parameter moet zijn?)

Toevoeging op 29/02/2012 11:02:48:

Wouter J op 29/02/2012 11:01:42:
@Kris, ik denk dat Ozzie een Exception gaat throwen in de if.

correct ;)
 
Kris Peeters

Kris Peeters

29/02/2012 11:46:34
Quote Anchor link
Ozzie PHP op 29/02/2012 11:02:12:
(hoe geef jij aan wat voor type de parameter moet zijn?)


Een voorbeeld, dit staat (als user commentaar) op php.net, bij strpos()

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?php

/**
 *  This function implements all the strn*pos functions, which return the $nth occurrence of $needle
 *  in $haystack, or false if it doesn't exist / when illegal parameters have been supplied.
 *
 *  @param  string  $haystack       the string to search in.
 *  @param  MIXED   $needle         the string or the ASCII value of the character to search for.
 *  @param  integer $nth            the number of the occurrence to look for.
 *  @param  integer $offset         the position in $haystack to start looking for $needle.
 *  @param  bool    $insensitive    should the function be case insensitive?
 *  @param  bool    $reverse        should the function work its way backwards in the haystack?
 *  @return MIXED   integer         either the position of the $nth occurrence of $needle in $haystack,
 *               or boolean         false if it can't be found.
 */

function strnripos_generic( $haystack, $needle, $nth, $offset, $insensitive, $reverse )
{

    //  If needle is not a string, it is converted to an integer and applied as the ordinal value of a character.
...
?>


Er zijn nog andere coding standards voor commentaar, maar deze stijl is wel gebruikelijk.

Trouwens ...
Goede naamgeving helpt ook heel erg.
De namen $needle en $haystack gebruiken telkens je iets zoekt/detecteert in een groter geheel, is ook een goed idee
Gewijzigd op 29/02/2012 11:51:11 door Kris Peeters
 
Wouter J

Wouter J

29/02/2012 11:49:37
 
Roel -

Roel -

29/02/2012 11:51:14
Quote Anchor link
Kris, ik bedacht me net: hoe noem je een sql resource als je type?
 
Wouter J

Wouter J

29/02/2012 11:58:33
Quote Anchor link
@Roel, een resource. Alle resources zijn resources, een overzicht van alle resources in Core PHP: resource
 
Kris Peeters

Kris Peeters

29/02/2012 12:05:03
Quote Anchor link
Je kan altijd inspiratie halen uit
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
<?php
gettype($res)
?>


(geeft dus inderdaad "resource")
 
Ozzie PHP

Ozzie PHP

29/02/2012 12:06:07
Quote Anchor link
Oké, thanks.

Als iets een array moet zijn of een object van een bepaalde instantie, zetten jullie dat dan wel bij de parameters of zet je dat allemaal in het commentaar? Bijv.

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
<?php
public function(array $array, MyInstance $my_instance) {

}

?>
 
Roel -

Roel -

29/02/2012 12:06:28
Quote Anchor link
Thx, dat moest ik weten. Terug naar het onderwerp!
 
Wouter J

Wouter J

29/02/2012 12:25:14
Quote Anchor link
@Ozzie, een array zet ik er wel altijd bij de parameters. Dat omdat strings/ints/bools en arrays totaal verschillen. Precies zoals dat ik kijk of iets een object is.

Even een voorbeeldje van hoe ik een method zou schrijven in PHP:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
<?php
/**
 * This class is a example of PHPdoc and typing
 *
 * @author Wouter J
 * @package <Project naam>
 * @subpackage <Namespace naam>
 * @license Creative Commons 0.0
 */

class Example
{
  /**
   * All values that where set in this object
   *
   * @var array
   */

  protected $items = array();

  /**
   * Add an item to the object
   *
   * @param string $key The key of the item
   * @param mixed $value The value of the items
   */

  public function setItem( $key, $value )
  {

    $this->items[$key] = $value;
  }


  /**
   * Add multiple items to the object
   *
   * @param array $items All items with Array key represents the name and the array value the value
   */

  public function setItems( array $items )
  {

    foreach( $items as $key => $value )
    {

      $this->items[$key] = $value;
    }
  }
}

?>
 
Ozzie PHP

Ozzie PHP

29/02/2012 12:28:50
Quote Anchor link
Thanks Wouter. Waarom zet je voor iedere parameter @param?
Waarom bijv. niet:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
<?php
/**
   * Add multiple items to the object
   *
   * $items = array All items with Array key represents ...
   */

?>
 
Wouter J

Wouter J

29/02/2012 12:32:13
Quote Anchor link
@Ozzie, dat is de PHPdoc syntax, een standaard die in heel PHP wordt gebruikt. Je zou het bijv. ook nog verder kunnen uitbereiden en dan gebruik je ook andere PHPdoc tags:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<?php
/**
 * Some function who does something
 *
 * @access protected
 */

protected function some()
{

  // do something
}

/**
 * This function does something with the values and return them
 *
 * @param string $prefix The prefix, default is null
 * @return array $items The items
 */

public function doSomething( $prefix = null )
{

  // ...

  return $items;
}

?>
 
Ozzie PHP

Ozzie PHP

29/02/2012 12:36:11
Quote Anchor link
Oké, thanks. Ik vind het maar onoverzichtelijk... meer commentaar dan code :D
 
Wouter J

Wouter J

29/02/2012 12:41:19
Quote Anchor link
Dat komt omdat de functies nu nog heel klein zijn. Bij getters en setters zou ik het ook niet gebruiken, was slechts een voorbeeld. Maar bij grotere functies is het zeker handig om snel een overzicht te krijgen van wat er in komt, wat er uit en wat er mee gebeurd.
 
Ozzie PHP

Ozzie PHP

29/02/2012 12:56:03
Quote Anchor link
Hmmm, oké... maar even terugkomend op mijn vraag. Goed documenteren dus, en parameters niet controleren op type, met uitzondering van array en instances? Is dat een terechte conclusie?
 
Niels K

Niels K

01/03/2012 10:11:00
Quote Anchor link
Quote:
met uitzondering van array en instances?

Ik neem aan dat je weet dat je die gewoon voor de var kan zetten?

Example:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
<?php

class Dier {

    public function addOzzie(Aap $ozzie, array $items) {}
}


?>


Wanneer Ozzie nu geen instance van 'Aap' ( :-) ) is, wordt er een exceptie gethrowd.
 
Ozzie PHP

Ozzie PHP

01/03/2012 10:14:38
Quote Anchor link
Euh jaa, dat is ook precies wat ik bedoelde... lees nog maar een keer ;)

Enne.. bedankt dat je me vergelijkt met een aap he! ;)
 

Pagina: 1 2 3 4 5 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.