JAVA

Lol mas qual preferencia...


http://www2.sys-con.com/itsg/virtualcd/java/archives/0409/farn/index.html

[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]

Que casmurrice isto são convenções...
Cada um segue as que quiser...
 
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?
Às tantas ela ainda nem aprendeu OOP.

Anyway purple_comma, começa a ir às aulas, é a melhor forma para aprenderes.
 
Não te esqueças depois de fazer os imports.

Para a minha soluçao :
Código:
import java.io.*;
Para a soluçao do Scanner :
Código:
import java.util.Scanner;
 
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...

LOL. Paradoxo?
Se são convenções não é cada um segue as que quer. É: Todos devem seguir a mesma. E a que se deve seguir obviamente que é a especificada pelos proprios criadores da linguagem. Se não agora dava-me na cabeça e ia criar a "Convenção arkannis" em que escrevia o código de uma forma criptica, mas não faz mal porque estou a seguir uma convenção.

E por muitos mais links que ponhas, a verdade é que a documentação do java diz explicitamente como se deve escrever código em java e os nomes a atribuir às variaveis.

http://java.sun.com/docs/codeconv/

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 :hello:! 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!
 
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.

Caso não tenhas reparado para fazer um nextLine apenas faço:

_name = _in.readLine();

Nao faço não sei quantas coisas. Se te faz confusao o try e o catch, são excepções que podem ocorrer ao ler o input.

O que tens no construtor e a inicializaçao daquilo que vai receber o nome ou a idade tal como tu tens no Scanner...

Mas realmente é mesmo de quem não tem nada para fazer estar para aqui com esta discussão idiota. Se se preocupassem em ajudar a rapariga no problema dela ja esta thread tinha acabado... Enfim...


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 :hello:! 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!

E mais não digo... Não adienta continuar esta discussão.

Purple__comma fala com o teu professor e pergunta-lhe qual a melhor solução, no fundo quem te vai avaliar é ele... Boa Sorte.

Abraços a todos...
 
Última edição:
mas realmente teve piada primeiro _ sao convenções java e ainda nos chamas espertinhos, e de repente cada um segue a que quer.
Se reparares apenas demonstramos a nossa opinião, tu é que te sentiste muito ofendido.
Duma vez por todas, o this serve para evitar essa questão, hoje em dia os alunos são forçados inicialmente com o uso do this no que toca a variáveis de classe para entenderem a diferença.
Uma solução seria o uso de _ no construtor para igualar, mas qual a necessidade tendo em conta o this?
Para que complicar? No entanto ainda compreendo o uso de _ nestes casos, agora em todas as variáveis não faz qualquer sentido.
As variáveis começam sempre em low e se tiverem duas a segunda palavra começa em caps.
O uso do _ alem de horrivel torna o código mais ilegível.
 
Última edição:
O uso do _ alem de horrivel torna o código mais elegível.

Hmm, isso quer dizer que o código pode ser eleito :007:.


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.
 
Hmm, isso quer dizer que o código pode ser eleito :007:.


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.

Acho que entendeste a ideia:D
Boa correcção, o código não pode ser eleito:-D
Sem dúvida a tua resposta foi sem dúvida a mais correcta, claro que se programamos sozinho não faz grande diferença, mas para quem já esteve inserido em equipas em que cada um programava de maneira diferente e usava diferentes convenções viu a dificuldade acrescida.
 
Ainda outras razões para não usar underscore no início de nomes de variáveis:
The 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.doc.ic.ac.uk/lab/cplus/c++.rules/chap5.html

Ainda que este exemplo seja sobre C/C++, continua a aplicar-se pois a Hungarian Notation é transversal a qualquer linguagem.



Para além disso na Hungarian Notation, usando o underscore no início do nome da variável de instância, obriga também a adicionar um prefixo a seguir ao underscore, para evitar que, internamente, ao serem alteradas ou ao serem adicionadas novas variáveis de instância que comecem com underscore e não tenham prefixo, não ocorram conflitos.


Ainda relativamente a esse código postado com underscores e defendido como sendo Hungarian Notation, apenas se está a usar uma característica particular da notação e que é a menos relevante tendo em conta o princípio com que foi criada. Onde é que estão os tipos de dados visíveis nos nomes das variáveis? Se é para usar uma notação então usa-se em todas as particularidades e não apenas no que se gosta.


Mais, sendo Java uma linguagem OOP continua sem se justificar o seu uso:
No 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.
@ http://www.research.att.com/~bs/bs_faq2.html#Hungarian


Outras desvantagens: http://en.wikipedia.org/wiki/Hungarian_notation#Disadvantages_of_Systems_Hungarian
 
Back
Topo