Padrões de Desenvolvimento

[Detonador PHP 1]

Olá pessoal.

Olha só... trabalho com desenvolvimento web já faz alguns anos, mas sempre em empresas pequenas, o que fez com que eu trabalhasse a minha maneira sempre.

 

Agora trabalho e uma empresa um pouco maior, junto com outros funcionários, cada um trabalhando a sua maneira.

 

Por isso eu gostaria de saber se vocês conhecem algum lugar onde eles mostrem um padrão para desenvolvimento web, do tipo:

 

JS:

- Uso espaço entre as funções:

 

 

function teste() {


    var nomeDaVariável;


}

 

 

 

- NÃO uso espaço entre as funções:

 

 

function teste() {
    var nomeDaVariável;
}

 

Uso comentários extensos e bem desenhados:

 

 

 

///////////////////////////////////////////////////////////////////////////////////////////////////////
////    FUNÇÃO TESTE    ////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////


function teste () {
}


///////////////////////////////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////    fim da funcao teste()

 

 

Ou uso comentários mais enxutos:

 

 

 

/**
 * descrição da função teste()
 * parâmetros da função
*/
function teste () {
}

 

 

 

OU qual padrão para criação de nomes de variáveis:

 

 

 

var minhaVariavel
var MinhaVariavel
var minha_variavel
var minha-variavel

 

 

Saber também qual arquitetura deve possuir os arquivos do projeto.

Por exemplo, eu na pasta imagens sempre sigo esta arquitetura:

 

 

img/geral/ - Imagens que não se adequam as demais categorias
img/icones/ - todos os ícones do sistema
img/botoes/ - todos os botoes
img/modulos/ - imagens específicas de um módulo

 

 

 

É mais ou menos isso.

É como se fosse um padrão para desenvolvimento WEB.

 

Vocês possuem alguma coisa pra indicar?

Ou já trabalham com algum padrão?

 

 

Abraços!

[KhaosDoctor 242]

Cara, existem algumas coisas que foram definidas no fórum da MSDN e também algumas coisas que o Macoratti fala sempre sobre Camel Casing e outras coisas sobre padronização de desenvolvimento de variáveis, na verdade essa parte de nomes e comentários você pode pegar de praticamente todas as linguagens porque é meio que universal.

 

Quebras de linha e pastas já são uma coisa mais específica, mas eu acredito que você deva fazer para que não só você, mas outros também possam entender como o aplicativo funciona, então deixe sempre bem claro as coisas, veja de marcar uma reunião só para definir isto.

[thyquevedo 6]

Já tive o mesmo problema que você, a tempos atrás.

O que fiz, foi uma reunião para definir o padrão de desenvolvimento da empresa.

Juntando todas as definições da reunião, criei um padrão para os projetos, e já deixei pronto, por exemplo:

 

Criei um "site", com o ajax, jquery padrao, init.js, reset.css, padrões de formulário e etc, e passei a todos.

isso já ajuda muito no entendimento de todos.

[Detonador PHP 1]

Obrigado thyquevedo pela resposta.

 

Mas não tem algum lugar onde possa trazer alguns destes padrões?

Na verdade o meu medo é criar um padrão meu aqui, e de repente já tem alguma coisa consolidada pela comunidade web, ou pela comunidade dos programadores, entendeu?

 

Dai eu estaria "quebrando os padrões".

 

Se algumas coisas não tiverem padrões pré-estipulados, tudo bem. Dai crio os meus aqui e documento.

Mas se já tiver alguma coisa pronta gostaria de usar.

 

Um exemplo básico:
Identação deve ser Soft Tab, referente a 4 espaços.

Este já é um padrão definido a tempos, então supondo que eu não soubesse disso, se eu definisse o meu padrão como sendo 2 espaços eu estaria quebrando o padrão já consolidado.

 

Entenderam?

[KhaosDoctor 242]

Faça uma reunião com seus colegas de equipe, um deles vai saber sobre algum padrão e mesmo que não saiba, se apenas vocês vão usar o padrão, não tem necessidade de ser universal, crie o de vocês.

[Detonador PHP 1]

Pessoal, só pra enriquecer mais esta discussão, depois de muita pesquisa achei um material muito interessante.
Ele é basicamente para desenvolvimento Front-End, mas acredito que muitos dos conceitos podem ser reaproveitados para o back-end também.

 

Então deem uma olhada neste link:
Front-end Code Standards & Best Practices

 

O padrão de Front-end fala sobre padrões de comentários, como eu tinha falado anteriormente, mas só pra facilitar na leitura vou colocar um atalho para estes padrões também:

Natural Docs

 

Estou lendo e testando a maioria das coisas, e o Natural Docs é fantástico. Só me falta fazer ele funcionar. hehehe

Mas de resto é muito interessante.

 

 

Se vocês tiverem qualquer outro material pra contribuir, não deixem de postar.

Grande abraço a todos!

[Detonador PHP 1]

Pessoal, outra contribuição.

Encontrei um padrão de desenvolvimento para PHP, que acredito que pode ser usado para muitas outras linguagens.

O detalhe é que grandes frameworks estão começando a utilizar estes padrões, como o Drupal, Zend, CakePHP, phpBB, AWS SDK, FuelPHP, Lithium, entre muitos outros.

 

O link com todo o conteúdo é este aqui:
PHP: Do Jeito Certo

 

Mas acredito que estes padrões são os mais importantes.

Seria legal dar uma olhada neles para usar como guai de base para o desenvolvimento:
- Leia sobre a PSR-0

- Leia sobre a PSR-1

- Leia sobre a PSR-2

Espero que isso ajude.

Grande abraço a todos!

Outro link para leitura:
Coding standards front end

 

Queria saber do admin se poderia criar talvez um tópico fixo ou algo onde eu pudesse juntar todos estes conteúdos em um único post.

Quem sabe poderia ajudar o pessoal no desenvolvimento de seus projetos.

[Gabriel Heming 766]

Padrões de escrita de código existem vários, de XGH até os de grandes comunidades. Como é o exemplo das PSRs. Conhece-las é importante, principalmente dentro de uma comunidade (PHP em questão). Já segui-la, isso vai de cada equipe e somente dentro da equipe.

 

Se você já leu o livro "à espera de um milagre", ou viu o filme, conhecerá a frase: "O que acontece na milha fica na milha".

 

É mais ou menos isso. Caso você for ler algum livro sobre padrões de escrita de linguagem, tal como Clean Code, o autor, Robert "UncleBob" Martin, comentará no primeiro capítulo que, apesar dele escrever um livro sobre como escrever um bom código, ele mesmo pode não seguir tudo a risca, ele sempre fará uma reunião com toda a sua equipe, e definirá um padrão que deve ser utilizado.

 

Outro comentário dele é para não ficar apenas no seu livro, e sim saber o máximo possível de padrões de escrita de código, de outros autores e comunidades diferentes, e utilizar o que achar melhor.

 

Eu como programador e profissional em PHP, não utilizo tudo o que as PSRs descrevem. Vim da programação Java, com uma escrita semelhante, mas diferentes nos detalhes, e no caso de uma boa escrita, até os detalhes importam.

 

Um dos detalhes, que eu acho, mais importante no livro Clean Code, é sobre a não utilização de comentários. Pois o autor descreve um comentário como a forma de tentar explicar um código ruim e mal escrito. O uso de comentário é somente perdido quando a regra de negócio é tão complexa que o próprio código não consegue se explicar.

 

Exemplos de comentários como este:

/**
   função que converte uma string em um inteiro
   @param String $string A string a convertida
   @return int 
**/
function convertStringToInt($string) {
   /** código **/
}

 

Comentários como esse são, de longe, redundantes e apenas poluem o código. Mas por que redundantes?

Pois eles dizem tudo o que a função diz.

- Converter String para inteiro;

- String como parâmetro de entrada.

 

Logo, apenas pelo nome da função, se deduz que a função converte uma string para um inteiro, não necessita de comentários.

 

Sugiro que, além de ler todo o material que encontrar, sabe os "grãos" e então, com sua equipe, defina o que é melhor dentro da sua equipe, algumas coisas você terá que apenas engolir a decisão do grupo, mas sempre deve haver um bom motivo.

 

Eu por exemplo, já tive que aceitar padronizações de escrita de variáveis de formas que eu acho, de longe, inaceitáveis. Como uso de underline/underscore em métodos e nome de classes. Mas esse foi o consenso da equipe, então tive de aceitá-las.

[Eudes. 0]

Os padrões do PHP Doc também são bons.

[Enrico Pereira 299]

Alguns dos ensinamentos do Clean Code sobre comentários:

 

- comentários que atrapalham devem ser removidos

- um comentário não torna um código ruim em um código bom

- comentários do tipo //endtry //endif só atrapalham

 

Outro que acho excelente: somente três parâmetros por método.

 

E também concordo com o Gabriel, às vezes temos de seguir padrões que a equipe chega e simplesmente aceitá-los, todavia, mesmo que o padrão seja um lixo, use um padrão, não deixe o código despadronizado e para checar esse padrão o PHP CodeSniffer faz um bom trabalho.

 

E comentários, em PHP, são úteis para o PHPDoc, hoje em dia eu uso para qualquer método, apenas para informar os tipos, só uso descrições para coisa complicada (bem difícil de acontecer).

[Henrique Barcelos 290]

Outro que acho excelente: somente três parâmetros por método.

Essa regra tem suas exceções, e não são tão poucas...

[Bruno Augusto 417]

Eu já acho que seguir a PSR-2 inteira deixa o código feio e eu prezo muito por código elegante.

[Enrico Pereira 299]

O que você acha que deixa o código feio? na PSR-2

[Bruno Augusto 417]

Tokens grudados e uma linha exclusiva para a abertura de bloc (chaves).

[Enrico Pereira 299]

Linhas adcionais são somente para chaves que indicam classes, funções e métodos, justamente para diferenciá-los de estruturas de controle. Tokens grudados????

[Bruno Augusto 417]

Sim tokens grudados:

 

 

if(count($foo)==0){

Acho difícil de ler, prefiro:

 

 

if( count( $foo ) == 0 ) {

[Enrico Pereira 299]

O correto seria:

 

if(count($foo) == 0){

 

ou usando Yoda Conditions:

 

if(0 == count($foo)){

[Bruno Augusto 417]

Não importa se eu postei de um jeito ligeiramente diferente do pregado pelo padrão sendo que eu não o sigo à risca.

 

Foi só para ilustrar. Quanto ao Yoda Conditions... Acho que nunca programi nenhuma condição desse jeito.

[Enrico Pereira 299]

Eu atualmente uso, e penso que é melhor, você explicita o valor estático de uma vez só. E também faz um pouco mais de sentido e relação com testes unitários, por exemplo: o método assertEquals se usa o expected primeiro, mas sei lá o motivo de usar assim.

 

Uma boa leitura sobre esse vocabulário de maluco de programador: http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html

[Bruno Augusto 417]

Meio grande pra ler inteiro, mas eu sou adepto do Pokemon Exception Handling, pra adicionar um pouco de humor nos comentários e das Egyptian Bracket pelo motivo acima exposto.

 

E alguns de meus recursos sofrem um pouco com o Megamoth e, às vezes, principalmente em módulos que não domino muito bem (como DB), um pouco do Jenga Code.

 

E quem nunca foi Smug Reporter que atire a primeira pedra :lol: