Qual è l'impatto della ridefinizione di una variabile di tipo dinamica (come in PHP)?

Question

Qual è l'impatto della ridefinizione di una variabile di tipo dinamica (come in PHP)?

#1 da (9 voti)

5

Le variabili PHP sono di tipo dinamico, quindi posso fare:

$x = 'hello world!';  
$x = strlen($x);

A volte questo è banale e potrei salvare molte righe di codice, ma riduce la chiarezza. Sto usando un editor di testo, ma suppongo che gli IDE (e i programmatori) potrebbero essere confusi se un tipo di modifica delle variabili.

Caso meno banale:

if (is_string($data))  
    $lines = explode(PHP_EOL,$data);  
else  
    $lines = $data;

vs

if (is_string($data))  
    $data = explode(PHP_EOL,$data);

Ovviamente potrei fare qualcosa del tipo:

$lines = is_string($data) ? explode(PHP_EOL,$data) : $data;

Ma non è questo il punto.

BTW: sto assumendo che $ data sia una stringa o e questo dovrebbe essere documentato come tale.

variables php

posta boctulus 29.03.2016 - 18:35

fonte

1 risposta

Leggi altre domande sui tag variables php

Consigli per l'aggiunta di messaggi di eccezione al codice [chiuso] Unità testando l'astrazione del filo

score 9 · Answer 1

È meglio mantenere il codice il più semplice possibile. Questo significa cose diverse per persone diverse, ma nella mia esperienza ho scoperto che:

Le variabili dovrebbero sempre mantenere lo stesso tipo. Cambiare qualcosa che tiene concettualmente una stringa in un array è altamente confuso, specialmente se il tipo viene convertito solo in un percorso di codice.
Le variabili dovrebbero essere assegnate una sola volta. Ora, le variabili fanno sempre riferimento a un oggetto che semplifica la comprensione del resto del codice.
Le variabili non dovrebbero essere ombreggiate. Questo non vale per PHP, ma nelle lingue in cui le variabili devono essere dichiarate, non dobbiamo dichiarare nuovamente una variabile quando una var con lo stesso nome è già in ambito.
I valori non devono essere modificati. Invece, possiamo generare un nuovo valore e memorizzarlo in una nuova variabile. Ora, ogni variabile punta sempre agli stessi dati. Ogni volta che faccio qualcosa con una variabile, otterrò lo stesso valore. Questo rende il debug molto più semplice, ma ha meno a che fare con le variabili che con la progettazione di oggetti adatti.

La conseguenza di questi punti è che finirò con modulo a assegnazione singola , che rende il codice abbastanza "ragionevole" (come in, può essere ragionato). Alcune lingue (funzionali) lo fanno rispettare, ma un buon codice può usare questo concetto anche quando non è applicato da una lingua.

Ovviamente ci sono molti contro-esempi in cui questa non è una buona idea. Spesso non mi aggrappo all'immutabilità quando ...

... Sto costringendo argomenti ad un certo tipo. Spesso, avrò una funzione che è abbastanza lassa con l'input. Quindi scrivo il (pseudo-codice)
```
if (!has_expected_type($var)) {
  $var = coerce($var);
}
```
Questo viola il punto sul non cambiare mai il tipo di una variabile. Ma poiché la convalida viene eseguita nella parte superiore della funzione, prima di qualsiasi logica principale, questo sembra essere un compromesso ragionevole. D'altro canto, anche le variabili con un nome esplicito non sarebbero difficili:
```
$var = has_expected_type($coercible_var) ? $coercible_var : coerce($coercible_var);
```
... Sto aggiungendo una struttura dati, ad es. costruire una stringa o un array. Un po 'di mutabilità è OK. Solitamente chiamo queste variabili $out o $buf . Non vedo nulla di sbagliato con il codice come
```
$buf = "Hello, $name\n\n";
if ($idiot) {
   $buf .= "Use this one weird trick to lose 10lbs, doctors hate it!\n";
} else {
   $buf .= "10/10 studies show: our snake oil is the best snake oil!\n";
}
$buf .= "Buy now!";
return $buf;
```
Qualsiasi altro approccio alla costruzione di questa stringa sarebbe ancora più doloroso (a parte l'utilizzo di un sistema di template appropriato, ovviamente).