Boas práticas de programação( Resolvido )

38 respostas
L

Srs, tenho uma duvida em relação a uso de variáveis locais e nomes de campos. Exemplo.

No código abaixo dentro da minha classe eu estou usado as variáveis hour, minute, second. Dentro da classe SimpleTime tenho um construtor que possui três campos e estou utilizando os mesmos nomes das variáveis citadas anteriormente.

Minha duvida é: isso é uma prática de programação recomendada? Uma vez que estou utilizado e referenciando os campos com “this”. Ou nesse caso nem mesmo o uso do “this” é uma boa prática de programação? Obrigado.

public class This_Main
{
	public static void main( String[] args )
	{
		SimpleTime time = new SimpleTime( 15, 30, 19 );
		System.out.println( time.buildString() );
	
	}//End main	

}//End class


//Classe SimpleTime demostra a referência "this"
class SimpleTime
{
	private int hour;     // 0-23
	private int minute;  // 0-59 
	private int second; // 0-59
	
	  //Se o construtor utiliza nomes de parâmetros idênticos
	 //Nomes de váriaveis de instância a referência "this" será
	//Exigida para distinguir entre nomes
	public SimpleTime( int hour, int minute, int second )
	{
		this.hour   = hour;       //Configura a hora do objeto "this"
		this.minute = minute;    //Configura o minuto do objeto "this"
		this.second = second;   //Configura os segindos do objeto "this"
		
	}//End construtor SimpleTime
	
	//Usa "this" explícito e implícito para chamar toUniversalString
	public String buildString()
	{
		return String.format( "%24s: %s\n%24s: %s",
			"this.toUniversalString()", this.toUniversalString(),
			"toUniversalString()", toUniversalString() );
	
	}//End metodo buildString
	
	//Converte em String no formato d hora universal (HH:MM:SS)
	public String toUniversalString()
	{
		  //"this" não é requerido aqui para acessar variável de instância
		 //porque o método não tem variáveis locais com os mesmos
		//nomes das variáveis de instância
		return String.format( "%02d:%02d:%02d",
			this.hour, this.minute, this.second );		
	
	}//End do método toUniversalString			

}//End class SimpleTime

38 Respostas

x111

Na verdade está correto. O maior problema que existe ali são os comentários. Não existe comentário para fim de métodos e classes.

Outro problema que vejo é que você não verifica os dados na construção da classe SimpleTime, contudo como você está apreendendo, acredito que você ainda não tenha visto exceções para impedir que a classe seja criada com parâmetros inválidos.

L

x@ndy, boa tarde!

Quando você diz que está correto, quer dizer que é uma boa pratica usar nomes idênticos de variáveis e campos de um construtor, desde que o “This” seja empregado?
Obrigado pela dica quando ao comentário no final de cada método.

Abraço.

x111
  • ou - !

É uma boa pratica colocar nomes de variáveis que sejam significativos, sejam variáveis da classe, parâmetros de métodos ou variáveis locais. Você não deve encarar que deve repetir os mesmos nomes de variáveis das classes em métodos, você deve criar os nomes mais significativos para os métodos e para classe. Se esses nomes são iguais não existe problema!

L

Entendo. Obrigado pela ajuda.

CWeiler

Quero dar uns pitacos antes que o tópico seja fechado.

  1. Sim, é uma boa prática utilizar nomes de parâmetros idênticos aos nomes dos campos.

  2. Sim, é uma boa prática utilizar a referência this, independente do motivo.

Fora isso, também é uma boa prática adicionar prefixos aos campos, por exemplo:
this.mHour = hour;

Muitas vezes a forma com prefixo será considerada preferível a forma idêntica, mas de nenhuma forma isto é obrigatório, ambas são boas práticas.

L

CWeiler, boa noite!

Cara show de bola. Muito obrigado pelo retorno.

Hebert_Coelho
Honestamente nunca li algum material sobre o uso do "this" do código abaixo como boa prática:
public String toUniversalString()  
    {  
          //"this" não é requerido aqui para acessar variável de instância  
         //porque o método não tem variáveis locais com os mesmos  
        //nomes das variáveis de instância  
        return String.format( "%02d:%02d:%02d",  
            this.hour, this.minute, this.second );        
      
    }
O this é utilizado quando você recebe como parâmetro uma variável com o mesmo nome de um atributo da classe (por exemplo, no set ou contrutor).

No método acima (toUniversalString)... qual a utilidade do "this"? se vc retirar o código compila do mesmo modo, a linha ficará menor e mais fácil de ler.

Toda vez que faço code review eu arranco fora esse "this" desnecessário.

L

Caro Hebert Coelho, boa noite!

Meu objetivo não foi uma análise detalhada do código e sim do uso do comando “this” procurei usar em todas as partes possíveis no programa com objetivo de levantar essa discussão. Obrigado por responder com uma visão diferente dos demais, sem duvida seu comentário foi muito produtivo.

Abraço.

Hebert_Coelho

leandroendrix:
Caro Hebert Coelho, boa noite!

Meu objetivo não foi uma análise detalhada do código e sim do uso do comando “this” procurei usar em todas as partes possíveis no programa com objetivo de levantar essa discussão. Obrigado por responder com uma visão diferente dos demais, sem duvida seu comentário foi muito produtivo.

Abraço.


Opa, tudo bem?

Eu não quis criticar de forma a denegrir sua dúvida. Só quis mostrar que para esse tipo de método não tem sentido em utilizar o this.

Eu nunca li nada sobre o this ser utilizado como boa prática, apenas como um modo de diferenciar os atributos de nomes iguais. [=

L

Hebert Coelho, bom dia!

Não se preocupe. O importante que seu retorno trouxe muita credibilidade, eu estou pesquisando na net e e alguns livros e cheguei achar a seguinte resenha para comando “this” com esse cenário:

“Evite nomes de parâmetros ou variáveis locais nos métodos que conflitem com nomes de campos. Isso ajuda a evitar bugs sutis, difíceis d corrigir”. Não recomendamos essa prática.

Eu achei esse texto no livro Java como programar oitava edição. Está no capitulo 8 na seção 8.3 Controlado o acesso a membros.

Graças a sua crítica construtiva fui motivado a buscar tal resposta nos livros. Muito obrigado.

CWeiler

A obtenção de consenso em codificação e linguagens de programação é uma tentativa fútil.

Recomendações ou “boas práticas” são indicativos de caminhos bons a serem seguidos, mas de nenhuma forma querem dizer que sejam obrigatórios ou os únicos caminhos possíveis.

Então, sim, o uso da referência this é uma boa prática pois elimina qualquer possibilidade de ambiguidade de código e sim, o código sem a referência this irá compilar sem problema nenhum. Lembrando que a referência this será colocada pelo compilador, pois na realidade ela sempre existe (definição OO).

Assim como prefixos também são boas práticas pelo mesmo motivo: ambiguidade.

As ferramentas de trabalho também podem ajudar muito em resolução de ambiguidade em códigos, como a IDE Eclipse que possui forma de marcar com warning uma possível ambiguidade. Sendo assim, também, uma boa prática.

Hebert_Coelho

CWeiler:
A obtenção de consenso em codificação e linguagens de programação é uma tentativa fútil.

Recomendações ou “boas práticas” são indicativos de caminhos bons a serem seguidos, mas de nenhuma forma querem dizer que sejam obrigatórios ou os únicos caminhos possíveis.

Então, sim, o uso da referência this é uma boa prática pois elimina qualquer possibilidade de ambiguidade de código e sim, o código sem a referência this irá compilar sem problema nenhum. Lembrando que a referência this será colocada pelo compilador, pois na realidade ela sempre existe (definição OO).

Assim como prefixos também são boas práticas pelo mesmo motivo: ambiguidade.

As ferramentas de trabalho também podem ajudar muito em resolução de ambiguidade em códigos, como a IDE Eclipse que possui forma de marcar com warning uma possível ambiguidade. Sendo assim, também, uma boa prática.


Me ajude a esclarecer a situação abaixo, por favor. Qual a ambiguidade que o código abaixo apresenta para justificar o this como boa prática?

public String toUniversalString()    
       {    
             //"this" não é requerido aqui para acessar variável de instância    
            //porque o método não tem variáveis locais com os mesmos    
           //nomes das variáveis de instância    
           return String.format( "%02d:%02d:%02d",    
               this.hour, this.minute, this.second );          
           
       }
CWeiler

Herbert

Eu tentei ser o mais claro possível em minha exposição, não sei aonde você quer chegar mais tudo bem.

Você poderia me explicar em que momento eu me referi a algum trecho de código em especial? Então poderei tentar te ajudar a entender a sua dúvida.

Hebert_Coelho

CWeiler:
Herbert

Eu tentei ser o mais claro possível em minha exposição, não sei aonde você quer chegar mais tudo bem.

Você poderia me explicar em que momento eu me referi a algum trecho de código em especial? Então poderei tentar te ajudar a entender a sua dúvida.


Pelo que entendi de sua resposta, você afirma que em todo momento o this serve para retirar ambiguidade. É isso que eu queria esclarecer, onde no exemplo que eu destaquei estaria a ambiguidade.

CWeiler

Não, eu não afirmo que a referência this retira ambiguidade em todo momento. Peço para reler meus posts com calma e livre de pré-conceitos.

Eu exponho que:

Observe a palavra “possibilidade”, e antes disto eu declaro que:

Hebert_Coelho

Não, eu não afirmo que a referência this retira ambiguidade em todo momento. Peço para reler meus posts com calma e livre de pré-conceitos.

Eu exponho que:

Observe a palavra “possibilidade”, e antes disto eu declaro que:

Bem, não foi isso que eu e outras pessoas que comentaram seu post comigo entederam. Mas tudo bem, então está mais claro agora. [=

ViniGodoy

CWeiler:

2. Sim, é uma boa prática utilizar a referência this, independente do motivo.

Fora isso, também é uma boa prática adicionar prefixos aos campos, por exemplo:
this.mHour = hour;

Eu também gostaria de saber de onde surgiu o conceito de que essas são boas práticas. Vários livros de programação modernos, como o clean code, condenam esse tipo de prática. Prefixos tornaram-se bastante obsoletos com a evolução das IDEs e com a melhor modularização do código. Em algumas linguagens como o C++ (onde o prefixo “m” é comum, pois lá atributos são chamados de “variáveis membro”) ou o C# (onde é comum prefixar os atributos com _) os prefixos são necessários porque ou as convenções de código não são suficiente claras para distringuir algumas situações.

Por exemplo, no caso do C++, o nome da função pode ser usado para obter um ponteiro para essa função. Então, diferentemente do Java, não pode haver uma variável nome e uma função nome() na mesma classe.

Esse tipo de prefixação lembra a época da notação húngara, que gerou aquele código feio da API do Windows.

O único caso que recomendo prefixo é o caso do Swing, onde você tem muitos componentes se referindo a mesma coisa. Por exemplo, um nome pode ter um label (lblNome) e uma caixa de texto (txtNome) e as vezes até um checkbox associado (chkNome).

CWeiler

Cara, eu não entendo esta necessidade de trollagem de algumas pessoas.

Alguém vem aqui e faz uma pergunta objetiva e bem definida, alguém responde e aí começam a criticar uma resposta sem contra argumentar. Pior, fazem referências como se isto fosse a salvação do mundo. “Cara, vai lá no livro tal, tá tudo lá…”, pô, não quer ajudar não ajuda.

E isto ainda vem de um moderador. Vini, você me traz uma referência a um livro direcionado à código limpo e desenvolvimento ágil como justificativa de que uma recomendação é totalmente errada em qualquer situação e em qualquer código. Cara, o autor não perguntou sobre código limpo, a pergunta dele foi bem formulada, por favor, releia. E depois ainda divaga sobre ponteiro, referência, notação e prática antiquada??? Foco, por favor, foco.

Você quer uma referência de que o uso da referência this é uma boa prática? Faça um código qualquer, compile e decompile, procure os seus campos cuidadosamente criados sem o this.

Finalizando, que contrariar a prática, faça isso com clareza, e pontuação. Por exemplo:
“Em codificação ágil e desaconselhável o uso de prefixos em campos pois o controle de ambiguidade não justifica o custo desta prática.”

ViniGodoy

CWeiler:
Cara, eu não entendo esta necessidade de trollagem de algumas pessoas.

Alguém vem aqui e faz uma pergunta objetiva e bem definida, alguém responde e aí começam a criticar uma resposta sem contra argumentar. Pior, fazem referências como se isto fosse a salvação do mundo. “Cara, vai lá no livro tal, tá tudo lá…”, pô, não quer ajudar não ajuda.

E isto ainda vem de um moderador. Vini, você me traz uma referência a um livro direcionado à código limpo e desenvolvimento ágil como justificativa de que uma recomendação é totalmente errada em qualquer situação e em qualquer código. Cara, o autor não perguntou sobre código limpo, a pergunta dele foi bem formulada, por favor, releia. E depois ainda divaga sobre ponteiro, referência, notação e prática antiquada??? Foco, por favor, foco.

Você quer uma referência de que o uso da referência this é uma boa prática? Faça um código qualquer, compile e decompile, procure os seus campos cuidadosamente criados sem o this.

Finalizando, que contrariar a prática, faça isso com clareza, e pontuação. Por exemplo:
“Em codificação ágil e desaconselhável o uso de prefixos em campos pois o controle de ambiguidade não justifica o custo desta prática.”

Ei, calma lá. Ninguém está te trollando não.

Eu mostrei uma referência, como exemplo, mas posso citar outras (como o Core Java). Eu só queria conhecer suas referências e, pela sua resposta, aparentemente não tem nenhuma. Eu também não disse que sua forma era errada. Além disso, a pergunta original é sobre boas práticas de programação (veja o título), que é exatamente o que o livro que indiquei traz.

Eu disse só que queria saber onde se recomenda da forma que você colocou, e com que argumentos. E dei exemplo de onde, em outras linguagens, os prefixos são recomendados, por exemplo, e em que casos eu os utilizo.

Quanto a sua argumentação atual: O código descompilado com ou sem o this será exatamente igual. Afinal, se não está sendo usado para desambiguação, está se referenciando exatamente a mesma variável. Não existe oportunidade de otimização, ou qualquer outra coisa, por parte do compilador ao incluir o this.

Esse é um fórum de discussão. Se não estiver disposto a argumentar suas opiniões com algum embasamento técnico melhor do que “é boa prática porque estou dizendo que é”, é melhor não aparecer por aqui. Discussão envolve pessoas conversando sobre o assunto, apresentando seus argumentos, não só aceitando cegamente o que os outros dizem.

CWeiler

Trollagem: tumultuar um tópico de fórum.
Com certeza, você não consegue argumentar que uma recomendação não é boa prática e pergunta cadê a referência. Super construtiva a sua crítica, adicionou um ótimo ponto ao tópico do fórum. irônic mode on

Eu só queria conhecer suas referências e, pela sua resposta, aparentemente não tem nenhuma

Eu disse só que queria saber onde se recomenda da forma que você colocou, e com que argumentos

Não, eu não tenho nenhuma referência para demonstrar, e não vejo necessidade em sair catando nenhuma, a minha forma de programar não está em discussão aqui, até por que eu não utilizo prefixos ou a referência this em todos os meus códigos.
Eu não disse que o livro tal recomenda que se use tal forma. Eu não disse que tal forma é a única forma possível e imaginável de se programar. Eu não disse que não fazer de tal jeito é errado.
Eu apenas disse que, conforme perguntou o autor, o uso da referência this é uma boa prática, pois, argumento, remove possibilidades de ambiguidade, posso argumentar mais: torna o código mais didático, evita erros de principiantes, facilita depuração de leitura. Novamente, este não é o meu padrão de codificação e não digo que é o único jeito de codificar ou a melhor forma ou o padrão mais limpo e recomendável do mundo Java.
Eu sei, perfeitamente, que as ferramentas atuais permitem uma codificação com padrões mais limpos, conheço as boa práticas dos livro Clean Code, e, novamente, esta não é a pergunta do autor do tópico.

Você nem poderia dizer isso pois em nenhum momento digo qual é a minha forma de programar. Nós estamos em um tópico onde expus a minha opinião sobre um conceito e este conceito foi criticado sem contra argumentações, apenas críticas questionando “não pode ser uma boa prática pois não existe nenhum livro com a referência para tal afirmação”.

Ótimo, bons exemplos de prefixos. Mas este tópico é de Java, não entendo a correlação de outras linguagens no impacto na codificação em Java, isto é divagação, e, no meu entendimento, outra forma de tumultuar um tópico. Daqui a pouco estamos discutindo qual a melhor linguagem, pois evita uso de prefixos.

Por que o único embasamento técnico é aquele que está escrito em um livro? Por que minhas argumentações não são técnicas?

Este, com certeza, foi o melhor dos seus argumentos. A minha opinião é errada apenas por que não existe referência a algum livro, e não por que é errada devido aos fatos 1, 2 e 3. Novamente, peço, suplico, demonstre que isto não é uma boa prática com argumentos sobre a forma e não sobre a melhor prática.

Trabalhamos com lógica. O que você quer impor é que se boas práticas estão em livros, então, o que não está em livros não é boa prática. Você, assim como eu, sabe que esta lógica é falha.

Não, a minha argumentação, neste ponto, é que o this sempre existe, apenas isto. Paradigma OO. O compilador irá colocar o this, mesmo que ele não exista no código fonte, pois este é o paradigma.

ViniGodoy

Essas argumentações são técnicas:

Essa argumentação não é técnica, é puro mimimi:

A crítica era uma contra-argumentação. A referência é uma contra-argumentação. E é uma ajuda. Além de dizer que ficar colocando “this.” não é uma boa prática, estou explicando o porque e citando locais onde a pessoa pode se aprofundar na minha argumentação e ver outras boas práticas.

Novamente. Se você afirma alguma coisa, afirma com base em alguma coisa. Ou em uma referência, ou em sua experiência. Mas, só dizer que “é porque é” vai, com certeza, gerar questionamento. Se sua experiência demonstra o contrário do que a literatura indica, então, compartilhe-a, como você fez a contra-gosto quando eu insisti em te questionar.

Desculpe, mas discutir o argumento técnico central do tópico não é tumultuar o tópico. Ficar se doendo e chamando outros usuários de “trollers”, dizer que “não sabem ler”, que só “criticam sua resposta” e se portar feito uma criança mimada só por que foi contrariado, é.

A motivação em citar outras linguagens é explicar porque prefixos são criados em outras situações - mas não são justificáveis aqui. Práticas de código não são restritas a uma única linguagem. Não é incomum em discussões sobre práticas fazer comparações com outras linguagens.

Foi você quem sugeriu o prefixo “m” em variáveis privadas. Por que “m”, se em Java sequer existe o termo “função membro” ou “variável membro”? Foi esse “m” que me lembrou do C++. Ou seja, você mesmo, acabou sugerindo (talvez sem querer) uma prática de outra linguagem em Java.

Porque pressupõe que o autor do livro pesquisou muito antes de escrevê-lo. Especialmente no caso de livros que são consideradas referências importantes na área, como Clean Code, Design Patterns, Core Java, etc.

Mas veja. Você já tinha dado pouquíssimos argumentos quanto ao uso do this, tanto que não fui o único a questioná-lo.


Não, a minha argumentação, neste ponto, é que o this sempre existe, apenas isto. Paradigma OO. O compilador irá colocar o this, mesmo que ele não exista no código fonte, pois este é o paradigma.

O paradigma OO não descreve o uso de this, ele descreve conceitos mais abstratos.

O compilador também não precisa inserir this no código todo, pois para ele cada objeto é representado por um único identificador único. A prática de colocar this não está descrita como algo obrigatório no paradigma.

CWeiler

A minha primeira postagem neste tópico foi apenas uma opinião genérica, foi questionada, e já na segunda postagem coloquei a argumentação. Aonde está o mimimi? O mimimi veio depois de pessoas que não aceitam as opiniões dos outros e tentam desqualificar com falácias.

Fiz até questão de reler todas as postagens, não vi em nenhum momento você explicando o porquê da referência this não ser uma boa prática, reforço, existiu apenas questionamento da minha opinião.
Você faz uma argumentação que o uso de prefixos é obsoleto e mais adequado a outras linguagens.

Novamente, a minha argumentação está já na segunda postagem. Ou você não viu esta postagem ou você está agindo de má fé tentando desconstruir a discussão. Esse é o tipo de ação que não gosto de ver em meus debatedores.
Se você reler minha segunda postagem irá ver que:
1- Minha argumentação básica está lá;
2- Deixo clara minha opinião que existem outras formas, inclusive o uso de IDEs.
A suposição do “é por que é” não é minha.

Volto afirmar, você não sabe ler, e suas colocações apenas reafirmam isto, caso contrário apenas sobra a má fé. Se sou criança por defender meu ponto de vista contra falácias que seja.

Você tem certeza disso? Posso perguntar? Declaring Member Variables
Não uso prefixos, não posso afirmar qual a letra recomendada. Foi uma sugestão “sem querer”.

Novamente, não sabe ler:
“Por que o único embasamento técnico é aquele que está escrito em um livro?
Observe o ponto de interrogação e a palavra único.

Não ocorreu uma crítica construtiva sobre a idéia, o que ocorreu foi uma crítica sobre a minha postura de opinar sem possuir referência:

ViniGodoy

Só porque não concordo com você, não quer dizer que estou te ofendendo. Eu critiquei o fato de você ter feito uma afirmação “solta”, com base no único argumento que “evita ser ambíguo”, que o Herbert mesmo questionou pois, em muitas situações não haver qualquer ambiguidade. Também foi questionado o fato de que ele não viu lugar nenhum estimular as práticas que você comentou como boas, e nem eu vi. No entanto, eu já vi afirmarem categoriamente o contrário.

Eu fui realmente um pouco contundente ao dizer que o termo “variáveis membro” não existe em Java. Eu queria dizer que não é comum. A documentação original do Java é focada em programadores C++, então, não é de se estranhar que o termo apareça de vez em quando. De qualquer forma, a prefixação indicada não é comum em Java, e também fiquei curioso de onde tal boa prática teria surgido.

Desculpe, mas continuo discordando de você ao dizer que meus comentários não somam na discussão. Eu continuo achando que o uso do this é desnecessário, pois polui o código e não tem qualquer efeito prático - como afirma a literatura que citei.

A prefixação, então, nem se fala. Ainda mantenho o argumento de que as IDEs tornaram obsoletos, e cito como exemplo a aberração criada na notação húngara, que foi abandonada pelo próprio criador, a MS. Eu nem bati tanto na questão do this, mas dessa outra “boa prática” que você fez questão de citar e que nem foi perguntada pelo autor do tópico.

Essa opinião não serve para nada. É lógico que existem várias outras formas, por isso, existem algumas que são consideradas “boas práticas” e outras que não são. Se for só para citar uma forma que “existe” e é sintaticamente válida, então, pode-se citar qualquer coisa.

Quem afirmou que tais práticas eram boas, diferente do que propõe livros consagrados como Clean Code e Refactoring, foi você. Portanto, é você quem deve demonstrar os por quês. E, aí, vai o questionamento: Se essas são boas práticas, como você mesmo citou, por que não as utiliza? Pois ao meu ver, ao cita-las como “boas práticas”, você está induzindo o autor do tópico a usa-las. No entanto, você mesmo disse não ser partidário delas.

Novamente, não sabe ler:
“Por que o único embasamento técnico é aquele que está escrito em um livro?”
Observe o ponto de interrogação e a palavra único.

Isso sim, é o tipo de frase totalmente troller. Ao questionar a minha capacidade de leitura, você está questionando a minha inteligência. Mas o que esperar de alguém que já começou me chamando de troll na primeira postagem?

Lógico que notei que era uma pergunta, por isso te respondi. Sobre a palavra “único”, foi um pressuposto que você incluiu, pois ninguém no resto da discussão inteira afirmou que esse seria a única forma de embasamento. Mas é uma forma muito importante, como expliquei. Também expliquei ao final que não havia outros argumentos (citados ou não) que defendem-se seu ponto de vista. O único que você havia citado, havia sido questionado pelo Herbert, e eu estou concordando com ele ao te questionar também.

Se não vai citar ninguém e vai contrariar o que a literatura diz, como eu já falei, esteja preparado para defender seu ponto de vista com uma argumentação consistente.

CWeiler

Existem formas de se questionar, criticar, dar feedback. Essas não são as intenções extraídas dos questionamentos voltados genericamente ao pensamento do debatedor. A intenção extraída dos questionamentos é a desvalorização da opinião.

Agora o problema não é a falta de argumentação, mas sim que “apenas um” argumento não valida a tese.

Novamente na mesma tecla, eu já disse que não tenho referência outra da minha opinião baseada na minha experiência.

Então por favor, exponha os motivos da negação, pode até citar o livro, mas depois que citar o trecho do livro que fala isso. Então, poderemos discutir sobre cada ponto.

É um argumento válido, que vai de encontro ao meu argumento, que não deixa de ser um efeito prático. São pontos de vista. Já a poluição de código é relativa ao código limpo e isto é uma questão que você deve deixar clara.

O meu objetivo é justamente evitar estes tipos de discussão em cima de uma opinião, tentativa inútil.

Não uso pois tenho a minha prática de programação, isso não invalida a minha opinião. É desconstrução de pensamento.

Eu perguntei uma coisa e você respondeu outra totalmente diferente. Você me respondeu que livros possuem embasamento técnico, pesquisa e estudo em cima de uma teoria, coisa que concordo plenamente, mas não é o que eu perguntei.

ViniGodoy

CWeiler:

Agora o problema não é a falta de argumentação, mas sim que “apenas um” argumento não valida a tese.

E apresentar um único argumento já refutado, que discorda da literatura, e que não valida a tese, não é um problema de argumentação?!?!

CWeiler:

Novamente na mesma tecla, eu já disse que não tenho referência outra da minha opinião baseada na minha experiência.

Até então, você não havia citado de onde havia tirado o argumento.

O código limpo é uma boa prática de programação - que é o tema do tópico. É boa por diversos motivos, discutidos em diversos materiais citados. Eu estou de acordo com os materiais e práticas.

Se você considera a prática “boa prática”, ao ponto de desviar da pergunta do tópico para recomendá-la, soa muito estranho que não a use. Só estou apontando a contradição do seu argumento.

Você realmente quer ser tratado como uma criança incapaz de entender contexto? Devo realmente acreditar que você foi incapaz de entender onde minha resposta se encaixava na sua pergunta?

Nesse caso, a resposta que você queria era simplesmente um seco e sem maiores explicações: “Não é a única forma. Outras formas são válidas, desde que bem embasadas.”?

Superestimei sua inteligência é isso?

M

Acredito que o uso do this seja uma boa prática sim pois isso mostra que o atributo pertence a classe que o contem.

CWeiler

Cronologicamente:

A sua primeira manifestação neste tópico foi um questionamento do embasamento para uma opinião, sendo que o embasamento já estava presente no tópico através de uma argumentação. Este questionamento foi feito de forma inapropriada, tentando desacreditar o debatedor, pois não leva em consideração a argumentação já apresentada.

ViniGodoy 2º post:
Eu só queria conhecer suas referências e, pela sua resposta, aparentemente não tem nenhuma.

Eu disse só que queria saber onde se recomenda da forma que você colocou, e com que argumentos.

Se não estiver disposto a argumentar suas opiniões com algum embasamento técnico melhor do que “é boa prática porque estou dizendo que é”, é melhor não aparecer por aqui.

Depois, você afirma que o embasamento solicitado era uma referência bibliográfica, você dá a entender que o único embasamento que você aceita é uma referência bibliográfica, aonde eu refuto esta ideia. Quando leio jornais ou revistas semanais, a opinião dos jornalistas me é válida como forma de construção ou adequação do meu pensamento, jamais o raciocínio do jornalista será minha verdade, eu realizo a mesma construção de pensamento para livros técnicos, onde minha experiência também vale muito nas minhas opiniões.

ViniGodoy 3º post:
Novamente. Se você afirma alguma coisa, afirma com base em alguma coisa. Ou em uma referência, ou em sua experiência. Mas, só dizer que “é porque é” vai, com certeza, gerar questionamento. Se sua experiência demonstra o contrário do que a literatura indica, então, compartilhe-a, como você fez a contra-gosto quando eu insisti em te questionar.

Mas veja. Você já tinha dado pouquíssimos argumentos quanto ao uso do this, tanto que não fui o único a questioná-lo.

Então, vem a afirmação de que eu gerei o motivo do questionamento pois não tinha apresentado embasamento algum e deixei entender que, “é por que é”, sendo que o embasamento já estava apresentado. Neste mesmo trecho você diz que aceitaria algo de minha experiência mas até este momento você não havia mencionado a minha argumentação. E, pior, afirma que apenas argumentei após ser “contrariado insistentemente”.
Depois, afirma que apresentei pouquíssimos argumentos, mas, novamente, estes argumentos não foram questionados até aqui, o que foi questionado até aqui é a “falta de referência”, esta foi a sua primeira postagem onde você menciona que aceitaria meus argumentos baseados na minha experiência mas continua me criticando pela forma de apresentação e não realiza análise crítica sobre meus argumentos.

ViniGodoy 4º post:
Eu critiquei o fato de você ter feito uma afirmação “solta”, com base no único argumento que “evita ser ambíguo”, que o Herbert mesmo questionou pois, em muitas situações não haver qualquer ambiguidade. Também foi questionado o fato de que ele não viu lugar nenhum estimular as práticas que você comentou como boas, e nem eu vi. No entanto, eu já vi afirmarem categoriamente o contrário.

Quem afirmou que tais práticas eram boas, diferente do que propõe livros consagrados como Clean Code e Refactoring, foi você. Portanto, é você quem deve demonstrar os por quês. E, aí, vai o questionamento: Se essas são boas práticas, como você mesmo citou, por que não as utiliza? Pois ao meu ver, ao cita-las como “boas práticas”, você está induzindo o autor do tópico a usa-las. No entanto, você mesmo disse não ser partidário delas.

Novamente, você critica a minha forma de apresentar pois não possui referência bibliográfica (afirmação “solta”). A argumentação é inválida pelo simples fato de não possuir literatura.
Mencionar o questionamento do Herbert não valida as suas conclusões. Até antes da sua postagem acreditei que havia chegado em um consenso com o Herbert, ele pode vir aqui e dar continuidade ao debate.
Depois você descontrói meu pensamento me para colocar em contradição. Já que, se não uso a prática, então não sou partidário e sou contraditório. Usar ou não não tem nada a ver com a minha opinião, eu sou partidário da prática e nem por isso sou obrigado a segui-la.

ViniGodoy 5º post:
E apresentar um único argumento já refutado, que discorda da literatura, e que não valida a tese, não é um problema de argumentação?!?!

Até então, você não havia citado de onde havia tirado o argumento.

Agora minha argumentação volta a ser problemática pois foi refutada em literatura, e, eu não apresentei referência bibliográfica.

Vini, você faz um questionamento cíclico sobre a apresentação da opinião ser faltosa de referência bibliográfica.
Você diversa do questionamento do tópico para contradizer a minha forma de apresentação defendendo que o título do tópico é “Boas práticas em programação”, sendo que, apesar do título ser bem genérico, a pergunta do autor é focada e bem definida.
Você não se dispõe a emitir a sua opinião sobre a pergunta do autor e questiona a minha infeliz participação com os malditos prefixos, quando eu tinha a simples intenção de demonstrar outras formas de realizar o que o autor pretendia; se arrependimento matasse…
Se, você tivesse iniciado a sua participação com algo como “Discordo da opinião do Claudio, o uso do this deve ser evitado ao máximo e utilizado somente em casos de clara ambiguidade para que seu código seja limpo e claro, conforme as recomendações do Clean Code”, você teria sido construtivo, mas é muito mais fácil apenas criticar a opinião de alguém de forma destrutiva baseado na falta de bibliografia.

Considerando tudo isso, você realmente acha que não realizou trollagem? Você realmente acha que todo esse debate em volta de uma “forma de apresentação” foi construtivo para o tópico?

CWeiler

Você realmente quer ser tratado como uma criança incapaz de entender contexto? Devo realmente acreditar que você foi incapaz de entender onde minha resposta se encaixava na sua pergunta?

Nesse caso, a resposta que você queria era simplesmente um seco e sem maiores explicações: “Não é a única forma. Outras formas são válidas, desde que bem embasadas.”?

Superestimei sua inteligência é isso?
Eu já afirmei que sou uma criança, não tenho problemas com isso, então, por favor me trate como tal.

A sua resposta anterior, de forma alguma encaixa na minha pergunta, pode levantar o contexto que você quiser. “Não é a única forma. Outras formas são válidas, desde que bem embasadas.” esta resposta sim, responde a minha pergunta.

A

Na minha opinião, só se deve usar algo “a mais” se se justificar e não causar distúrbios.

No caso, o uso do “this” só se justifica para desambiguação. O uso do “this”, quando desnecessário, vai causar uma análise adicional quando o código estiver sendo mantido, claro que num código com dezenas de linhas, se tiver um “this.x” no final, vai ser necessário verificar se existe um “x” local para justificar o uso do “this”. Isso não pode ser considerado uma boa prática.

CWeiler

Gusukuma, eu acredito que é mais correto afirmar que o não uso da referência this é uma algo “a menos”, pois, a referência sempre está lá, apenas é possível omiti-la no código fonte.

Particularmente:
Discordo e concordo com você quanto a causar uma análise adicional, pois isto é uma questão muito pessoal. No meu caso, enquanto sou extremista com outros pontos (como identação por exemplo) e saio varrendo o código corrigindo ou configuro a IDE para corrigir automaticamente, no caso de um código com this.x eu não daria a menor bola mas acredito que outros desenvolvedores fariam como você falou.

Profissionalmente:
Quanto a não ser uma boa prática, pois “força” os desenvolvedores a uma análise do código, o desenvolvedor precisa analisar o código, e, uma visão direta do escopo da variável apenas reduz o conjunto de análise. Nossa equipe é adepta do encapsulamento (métodos get/set), assim, quando vejo um this.x fora do encapsulamento sei que foi um erro de convenção e apenas corrijo, o que o acesso direto ao x não me mostraria “tão diretamente”.
Falando especificamente de uma equipe, acho muito mais importante a existência de uma convenção acordada e que todos a sigam, do que se o conteúdo da convenção é uma coleção perfeita de ótimas práticas.

A

CWeiler:
Gusukuma, eu acredito que é mais correto afirmar que o não uso da referência this é uma algo “a menos”, pois, a referência sempre está lá, apenas é possível omiti-la no código fonte.

Particularmente:
Discordo e concordo com você quanto a causar uma análise adicional, pois isto é uma questão muito pessoal. No meu caso, enquanto sou extremista com outros pontos (como identação por exemplo) e saio varrendo o código corrigindo ou configuro a IDE para corrigir automaticamente, no caso de um código com this.x eu não daria a menor bola mas acredito que outros desenvolvedores fariam como você falou.

Profissionalmente:
Quanto a não ser uma boa prática, pois “força” os desenvolvedores a uma análise do código, o desenvolvedor precisa analisar o código, e, uma visão direta do escopo da variável apenas reduz o conjunto de análise. Nossa equipe é adepta do encapsulamento (métodos get/set), assim, quando vejo um this.x fora do encapsulamento sei que foi um erro de convenção e apenas corrijo, o que o acesso direto ao x não me mostraria “tão diretamente”.
Falando especificamente de uma equipe, acho muito mais importante a existência de uma convenção acordada e que todos a sigam, do que se o conteúdo da convenção é uma coleção perfeita de ótimas práticas.

Imagine você mantendo diversas classes e centenas de métodos, se o uso do “this” for somente quando necessário, faz muita diferença.
Quanto à análise do código, isso gera uma distração e é irritante. Não vai ajudar e ainda pode prejudicar, não é nada bom.
Outra coisa, “boas práticas” ultrapassam os limites de uma equipe, alcançam a comunidade.

CWeiler

Gusukuma,

Sim, isto é um ponto pacífico, não discordamos e eu não mencionei o contrário.

Como mencionei, é uma visão pessoal, para mim não é nada irritante, teremos pessoas de ambos os lados da linha.
Quanto a ajudar ou não, ainda acredito que esta prática ajuda, tanto em iniciantes na linguagem, assim como em desenvolvimento em equipe. Não vi, ainda, argumento efetivo para que reconsidere minha opinião.

Quanto a o que são “boas práticas” não quero retornar nessa discussão, podemos abrir outro tópico sobre isso, solicito o foco quanto a prática em questão neste tópico.

A

CWeiler:
Gusukuma, corrigi minha postagem anterior para um melhor entendimento, se possível atualize o seu quote.

Sim, isto é um ponto pacífico, não discordamos e eu não mencionei o contrário.

Como mencionei, é uma visão pessoal, para mim não é nada irritante, teremos pessoas de ambos os lados da linha.
Quanto a ajudar ou não, ainda acredito que esta prática ajuda, tanto em iniciantes na linguagem, assim como em desenvolvimento em equipe. Não vi, ainda, argumento efetivo para que reconsidere minha opinião.

Quanto a o que são “boas práticas” não quero retornar nessa discussão, podemos abrir outro tópico sobre isso, solicito o foco quanto a prática em questão neste tópico.

Corrigido.

Não entendi. Você concorda com minha colocação, e em seguida discorda. Veja que estou me referindo ao mesmo fato: o uso desnecessário do “this”. Para mim, se usou o “this” foi por um motivo (necessário), se usou sem motivo, vai causar uma preocupação desnecessária (e se for repetitivo, vai irritar, desviar a atenção) e isso me basta para não recomendar esse uso.

CWeiler

Gusukuma, eu não preciso discordar totalmente de você apenas para provar minha opinião.

Concordo que evitar o uso da referência this é uma boa prática. Meu ponto é que A não exclui B.

A

CWeiler:
Gusukuma, eu não preciso discordar totalmente de você apenas para provar minha opinião.

Concordo que evitar o uso da referência this é uma boa prática. Meu ponto é que A não exclui B.


Claro.
O meu ponto é: se encontrar uma (boa) justificativa para não usar (ou para usar), é suficiente. Desde, é claro, que não tenha outras considerações.
O meu ponto de vista é no uso geral, não apenas em uma empresa (que é obviamente um ambiente mais controlável por normas internas).

CWeiler

Gusukuma, desculpe, agora fui eu quem não entendeu…

Você fez uma crítica a algum afirmação minha?

A

CWeiler:
Gusukuma, desculpe, agora fui eu quem não entendeu…

Você fez uma crítica a algum afirmação minha?


Não, estou colocando como eu avalio uma prática em programação.

lucasvvasconcelos

é como falar de colocar Modificadores de acesso em tudo…

Criado 7 de julho de 2014
Ultima resposta 18 de jul. de 2014
Respostas 38
Participantes 8