A notação húngara teve sua época e sua utilidade, basicamente serve para diferenciar tipos. Hoje com o avanço das IDEs, nem linguagens de tipos fracos precisam de notação húngara.
A notação húngara influenciou outras áreas como Banco de dados. Criaram notações para objetos de banco devido às deficiências das ferramentas em identificar tipos, os DBAs mantiveram o costume de padronizar os nomes dos artefatos com prefixos e as vezes tambem com sufixos. Na SEAD-Ce usávamos “TB_” como prefixo de tabelas para diferenciar de “TR_” para triggers. Isso tem uma valia grande para um DBA na hora de listar os objetos no Oracle ou criar rotinas de manipulação.
Mas pelo amor de Javé, não use isso em uma linguagem orientada a objetos, ainda mais com tipos fortes e estáticos como JAVA.
Imagine a seguinte situação em java:
Class Categoria {
private String nomeCategoria;
//segue ...
}
Se nome é uma propriedade da classe Categoria, para que diabos nomear como nomeCategoria? Com qual Objetivo? Qual a vantagem que isso trás?
O pior é definirem padrões semelhantes ao que o DBA (que tem necessidade disso) define para seus artefatos em uma linguagem OO. Vi padrão definido como “usar as três primeiras letras da classe antes das propriedades” e todo tipo de monstruosidade.
Nem que voce me prove que usa o bloco de notas para programar, eu ficaria convencido da real utilidade disso.
Dar manutenção em código desse tipo mais atrapalha do que ajuda, fora que construir também nunca vi utilidade nisso.
Usar notação Java padronizada pela SUN tudo bem , como definir o nome de variáveis em minúsculo e as demais palavras com a primeira letra em maiúsculo, mesmo assim é uma sugestão para facilitar o reconhecimento pela comunidade, se você não quiser seguir o código compila numa boa. Outras comunidades definem a segunda palavra separada por “_” como data_inicio. Mas nada de PTcaixaDoisDTO por favor.
Não invente notação estranha para seu código, imagine que a pessoa que vai dar manutenção é o Dexter Morgan e ele sabe seu endereço.
Typically chemist’s shop can sale to you with discreet treatments for various health problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a extremely complicated question. Matters, like “coupons for viagra“, are coupled numerous types of heartiness problems. If you need to take prescription medications, ask your pharmacist to check your testosterone levels before. Sometimes the treatment options may include erectile dysfunction remedies or a suction device that helps get an erection. Keep in mind web-site which is ready to sell erectile dysfunction drugs like Viagra without a formula is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.
Hahaha, até que nossa discussão dias atrás rendeu um post interessante 🙂
Como você já sabe eu concordo com você a este respeito, cansei de ver códigos de objetos com os nomes das propriedades e até mesmo da classe baseado no banco de dados, pra que? Pra facilitar a vida ou integração com algum framework ORM? Bullshit! Isso mais atrapalha que ajuda.. alias, somente atrapalha.. pois se estiver te ajudando me desculpe, mas você está desenvolvendo uma aplicação procedural orientada a banco de dados 😛
Eu ainda não consigo engolir o “_” entre os nomes das propriedades de um objeto Java, aff.. Talvez por eu já estar acostumado com o padrão da SUN, não sei.. mas em C ou mesmo Ruby isso é bem normal, mas evitemos em Java 🙂
credo o dexter e o jason viu 🙂
mas concordo nao precisa colocar coisas estranhas tenham pena de quem vai ver o codigo depois
abraços e tudo de bom
=]
ops,
desculpe pelo comentario passado logado como admin foi sem querer
:~~
hahaha, boa boa 😉
as vezes excesso de detalhes eh prejudicial.
[]s
Muito legal esse post…
Eu já vi foi classes com atributos dtPeriodo, nuEtc, nmFulano, entre outras monstruosidades que não tem sentido no contexto de OO.
Otimo post a ser lembrado, pq eu ja fiz isso, eu admito!! =/
Concordo 99%. Só há um caso que se pode utilizar uma notação personalizada: a hahahaha
Há braços.
Concordo 99%. Só há um caso que se pode utilizar uma notação personalizada: a div id=”gog” hahahaha
Há braços.
O problema é que quem faz esse tipo de notação acha bacana e não costuma ler artigos como esse, ou qualquer outra coisa.
Aqui na empresa mesmo isso é um dos padrões utilizados.
Às vezes a gente tem que recorrer a isso viu. Por exemplo, eu fui criar um model no rails e tinha uma entidade Transaction que continha um atributo value, e um atributo date… o rails ficou louquinho e não colocou os dois atributos… tive que mudar para transaction_date e transaction_value. Nesse caso, o que fazer?
Pingback: Palestra Agilidade no Mundo Real - Milfont Consulting
Pingback: Desenvolver em Java em pleno 2012, mesmos erros de 2005 - Blog de desenvolvimento da Milfont Consulting, Client e Server-side
Olá,
Não concordo plenamente. A notação húngara tem seu uso prático sim. Já programou usando somente a API do Windows? Não, né…
Trabalho em uma grande empresa e usamos por convenção a notação húngara não porque achamos “bonitinho”, mas porque tem sua aplicação prática e funcional. Você devia falar sobre os programadores que tem o costume de iniciar o nome de cada variável com um “x”, tipo: xDate, xValue. isto sim é mal costume, além de ser dúbio, o prefixo x não diz nada sobre o tipo.