char *cstmr;
Que com muita imaginação se pode perceber que nesta variável iria guardar o nome de um cliente. É claro que conforme ia introduzindo 'bugs' nos meus programas passava a dar mais valor ao nome das variáveis, mas depois surgia a dúvida sobre o tipo de notação a utilizar:
char *costumer_name;
ou
char *costumerName;
ou ainda
char *CostumerName;
Na realidade estas acabavam por ser discussões inúteis, que nada contribuíam para a celeridade do trabalho. Muitas vezes a filosofia da tecnologia com que se está a desenvolver já tem algo a dizer sobre a notação que utilizar, mas quando isso não acontece acho que a única coisa importante é que todos os elementos do projecto sigam a mesma regra.
Mas apesar disto houve algo que me passou despercebido até ler este artigo, da autoria de Joel Spolsky. Nele é sugerida uma notação que facilita a detecção de erros, e creio que todos sabemos a dor de cabeça que é detectar e corrigir bugs. Apesar de ser uma sugestão simples, a sua subtileza surpreendeu-me. Acho que vale a pena perder dez minutos e evitar alguns dissabores.
Aposto que após lerem o artigo ficarão a pensar no custo efectivo de uma má escolha no nome das variáveis, pelo menos foi o que aconteceu comigo.
Um abraço,
Gama Franco
4 comentários:
Tenho ido por partes... até agora cheguei a: classes começam com maiusculas e variáveis ou métodos por minusculas. Sobretudo acho que para usar qualquer método é preciso habituação e se tentas habituar-te a tudo ao mesmo tempo é provável que te falhem um monte de coisas e depois a coisa fica toda incoerente. O maior desafio para mim ainda é tentar descrever o que cada coisa é/faz no seu nome sem ocupar uma linha inteira e sem retirar 90% das letras, ficando imperceptivel... :)
Isso que estás a dizer é verdade... para Java :)
Algumas linguagens têm as suas sugestões sobre a forma como os nomes das variáveis/métodos/atributos/etc devem ser definidos. Outras (i.e. C) deixam ao critério do programador.
Por exemplo, em C# os métodos devem começar por maiúsculas, assim como as propriedades (analogia com getVar/setVar) em Java.
Mas o que pretendia realçar não é a forma como escrevemos o nome de uma variável, mas sim o nome que lhes damos. A meta-informação associada ao nome pode, com o hábito, facilitar a detecção de Bugs.
Um abraço,
Gama Franco
Antes de mais, parabéns pela iniciativa (coisa em falta por Portugal).
Segundo, espero que este blog obrigue os 'dinossauros' de informática a dar mais valor à Engenharia de Software em geral.
Por fim, deixo só aqui dois links das 'code conventions' das principais linguagens de hoje:
c#: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.asp
java:
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
Já agora, qual será a 'code convention' para as 'code conventions'? Isto é, devemos usar as 'code conventions' sugeridas pelos proprietários das linguagens ou inventar uma convenção comum à nossa organização/empresa?
Na minha opinião, ainda que seja mais difícil, acho que se deve optar pela primeira, ainda que a segunda tenha alguma razão de ser.
Um abraço,
João Jorge
Concordo plenamente contigo. Até porque sei que és da opinião de adoptar a filosofia da tecnologia aos projectos nela desenvolvidos.
A meu ver, ao utilizar a convenção sugerida pelo proprietário ajuda o programador a aperceber-se que mudou de ambiente, ajuda-o a abandonar a filosofia da linguagem com que trabalhou à cinco minutos.
PS: esses 'links' vão dar jeito :)
Um abraço,
Gama Franco
Enviar um comentário