É melhor usar "get" como prefixo para getters?

8

se eu tivesse uma propriedade booleana, shouldAutoLoginé melhor nomear o getter getShouldAutoLoginou apenas shouldAutoLoginpara que fique mais parecido com o inglês?

ex:

if(shouldAutoLogin){
    ...
}

ou

if(getShouldAutoLogin){
    ...
}

readability clean-code

— Mike Bryant
fonte

A propriedade é chamada 'shouldAutoLogin'? A reflexão em alguns idiomas (por exemplo, estruturas jsp) espera que isso ${foo.something}seja traduzido para foo.getSomething()os bastidores.

Essa parece ser a norma. Para valores booleanos, no entanto, também é comum usar em isFoo()vez de getFoo(). No seu exemplo, isso seriaisAutoLogin()

— rath

Se você deseja acessar qualquer uma dessas classes a partir de um jsp, é praticamente necessário.

— 21413 Jaydee

@jmoreno enquanto eu (e outros) têm mencionado Java, não é claro que o OP está falando dele (se alguma coisa, dada a escolha de expressões dentro de if()que é improvável que isso é Java.

7

As convenções de nomeação do MikeBryant são específicas do idioma.

— CodesInChaos

9

A convenção de nomenclatura para getters é normalmente,

getAutoLogin() se estiver recebendo alguma string ou objeto.

isAutoLogin() para booleano.

— JNL
fonte

11

Esta é uma convenção de nomenclatura para java, que faz parte do JavaBeans . Para c #, você declara os nomes das propriedades sem nenhum prefixo como get / set / is.

— K3b

@ k3b Obrigado pela informação. Sou desenvolvedor Java. :) Mas é bom saber sobre a convenção C # também. Obrigado

— JNL

2

Esta pergunta é sobre getters / setters, não propriedades. Eu pensei que getters e setters em C # geralmente começam por get * ou set * também (veja, por exemplo, stackoverflow.com/questions/16718772/… ).

— sergut

1

@sergut: Verdade, mas se os métodos getter / setter forem rápidos e idempotentes, normalmente se preferiria propriedades ao invés dos métodos getter e setter. Se eles não são idempotentes, os prefixos get e set provavelmente são enganosos. Se não forem rápidos, os prefixos get e set provavelmente deverão ser substituídos por prefixos que tornam mais óbvios os custos (por exemplo, use "generateFrob" em vez de "getFrob").

— 28713 Brian

@ Brian Eu estava procurando mais esclarecimentos. A maneira como eu vi getters e setter eram APENAS para obter os dados privados e definir os dados. No comentário anterior, quando você deu um exemplo de calcularFrob (), isso seria mais como uma operação / cálculo a ser feito nos dados particulares. Esse cálculo também pode ser temporário e talvez não seja necessário definir os dados particulares. Espero que você esteja entendendo o que estou tentando dizer aqui.

— JNL

3

Tradicionalmente, os getters são prefixados com getou ispara o valor. Isso é frequentemente mencionado nos guias de estilo java. Por exemplo, o Java Programming Style Guide (este é apenas um exemplo).

A convenção para esses nomes de métodos é ocasionalmente aplicada em ferramentas que usam reflexão ou esperam determinados estilos de código. Por exemplo, novamente em Java (apesar da Expression Language do JSP), ${foo.bar}será traduzido para a chamada foo.getBar()quando o jsp for compilado. O getValue()é aplicado dessa maneira para que se torne mais do que apenas uma convenção.

Como mencionado, os exemplos acima são de Java. Esta é uma convenção para Java . Outros idiomas têm outras convenções que devem ser analisadas e provavelmente seguidas também. Alguns idiomas usam propriedades (e podem fazer outras coisas legais com eles, como copiar a pedido ou somente leitura).

Examine os guias de estilo para sua escolha de idioma específico. Provavelmente, é uma boa idéia segui-los sempre que possível, para que outros codificadores, ao ler seu código, possam entrar mais rapidamente no código sem tentar descobrir seu estilo pessoal.

2

Nomear um método de uma maneira inteligível e legível tem vantagens. Nomear métodos para que sua intenção e natureza sejam fáceis de derivar do nome ("getters têm prefixo get, predicados booleanos is") também possui vantagens.

Cabe a você encontrar um equilíbrio, mas em um grande projeto os benefícios da consistência geralmente superam os da esperteza acidental.

Renomear um método para tornar o nome legível e conforme a convenção é um bom exercício diário. No seu caso particular, eu consideraria algo como isAutoLoginEnabledou getAutoLoginFlag.

OTOH, você tem vários métodos conceitualmente semelhantes, dos quais todos podem seguir o padrão shouldDoSomething; seu nome original também pode ser bom.

— 9000
fonte

Eu gosto da acrescentado "Enabled" para o getter, melhora significativamente a legibilidade acho

— Mike Bryant

1

Eu sempre acho que o código deve ser o mais legível possível. Ajuda a definir claramente as intenções do código. No seu caso, pense sobre quais seriam os usos positivos e negativos do seu booleano e como isso afetaria a legibilidade e as intenções de sua lógica.

if(!shouldAutoLogin)
{
     ....
}

versus

if(!getShouldAutoLogin)
{
    ....
}

O que dá um significado mais claro à intenção do que o código está tentando fazer?

Como outros sugeriram, eu até renomearia a variável para

isShouldAutoLogin

ou similar

— Gibson
fonte

0

Costumo escrever getAutoLoginquando quero o método para returnum tipo de dados, como um intou um String. No entanto, se eu quiser verificar se é trueou false( boolean), simplesmente troquei getpara um iscomo este: getAutoLogin> isAutoLogin. Acredito que exista uma convenção de nomenclatura para cada idioma.

— Científico
fonte