📮 🐎 👨🏻‍💻 Usando o SwiftLint Static Code Analyzer em aplicativos de mobile banking para iOS 📘 👊🏾 👩🏽‍💼

Oleg Ivanov, Chefe do Centro de Competência em Canais de Serviço Remoto

Olá a todos! Conforme prometido no artigo “ICD Mobile Bank: Development History” , hoje quero falar sobre analisadores de código estático e a experiência de sua aplicação em aplicativos móveis iOS do banco.

Vamos definir a meta que queremos alcançar usando este kit de ferramentas:

detecção precoce de erros e deficiências;
Code Style ( — , ).

Uma maneira comum de atingir nossos objetivos é verificar manualmente o código - Revisão de código .

O testador ou um grupo de testadores examina cuidadosamente o código que está sendo testado e, em seguida, identifica erros ou seções do código que podem se tornar errôneos no futuro e fornece recomendações para aprimorá-lo através de comentários no código, que após algum tempo (!) Serão analisados e corrigidos pelo desenvolvedor. Como podemos ver, um processo longo e caro de verificação de código está surgindo. Além disso, sempre há um fator humano - alguns erros podem ser simplesmente ignorados pelos revisores.

Aqui, os analisadores de código estático vêm em nosso auxílio.

Analisadores de código estático- iniciar um processo automatizado para detectar erros e deficiências no código fonte dos programas.

Os analisadores de código estático não são uma panacéia ou um substituto para a revisão manual do código, mas são uma excelente ferramenta que permite reduzir o tempo necessário para realizar verificações e encontrar rapidamente erros padronizados. A relevância do uso de analisadores estáticos só aumentará com o tempo.

Como analisador de código estático em nossos projetos iOS, usamos o SwiftLint.

SwiftLint é um utilitário de verificação automática de código Swift que é executado durante a fase de construção de um projeto. O utilitário contém um conjunto de regras com a capacidade de suplementar esse conjunto com suas regras personalizadas. A ferramenta também é usada para cumprir o estilo de código.

Por que é importante seguir o estilo de código no aplicativo?
Quando você é um desenvolvedor em um projeto, tudo é simples: você escreve em seu próprio estilo e pode pagar o código dessa maneira:

Mas quando você trabalha em uma grande equipe de desenvolvimento. um fator importante é a velocidade de entender e encontrar o lugar para inserir melhorias no código de outra pessoa.
E aqui todos os membros da equipe precisam aceitar as convenções e regras para escrever código. Mas como verificar sua conformidade? Mais uma vez, o analisador de código estático SwiftLint nos ajudará. E nosso código terá uma aparência agradável que todos os membros da equipe entenderão:

Para se familiarizar com a ferramenta, recomendo a leitura da documentação oficial .

A instalação do SwiftLint é simples:

Adicione o pod 'SwiftLint' ao podfile do projeto
Adicione uma nova "Fase de script de execução" ao projeto.
```
"${PODS_ROOT}/SwiftLint/swiftlint"
```
SwiftLint .swiftlint.yml
.swiftlint.yml , SwiftLint

Se o projeto de incorporação do SwiftLint já contiver código, você precisará ser paciente e corrigir sistematicamente todas as recomendações do SwiftLint. Ele os forma através do erro usual e das exibições de aviso com dicas abrangentes sobre as recomendações.

Também entre parênteses, ele exibe o nome da regra que iniciou a recomendação (operator_usage_whitespace) .

Nesse caso, são eles:

Uso do
operador Espaço em branco Os operadores devem estar cercados por um único espaço.

Código correto: Código

recomendado:

cada regra possui um conjunto de atributos:

Identificador : operator_usage_whitespace
Ativado por padrão : desativado
Compatível com a correção automática :yes
Tipo : style
Regra do analisador : Não
Versão mínima do compilador Swift : 3.0.0
Configuração padrão : aviso

Preste atenção à “Versão mínima do compilador Swift” - correlacione o uso de regras com esse atributo e com as configurações do seu projeto.

Os “Configuração padrão” de atributos mostra como as regras com este atributo serão percebidos: ou um aviso regular, ou um erro de compilação, como um Elenco Força regra (configuração padrão: erro)

Todas as regras podem ser encontradas em um muito conveniente e ilustrado documentação.

Abaixo apresentarei as regras que escolhemos em nossa equipe. Você pode usá-las como exemplo para criar seu projeto.

Dividimos todas as regras em funcional e estilística - sim, sim, sim, e um espaço dentro de cada chave, e os parâmetros de fechamento devem estar na mesma linha que a chave de abertura e ... :). Eu não pinto as regras, você pode encontrar facilmente informações sobre elas usando o link acima.

Funcional :

- private_outlet
- force_unwrapping
- force_cast
- force_try
- strong_iboutlet
- private_action
- block_based_kvo
- contains_over_first_not_nil
- discarded_notification_center_observer
- discouraged_direct_init
- discouraged_object_literal
- discouraged_optional_boolean
- discouraged_optional_collection
- duplicate_imports
- dynamic_inline
- empty_count
- empty_parameters
- empty_parentheses_with_trailing_closure
- EMPTY_STRING
- explicit_enum_raw_value
- function_default_parameter_at_end
- generic_type_name
- identical_operands
- implicit_getter
- is_disjoint
- notification_center_detachment
- nsobject_prefer_isequal
- redundant_set_access_control
- unused_capture_list

O estilo de :

- unneeded_parentheses_in_closure_argument
- let_var_whitespace
- yoda_condition
- cólon
- vírgula
- closure_parameter_position
- closure_spacing
- collection_alignment
- leading_whitespace
- marca
- opening_brace
- operator_usage_whitespace
- operator_whitespace
- protocol_property_accessors_order
- return_arrow_whitespace
- switch_case_alignment
- statement_position
- trailing_comma
- trailing_newline
- unneeded_break_in_switch
- custom_rules
- closure_end_indentation
- file_name_no_space
- unowned_variable_capture
- no_space_in_method_call
- contains_over_filter_count
- contains_over_filter_is_empty
- contains_over_range_nil_comparison
- duplicate_enum_cases
- empty_collection_literal

também um objectivo da SwiftLint escolhemos apenas o catálogo com a nossa base de código, adicionando as configurações apropriadas na .swiftlint.yml arquivo de configuração:

incluíram:

- <diretório base de código>

Criamos sua regra de inadmissibilidade funções de impressão. a impressão é uma operação bastante difícil. Por meio do arquivo de configuração .swiftlint.yml:

custom_rules:
  disable_print:
    included: ".*\\.swift"
    name: "print usage"
    regex: "((\\bprint)|(Swift\\.print))\\s*\\("
    message: "Prefer os_log over print"
    severity: error

Essa regra nos levou a escrever nossa função de log (com um nível de log). Esse log é usado pelos desenvolvedores para depuração rápida, por exemplo, logs com parâmetros, um corpo de solicitação / resposta é necessário para qualquer análise de erros, para desenvolvimento. Para o Release, o nível do log em nossa versão .none. O restante do uso da função de impressão resultará em um erro de compilação para o projeto.

func logApp(level: Constants.LogLevel, items: Any...) {
    if Constants.logLevel == .none {
        return
    }
    
    if level.rawValue <= Constants.logLevel.rawValue {
        // swiftlint:disable disable_print
        if let strings = items as? [String] {
            for string in strings {
                print(string)
            }
        } else {
            print(items)
        }
        // swiftlunt:enable disable_print
    }

Mas, para usar a função de impressão, tivemos que fechar sua chamada em nossa função de registro usando o SwiftLint para ignorar nossas próprias regras em um bloco de código marcado com uma instrução especial.

// swiftlint:disable disable_print
// swiftlunt:enable disable_print

SwiftLint tem a capacidade de ignorar suas próprias regras:

// swiftlint:disable <rule1 [rule2 rule3…]>
<,   SwiftLint   rule1 [rule2 rule3…]>
// swiftlunt:enable <rule1 [rule2 rule3…]>

// swiftlint:disable all
<,   SwiftLint   >
// swiftlint:enable all

Aproveite esta oportunidade, ciente de que é necessário!

Concluindo, observo : o uso do SwiftLint em nossa equipe reduziu o custo da revisão manual do código em 20%. Agora, nossos revisores não prestam atenção a erros típicos (Forçar conversão, etc.), Estilo de código e podem se concentrar totalmente na verificação do novo código. O que aumentou significativamente a eficiência geral da equipe (não há necessidade de corrigir essa verificação de erros, são funcionários qualificados, cujo tempo é muito importante).

Todos! Agora SwiftLint é para sempre com você :)

Usando o SwiftLint Static Code Analyzer em aplicativos de mobile banking para iOS

More articles: