Ola pessoal...Bem, hoje irei comentar sobre algumas boas praticas, que eu julgo muito importantes no desenvolvimento.No dia a dia, comecei a encontar alguns detalhes que fazem muita diferenca no entendimento de codigo implementado por outro desenvolvedor.1a Dica.Nao altere o valor de um argumento de um metodo.Exemplo:public function fazAlgumaCoisaComNome($nome){ // codigo...} Se voce, mero desenvolvedor, nunca alterar o valor do parametro $nome, dentro desse metodo, outro desenvolvedor podera utilizar esse valor dentro do metodo sem ter medo de estar utilizando um valor ja alterado. Essa situacao serve para codigo legado, onde podemos ter metodos "gigantes".2a DicaNunca, mas nunca e apenas para garantir....N U N C A, retorne mais que um tipo em um metodo, mesmo isso sendo permitido no PHP. Mas pq? ...Imagine que voce, mero desenvolvedor, acabou de criar um metodo que retorna string ou int e ainda pode retornar um array....(que bela merda voce fez, mas tudo bem), quem for usar esse metodo, vai ter que tratar todas condicoes para que o codigo externo nao quebre o fluxo, quando na verdade ele so deveria esperar um dos tipos e tratar somente ele. Sempre que possivel utlize o Type Hinting.Se voce, seguir a 2a dica, pode tambem seguir essa abaixo...3a DicaUtilize as marcacoes de PHPDoc....Como assim???Vou exemplificar.../** * @param string $nome * @return string */public function fazAlgumaCoisaComNome($nome)Pessoal, olha que bacana... eu nao tenho o codigo desse metodo, e mesmo assim sei o que realmente importa para usa-lo.Eu sei que ele recebe uma string, e que tambem retorna uma string, com isso meu codigo ja vai estar sempre esperando por isso.Agora se eu nao soubesse essa informacao, teria que realizar todas as validacoes para poder verificar as entradas e saidas desse metodo.E logico que temos que acreditar que o "Cara" que fez esse metodo, fez certo.Para que nao tenhamos duvidas com relacao a um funcionamento de algo, ajuda muito, quando trabalhamos com testes unitarios.....Atualmente, trabalho com PHPUnit e ele me faz ter certeza que na situacao acima, aquele metodo realmente como deveria.Bom, estes cenarios citados sao de casos reais e que acontecem no dia a dia.Para finalizar....Ultima dica: Nunca faca metodos "PATOS"Como assim???? O que e isso?????Bem o apelido "PATO", e por que um pato nada, anda e voa, entao por favor, nao crie metodos que fazem de tudo. Um metodo deve fazer uma tarefa especifica e faze-la bem.Quando criamos metodos "PATO", eles comecam a ter muitos parametros opcionais e isso e uma merda.Bom, e isso.... ate a proxima e fujam dos Patos.... Ola, acabei de disponibilizar uma integracao do Meld com o Git.Essa configuracao ajuda muito para realizar analise de diferencas entre branchs, commits e quais alteracoes foram realizadas e ainda nao 'commitadas'.Esta no bitbucket no meu projeto de comandos Git.Utilizo no meu dia-a-dia e me ajuda muito.https://bitbucket.org/pcelta/git-commandsAte a proxima.Segue conteudo do bitbucket:Primeiramente temos que dizer para o Git que a partir de agora sera utilizado um novo e externo servico de diff, e que sera o Meld.Execute o seguinte comando: git config --global diff.external meldPara que o Meld funcione e ncessario passar dois parametros. O Git por padrao envia cinco, entao