Concordo com a resposta de Darien, mas queria adicionar um ponto de vista de uma perspectiva de programadores C #.
Quando vejo código que diz "setXXX" eu leio isso para dizer que ele está definindo um valor em uma coisa, eu não espero que isso tenha efeitos colaterais naquela coisa além de definir esse valor, e eu espero que isso para ser idempotente (ou seja, eu posso continuar configurando com o mesmo valor e está tudo bem). É como acessar um campo. Geralmente eu também esperaria ver um método 'getXXX' junto com um 'setXXX'.
Eu não sei se isso é o que você espera em Java e C ++, mas é isso que eu esperaria em C #, embora em C # há uma mão curta para este chamado Propriedades. E aqui estão algumas boas orientações sobre como usar as Propriedades ( link ).
Dada essa visão, a interface que escolheria depende apenas se houver efeitos colaterais (além de alterar o valor desse campo):
Se a ação tiver efeitos colaterais, por exemplo, se estiver mostrando uma caixa de diálogo, eu usarei "Show ()" e "Hide ()".
Se não houver efeitos colaterais, digamos que estou definindo a visibilidade de um "widget" e algo mais renderiza esse widget dependendo do estado, use o setVisibility ou o setIsVisible. (Eu não chamaria isso de SetVisible).
Em C # (não tenho certeza sobre Java), é muito comum adotar um padrão de observador, onde uma estrutura de UI irá escutar alterações nos objetos e automaticamente renderizar novamente a UI quando uma propriedade como Visibility for alterada. Isso significa que definir o valor chamando setIsVisible aparece como se tivesse efeitos colaterais, mas na minha definição isso não acontece. O contrato do widget é cumprido configurando seu valor de campo representando "IsVisible".
Por outras palavras, não há problema em alterar a visibilidade de um marcador em um formulário antes que o formulário seja exibido. Ou seja, label.getIsVisible == true, mas o formulário não é mostrado.
Não há problema em chamar o Hide () quando o formulário não está sendo exibido.