Fonte: http://forum.imasters.uol.com.br/index.php?showtopic=229485

Sumário

1. O que é tratamento de erros
2. Boas maneiras para programar sem erros
2.1 Programar de maneira errada
2.2 Esconder Erros
2.3 Falta de uma lógica mais apurada e desenvolvida
2.4 Não pensar nos usuários
2.5 Falta de conhecimento da linguagem com a qual se está programando
2.6 Falha no Hardware
3. Como debugar um script
4 – Validações para evitar erros
5. Tratando erros com Exceções

1. O que é tratamento de erros

Tratar um erro nada mais é do que preparar para rodar em qualquer situação ou, se não for possível, avisar por que não pôde ser executado. Tratando um erro você pode esperar uma situação e contorná-la ou, se não tiver jeito, finalizar a execução de uma forma segura e que não deixe o usuário sem saber o que está acontecendo. Ao fazer um tratamento de erros adequado, você pode preparar mensagens personalizadas para avisar os usuários que o sistema não pôde ser executado e notificar o erro ao administrador do site, para ele saber exatamente o que aconteceu e como proceder para corrigir o problema. Além disso, é útil para criação de estatísticas de erros.

2. Boas maneiras para programar sem erros

Além de fazer um tratamento de erros adequado, você precisa programar de uma maneira que evite erros. Existem vários meios de gerar erros no seu sistema e, sabendo como evitá-los, você deixar seu sistema mais profissional e à prova de falhas. Possíveis causas de erros no sistema:

Programar de maneira errada
Esconder erros
Falta de uma lógica mais apurada e desenvolvida
Não pensar nos usuários
Falta de conhecimento na linguagem com a qual se está programando
Falha por parte de hardware

Explicarei um pouco sobre cada um.

2.1 Programar de maneira errada

Esta tem suas principais causas: preguiça, pressa, falta de planejamento e/ou falta de conhecimento. A preguiça é porque na maioria das vezes o programador não quer saber como faz, mas, sim, entregar o sistema o mais rápido possível. Ele procura scripts prontos na Internet, só edita algumas coisas fáceis e acaba fazendo uma salada mista de vários sistemas prontos, tudo mal feito. O resultado é um sistema cheio de erros. Quanto mais o programador estudar e procurar entender para fazer seus sistemas, mais eles ficarão enxutos e livres de erros.

A pressa é outra vilã. O programador acaba fazendo um monte de gambiarras e pensa assim: “Ah, depois de entregar o sistema eu arrumo os erros com calma. O mais importante é entregar no prazo!”, e acaba nunca arrumando. Falta de planejamento também é muito ruim e acontece quando o programador mal pegou o serviço e já quer fazer tudo de uma vez, sem pensar em como o desenvolverá. Como resultado, acaba fazendo o sistema, depois o banco de dados, e depois sai costurando as falhas até deixar tudo funcionando. Tenha calma e não se apresse em fazer. Em um sistema bem feito, 70% dele é planejamento e o restante, escrever os códigos, modelar um banco de dados de forma correta, etc.

Já a pior das causas é a falta de conhecimento, pois é comum pessoas mal saberem o que é um HTML e já querem programar em PHP. Em alguns casos, conseguem até clientes e sempre aparecem desesperadamente nos fóruns pedindo ajuda para fazer um sistema para eles. Consequentemente nunca farão um sistema bem feito, até aprenderem a fazê-los por conta própria. Outros programadores têm até certo conhecimento, mas não o usa, enquanto outros chegam a um limite e param, acreditando que não precisam aprender mais nada. Aí surgem com aquela frase: “Em time que está ganhando não se mexe!”. Já vi programadores com 40 anos nas costas que usam o mesmo sistema que aprenderam a fazer no passado. Não querem evoluir ou aprender coisas novas, e aí acabam escondendo erros em vez de tratá-los.

Existem várias maneiras de se esconder erros no PHP e muitos têm abusado desses recursos. Não se devem esconder erros!. Claro que num site já publicado você não pode deixar que usuários vejam erros do seu sistema, mas nem por isso se deve escondê-los. Se o sistema tem falhas deixe uma mensagem avisando que logo ele estará funcionando, em vez disso, por exemplo, mostrando um erro grotesco e que não significa nada ao usuário leigo, além de expor informações internas do seu sistema, como por exemplo Warning: mysql_connect() [function.mysql-connect]: Access denied for user ‘root’@'localhost’ (using password: NO) in…

Muitas vezes eu falo que esconder erros é a mesma coisa que varrer a sujeira para debaixo do tapete. Não vou entrar em detalhes na parte de boas maneiras ao programar, porque já publicamos um artigo sobre isso (leia-o aqui).

2.2 Esconder Erros

Agora vou explicar como esconder um erro do PHP e como fazer para mostrar mensagens personalizadas. Os erros têm que ser escondidos em certos casos porque senão o PHP acaba mostrando mensagens de erros para o usuário, por exemplo:

Exemplo 2.2.1 Operadores de controle de erro (retirado do Manual do PHP)
O PHP suporta um operador de controle de erro: o sinal ‘arroba’ (@). Quando ele precede uma expressão em PHP, qualquer mensagem de erro que possa ser gerada por ela será ignorada.
Se o recurso track_errors estiver habilitado, qualquer mensagem de erro gerada pela expressão será gravada na variável global $php_errormsg. Esta variável será sobrescrita em cada erro, assim verifique-a constantemente se você quiser usá-la.

1
2
3
4
5
6
7
8

<?php
/* Erro intencional de arquivo */
$my_file = @file ('arquivo_nao_existente') or die("Falha abrindo arquivo: '$php_errormsg'");
 
// Isto funciona para qualquer expressão, não apenas para funções:
$valor = @$carrinho[$produto];
// você não receberá nenhum aviso se a chave $produto não existir.
?>

Nota: o operador @ funciona somente em expressões. Uma regra simples para lembrar disso: se você pode pegar o valor de alguma coisa, você pode prefixar isso com o @. Assim, você pode prefixar chamadas de variáveis, funções e include()’s, constantes e afins. Você não pode prefixar definições de funções ou classe, estruturas condicionais como o if, foreach e assim por diante.

Exemplo 2.2.2 Ocultar erro em conexões com banco de dados
Usando o @ você pode ocultar erros de conexões com o banco de dados:

1
2
3

<?php
@mysql_connect("localhost", "root") or die("Mensagem de erro");
?>

Usando o @ podemos ocultar a mensagem de erro do PHP, mas devemos, ainda, informar o usuário e exibir uma mensagem de erro personalizado, podendo usar CSS, imagens etc. O mesmo vale para erros na abertura de arquivos ou envio de e-mails.

Outra maneira de ocultar erros é editando o PHP.INI na linha “display_errors = off”. Muitos programadores, por não saberem configurar corretamente o PHP.INI, deixam-no no padrão de instalação e, dependendo da versão do PHP, o display_errors está em “off”. O que recomendo é deixar em “on”, caso contrário, o PHP não irá mostrar os erros, caso ocorram. Eu vejo erros comuns pelos fóruns, tipo esse:

Exemplo 2.2.3 Índice não encontrado

1

$val = $_POST[val]; // erro não delimitou uma string com aspas ou apóstrofos

Daí eu falo para o usuário que ele precisa delimitar as strings com aspas, por exemplo, $_POST["val"]. Mas o usuário acaba comentando: “Mas assim também funciona e não tem erro!”. Isso acontece porque o display_errors dele esta em “off” e por isso não consegue perceber o erro. O PHP entende, conforme o exemplo acima, que val é uma constante. Não a encontrando, assume como uma string e exibe um erro do tipo E_NOTICE.

Exemplo 2.2.4 Ocultar erros com error_reporting() (retirado do Manual do PHP) A função error_reporting() define a diretiva error_reporting em tempo de execução. O PHP tem vários níveis de erros, usando essa função você pode definir o nível durante a execução do seu script. error_reporting() define o nível de erros que o PHP irá reportar, e retorna o nível antigo. O parâmetro nível pode usar um bitmask, ou constantes. É fortemente recomendado que você use constantes para assegurar compatibilidade com futuras versões. Como níveis de erros podem ser adicionados, o intervalo das constantes pode crescer, então os níveis de erros indicados anteriormente por inteiros podem não funcionar como esperado.
Exemplo 1. Exemplos error_reporting()

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<?php
// Desativa o relatório de todos os erros
error_reporting(0);
// Reporta erros simples
error_reporting(E_ERROR | E_WARNING | E_PARSE);
 
// Reportar E_NOTICE pode ser bom também (para reportar variáveis não iniciadas
// ou erros de digitação em nomes de variáveis ...)
error_reporting(E_ERROR | E_WARNING | E_PARSE | E_NOTICE);
 
// Reportar todos os erros exceto E_NOTICE
// Este é o valor padrão no php.ini
error_reporting(E_ALL ^ E_NOTICE);
 
// Reporta todos os erros (bitwise 63 deve ser usado no PHP 3)
error_reporting(E_ALL);
// O mesmo que error_reporting(E_ALL);
ini_set('error_reporting', E_ALL);
?>

Os níveis de erros disponíveis estão listados abaixo. A descrição deles está em constantes predefinidas.

1 E_ERROR
2 E_WARNING
4 E_PARSE
8 E_NOTICE
16 E_CORE_ERROR
32 E_CORE_WARNING
64 E_COMPILE_ERROR
128 E_COMPILE_WARNING
256 E_USER_ERROR
512 E_USER_WARNING
1024 E_USER_NOTICE
2047 E_ALL
2048 E_STRICT

Atenção
A partir do PHP 5.0.0, E_STRICT com o valor 2048 está disponível. E_ALL NÃO mostra erros do nível E_STRICT.

Recomendo deixar error_reporting(E_ALL), para mostrar todos os tipos de erros.

2.3 Falta de uma lógica mais apurada e desenvolvida

Agora falando sobre lógica! Muitos erros acontecem também por falta de uma lógica correta, ou seja, programam de maneira errada, fazem gambiarra (famosa POG – Programação Orientada à Gambiarras)) ou complicam demais algo que poderia ser mais simples. Já vi muitos usuários não saberem manipular datas, como somar, subtrair, etc. Acabam fazendo cada loucura com uma coisa simples. Falta de lógica pode fazer com que o sistema fique com erros e, por azar, o programador não percebe até que o erro aconteça.

2.4 Não pensar nos usuários

Não pensar nos usuários também pode fazer com que o sistema tenha erros. Um exemplo disso é o programador ter um micro de último tipo, e configurar o PHP.INI a seu gosto, com programas atualizados e acaba desenvolvendo pensando só nele. Esquece que outros usuários que irão usar o sistema não têm o mesmo recurso. Por exemplo: o programador faz um sistema usando PHP 5.2, Apache 2.2.4, Mysql 5 e disponibiliza o sistema para outros usuários e o coitado do usuário baixa o sistema e vai rodar num servidor com PHP 4 e Mysql 3 (a grande maioria dos servidores de hospedagem demoram para se atualizarem). Aí o sistema não funciona e aparecerá um monte de mensagens de erros e o usuário nem sabe o porquê. Não estou falando que não se deve programar usando as últimas versões, mas tem que ver pra qual situação será usado o sistema e verificar se o sistema está apto a rodar na plataforma em que foi instalado.

2.5 Falta de conhecimento da linguagem com a qual se está programando

Falta de conhecimento na linguagem PHP também faz o sistema ter muitos erros. Muitas vezes o usuário é até esforçado, mas por falta de conhecimento não sabe identificar um erro ou um problema e muito menos fazer de um jeito melhor. Acaba pegando scripts prontos para aprender, mas estes também estão sujeitos a erros e o usuário vai querer editar, deixando-o cada vez pior. Por falta de conhecimento na linguagem também acontecem muitos erros de concatenação de strings, tags PHP, ou juntar HTML + PHP, banco de dados, entre outras coisas. Nesse tipo de coisa é muito fácil de cometer erros, principalmente se o usuário for inexperiente.
É importante estudar muito, acompanhar os novos recursos e buscar conhecimento em fontes sérias. Só assim evita-se dor de cabeça ou mesmo a perda de espaço no mercado de trabalho.

2.6 Falha no Hardware

E por último, erros também acontecem independente do sistema estar perfeito ou não. Pode ser que o servidor esteja em manutenção, ou outros problemas relacionados a hardware etc. Por esse motivo que, mesmo você fazendo um ótimo tratamento de erros, o sistema não conseguirá ser executado. Falarei de exceções logo mais à frente.

3. Como debugar um script

Para testar um script e ver se ele está funcionando corretamente, há várias maneiras. A primeira delas é testar num servidor local. Para desenvolver, sempre deixe essas opções configuradas no php.ini:

display_errors = On
display_startup_errors = On
error_reporting = E_ALL
log_errors = On
track_errors = On
register_globals = Off

Via script você pode fazer assim:

1
2
3
4
5

<?php
@ini_set("display_errors", 1);
@ini_set("log_errors", 1);
@ini_set("error_reporting", E_ALL);
?>

Em versões do PHP igual ou anterior à 4.2.3 era possível setar a diretiva register_globals via script, mas agora só via PHP.INI ou .htaccess. Via .htaccess é assim:

1

php_flag register_globals off

Agora, com tudo preparado, só resta testar o sistema. Existem vários editores com recursos para debugar um script, como por exemplo o PHPEdit da WaterProof, o editor da Zend ou o da Maguma.

4 – Validações para evitar erros

Um bom tratamento de erros precisa prever vários tipos de erros e, pra isso, existem funções específicas, como por exemplo:

file_exists – serve para verificar se um arquivo existe
defined – serve para verificar se uma constante foi definida.
isset – verifica se uma variável existe.
is_array – verifica se a variável é um array
is_resource – verifica se a variável é um resource
is_numeric – verifica se a variável é um número ou uma string numérica.
is_uploaded_file – verifica se o arquivo foi uploaded via HTTP POST.
is_writable – verifica se pode escrever para o arquivo (writable).
version_compare – Compara a versão do php.
extension_loaded – verifica se a extensão foi habilitada.

Com essas funções você pode testar, por exemplo, se um arquivo existe, antes de incluí-lo. Caso não exista, você pára o script e dá um aviso para o usuário. Outro exemplo: antes de gravar um arquivo texto, você verifica se ele pode ser escrito, ou antes de usar uma variável teste, se ela existe com isset()
Outra validação muito importante é validar se o formulário foi enviado, assim evitando erro, por exemplo:

Exemplo 4.1 Verificando se um formulário foi enviado

1
2
3

if (getenv("REQUEST_METHOD") == "POST") {
    //...faça tal coisa
}

Se for get só mudar para GET, assim você testa se o formulário foi enviado.
Outra dica importante é testar se a variável existe caso venha de algum formulário:

Exemplo 4.2 Verificando se uma variável foi inicializada

1

$campo = isset($_POST["campo"]) ? $_POST["campo"] : "";

Exemplo 4.2 Incluindo um arquivo sem verificação
De tratamento de erros:

1
2
3

<?php
require "arquivo.php";
?>

Mas e se o arquivo nao existir? Iria dar erro, então o mais correto é:

Exemplo 4.3 Incluindo um arquivo com verificação

1
2
3
4
5

<?php
if (file_exists("arquivo.php")) {
 require "arquivo.php";
}
?>

Exemplo 4.4 Desabilitando magic_quotes
Programar dependente de magic_quotes não é recomendando, visto que o site ou sistema poderá não funcionar corretamente caso seja hospedado em um servidor com configuração divergente da que foi adotada para os testes locais. Os erros mais comuns são na inserção de valores em um banco de dados. Além disso, a partir do PHP 6, a diretiva magic_quotes_gpc não existirá mais e, por isso, é recomendado programar desabilitando este recurso. Esta diretiva não pode ser alterada através da função ini_set, devendo ser configurada diretamente no PHP.INI ou, se também possível, através do .htaccess, da seguinte forma:

1

php_flag magic_quotes_gpc Off

Como alternativa, você pode utilizar a função abaixo:

1
2
3
4
5
6
7
8
9
10
11
12

function remove_magic_quotes() {
 if (get_magic_quotes_gpc()) {
  $_GET = array_map("remove_mq", $_GET);
  $_POST = array_map("remove_mq", $_POST);
  $_REQUEST = array_map("remove_mq", $_REQUEST);
  $_COOKIE = array_map("remove_mq", $_COOKIE);
 }
}
 
function remove_magic_quotes(&$var) {
 return is_array($var) ? array_map("remove_magic_quotes", $var) : stripslashes($var);
}

Basicamente, a função verifica se a diretiva magic_quotes está habilitada e, então, varre pelos dados dos arrays globais inicializados (enviados por um formulário, por exemplo), eliminando os escapes dos caracteres. Preferencialmente, esta função deve ser chamada num arquivo de inicialização do sistema ou site.

5. Tratando erros com Exceções

A partir da versão 5 do PHP, pode-se tratar erros usando Exceções. Com o uso desse recurso, podemos manipular os erros com mais precisão, facilitando, por exemplo, a criação de um log de erros contendo o nome do arquivo e a linha em que o erro ocorreu.
A classe Exception pode ser extendida a uma outra, viabilizando a personalização de mensagens de erro e a criação de uma classe para cada tipo de exceção. Por exemplo: é possível termos uma classe para manipular erros relacionados a banco de dados, outra para o manuseio de arquivos, de imagens, etc.
Uma exceção deve ser disparada (thrown) dentro de um bloco try{}. Em seguida, deve ser pega (catched) usando o bloco catch{}.

Exemplo 5.1: Usando exceções para capturar um possível erro na conexão com um banco de dados MySQL

1
2
3
4
5
6
7
8
9
10
11
12

try {
   //usamos o arroba para ocultar o possível erro retornado pelo PHP
   @$MySQLi = new MySQLi("localhost", "user", "pass", "db_name");
 
   if (!$MySQLi) { //se conexão falhar
      throw new Exception("Erro ao realizar a conexão com o banco de dados");
   }
}
catch (Exception $e) {
 echo $e->getMessage();
 exit;
}

Se a conexão falhar, será disparada uma exceção, que será, posteriormente, pega no seu bloco catch correspondente. Nesse bloco, devemos colocar o nome da classe de exceção utilizada e criar uma variável, a qual será uma instância da exceção.

Para obter mais informações sobre exceções, veja o link abaixo:
http://www.php.net/manual/pt_BR/language.exceptions.php

Colaboraram neste artigo:
Anderson Mello
Beraldo
Fabyo

Boa leitura a todos!

Fonte: http://forum.imasters.uol.com.br/index.php?showtopic=214963

Índice

1. Introdução
2. Utilize sempre as tags completas
3. Indentação
4. Funções para verificar a existência de variáveis e os seus tipos
5. Tipos de dados e casting
6. Adotar padrões para nomes de funções, classes, constantes e variáveis
7. Codificar usando exibição de erros E_ALL
8. Não ocultar erros utilizando @ ([arroba])
9. Não codificar dependendo de register_globals
10. Criar arquivo de inicialização
11. Mantenha-se sempre atualizado
Apêndices
Apêndice A. Sobre o php.ini
Apêndice B. Palavras reservadas
Apêndice C. Funções úteis para verificação de variáveis, diretórios e outros

1. Introdução

Muitas das dicas abaixo valem para qualquer linguagem de programação, mas a abordagem principal é voltada para programação em PHP. Para quem quer ser um bom profissional não basta conhecer dezenas de linguagens diferentes e decorar as milhares de funções disponíveis para cada uma delas. Algo que muitos deixam de lado são os cuidados ao formatar o código, organizando-o e documentando-o adequadamente. Isso contribui, em muito, à alteração e à leitura do mesmo por outros profissionais, poupando tempo e permitindo fácil seqüência ao projeto.

Vamos a algumas dicas recomendadas por vários profissionais da área. Todas elas devem ser consideradas também como referências para os próximos artigos que serão publicados aqui no fórum.

2. Utilize sempre as tags completas

O PHP aceita quatro tipos de tags:

1
2
3
4

<?php ?>
<? ?>
 <script language="php"></script>
<% %>

A primeira opção é a padrão e preferencial, mas muitos programadores utilizam a segunda opção, por ser mais curta. Com ela, há também a possibilidade de usar esta sintaxe para exibir uma informação:

1
2
3

<?= "Hello World!" ?>
// equivale a
<? echo "Hello World!"; ?>

Apesar disso, a utilização desse tipo de tag também não é recomendada, porque pode estar desabilitada no servidor, ou seja, quando a diretiva short_open_tag estiver em off, fazendo com que o script não seja interpretado.

A terceira opção não é muito comum, mas não é afetada pela diretiva short_open_tag, sendo tão segura quanto a primeira. As tags ASP <% %>, que também devem ser evitadas, só serão interpretadas se a diretiva asp_tags estiver em on, o que é pouco comum, visto que o seu valor padrão é off.

Mais detalhes:
http://www.php.net/manual/pt_BR/language.basic-syntax.php

3. Indentação

Uma boa indentação facilita a organização e a leitura do código. Veja os seguintes exemplos:

Exemplo 3.1 Código em linha única e sem indentação

1

if($a < 4) { echo "Hello World!"; }

Exemplo 3.2 Código sem indentação

1
2
3

if($a < 4) {
echo "Hello World!";
}

Exemplo 3.3 Código com indentação adequada

1
2
3

if($a < 4) {
    echo "Hello World!";
}

Com os exemplos acima, podemos notar que a ausência de identação em um pequeno trecho de código pode não fazer diferença, mas tente imaginar 300 ou 400 linhas sem identação. Melhor ainda (ou pior), imagine fazer uma alteração em um script escrito nesse formato…
Alguns podem, inclusive, pensar que reduzindo o número de linhas de código, facilita-se a navegação e a leitura do mesmo.
Uma boa identação é a que você adotar como padrão. O recomendado, e também adotado por muitos, é uma indentação de quatro espaços. Dê atenção especial às estruturas de controle, onde o “aninhamento” delas podem causar confusão de leitura.

Exemplo 3.4 Código sem indentação

1
2
3
4
5
6
7

if($a) {
if($b == $a) {
//código
} else {
//código
}
}

Exemplo 3.5 Código com indentação adequada

1
2
3
4
5
6
7

if($a) {
    if($b == $a) {
        //código
    } else {
        //código
    }
}

Nos exemplos 3.4 e 3.5 é possível perceber mais claramente o problema da falta de indentação.

4. Funções para verificar a existência de variáveis e os seus tipos

É importante verificar se uma variável, constante ou mesmo chave de array associativo foi inicializado, antes de resgatar o seu valor e utilizá-lo em algum processamento. Isso evita resultados inesperados. Veja o exemplo abaixo:

Exemplo 4.1

1
2
3
4
5
6

<?php
$a = $_POST['a'];
$b = " World!";
 
echo $a.$b;
?>

Considerando-se que o valor de $a tenha sido enviado por um formulário, pelo método POST, e esse valor seja “Hello”, a saída será “Hello World!”. Porém, se nenhum valor for preenchido, teremos um resultado inesperado, podendo ser gerada uma notificação de inexistência de variável. Para testar se a variável foi iniciada, utilizamos isset().

Exemplo 4.2

1
2
3
4
5
6
7
8
9
10

<?php
if(isset($_POST['a'])) {
    $a = $_POST['a'];
} else {
    $a = "Hi";
}
$b = " World!";
 
echo $a.$b;
?>

Outra forma, mais curta, é utilizar o operador condicional ternário (ou somente operador ternário).

Exemplo 4.3 – Utilizando o operador ternário

1
2
3
4

$a = isset($_POST['a']) ? $_POST['a'] : "Hi";
$b = " World!";
 
echo $a.$b;

Se a primeira expressão retornar verdadeiro (TRUE), o segundo bloco é executado. Caso contrário, executa-se o terceiro. Dessa forma, caso a variável não tenha sido enviada pelo formulário, atribuímos a ela o valor “Hi”, produzindo a saída “Hi World!”. Para fazer esse tipo de verificação com constantes, utilizamos a função defined().

Exemplo 4.4

1
2
3
4
5
6
7

<?php
define("CAMINHO", "www/meudiretorio/");
if(defined("CAMINHO")) {
    echo "A constante já foi definida.";
} else {
    echo "A constante não foi definida.";
}?>

Confira no Apêndice uma lista de funções úteis para verificação de tipos de variáveis, existência de diretórios, funções e outros.

Mais detalhes:
http://www.php.net/manual/pt_BR/ref.variables.php

5. Tipos de dados e casting

Ao desenvolvermos um sistema ou site, deparamo-nos com o uso de diversos tipos de variáveis, como strings, arrays, booleans, dentre outros. Como o PHP não suporta a definição de tipos de variáveis nas declarações das mesmas, em determinados momentos, uma variável que deveria conter como valor um número inteiro, pode receber uma string. Isso pode gerar erros sileciosos, comprometendo o funcionamento do código. Veja o exemplo:

Exemplo 5.1

1
2
3
4
5
6
7
8
9

<?php
//Retorna 'integer'
$var = 2;
print gettype($var);
 
//Retorna 'string'
$var = "6";
print gettype($var);
?>

Usamos a função gettype() para retornar o tipo de variável declarada. No segundo trecho temos a declaração da mesma variável $var, que passa a receber o tipo de variável string. Este dado é convertido automaticamente ao fazer uma soma, por exemplo, voltando novamente a ser um valor do tipo inteiro. Para contornar esse tipo de situação e evitar surpresas, recomenda-se moldar o tipo de variável, também chamado de casting, assegurando assim que a variável será do tipo esperado. Para isso, pode-se utilizar a função settype().

Exemplo 5.2

1
2
3
4
5
6

<?php
//Retorna 'integer', mesmo com o valor declarado como 'string'
$var = "6";
settype($var, 'integer');
print gettype($var);
?>

A moldagem de tipos também pode ser feita no momento da declaração da variável, antecedendo o seu valor com o tipo desejado, entre parênteses:

Exemplo 5.3

1
2
3
4
5

<?php
//Define o tipo 'integer'
$var = (integer) "6";
print gettype($var);
?>

Mais detalhes:
http://www.php.net/manual/pt_BR/language.types.php

6. Adotar padrões para nomes de funções, classes, constantes e variáveis

Mesmo que as maiores diferenças sejam notadas em grandes projetos, adotar padrões ao declarar funções, variáveis etc. auxilia o desenvolvimento, pois se evita a dúvida ou mesmo erros, por exemplo, ao chamar funções que não existam, simplesmente por se ter um nome confuso ou uma falta de padrão.
Você deve estar ciente da padronização que irá fazer, e respeitá-la rigorosamente em todo o site ou sistema. Um exemplo:

Exemplo 6.1

1
2
3
4
5
6
7

function primeira_funcao() {
     //...
}
 
function segundaFuncao() {
    //...
}

Programar sem um padrão, como no exemplo acima, compromete o desenvolvimento, pois será muito fácil acabar chamando por funções inexistentes (nomes diferentes do esperado). É muito importante analisar os padrões já utilizados por outros programadores ou desenvolver seu próprio padrão e seguí-lo à risca, garantindo assim um projeto fluente.
Essa mesma situação pode ser enfrentada para nomes de constantes, variáveis ou classes. Por isso, é importante seguir um padrão, tal como o exemplo abaixo:

Exemplo 6.2

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<?php
$var = 7;
$minhaVar = "PHP";
define("CONSTANTE", "Valor da constante");
define("SEGUNDA_CONSTANTE", 100);
 
function minhaFuncao($argumento) {
    print "<b>$argumento<b>";
}
 
classe MinhaClasse {
     //...
}
?>

Para o nome de variáveis, prefira utilizar nomes sempre em minúsculas. Para variáveis com palavras compostas, separe-as alterando as palavras seguintes com letra inicial maiúscula. Nomes de constantes preferencialmente devem ser declarados em maiúsculas, utilizando underline (“_”) como separador de palavras.
As funções e seus argumentos, assim como as classes, devem ser declaradas utilizando-se o mesmo padrão para as variáveis. Como forma de diferenciar as classes de funções, estas devem ter seus nomes com a inicial também em maiúscula.

7. Codificar usando exibição de erros E_ALL

Durante a estruturação de seu código, é muito importante manter as diretivas error_reporting em E_ALL e display_errors em on. Isso faz com que todos os possíveis erros sejam exibidos, para que você possa corrigi-los.
Não é necessário acessar o arquivo php.ini para alterar esses valores, basta usar a função ini_set(), como no exemplo abaixo:

Exemplo 7.1

1
2
3
4
5
6

<?php
ini_set('error_reporting', E_ALL);
ini_set('display_errors', 1);
 
// restante do código
?>

Deve-se inserir essas mudanças sempre antes do restante do código, para que elas afetem o script inteiro.

Mais detalhes
http://www.php.net/manual/pt_BR/ref.errorfunc.php

8. Não ocultar erros utilizando @ ([arroba])

É desaconselhável o uso excessivo do operador de controle de erros (@, “arroba”). Esse operador somente deve ser usado nos casos em que a ocorrência de erro seja uma excessão, como na função mail(), funções de conexão com banco de dados e outras.

Exemplo 8.1

1
2

if (!@mysql_connect ("servidor", "usuario", "senha"))
    die ("Erro ao conectar com o banco de dados MySQL").

Considerando-se que os argumentos da função mysql_connect() acima estejam corretos, erros de conexão tornam-se uma exceção, como em caso de servidor fora do ar.
A partir do PHP 5, é possível manusear erros por meio de Exceções, mas esse tema não será abordado neste artigo.

Nota importante:
Atualmente, o operador de controle de erro “@” sempre desativa mensagens de erro, mesmo para erros críticos, que terminam a execução de scripts. Além de outras coisas, isto significa que se você usar “@” para suprimir erros de certas funções e elas não estiverem disponíveis ou com tipos incorretos, o script vai parar exatamente aí sem nenhuma indicação da razão.

Mais detalhes:
http://www.php.net/manual/pt_BR/language.operators.errorcontrol.php

9. Não codificar dependendo de register_globals

A register_globals é uma diretiva que passou a estar desabilitada (Off), por padrão, a partir do PHP 4.2.0. Essa diretiva, quando habilitada no PHP.INI, faz com que as variáveis globais sejam registradas (inicializadas) diretamente no script em execução.

Exemplo 9.1 valor inicializado por GET

1
2
3
4
5
6
7

//Script acessado com valor via GET
//meu_script.php?var=Teste
if(isset($var)) {
    print "A variável foi inicializada pela register_globals;
} else {
    print "A variável $var não foi inicializada";
}

O exemplo acima, apesar de inofensivo, pode sugerir a vulnerabilidade que o uso incorreto da diretiva register_globals pode acarretar. Imagine uma função que verifica a autenticação do usuário e define uma variável como verdadeira:

Exemplo 9.2

1
2
3
4
5
6
7
8
9

if (usuario_logado()) {
    $usuario_autenticado = true;
}
 
if ($usuario_autenticado) {
    include "menu.php";
} else {
    print "Você não tem permissão.";
}

Neste exemplo fica claro a brecha de segurança, pois basta inicializar a variável $usuario_autenticado como verdadeira (TRUE) ao acessar o script para que o menu esteja disponível, burlando a função de verificação de autenticação do usuário. Para corrigir este problema, basta simplesmente inicializar a variável como false. Além de uma boa prática, previne que o valor seja “forçado” a ser verdadeiro.

Exemplo 9.3

1
2
3
4
5
6
7
8
9
10
11
12

//Inicializando a variável $usuario_autenticado
//como false, evitando que a register_globals
//interfira no código
$usuario_autenticado = false;
if (usuario_logado()) {
    $usuario_autenticado = true;
}
if ($usuario_autenticado) {
    include "menu.php";
} else {
     print "Você não tem permissão.";
}

10. Criar arquivo de inicialização

Um arquivo de inicialização é útil para verificar a versão do PHP em que o script está sendo executado, suas configurações padrão e definir valores que serão usados em todo o sistema. Isso torna a execução mais segura e não suscetível a erros.
Os pontos mais importantes em um arquivo de inicialização de sistemas são:

*Versão do PHP em que o script está sendo executado;
*Verificar se determinadas extensões foram carregadas, como mysql, mysqli, gd, etc;
*Definir valores para diretivas do php.ini, como error_reporting e display_errors;
*Definir constantes, como informações para conexão com bancos de dados, diretório-raiz do sistema e outras.

Mais detalhes:
http://forum.imasters.com.br/index.php?showtopic=202215

11. Mantenha-se sempre atualizado

A linguagem PHP está em constante atualização, sendo frequentemente disponíveis novas atualizações de versões para download. Por isso, acesse periodicamente o site oficial do PHP (http://www.php.net) e verifique se não há uma versão mais recente do que a qual você está utilizando no momento. Se houver, baixe-a e instale-a imediatamente. Para facilitar esta verificação, segue abaixo um script desenvolvido pelo Fabyo. Além de verificar, ele exibe também os links para download.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<?php
$url  = "http://www.php.net/downloads.php";
$file = @file_get_contents($url);
preg_match_all("#<h2>Windows Binaries<\/h2>(.+?)</ul>#si", $file, $matches);
preg_match_all("#<a href=(.+?)>(.+?)<\/a>#si", $matches[0][0], $matches2);
$php = str_replace("PHP", "", $matches2[2][0]);
$php = str_replace("zip package", "", $php);
$php = trim($php);
 
if(version_compare(phpversion(), $php, "<") == "-1") {
    echo "Sua versao do php esta desatualizada baixe a nova versao:<br />";
    echo $matches2[0][0]."<br />";
    echo $matches2[0][2];
} else { 
    echo "<img src=\"". $_SERVER["PHP_SELF"] ."?=" . php_logo_guid() . "\" alt=\"Logo\" />";
    echo "<br />Sua versão esta atualizada";
}
?>

Também é importante prestar atenção às alterações feitas em cada versão, para que um script não gere incompatibilidade entre duas ou mais vesões do PHP. As duas mais importantes mudanças que podem afetar a execução de um código PHP são estas:

* A extinção das variáveis $HTTP_*_VARS (como $HTTP_GET_VARS e $HTTP_POST_VARS) e a criação das autoglobais (ou super globais) $_GET, $_POST, $_COOKIE, $_SERVER, $_ENV, $_REQUEST, e $_SESSION.
* A mudança do valor padrão da diretiva register_globals de on para off.

Mais detalhes:
http://br.php.net/manual/pt_BR/tutorial.oldcode.php
http://br.php.net/manual/pt_BR/language.variables.predefined.php
http://br.php.net/manual/pt_BR/security.globals.php

Apêndices

Apêndice A. Sobre o php.ini

http://br.php.net/manual/pt_BR/ini.php

Entenda o PHP.INI (artigo publicado pelo Fabyo): http://forum.imasters.com.br/index.php?showtopic=144987

Apêndice B. Palavras reservadas

http://br.php.net/manual/pt_BR/reserved.php

Apêndice C. Funções úteis para verificação de variáveis, diretórios e outros

*is_array()
*is_bool()
*is_float()
*is_int()
*is_numeric()
*is_null()
*is_object()
*is_resource()
*is_string()
*is_dir()
*is_file()
*file_exists()
*function_exists()
*array_key_exists()

Colaboraram neste artigo:

Anderson Mello
Beraldo
Fabyo
Thiago Ferreira (tmferreira)