O uso excessivo de `this` em C ++ [duplicado]

StackOverflow https://stackoverflow.com/questions/1057425

  •  21-08-2019
  •  | 
  •  
Foi útil?

Solução

A sua versão é um pouco mais limpo, mas enquanto você está nisso, eu o faria:

  1. Evite líder sublinhado: _x é ok até que alguém escolhe _MyField que é um nome reservado. Um sublinhado inicial seguido por uma letra maiúscula não é permitido como um nome de variável. Veja: Quais são as regras sobre o uso de um sublinhado em um identificador C ++
  2. Faça o atributo privada ou protegida:. A mudança é seguro se ele compila, e você vai garantir a sua setter será usado
  3. A história this-> tem um uso, por exemplo, no código templated para fazer o nome do campo dependente do seu tipo (pode resolver alguns problemas de pesquisa).

Um pequeno exemplo de resolução de nome que são fixadas por meio de um esta- explícito> (testado com g ++ 3.4.3): 

#include <iostream>
#include <ostream>

class A
{
public:
  int g_;
  A() : g_(1) {}
  const char* f() { return __FUNCTION__; }
};

const char* f() { return __FUNCTION__; }
int g_ = -1;

template < typename Base >
struct Derived : public Base
{
  void print_conflicts()
  {
    std::cout << f() << std::endl; // Calls ::f()
    std::cout << this->f() << std::endl; // Calls A::f()
    std::cout << g_ << std::endl; // Prints global g_
    std::cout << this->g_ << std::endl; // Prints A::g_
  }
};

int main(int argc, char* argv[])
{
   Derived< A >().print_conflicts();
   return EXIT_SUCCESS;
}

Outras dicas

nomenclatura campo não tem nada a ver com um codesmell. Como Neil disse, a visibilidade campo é a única codesmell aqui.

Existem vários artigos sobre convenções de nomenclatura em C ++:

etc.

Esse uso de 'isto' é incentivado pela Microsoft C padrões de codificação #. Ele dá uma clareza de código bom, e se destina a ser um padrão sobre o uso de m_ ou _ ou qualquer outra coisa em variáveis ??de membro.

Honestamente, eu realmente não gosto de sublinhado em nomes de qualquer maneira, eu usado para prefixar todos os meus membros por uma única 'm'.

Um monte de pessoas usam isso porque em sua IDE ele vai fazer uma lista de identificadores de classe atual pop-up.

Eu sei que eu faço no BCB.

Eu acho que o exemplo que você fornecer com o conflito de nomes é uma exceção. Em Delphi, porém, diretrizes de estilo usar um prefixo (geralmente "a") para os parâmetros para evitar exatamente isso.

Meu sentimento pessoal é que lutando uma convenção de codificação existente é algo que você não deve fazer. Como coloca Sutter / Alexandrescu-lo em seu livro 'C ++ convenções de codificação': não suar as pequenas coisas. Qualquer um é capaz de ler a uma ou a outra, se há um líder 'this->' ou '_' ou o que quer.

No entanto, a consistência em convenções de nomenclatura é algo que você normalmente deseja fazer, de modo que adere a uma convenção em algum escopo (no escopo do arquivo menos, idealmente toda a base de código, é claro) é considerada uma boa prática. Você mencionou que este estilo é usado em toda a base de código maior, então eu acho que a adaptação outra convenção seria sim uma má idéia.

Se você, afinal de contas, achar que há uma boa razão para mudá-lo, não fazê-lo manualmente. Na melhor das hipóteses, seu IDE suporta este tipo de 'refatorações'. Caso contrário, escrever um script para mudá-la. Pesquisar e substituir deve ser a última opção. Em qualquer caso, você deve ter uma cópia de segurança (controle de origem) e algum tipo de facilidade de teste automatizado. Caso contrário, você não vai se divertir com ele.

Usando 'this' dessa maneira não é IMO um cheiro de código, mas é simplesmente uma preferência pessoal. Por conseguinte, não é tão importante quanto a consistência com o resto do código no sistema. Se este código é inconsistente você pode alterá-lo para coincidir com o outro código. Se, alterando-o você vai apresentar inconsistência com a maioria do resto do código, que é muito ruim e eu gostaria de deixá-lo sozinho.

Você não quer nunca ficar em uma posição de jogar ténis de código onde alguém muda algo puramente para fazer parecer "bom" apenas para alguém para vir mais tarde com diferentes gostos que então muda-lo de volta.

Eu sempre usar o m _ convenção de nomenclatura. Embora eu não gosto "notação húngara" em geral, acho que é muito útil para ver muito claramente se eu estou trabalhando com dados membro da classe. Além disso, eu encontrei com 2 nomes de variáveis ??idênticas no mesmo escopo muito propenso a erros.

Eu concordo. Eu não gosto disso convenção de nomenclatura - Eu prefiro aquele em que há uma distinção clara entre variáveis ??de membro e variáveis ??locais. O que acontece se você deixar de fora o this? 


class MyClass{
public:  
  int x;  
  void f(int xval);
};
//
void MyClass::f(int xval){  
  x = xval;
}

Na minha opinião este tende a adicionar confusão para o código, por isso tendem a usar diferentes nomes de variáveis ??(dependendo da convenção, pode ser um sublinhado, m _ , qualquer que seja). 

class MyClass
{
public:
  int m_x;
  void f(int p_x);
};


void MyClass::f(int p_x)
{
  m_x = p_x;
}

... é a minha maneira preferida usando prefixos de escopo. m_ para membro, p_ para o parâmetro (alguns a_ uso para o argumento em vez), g_ for global e às vezes l_ para local, se ele ajuda a legibilidade.

Se você tem duas variáveis ??que merecem o mesmo nome, então isso pode ajudar muito e evita ter que inventar alguma variação aleatória sobre o seu significado apenas para redefinição evitar. Ou, pior ainda, o temido 'x2, x3, x4, etc' ...

É mais normal em C ++ para os membros para ser inicializado em construção utilizando initialiser.

Para fazer isso, você tem que usar um nome diferente para o nome da variável de membro.

Assim, mesmo que eu usaria Foo(int x) { this.x = x; } em Java, eu não iria em C ++.

O cheiro real pode ser a falta de uso de initialisers e métodos que fazer nada além de mutação variáveis ??de membro, ao invés do uso do próprio this -> x.

Alguém sabe por que é prática universal em cada C ++ compras Eu estive em usar nomes diferentes para argumentos do construtor para as variáveis ??de membro ao usar com initialisers? estavam lá alguns compiladores C ++ que não apoiá-lo?

Hoje, a maioria dos editores IDE colorir suas variáveis ??para indicar os membros da classe de variáveis ??locais. Assim, IMO, nem os prefixos ou 'this->' deve ser exigido para facilitar a leitura.

Eu não gosto de usar "this" porque é atávica. Se você está programando em boa C de idade (lembre-C?), E você quer alguma mímica das características do OOP, você cria uma estrutura com vários membros (estes são análogas às propriedades do seu objeto) e você criar um conjunto de funções que todos tenham um ponteiro para essa estrutura como seu primeiro argumento (estes são análogos aos métodos de que objecto).

(acho que esta sintaxe typedef é correto, mas ele tem sido um tempo ...) 

typedef struct _myclass
{
   int _x;
} MyClass;

void f(MyClass this, int x)
{
   this->_x = x;
}

Na verdade eu acredito mais velhos compiladores C ++ seria realmente compilar o código para o formulário acima e em seguida, basta passá-lo para o compilador C. Em outras palavras - C ++, até certo ponto era apenas açúcar sintático. Então, eu não sei por que alguém iria querer programa em C ++ e voltar para explicitamente usando "isto" no código - talvez é "Nutrisweet sintática"

Se você tem um problema com as convenções de nomenclatura que você pode tentar usar algo como o folowing. 

class tea
{
public:
    int cup;
    int spoon;
    tea(int cups, int spoons);
};

ou 

class tea
{
public:
    int cup;
    int spoon;
    tea(int drink, int sugar);
};

Eu acho que você teve a idéia. É basicamente a nomeação de variáveis ??diferentes, mas "mesmo" no sentido lógico. Espero que ajude.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top