IComeFromBehind
Power Member
Engraçado como começaste como um convention riot e agora tentas justificar com preferência pessoal.
[FONT=Arial,Helvetica,Verdana,sans-serif][SIZE=-1]Reuse of Variable Names
Hungarian Notation also allows variable names to be reused when only the notation part of the name is different. Let's take a look at a slightly more complex example, shown in Listing 1. In this class the constructor is given a file name and a "boolean." The file name is the name of a file and the boolean is used to tell the constructor whether the file name should be used. [/SIZE][/FONT]
[FONT=Arial,Helvetica,Verdana,sans-serif][SIZE=-1]In this example an underscore character prefix distinguishes the instance variables from the local variables and function arguments. Also the letter "b" is used as the notation prefix for boolean type variables, as in "_bNameIsValid". The variable name "strFilename" is used for both the input argument and the instance variable with the exception of the underscore prefix in the instance variable. If you just see the statements: [/SIZE][/FONT]
[FONT=Arial,Helvetica,Verdana,sans-serif][SIZE=-1] _strFilename = strFilename;
_bNameIsValid = true; [/SIZE][/FONT]
Às tantas ela ainda nem aprendeu OOP.Para o programa pequeno dela isso serve... Se calhar tenho mais linhas porque organizei isso em métodos. Organização de código já ouviste falar?
Lol mas qual preferencia...
http://www2.sys-con.com/itsg/virtualcd/java/archives/0409/farn/index.html
Que casmurrice isto são convenções...
Cada um segue as que quiser...
Caso tenhas dificuldades em inglês: http://wiki.portugal-a-programar.org/java:convencoes_linguagem
E se para ti organizar código é fazer dois métodos e mais não sei quantas coisas só para fazer um nextLine, deixa-me rir.
Existem sempre muitas "convenções"... nem que sejam inventadas por algum professor universitário...
Dos 10 anos de programação em Java... nunca utilizei, nem vi utilizar, "_" para nomes de variaveis...
O link postado apreenta uma convenção aceite pela maioria dos programadores... tanto mais que esta disponivel no site da sun http://java.sun.com/docs/codeconv/
Quanto à questão do Scanner... não me parece que diminuir o nº de linhas programadas, vá diminuir o nº de linhas a serem executadas!
Esta classe detecta padroes utilizando expressões regulares ! Sendo util para casos em que seja necessário detectar padroes complexos, neste caso parece-me um canhão para caçar um mosquito!
Para os mais distraidos... a classe java.util.Scanner tem 2591 linhas de codigo (o que dá uma ideia do que estou a falar...). E já agora... esta classe tambem utiliza um "InputStreamReader"... da mesma forma como foi aqui descrito!
O uso do _ alem de horrivel torna o código mais elegível.
Hmm, isso quer dizer que o código pode ser eleito .
Em relação às convenções, penso que cada um deve usar aquelas que lhe forem mais convenientes, desde que esteja a trabalhar sozinho. No entanto, para trabalhos que envolvam (ou que possam vir a envolver) outros programadores, é conveniente que se estabeleça um conjunto de normas que todos devem seguir, de modo a garantir que existe coerência no código desenvolvido, entre outras possíveis vantagens. Um bom ponto de partida são as tais convenções "oficiais" que já foram referenciadas nesta thread.
Existem no entanto certas convenções que devem ser impreterivelmente seguidas, tais como aquelas que existem em algumas frameworks, pois só desta forma é assegurado o correcto funcionamento de determinadas funcionalidades.
@ http://www.doc.ic.ac.uk/lab/cplus/c++.rules/chap5.htmlThe use of two underscores (`__') in identifiers is reserved for the compiler's internal use according to the ANSI-C standard.
Underscores (`_') are often used in names of library functions (such as "_main" and "_exit"). In order to avoid collisions, do not begin an identifier with an underscore.
@ http://www.research.att.com/~bs/bs_faq2.html#HungarianNo I don't recommend "Hungarian". I regard "Hungarian" (embedding an abbreviated version of a type in a variable name) a technique that can be useful in untyped languages, but is completely unsuitable for a language that supports generic programming and object-oriented programming - both of which emphasize selection of operations based on the type an arguments (known to the language or to the run-time support). In this case, "building the type of an object into names" simply complicates and minimizes abstraction. To various extent, I have similar problems with every scheme that embeds information about language-technical details (e.g., scope, storage class, syntactic category) into names. I agree that in some cases, building type hints into variable names can be helpful, but in general, and especially as software evolves, this becomes a maintenance hazard and a serious detriment to good code. Avoid it as the plague.