Miguel,pessoalmente não sou apologista de usar _myVar nas variáveis privadas, EXCEPTO se tiverem um getter/setter correspondente. Não ganhas nada em usar um _ atrás de uma variável privada - i.e. só te interessa saber se ela é privada ou não no momento em que fazes a especificação da classe (durante a arquitectura). A partir daí (algoritmia), é "indiferente" nos teus algoritmos usares _myVar ou myVar (isto é, o facto dela ser privada ou pública não deve ter impacto na forma como implementas o teu algoritmo, pois não é aqui que decides sobre a sua visibilidade - excepto se for uma helper var, claro).
Porém, se colocares _myVar em variáveis privadas que tenham getters e setters, quando te referires a elas tens um indicador óbvio e explícito de que estás a aceder directamente à variável sem passar pelo setter/getter - o que pode dar "bronca" em alguns casos (isto é: _myVar="xpto" é diferente de myVar="xpto", pois no segundo caso irá passar pelo setter, e possivelmente executar operações adicionais - por exemplo, despoletar um evento ou marcá-la como "dirty"). Pessoalmente, prefiro "reservar" o _ para representar estes casos: identificar uma variável privada que possui getter/setter.
Se analisares o SDK do Flex, a Adobe usa esta mesma prática.
Em resumo, sugiro que:
* Variáveis privadas, públicas e protegidas tenham todas a mesma
nomenclatura: myVar
* Se a variável possuir um getter, ou um setter, então aí deve-se
utilizar _myVar
Sugiro ainda que:
* Sempre que possível, deve-se evitar variáveis privadas. Deve-se,
sim, usar variáveis protegidas.
Este último ponto tem sobretudo a ver com a escabilidade. Ao marcarem
uma variável como privada estão a bloquear o acesso à mesma no futuro
através de classes que herdem desta - comprometendo a escalabilidade.
Uma variável só deve ser marcada como privada:
* quando funciona como "helper";
* quando possui um getter/setter;
* quando sabemos MESMO que não queremos que ela seja acedida pelas
heranças (i.e. "final")
* ou quando consideramos que a nossa classe está "inacabada" e não
queremos "expôr" a variável na API para não comprometer alterações
à especificação no futuro (deve-se tentar fechar a especificação
da classe, e evitar alterações à API - variáveis e métodos
"deprecated").
Esta questão de se usar muito private, e pouco protected, é, a meu ver,
um dos calcanhares de aquiles do Flex SDK. Sobretudo na versão 3:
extender o SDK é de loucos... Eles agora no 4 já se estão a portar
"melhor" (temos sido uns "chatinhos" a pressioná-los com isto ;) )
linkedIn <http://pt.linkedin.com/in/jsaleiro> João Saleiro Chief Technology Officer Tel: 00351 916 077 097 Email: [email protected] <mailto:[email protected]> Skype: joao.saleiro <callto://pedro.arelo>Webfuel Solutions <http://www.webfuel.pt> www.webfuel.pt <http://www.webfuel.pt>
Lisbon, Portugal On 24-01-2011 21:03, Miguel Pinto wrote:
Nuno,Não penso que seja o sexo dos anjos, funciona das 2 maneiras é verdade mas em empresas com projectos grandes e mais de um developer é sempre bom ter coding standards bem definidos, para que facilmente uns possam ler e rapidamente perceber o codigo desenvolvido por outros.Pessoalmente uso sempre na linha de baixo, habituei-me com algumas frameworks de PHP como a Zend que usam esse standard e acabei por o transportar para o flash.Passei outros também por exemplo tudo o que sao variaveis privadas começam por underscore.(actionscript) private var _something:String; (PHP) private $_something;Se toda a equipa usar os mesmos coding standards o código fica mais limpo e facil de entender quando feito por outros programadores.No dia 24 de Janeiro de 2011 20:06, Nuno Ribeiro <[email protected] <mailto:[email protected]>> escreveu:Não estarão vocês a "discutir" o sexo dos anjos? Eu pessoalmente prefiro a versão apresentada pelo João Saleiro e é a que uso. O importante é não se esquecerem de "fechar" as chavetas :P. De uma forma ou de outra o compilador não se queixa e isso sim é o importante (a meu ver :P). Abraços, Nuno Ribeiro On Jan 24, 2011, at 6:26 PM, Paulo Afonso wrote:Vê isto também http://gskinner.com/blog/archives/2008/11/curly_braces_to.html No dia 24 de Janeiro de 2011 17:03, Paulo Lameira <[email protected] <mailto:[email protected]>> escreveu: ... reconheço que poderá ser uma vantagem no reconhecimento mas soa estranho para quem não está habituado... parece que graficamente não é tão apelativo.... ;o) 2011/1/24 João Saleiro <[email protected] <mailto:[email protected]>> Ricardo, nós fazemos assim: for (var i:Number = 0; i < 10; ++i) { if (myNumber == i) { trace("do this"); } else { if (name == "xpto") { trace("do else, and xpto"); } else { trace("do else, but not xpto"); } } } A vantagem é mesmo a facilidade em reconhecer blocos. Provavelmente o Google Groups vai desformatar a identacão, mas veremos se chega bem... * *-- Paulo LameiraNew Media Developer (+351) 962.855.462 http://paulolameira.pt.to <http://paulolameira.pt.to/>-- Recebeu esta mensagem porque está inscrito no grupo "MailingList da Comunidade Portuguesa de Rich Internet Applications - www.riapt.org <http://www.riapt.org/>" dos Grupos do Google. Para publicar uma mensagem neste grupo, envie um e-mail para [email protected] <mailto:[email protected]>. Para anular a inscrição neste grupo, envie um e-mail para [email protected] <mailto:riapt%[email protected]>. Para ver mais opções, visite este grupo em http://groups.google.com/group/riapt?hl=pt-PT.-- *Paulo Afonso*Tlm: 938945683 http://www.semmais.com/ http://www.linkedin.com/in/semmais/ http://www.facebook.com/semmais/ / / /O teu êxito depende muitas vezes do êxito das pessoas que te rodeiam. (Benjamin Franklin)/-- Recebeu esta mensagem porque está inscrito no grupo "Mailing Listda Comunidade Portuguesa de Rich Internet Applications - www.riapt.org <http://www.riapt.org>" dos Grupos do Google. Para publicar uma mensagem neste grupo, envie um e-mail para [email protected] <mailto:[email protected]>. Para anular a inscrição neste grupo, envie um e-mail para [email protected] <mailto:[email protected]>. Para ver mais opções, visite este grupo em http://groups.google.com/group/riapt?hl=pt-PT.-- Recebeu esta mensagem porque está inscrito no grupo "Mailing Listda Comunidade Portuguesa de Rich Internet Applications - www.riapt.org <http://www.riapt.org>" dos Grupos do Google. Para publicar uma mensagem neste grupo, envie um e-mail para [email protected] <mailto:[email protected]>. Para anular a inscrição neste grupo, envie um e-mail para [email protected] <mailto:riapt%[email protected]>. Para ver mais opções, visite este grupo em http://groups.google.com/group/riapt?hl=pt-PT. -- Miguel Pinto Comunidade portugesa de php (www.php-pt.com <http://www.php-pt.com>) [email protected] <mailto:[email protected]> [email protected] <mailto:[email protected]> --Recebeu esta mensagem porque está inscrito no grupo "Mailing List da Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" dos Grupos do Google. Para publicar uma mensagem neste grupo, envie um e-mail para [email protected]. Para anular a inscrição neste grupo, envie um e-mail para [email protected]. Para ver mais opções, visite este grupo em http://groups.google.com/group/riapt?hl=pt-PT.
-- Recebeu esta mensagem porque está inscrito no grupo "Mailing List da Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" dos Grupos do Google. Para publicar uma mensagem neste grupo, envie um e-mail para [email protected]. Para anular a inscrição neste grupo, envie um e-mail para [email protected]. Para ver mais opções, visite este grupo em http://groups.google.com/group/riapt?hl=pt-PT.
<<inline: LinkedIn.gif>>
<<inline: Webfuel.gif>>
