É necessário adicionar o caso padrão ao usar casos de opção?

Durante uma recente revisão de código, fui solicitado a colocar defaultcasos em todos os arquivos onde quer que o switchbloco seja usado, mesmo que não haja nada para fazer default. Isso significa que eu tenho que colocar o defaultcaso e não escrever nada nele.

Esta é a coisa certa a fazer? Que finalidade isso serviria?

Parece que existem três casos em que uma defaultdeclaração não é necessária:

1. não restam outros casos, porque há um conjunto limitado de valores que inserem o switch case. Mas isso pode mudar com o tempo (intencionalmente ou acidentalmente), e seria bom ter um default casese algo mudar _ você pode registrar ou avisar o usuário sobre um valor errado.

2. você sabe como e onde o valor switch caseserá usado e quais valores entrarão nele. Novamente, isso pode mudar e pode ser necessário um processamento extra.

3. outros casos não precisam de nenhum processamento especial. Se for esse o caso, acho que você deve adicionar um default case, porque é um estilo de codificação aceito e torna seu código mais legível.

Os dois primeiros casos são baseados em suposições. Então (supondo que você trabalhe em uma equipe não tão pequena, pois você tem revisões regulares de código), não pode se dar ao luxo de fazer essas suposições. Você não sabe quem trabalhará com seu código ou fará chamadas para funções / métodos de chamada em seu código. Da mesma forma, pode ser necessário trabalhar com o código de outra pessoa. Ter o mesmo estilo de codificação tornará mais fácil lidar com o código de alguém (incluindo o seu).

Esta é a coisa certa a fazer? Que finalidade isso serviria?

Não é incomum que os padrões de codificação da empresa exijam um caso padrão para todas as switchdeclarações. Uma razão para isso é que facilita para os leitores encontrar o fim do switch. Outra razão, provavelmente melhor, é que isso faz você pensar por um segundo sobre o que seu código deve fazer quando a condição não corresponde às suas expectativas. Independentemente do motivo do requisito, se for um padrão da empresa, você deve segui-lo, a menos que haja um motivo hermético para não fazê-lo.

Se você acredita que switchinclui casos para todas as condições possíveis, uma boa coisa a fazer é colocar uma assertdeclaração no caso padrão. Dessa forma, quando alguém altera o código e adiciona inadvertidamente uma condição que a sua switchnão cobre, eles acessam asserte percebem que precisam endereçar essa parte do código.

Se você switchcobrir apenas algumas das condições possíveis, mas nada de especial for necessário para as outras, você poderá deixar o caso padrão em branco. É uma boa ideia adicionar um comentário nesse caso para indicar que o caso padrão está intencionalmente vazio porque as condições que o atingem não precisam de nenhum trabalho a ser feito.

Se você "ativar" o tipo de enumeração pura, é perigoso ter um fallback padrão. Quando você adiciona valores posteriormente ao tipo de enumeração, o compilador destacará opções com novos valores não cobertos. Se você tiver uma cláusula padrão, o compilador permanecerá silencioso e você poderá perdê-la.

Em muitos aspectos, esta pergunta é o mesmo que o pedido frequentemente que preciso de uma elsecláusula no final de um if/ else ifescada que cobre todas as opções .

A resposta é, sintaticamente falando, não, você não. Mas há um porém ...

Uma defaultcláusula pode estar lá por (pelo menos) dois motivos:

1. Como manipulador de erros - com certeza, nunca deve chegar aqui! é uma reivindicação que pode ser feita, mas e se acontecer? A corrupção de dados ou, pior ainda, a validação de dados não é uma rota para a falha do programa, se não for capturado adequadamente. Nesse caso, não deve ser uma cláusula vazia!
2. Cobertura de Design / Código - mesmo na forma mais simples de um fluxograma, existem duas rotas a partir de uma instrução if, e sempre a otherwisepartir de um caso. Não há razão alguma para não incluí-las no código fonte.

Minha filosofia é sempre bastante simples - avalie o pior cenário das duas opções e opte pelo mais seguro. No caso de uma cláusula vazia elseou default, as piores opções são:

• Inclua-os: três ou quatro linhas extras de código "redundante".
• Não os inclua: Dados não autorizados ou uma condição inesperada não ficam presos, potencialmente causando falha no programa.

Dramático demais? Talvez ... mas então meu software tem o potencial de matar pessoas se der errado. Prefiro não correr esse risco.

Como um aparte, as diretrizes da MISRA-C {ver perfil para afiliação} recomendam uma defaultcláusula para cadaswitch

O Java não força você a ter uma declaração 'padrão', mas é uma boa prática ter uma o tempo todo, mesmo que o código nunca possa ser alcançado (agora). Aqui estão alguns motivos:

Por ter uma cláusula padrão inacessível, você mostra ao leitor do seu código que você considerou os valores e sabe o que está fazendo. Você também permite alterações futuras, digamos, por exemplo: um novo valor de enum é adicionado, o comutador não deve ignorar silenciosamente o novo valor; você pode lançar uma exceção lá ou fazer outra coisa.

Para capturar um valor inesperado (caso você não esteja ativando uma enumeração) que é passado - pode ser maior ou menor do que o esperado, por exemplo.

Para lidar com ações 'padrão' - onde os comutadores são para comportamento especial. Por exemplo, uma variável pode ser declarada fora do comutador, mas não inicializada e cada caso a inicializa para algo diferente. O padrão, nesse caso, pode inicializá-lo para um valor padrão, para que o código imediatamente após a alternância não erro / lance uma exceção.

Mesmo que você decida não colocar nada no padrão (sem exceções, registros etc.), mesmo um comentário para dizer que você considerou o fato de que o padrão nunca ocorrerá pode ajudar na legibilidade do seu código; mas isso se resume à preferência pessoal.

Eu também acrescentaria que isso depende da filosofia do idioma que você está usando. Em Erlang, por exemplo, onde é uma abordagem comum "deixar travar", você não definiria um caso padrão, mas deixaria sua casedeclaração gerar um erro se ocorrer uma situação que não foi atendida.

Você deve sempre ter um padrão, a menos que tenha provada e permanentemente coberto todos os casos. Não custa nada, e é seguro contra falhas em manter sua declaração de troca em um programa em evolução.

Se você realmente tem certeza de que não se importa com nenhum outro caso, o padrão: break; // não se importa, mas o padrão padrão deve ser algo como o padrão: throw new Error ("valor inesperado");

Da mesma forma, você nunca deve "mostrar" uma construção de caso não trivial sem adicionar um comentário ao efeito que pretende mostrar. O Java errou este no estágio de design.

Considerar

enum Gender
{
       MALE ,
       FEMALE ;
}

e

void run ( Gender g )
{
      switch ( g )
      {
           case MALE :
                 // code related to males
                 break ;
           default :
                 assert Gender . FEMALE . equals ( g ) ;
                 // code related to females
                 break ;
      }
}

Eu diria que isso é superior a ter um caso MALE, um caso FEMALE e um caso padrão que gera uma exceção.

Durante a fase de teste, o computador verificará se g é FÊMEA. Durante a produção, a verificação será omitida. (Sim, uma micro otimização!)

Mais importante, você manterá sua meta de 100% de cobertura de código. Se você escreveu um caso padrão que lança uma exceção, como você a testaria?