Pessoal, O que o Julio disse, assino embaixo. Eu me assombro demais com comentários infelizes como este de que o Morimoto é isso, é aquilo. E sinceramente, o Kurumin foi um erro? Jamais! Muita gente hoje usa Software Livre, justamente por causa dele.
Sério, me espanta ver como as pessoas azucrinavam e pelo visto ainda azucrinam o Morimoto. O cara fez muito mais do que muitos que o criticam pelo SL no Brasil. E o que ele recebe? Bazófias, piadas de pessoas que aprenderam com ele e julgam um erro bobo como /usr é abreviação de USER. Oras, convenhamos, quem nunca erra? Imagina se cada um aqui escolhesse um membro da lista para chacotear dos erros, muitas vezes considerados bobos por alguns? Enfim, após meu repúdio a esta infelicidade, gostaria de comentar sobre a nomenclatura das variáveis. As variáveis, desde que aprendi Shell, são geralmente escritas em maiúsculo. Maaas como muitos programadores não programam apenas em Shell, acabam trazendo mecanismos que aprenderam de outros lugares. Por exemplo, eu costumo ver quem começou programando em PHP, ter uma queda pelos "_". Muito provavelmente porque as funções do PHP foram nomeadas assim. Mas o importante saber é que existem diversas formas de nomear variáveis, e concordo novamente, mas desta vez em termos, com o Julio. Isso é pessoal se o script for pessoal. Mas, se temos que escrever em equipe (seja para a comunidade ou para um projeto remunerado), geralmente temos que seguir uma convenção, adotada pela equipe para não virar zona. Por exemplo, imaginem se eu me predisponho a fazer o projeto CHOPP DO JULIO com todos vocês. Agora, imaginem se eu resolvo usar o padrão Pascal, o Mr Bits resolve usar tudo em UPPERCASE, o Julio usando variáveis coma primeira em UPPER e o restante em LOWER e outros usando só Lowercase, uns outros com polaco, e mais alguns com o Camel. Imaginem a zona! Então, a questão é medir o que cabe cada caso. Se eu quero fazer um script em 5 minutos para organizar um backup pessoal meu ou fazer um wget rapidinho aqui e acolá, provavelmente vou fazer o clássico "for i in...". Agora, se for um projeto de equipe, vou ler a documentação para saber como escrever e até mesmo comentar como deve ser feito. []'s Gunter [As partes desta mensagem que não continham texto foram removidas]
