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.
Categories: Engenharia de Software, Java, Linguagens, Melhores práticas, Orientação a Objetos ~ ~ Trackback
OPML Completo.
Texto Completo
January 21st, 2008 at 10:26 am
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
January 21st, 2008 at 10:28 am
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
=]
January 21st, 2008 at 10:30 am
ops,
desculpe pelo comentario passado logado como admin foi sem querer
:~~
January 21st, 2008 at 11:07 am
hahaha, boa boa
as vezes excesso de detalhes eh prejudicial.
[]s
January 12th, 2010 at 10:38 am
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.
January 28th, 2010 at 1:50 pm
Otimo post a ser lembrado, pq eu ja fiz isso, eu admito!! =/
January 29th, 2010 at 5:13 am
Concordo 99%. Só há um caso que se pode utilizar uma notação personalizada: a hahahaha
Há braços.
January 29th, 2010 at 5:14 am
Concordo 99%. Só há um caso que se pode utilizar uma notação personalizada: a div id=”gog” hahahaha
Há braços.
February 10th, 2010 at 7:56 am
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.
March 8th, 2010 at 7:37 am
À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?
July 11th, 2010 at 4:45 am
[...] http://www.milfont.org/tech/2008/01/20/frameworkstools-caseiros-ou-fechados/ http://www.milfont.org/tech/2009/06/06/frameworks-caseiros-2-a-missao/ http://www.milfont.org/tech/2008/01/21/nao-use-notacao-estranha/ [...]