Só pra complementar a outra resposta (que já deu a solução mais sucinta que posso pensar, mas acho que vale o complemento):
Por que o ano é um array contendo uma string? Tem algum requisito/condição para isso?
De qualquer forma, isso só funcionou porque o JavaScript tem algumas "mágicas" que acontecem por debaixo dos panos. Se vc tenta usar qualquer objeto em um contexto numérico, primeiro ele é convertido para número. As regras - bem complicadas, por sinal - estão descritas na especificação da linguagem.
Mas de forma bem resumida, um array primeiro é convertido para "primitivo", que no caso gera uma string contendo seus elementos separados por vírgula. Então quando o array só tem um elemento e este é uma string, o resultado é esta string, que depois é convertida para número. Por isso "funciona". Mas se eu passar um array com dois elementos, ou qualquer outra coisa (como a string "xyz"), não funciona mais.
Enfim, não ficou claro se a ideia era também validar o ano antes de calcular o século. Se não for, então a solução do Maniero é a mais simples e direto ao ponto. Mas se tiver que validar, poderia ser:
function getCentury(year) {
return Math.ceil(parseInt(year) / 100);
}
let year = ["1900"];
let century = getCentury(year);
if (isNaN(century)) {
console.log('Ano inválido, não foi possível obter o século');
} else {
console.log(century);
}
Agora se eu passar algo como "xyz"
, vai indicar que o ano é inválido.
Se bem que, caso year
seja um número, não tem porque converter, então para ser mais preciosista, poderia ser:
function getCentury(year) {
if (typeof year !== 'number')
year = parseInt(year);
return Math.ceil(year / 100);
}
Claro, também poderia verificar dentro da função, mas aí ela teria que retornar algo para indicar que deu erro, e quem a chamou precisaria verificar isso. É outra alternativa, mas o "melhor" depende de cada caso, dos requisitos e outras informações que não temos. Por ora, deixemos assim mesmo.
Ou então vc só tenta fazer o cálculo direto mesmo, e deixa para as regras de coerção da linguagem converterem. Eu particularmente não gosto, pois prefiro deixar claro o que a operação espera - ao usar parseInt
, por exemplo, sinalizo que deve ser um número inteiro. "Vai ficar com menos linhas" não é uma boa justificativa para retirar uma validação (ou qualquer outra coisa que deixe o código mais claro e semântico).
E reforçando o que foi dito sobre ponto-e-vírgula no final das linhas: pode parecer "frescura", e sei que o JavaScript "aceita" o código sem ponto e vírgula e "funciona", mas isso evita algumas situações bizarras que podem ocorrer se você não usá-los, como essa e essa (veja mais sobre isso aqui).