l18n ... problema de quem for traduzir o soft (6)
E se o trabalho for em equipe? Tá, não é, mas poderia ser. Adotar mais de um método além de inviável se torna confuso, acaba misturando conceitos... Coding Standards na programação é como os Web Standards na marcação, algo que deve ser seguido. Garante uma maior legibilidade e profissionalismo ao código, não é mesmo? A página sobre POG na Desciclopédia é um ótimo exemplo do que não se deve ser seguido.
Depende muito do escopo do projeto, tá certo que se holandeses invatarem de traduzir meu código eles vão me xingar até a 10ª geração porque minhas variáveis vão estar em PT.
Mas se as variáveis tem que seguir nomeclatura em inglês, logo os comentários tambem tinham que estar 
'
Depende do escopo? Não necessariamente. Você pode muito bem codificar da mesma forma que codificaria se estivesse trabalhando em equipe, só depende de tu. Trabalho a mais não terá, pelo contrário, a menos, na hora do debug...
Eu sou a favor de que se crie um padrão genérico, que todo programador tenha sabe?
Tipo $i para um interador aos invés de $c ou num, este tido de coisa.
Assim facilitaria na hora de ler um código, eu não precisaria ler o manual do zend para entender a nomeclatura do cara >.<
Aí não seria bem um padrão... Deve haver semântica no nome de uma variável, isto é, ela deve representar o que realmente é. Se eu utilizar
$i num iterador primário, que nome darei à um iterador secundário dentro do primário,
$j? Perde o sentido.
Um código que segue algum padrão dificilmente terá de se traduzir para interpretar... Códigos padronizados são semânticos (leia-se interpretáveis) do início ao fim.
Olha só que maravilha de código:
http://cvs.php.net/v...D...ain&view=co (exemplo simples)
Qualquer programador em qualquer lugar do planeta irá interpretá-lo da mesma maneira. Vejam que legibilidade absurda que um padrão proporciona.
Comentários em inglês? Sim, porque não?
Semantic development. Seja bem-vindo ao futuro.
[]’s
Até mais
