Re:Legibilidade de código

Código bonito e bastante legível!

agora com realção a "“caminho certo”, como o colega thingol citou, interface é uma parte de programacão que tem sido “automatizada” pelas IDE`s em nome da produtividade.

A mesma identação e regras utilizadas, se fossem aplicadas a uma classe que envolvesse o algoritmo que de fato resolve o problema não estaria melhor ou pior do que você apresentou, apenas estaria sendo usada em uma área onde de fato o talento em programação é mais crítico.

Lembrando que o “java code conventions” http://java.sun.com/docs/codeconv/ também podem lhe auxiliar nisso, ok?

boa sorte!

Ja que voce perguntou…

• Nao abrevie o nome das coisas, exceto em casos especiais. No caso estou me referindo ao “AutGUI”. Como nao mexo no dia-a-dia com codigo de GUI, nao sei dizer como isso pode ser interpretado para o caso dos prefixos para componentes (lbl, btn, etc), mas no nome da classe isso eh fundamental.

• Utilize Javadoc.

• Identacao mais compacta (4 espacos) e instrucoes no mesmo nivel devem utilizar a mesma identacao. Hehehehe - eu sei, provavelmente isso eh por causa da formatacao no forum, estou forcando.

No geral esta legal. Parabens. Nao pelo codigo, mas pela atitude. Sempre pense que outra pessoa pode vir (provavelmente vira) a ler seu codigo e tambem no que voce gostaria de encontrar quando estivesse lendo codigo de outras pessoas.

Marcio Kuchma

Eu não gosto de notação hungara (http://en.wikipedia.org/wiki/Hungarian_notation), portanto nomes de variáveis como lblPassword ou txtNome não são legais, em minha opinião…

Concordo. Mas como ficam as variaveis para a programacao de GUI nesse caso? (label para nome, edit para nome, variavel String para nome, etc)

Quem costuma desenvolver esse tipo de coisa por aqui? Como voce faz?

Marcio Kuchma

Complementando a dica do Marcio, use espaços para identar, não tabs. Se tiver um editor que substitua tabs por espaços, fica melhor ainda. Isso porque cada um configura a exibição dos tabs com um tamanho diferente.

Outra coisa que não me agradou muito foi usar métodos públicos para a configuração dos componentes de tela. Separar em métodos pode ser interessante para separar melhor o código, mas, a menos que você pretenda usar essas configurações de componentes em outras classes, deixar os métodos públicos é uma quebra de encapsulamento.

Kuchma, eu mexo com gui e acho que, usando uma IDE que indique o tipo da variável, indicar o formato do componente é bobagem. O importante é saber qual vai ser a entrada lá. Só os labels que são chatos nesse sentido, mas até a existência deles já é chata.

Devido a um costume antigo eu ainda prefiro, quando um dado (modelo) é representado em uma interface visual (visão), usar o nome sem notação húngara para o modelo, e a notação húngara para a visão.

Exemplo:

txtUsuario (visão) --> JTextField
usuario (modelo) --> String

Mas concordo que isso é questão de costume e não é muito razoável. Imagine isso quando usado em uma interface HTML:

<input type="text" id="txtUsuario" name="txtUsuario">

É óbvio que é mais simples e mais direto usar

<input type="text" id="usuario" name="usuario">

sem notação húngara, mesmo para a visão.

• Coisas que na sua interface de usuário são fixas (como "lblUsuario") não deveriam ter nem métodos, nem variáveis públicas ou protegidas associadas a elas. Nesse caso cabe o tal do método "init".
  Na verdade nem deveriam ser codificadas, mas carregadas a partir de uma descrição. Imagine se o HTML em vez de ser uma descrição da página fosse uma codificação.
  Talvez você até quebrasse o método "init" em vários, para as diversas partes de sua tela. Mas ainda acho que é a IDE que deve preparar a interface de usuário.
• Coisas que representam uma visão de seu modelo de dados (como "txtUsuario" --> "usuario") já merecem uma variável, ou um "getter" para ela.

A questão dos métodos para os componentes é meio complicada. No geral, eu concordo com o thingol no sentido de que isso não deveria ser programado, deveria ser descrito. Por exemplo, você ter separado em métodos auxilia na separação do código e ajuda na abstração das coisas, mas os métodos públicos fazem com que quem use a sua classe tenha o direito de chamá-los, o que pode ser inconveniente. Deixar os métodos private ia conter este problema apenas à sua classe, mas não ia eliminá-lo. A solução “método init”/construtor/bloco de inicialização é até válida. Apenas tome cuidado para separar as coisas. Algumas coisas vão ocorrer e devem ocorrer apenas uma vez, que é a montagem da tela. Porém, a atualização da tela vai ocorrer várias vezes, então seria conveniente deixar tudo que é relativo à atualização (limpar conteúdo de campos, zerar validações, etc) em um método separado.

<blockquote><div class="quote-author">Spool:</div> Como gosto de programar “na unha”, pelo menos para mim fica bem mais fácil de “decifrar” o que é um label ( lbl ), o que é um textfield ( txt ), o que é um botão ( cmd ) etc etc etc…

(…)

magine um momento em que vc pegue uma variavel usuario.setText(“Nome”)

como saberia se ela é um label ou um tField sem consultar a declaração da variavel??

Pelo bem da sua sanidade, espero que “na unha” simplesmente signifique “editar código” e não “usar bloco de notas”. Se significa “editar código”, a coisa fica mais simples, já que IDEs como Eclipse e NetBeans indicam o tipo da variável quando você coloca o mouse em cima (ou no caso do Eclipse, quando aperta F2 com o cursor sobre a variável), o que já amena esta necessidade. De resto, você sempre pode saber o que algo é pelas suas ações, que devem estar indicadas no nome. Se for um verbo, é uma ação (botão), se for um nome é uma indicação ao seu modelo (campo), etc. O problema da notação húngara vem quando se muda de um ComboBox para um TextField e não se muda o nome da variável de cmbTipo para txtTipo.

Claro que tudo isso que eu estou falando é prontamente desobedecido quando se trata de labels, já que estes em geral estão acoplados aos campos de edição, portanto se simplesmente nomeá-los de acordo com o modelo, fica-se com variáveis duplicadas. Então é mais prático mandar o que eu falei às favas e usar um “lb” ali, mesmo porque labels só vão ser usados duas vezes, uma na criação e outra na hora de mostrar.

Spool:

Quer dizer então que me enquadro no grupo de insanos?! hehehe

Na realidade, TextPad!!!

To “fuçando” em IDE´s ( Eclipse / NetBeans ). Mas não me agrada muito a idéia.
Vou tentar me acostumar.

hehehehe

Quer dizer então que me enquadro no grupo de insanos?! hehehe

Por mais que minha sanidade seja questionável, editores de texto simples só servem para estudar. Usar uma IDE é essencial para o dia-a-dia, visto que além de programar, você tem que fazer deploy, builds, unit cases, subir webserver, configurar framework e tomar cafézinho. Sem contar que as opções de refactoring do Eclipse são sensacionais.

Spool:

Olá pessoal. Gostaria de saber se estou indo pelo caminho certo.

Gostaria de algumas opiniões a respeito.

- Voce considera o codigo abaixo "legível"?
- O que faria para melhorá-lo?

public class AutGUI extends JFrame {

		private static final int PANEL_LEFT_MARGIN = 25;

		public AutGUI() {
				super();

				setDefaultCloseOperation(EXIT_ON_CLOSE);
				setTitle("Ful-Control - [v0.1]");
				setSize(300, 250);
				setLocationRelativeTo(null);
				setResizable(false);

				getContentPane().add(BorderLayout.CENTER, mainPanel());

				setVisible(true);
		}

		public JPanel mainPanel() {
			JPanel mainPanel = new JPanel();

				mainPanel.setSize(280, 230);
				mainPanel.setLayout(null);

				mainPanel.add(lblUserName());
				mainPanel.add(lblPassword());

				return mainPanel;
		}

		public JLabel lblUserName() {
			JLabel lblUsername = new JLabel("Usuário:");

				lblUsername.setFont(new Font("Arial", Font.BOLD, 12));
				lblUsername.setBounds(PANEL_LEFT_MARGIN, 10, 50, 20);
				lblUsername.setBorder(BorderFactory.createLineBorder(Color.white));
				lblUsername.setHorizontalAlignment(JLabel.RIGHT);

				return lblUsername;
		}

		public JLabel lblPassword() {
			JLabel lblPassword = new JLabel("Senha:");

				lblPassword.setFont(new Font("Arial", Font.BOLD, 12));
				lblPassword.setBounds(PANEL_LEFT_MARGIN, 35, 50, 20);
				lblPassword.setBorder(BorderFactory.createLineBorder(Color.white));
				lblPassword.setHorizontalAlignment(JLabel.RIGHT);

				return lblPassword;
		}

sendAbraços();

opa!!! uma dica!! as chaves deve ficar na mesma tabulação a qual se refere ficaria 100% legivel!!!

Olá pessoal.
Gostaria de saber se estou indo pelo caminho certo.

Gostaria de algumas opiniões a respeito.

- Voce considera o codigo abaixo "legível"?
- O que faria para melhorá-lo?

public class AutGUI extends JFrame {

		private static final int PANEL_LEFT_MARGIN = 25;

		public AutGUI() {
				super();

				setDefaultCloseOperation(EXIT_ON_CLOSE);
				setTitle("Ful-Control - [v0.1]");
				setSize(300, 250);
				setLocationRelativeTo(null);
				setResizable(false);

				getContentPane().add(BorderLayout.CENTER, mainPanel());

				setVisible(true);
		}

		public JPanel mainPanel() {
			JPanel mainPanel = new JPanel();

				mainPanel.setSize(280, 230);
				mainPanel.setLayout(null);

				mainPanel.add(lblUserName());
				mainPanel.add(lblPassword());

				return mainPanel;
		}

		public JLabel lblUserName() {
			JLabel lblUsername = new JLabel("Usuário:");

				lblUsername.setFont(new Font("Arial", Font.BOLD, 12));
				lblUsername.setBounds(PANEL_LEFT_MARGIN, 10, 50, 20);
				lblUsername.setBorder(BorderFactory.createLineBorder(Color.white));
				lblUsername.setHorizontalAlignment(JLabel.RIGHT);

				return lblUsername;
		}

		public JLabel lblPassword() {
			JLabel lblPassword = new JLabel("Senha:");

				lblPassword.setFont(new Font("Arial", Font.BOLD, 12));
				lblPassword.setBounds(PANEL_LEFT_MARGIN, 35, 50, 20);
				lblPassword.setBorder(BorderFactory.createLineBorder(Color.white));
				lblPassword.setHorizontalAlignment(JLabel.RIGHT);

				return lblPassword;
		}

sendAbraços();

Valew pelas sugestões.
To dando uma olhada mais completa nas convenções. Conheço algumas, mas tem muitas que estão lá que eu nem imaginava.

Mais dicas e opiniões são sempre bem vindas.

sendAbraços();

Se eu colocar os métodos como privados?
Resolveria? Ou ainda seria uma forma de quebrar o encapsulamento?

O que sugeria para não criar componentes em métodos separados? Criar todos dentro do construtor?

Ou criar um único método ( por ex. init() ) e criar os componentes lá?

Valew!

Devido a um costume antigo eu ainda prefiro, quando um dado (modelo) é representado em uma interface visual (visão), usar o nome sem notação húngara para o modelo, e a notação húngara para a visão.

Exemplo:

txtUsuario (visão) --> JTextField
usuario (modelo) --> String

Mas concordo que isso é questão de costume e não é muito razoável. Imagine isso quando usado em uma interface HTML:

<input type="text" id="txtUsuario" name="txtUsuario">

É óbvio que é mais simples e mais direto usar

<input type="text" id="usuario" name="usuario">

sem notação húngara, mesmo para a visão.

Eu mantenho essa notação por herança do VB. :S
Como gosto de programar “na unha”, pelo menos para mim fica bem mais fácil de “decifrar” o que é um label ( lbl ), o que é um textfield ( txt ), o que é um botão ( cmd ) etc etc etc…

Mas acho interessante discutir isso, pelo menos esse é o tema do tópico: Legibilidade de Código.
Isso só pode ser alcançado em grande escala ( assim creio eu ) se todos os programadores tiverem a mesma mentalidade ( nesse momento me refiro a nomenclatura ) para programar.

Isso em codigos implementados por diversos desenvolvedores faz a GRANDE diferença.

Imagine um momento em que vc pegue uma variavel usuario.setText(“Nome”)

como saberia se ela é um label ou um tField sem consultar a declaração da variavel??

Eu acho bem mais complicado.

Mas vou ver se na convenção Java existe alguma coisa a respeito.
Depois posto a respeito.

Na realidade, TextPad!!!

To “fuçando” em IDE´s ( Eclipse / NetBeans ). Mas não me agrada muito a idéia.
Vou tentar me acostumar.

hehehehe

Quer dizer então que me enquadro no grupo de insanos?! hehehe