Sugiro que você se familiarize com a transcrição do relatório de Denis Isaev jirfag "Linter in Go. Como cozinhá-los".
Em mais de 50 anos: qual é o lucro e como integrá-los efetivamente ao processo de desenvolvimento? O relatório será útil tanto para quem ainda não usa o linter quanto para quem já o usa: revelarei truques e práticas pouco conhecidos para trabalhar com o linter.
Quem se importa, por favor, debaixo do gato.
Oi Meu nome é Dennis Isaev. Falaremos sobre como cozinhar forros em Go. O relatório será interessante tanto para iniciantes que ainda não usaram o linter quanto para profissionais. Vou falar sobre alguns truques pouco conhecidos.
Um pouco sobre mim. Eu sou o autor do projeto de código aberto Golangci-lint. Trabalhou em mail.ru. Agora, trabalho como TeamLead no back-end no Yandex.Taxi. Meu relatório é baseado na experiência de centenas de usuários de Golangci. Sobre como eles usaram o linter, quais dificuldades tiveram e a experiência de implementar linters Go no mail.ru e no Yandex.
Abordaremos cinco questões principais no relatório.
Vejo muitas vezes que os linters não usam nada. Levante suas mãos para aqueles que usam o linter em todos os projetos, sem exceção. Nem todos.
Vamos falar sobre por que eles não são usados. Na maioria das vezes, quando pergunto por que vocês não usam, eles dizem que o linter interfere conosco. Eles apenas atrasam o desenvolvimento. Não há nada de bom neles. Isto é parcialmente verdade. Se você não conhece as sutilezas da sintonia, elas podem realmente interferir. Falaremos sobre isso um pouco mais tarde.
Além disso, eles costumam pensar que o linter encontra apenas uma coisa pequena, algo estilístico, alguns erros não críticos e, de fato, não vale a pena. É mais fácil perder tempo.
Contra-exemplos imediatamente. Um bug no Docker foi encontrado usando o go vet. Chamada esquecida para a função Cancelar. Por esse motivo, a goroutina em segundo plano pode não terminar.
Um erro no projeto Etcd. O linter legal de crítico descobriu que o argumento strings.HasPrefix está confuso. Significa que a verificação do protocolo HTTP não seguro não funcionará.
Em Go, o problema é que o elemento i é comparado pelo i-ésimo, embora deva ser comparado com o j-ésimo. Também encontrado por linter.
Três exemplos em grandes projetos de código aberto encontrados por linters. Alguns perguntam: Ok, e daí? Ele encontra alguns erros críticos. Para um bug crítico, ele encontra 100 positivos falsos ou não críticos. Posso fornecer minhas estatísticas empíricas: geralmente tenho cerca de 80% de todos os problemas relatados pelos linters: alguns problemas estilísticos, por exemplo, variáveis não são usadas e assim por diante, 15% são erros reais e cerca de 5% são falsos positivos.
Agora vamos falar sobre por que os linters são necessários. O bônus mais importante é que os linters economizam tempo. E tempo é dinheiro. Quanto mais cedo você encontrar erros, mais baratos eles custam para sua empresa. No slide, há um gráfico do custo aproximado da correção do bug, dependendo do estágio em que ele é encontrado. Assim, de cada estágio do desenvolvimento à produção, o custo aumenta três vezes. Encontre erros com antecedência, idealmente no IDE e economize dinheiro da empresa.
Muitas vezes acontece que no CodeReview, os desenvolvedores relatam alguns problemas que os linters podem encontrar. Por que eles fazem isso é incompreensível. Primeiro, o autor do código precisa esperar até que ele passe no CodeReview. Em segundo lugar, o próprio examinador precisa dedicar algum tempo a encontrar problemas mecânicos. Ele podia confiar isso em Linter. Quando percebo isso, sempre forço e concordamos na equipe que não podemos analisar a revisão de tudo o que pode ser encontrado pelo linter. Se confiamos em tudo isso para diminuir. Além disso, se encontrarmos alguns problemas que geralmente ocorrem na revisão e não houver linhas sobre eles, tentamos encontrar linhas que possam pegá-los na teoria. Portanto, não perdemos tempo revisando.
Os linters nos permitem de alguma forma garantir e ter qualidade de código previsível no projeto. Por exemplo, nesse caso, esses são argumentos de função não utilizados.
Os linters permitem encontrar erros críticos o mais cedo possível, economizando tempo no CodeReview. Ao mesmo tempo, garanta alguma qualidade do código do projeto.
Go tem mais de 50 linters, mas os mais populares são 4. Estes são os que estão no slide. Eles são usados simplesmente porque são legais. O resto geralmente não quer lidar. Agora, quero mostrar por exemplos que tipo de linters existem. Quero demonstrar 25 exemplos de linter. Agora provavelmente será a coisa mais importante no relatório.
Vamos começar com os formatadores que verificam os formatadores. Gofmt não é essencialmente um linter. Mas podemos considerá-lo um linter. Ele sabe como nos dizer que não há feeds de linha suficientes, em algum lugar espaços extras. Em geral, esse é o padrão para verificar e manter a formatação do código.
O Gofmt também possui uma opção pouco conhecida -s, que permite simplificar expressões.
O Goimports contém tudo o que o gofmt contém, mas além disso ainda sabe como reordenar as importações, excluir e adicionar as importações necessárias.
O Unindent é um linter maravilhoso que pode diminuir o nível de aninhamento de código. Nesse caso, ele nos diz que, se combinarmos os dois ses em um, teremos uma queda no nível de aninhamento por um.
Vamos considerar linters verificando a complexidade do código. O mais legal deles é o gocyclo. Ele é o mais chato. Muitos o odeiam. Ele verifica a complexidade ciclomática do código e jura quando essa complexidade da função excede algum limite. O limite é configurável. Se simplificada, a complexidade ciclomática é a quantidade de if no código. Aqui ele é grande demais e o linter jura.
Nakedret é um linter que pode dizer que você usa retorno sem valores e, ao mesmo tempo, usa-o em uma função que é muito longa. De acordo com o guia oficial, esses retornos não são recomendados.
Há um grupo de estilos de teste de linter. Por exemplo, gochecknoglobals verifica se você não está usando variáveis globais. Claro que eles não precisam ser usados.
Golint jura na mesma variável apiUrl. Diz que o URL deve ser usado em letras maiúsculas. Desde esta abreviação.
Gochecknoinits garante que você não esteja usando as funções init. As funções de inicialização não devem ser usadas por certos motivos.
Gosimple cool linter. Parte do staticheck ou megacheck. O próprio interior contém um grande número de padrões para simplificar o código. Nesse caso, você pode perceber que strings.HasPrefix não é necessário, pois strings.TrimPrefix já contém as verificações necessárias e é possível remover se.
O Goconst verifica se você não possui literais de string duplicados no seu código que possam ser inseridos em constantes. O número dessas repetições é configurável. Nesse caso, dois.
Erro de ortografia incorreta, que verifica se você não encontrou erros de digitação no código nos comentários. Nesse caso, o slide contém um erro de digitação da palavra mais no texto do comentário. Você pode personalizar o dialeto do inglês: americano, britânico.
Desconverte o linter, que verifica se você não faz conversões desnecessárias. Nesse caso, a variável já é do tipo string. Não faz sentido convertê-lo.
Agora vamos ver os linters que verificam o código não utilizado. O primeiro é varcheck. Ele verifica variáveis não utilizadas.
Não utilizado pode xingar em campos não utilizados de estruturas.
O código morto informa se um tipo não é usado.
Ou a função não é usada.
O unparam pode relatar quando os argumentos da função não são usados no próprio corpo da função.
Não atribui relatórios quando uma alteração por uma variável não é usada mais no código. Esse é o resultado de algum tipo de refatoração. Em algum lugar eles esqueceram de limpar alguma coisa ou um bug. Neste exemplo, a contagem é incrementada. Além disso, não é mais utilizado. Isso é muito parecido com um bug.
Há um grupo de desempenho de teste de linter. Por exemplo, maligned nos diz que uma determinada estrutura testStruck pode ser compactada em tamanho reordenando os campos. Além disso, se você executá-lo como parte do golangci-lint, ele possui uma opção que permite imprimir imediatamente a ordem desejada dos campos, para não selecioná-los.
Existe um linter gocrítico tão legal. Ele tem muitos cheques lá dentro. Um deles é enormeParam. Ela sabe como nos informar sobre como copiar estruturas de dados pesadas. Nesse caso, heavyStruct é copiado por valor e só precisamos passá-lo como um ponteiro.
O Prealloc pode encontrar lugares no código onde podemos pré-implantar a fatia. Ele o encontra para procurar onde fazemos iterações horárias constantes na fatia. E neles assuntos acrescentam-se. Nesse caso, você pode pré-alocar a variável ret para o tamanho da fatia ss e economizar memória e CPU.
E, finalmente, linters que encontram bugs. O Scopelint provavelmente encontra o erro mais frequente para iniciantes: capturar a variável range de um loop por referência. Nesse caso, a variável de loop arg é capturada por referência. Na próxima iteração, já haverá um significado diferente.
Staticcheck Costumava ser chamado megacheck. Agora foi renomeado. Por esse motivo, existe uma pequena confusão na comunidade. O Staticcheck pode encontrar toneladas de bugs diferentes. Isso é uma coisa muito legal. Como ir ao veterinário. Um deles no slide é uma corrida. Obviamente, precisamos incrementar o sync.WaitGroup antes de entrar na goroutine.
Go vet encontra principalmente erros. Nesse caso, a variável i é comparada para que o resultado sempre seja verdadeiro. Portanto, obviamente existe um bug. Em geral, você deve sempre usar o go vet.
Gosec significa segurança. Localiza possíveis problemas de segurança no Go. Nesse caso, os dados do usuário podem chegar em arg. Portanto, ele pode se infiltrar no comando rm shell. E aqui talvez shell em ação, por exemplo. Observo que a segurança de segurança geralmente produz falsos positivos. Portanto, às vezes eu desativo.
Errchek encontra lugares onde esquecemos a verificação de erros. Um estilo de programação bom e seguro está sempre em todo lugar para verificar todos os erros.
Dois ponteiros devem ser anotados separadamente: staticcheck e go-critical. Porque dentro de cada um deles há dezenas, senão centenas, de cheques. Portanto, não deixe de experimentá-los.
Agora examinamos 25 exemplos de linter. E eu também disse que temos mais de 50 linters no Go. Qual usar? Eu aconselho você a usar tudo ao máximo. Basta incluir todos os linters que puder. Depois, passe uma hora e comece a desligá-los, um de cada vez. Desligue aqueles que lhe parecem insignificantes. Por exemplo, ele encontra algumas otimizações de desempenho nas quais você não está interessado. Você passará uma hora e criará sua própria lista de linter para si mesmo e poderá viver com ele ainda mais.
O catálogo completo de todos os linters está disponível no link no slide.
Vamos falar sobre como executar o linter. Às vezes, os linters são lançados usando esses makefiles. O problema é que é lento. Tudo é executado sequencialmente.
Podemos executar a execução em paralelo via xargs -P. Há também um problema. Em primeiro lugar, estes são apenas 4 linters. E já 10 linhas de código. O que acontece se ativarmos 20 linters. Em segundo lugar, essa paralelização é, para dizer o mínimo, não a mais ótima.
Gometalinter vem em socorro. O Gometalinter é um agregador de linters que pode ser executado literalmente em alguns comandos. No slide, o comando para iniciar o mesmo linter é semelhante ao slide anterior. Mas eles não precisam ser instalados de forma independente e não precisam ser shamanized com o lançamento paralelo. O Gometalinter já está paralelizando tudo sob o capô. Mas ele tem um problema fundamental. Inicia cada linter como um processo separado. Garfos ele. Se somarmos a isso o conhecimento de que cada ponteiro dentro de si passa 80% do tempo analisando o código e apenas 20% na própria análise, acontece que desperdiçamos 80% do trabalho. E não reutilize os dados. Poderíamos analisar o programa uma vez e depois alimentar 50 linter.
Felizmente, há golangci-lint que faz exatamente isso. Ele analisa uma vez. Digite uma vez. Outros analisadores são executados neles. Devido a isso, ele funciona muito mais rápido. Um comando de inicialização semelhante em um slide.
Você pode ver o gráfico em um dos meus projetos com 30 mil linhas de código. Um projeto pequeno e apenas 4 linter. Você pode notar uma enorme diferença na velocidade do trabalho às vezes, tanto entre o lançamento seqüencial quanto entre gometalinter e golangci-lint. Se esse linter não for 4, mas 20, a diferença será muito maior.
Esclarecimentos importantes sobre o gometalinter. Desde 7 de abril, o autor do projeto gometalinter declara-o obsoleto. O repositório foi arquivado e todos são aconselhados a mudar para golangci-lint, uma vez que é mais rápido e possui mais vantagens. Por exemplo, suporte para módulos go e assim por diante.
E além dos módulos de desempenho e Go, o golangci-lint possui recursos como a configuração YAML, a capacidade de ignorar avisos, excluí-los e assim por diante.
Golangci-lint é configurado usando o arquivo golangci-lint.yaml. Um exemplo deste arquivo com uma descrição de todas as opções está no link no slide. Considere, por exemplo, a seção linters-settings. Nesta seção, iremos fazer a configuração de importação. Tem uma opção rara de prefixos locais. Nele, você pode especificar o caminho para o projeto atual. Nesse caso, por exemplo, github.com/local/repo.
Quando o goimports vê importações locais em github.com/local/repo, ele garante que elas estejam em uma seção separada.
Para que eles estejam no final. Para que eles sejam separados de todas as importações externas. Isso facilita a distinção visual entre importações externas e internas. Se ele perceber que isso não é verdade, ele jurará.
E se você também usar a opção golangci-lint run --fix, o golangci-lint irá corrigi-lo automaticamente e reordenar as importações.
Vamos falar sobre o que os linters estão na terminologia golangci-lint. Linter são divididos em rápido e lento. Os rápidos são chamados de rápidos, marcados com a bandeira rápida em ajuda. Eles diferem no fato de que os linters rápidos requerem uma representação bastante limitada do programa, por exemplo, a árvore AST e algumas informações de tipo. Embora os linters de cobre ainda exijam o envio de SSA pelo programa e reutilizem menos o cache. Existem apenas seis linhas lentas. Eles estão marcados no slide. Existem certos casos em que faz sentido executar apenas um linter rápido.
Você pode notar uma diferença de velocidade. São três vezes tremendas entre o início rápido e o lento. Na verdade, golangci-lint run - rápido apenas lançadores rápidos são lançados.
Sobre o cache de compilação. Existe um cache de compilação. Esse é o cache que o binário Go cria ao compilar o programa quando os tipos são carregados, para que na próxima vez que essa compilação seja mais rápida. O mesmo cache é reutilizado pelos linters para analisar programas e construir informações de tipo. Você pode perceber que, se você limpar o cache, o primeiro novo começo será bastante longo. E o próximo será 3 vezes mais rápido. Preste atenção ao seu primeiro lançamento do linter em seu projeto. Sempre será muito mais lento.
Aqui você pode concluir que faz sentido no IC entre lançamentos de IC para reutilizar seu cache. Você não apenas acelerará os linters, como também executará os testes, apenas compilará e talvez outra coisa. Eu aconselho a todos.
Eu não posso falar sobre análise de ir. Esta é uma nova estrutura que apareceu desde o Go 1.12. Ele unifica as interfaces de tal maneira que o linter se torna fácil de escrever, o linter é fácil de usar, executar. Go vet inicia a versão 1.12 totalmente comutada para análise. Obviamente, este é o futuro. Isso mudará bastante todo o ecossistema do Go. Mas, por enquanto, geralmente é muito cedo para falar sobre isso. Então, o que vai acontecer a seguir? Porque eu vi apenas algumas linhas de análise em andamento e quase nenhuma das existentes mudou para ela ainda.
Se você concluir brevemente a seção sobre como executar linters, aconselho a todos que usem golangci-lint. Você executará rapidamente linters convenientemente. Você não precisa usar shaman com outras instruções, comandos.
Vamos falar sobre como implementar o linter no projeto. Eu acho que todos que tentaram introduzir linters enfrentaram esse problema. Aqui você tem um projeto para um milhão de linhas de código com histórico. Você convenceu o TeamLead a implementar linters. Inicie e veja um milhão de mensagens. Entenda que você não tem tempo para sentar por semanas para consertar tudo. O que fazer Você pode simplesmente desistir e desistir de tudo. Ou você pode inventar algo.
Primeiramente, a opção mais fácil, você pode tentar excluir regularmente alguns comentários dos linters no texto usando a configuração golangci-lint.yaml. Se você perceber que há listas de jurados nos comentários, mas geralmente não se importa com esses comentários, você pode adicionar às exceções.
Podem ser excluídos caminhos. Por exemplo, você tem um diretório de terceiros e seu código não está lá. Você não precisa verificar. Pode ser excluído por nomes de arquivos.
Se você não deseja excluir o arquivo inteiro, é possível excluir a função com nolint antes da função. Para o nolint, é possível especificar através dos dois pontos uma lista de linters para os quais ele atua como uma exceção. Ou, para não especificar, todo o linter será ignorado.
Quando usar o nolint? Por exemplo, eu uso o nolint: deepguard, que pode capturar importações, ou seja, As importações não podem ser usadas. Eu atordoei a importação da biblioteca do logrus para não usá-la acidentalmente, em vez do meu logger desejado. Mas no meu próprio logger eu uso o logrus. Portanto, preciso apenas em um local do projeto para criar apenas um arquivo a partir da importação. Eu identifico com nolint.
Suponha que você tenha feito tudo isso, adicione exclude, nolint affix. Vemos que ainda existem milhares de mensagens. Corrija alguns dias. Há um truque legal. Vejamos um exemplo. Há um arquivo main.go no qual a quinta linha é adicionada há muito tempo e a sexta linha é adicionada somente hoje. O que podemos fazer?
Nós podemos usar revgrep. O Revgrep nos permite especificar uma revisão do git, após a qual precisamos procurar bugs. Ou seja, deixe uma mensagem para vincular apenas após uma determinada revisão. Se a 6ª linha for alterada após o mestre de origem, ela será corrigida apenas. E todas as mensagens anteriores, ele não reportará a quinta linha. . . . golangci-lint . . , . git hash commit. . . hash commit tag revgrep CI. . . . mail.ru, .
revgrep golangci-lint. --new-from-rev --new. .
. --new. 20 , . . . . . ? --new-from , . .
. golangci-lint . . . , .
Falamos sobre a introdução do linter em qualquer projeto. Agora vamos falar sobre a conveniência do trabalho. Primeiro, você precisa alcançar a reprodutibilidade no IC. Assim que você adiciona um ponteiro ao CI, é necessário que ele seja estável. Nunca vá buscar. Porque não é versionado. O Linter mudou a qualquer momento, atualizado e todas as suas compilações de IC começaram a falhar. Eu já vi isso dezenas de vezes. Sempre use versões específicas. Melhor com o wget. Ela será ainda mais rápida. Além disso, eu não recomendo o uso da opção --- enable-all para linter, porque em um dia você atualiza o golangci-lint, por exemplo, adiciona 5 novos linter e todo o seu build começa a falhar. Porque você acidentalmente ligou esses linter. É melhor prescrever explicitamente quais linters você inclui.
O legal é o gancho de pré-confirmação. Quem usa o gancho de pré-confirmação levante suas mãos? Muito pouco. O gancho de pré-confirmação é um arquivo git que permite executar código arbitrário depois que você deseja confirmar. Mas antes que esse commit seja bem-sucedido. Se o gancho de pré-confirmação retornar um erro, a confirmação falhará. Geralmente, é conveniente incorporar testes rápidos, análises estáticas e assim por diante. Aconselho a todos que incorporem golangci-lint. Você pode fazer isso manualmente através do script de shell. É possível através do utilitário pré-confirmação. Um exemplo de como configurar um slide. Instala a pré-confirmação com o pip, um utilitário para instalar pacotes Python. O pip install pre-commit instala a configuração. O Golangci-lint já suporta integração com pré-confirmação.
A opção --fast. Nós voltamos para ela. Aconselho todos a usá-lo no IDE. Em geral, o IDE, é claro, deve usar a integração com linters. Para que o seu IDE não congele, use a opção --fast.
Eu acho que isso é bastante óbvio. No IC, os linters precisam ser incorporados. Se você não as incorporar, haverá uma imagem clássica: "vamos martelar agora, agora temos uma versão, não antes disso". Gradualmente, você terá mais e mais comentários. Você simplesmente para de olhar para linters como uma classe. Portanto, estritamente no IC. Além disso, você pode simplesmente instalar linters no CI, com a falha de compilação, entramos no log de compilação e procuramos por que ele caiu lá. Onde está o comentário, em qual linha? Isso não é muito conveniente.
Existe uma maneira mais legal. Você pode fazer com que o linter atue como pessoa, como revisor. Eles podem comentar sobre você em github.com, gitlab.com, para obter uma linha de código de erro na sua solicitação Pull. Linter pode escrever que encontrou um problema. Isso é incrivelmente legal. Isso economiza tempo no código dos autores. Porque você não precisa entrar no log de compilação. Além disso, uma pessoa pode comentar se não concordar com esta observação do linter. No exemplo do slide, isso é feito usando o utilitário reviewdog. Utilitário de código-fonte aberto. Ela é livre Você pode se instalar.
Além de reviewdog, também existem projetos como GolangCI, Code Climate, Hound. Eles permitem que você conecte esses linters com apenas um clique ao seu opensouce ou repositórios particulares e comente em linha no Pull Request. Ainda há uma coisa legal no SonarQube.
Não posso mencionar o goreportcard ainda. Este projeto permite que você crie um relatório em seu repositório. Eles colocam notas lá, dão um distintivo, escrevem o quão bom é o seu código para uma dúzia de limpas. Eu também aconselho.
Gostaria que você viesse trabalhar na segunda-feira e pudesse aplicar algo do que eu disse. Aqui está um resumo do que você pode aplicar. Primeiro instale o golangci-lint. Ligue todas as linhas lá. Depois gaste 1 hora. Durante esta hora, desligue todas as linhas que parecem ilusórias para você. Depois disso, incorpore golangci-lint no IC, no IDE e configure o gancho de pré-confirmação. Logo depois disso, você pode configurar --new-from-rev e indicar que, a partir do commit atual, estamos procurando por bugs. E todos os erros anteriores serão corrigidos posteriormente posteriormente separadamente. Depois disso, opcionalmente, configure o reviewdog para que ele ainda faça comentários sobre você no seu github ou no gitlab. Você aumentará enormemente a qualidade do projeto. Delicie toda a equipe.
Obrigado a todos pela atenção. Meus contatos no slide.
Pergunta: Diga-me, você tem arquivos de configuração prontos que você coloca em acesso aberto e que você pode simplesmente baixar e usar para não entender a tonelada de configurações de golangci-lint? O que você recomenda.
Resposta: Boa ideia. O próprio Golangci-lint já possui seu próprio golangci-lint.yaml, que ele usa. Você pode usá-lo como ponto de partida.
Pergunta: No slide sobre o cache de compilação, consulte o cache dos módulos. No cache, você especifica todo o cache dos módulos. Você pode especificar .cache / downloads, então haverá uma diferença bastante grande: 400 megabytes versus 10. Isso é suficiente para simplesmente extrair os módulos. Mas isso é apenas se o módulo for usado.
Pergunta: Você também suporta go modules ou dep ou entra em algo em um?
Resposta: Não há necessidade de suporte. Agora existe uma biblioteca de pacotes go. Ela está envolvida no carregamento do código fonte. Ele suporta módulos e não módulos. Ela ainda não removerá o suporte para não módulos.
Pergunta: Você planeja criar vários plugins para integração não apenas com o Travis, mas também com outros servidores de automação?
Resposta: golangci-lint não faz nenhuma integração. Para executar no CI, basta chamar golangci-lint --run.
Pergunta: Para analisar alguns relatórios, por exemplo, no Jenkins, salvamos um arquivo html.
Resposta: Há um formato de saída junit, csv, json xml. Tudo isso já pode ser analisado.
Pergunta: usamos o gometalinter antes e foi lento. Depois, mudamos para um linter chamado revive. Você não o mencionou. E, da minha parte, não sou especialista no assunto. Eu não sabia sobre o seu linter, o que você estava dizendo. Você poderia escrever no final, digamos os profissionais do seu linter ou os profissionais do reviver.
Resposta: reviver é um gol reescrito. Este é apenas um dos linter. Existem configurações. Ele também adicionou alguns filtros, alguns cheques. Golangci-lint está dentro de si 30-50 linter. Este é um reviver um meio e meio. Reviver é legal, pois leva golint e torna paralelo. Reviva o trabalho mais rápido que o golint. Mas este é apenas um linter. Reviver pode fazer parte do golangci-lint.
Pergunta: Você teve um slide na revisão de linters sobre gocritic: hugeParam, recomendado para transferir estruturas em negrito por ponteiro. Mas isso levará ao fato de que todas essas estruturas serão alocadas exclusivamente no HEAP. E isso não levará a problemas maiores do que vantagens? Se tais estruturas, por exemplo, são transmitidas muito.
Resposta: Eu concordo completamente. Você não deve usar esses avisos e não apenas segui-los. Pode ser como otimização prematura, pode prejudicar o projeto. Geralmente desativo essa classe de linters em geral se não tenho o desempenho de uma tarefa crítica. onde encontro pontos fracos com o criador de perfil.
Pergunta: Eu sou do Yandex. Usamos seu linter em um grande repositório. Percebemos que ele já está começando a trabalhar muito rapidamente para um grande repositório. Em apenas alguns dias, eles escreveram um utilitário simples que, através do pacote go, encontra pacotes que foram alterados desde a introdução da ramificação do assistente e pacotes que dependem deles. E execute o linter apenas neles. E a verificação do linter acelerou várias vezes.
Resposta: Talvez você crie uma idssue, anexe um script e, possivelmente, eu incorporarei tudo isso no golangci-lint.
Pergunta: Os níveis de gravidade são planejados para os comentários encontrados, para que alguns possam ser incluídos no relatório, mas isso não falsifica o processo de IC? Por exemplo, através do código de conclusão.
Resposta: Muitas pessoas perguntaram e eu direi imediatamente a dificuldade que esses níveis de seriedade suportam a todos, existem 3 ou 4 em 30. O que fazer com o aço? Não está claro. É necessário analisar manualmente seus comentários, de alguma forma, marcá-los. Lidar com falsos positivos. Geralmente, isso é uma grande quantidade de trabalho. Não tenho certeza do que será feito quando. Existem outras maneiras de alcançar o mesmo objetivo.
Pergunta: Existem artigos no hub Mais precisamente, uma série de artigos sobre o C ++ linter. A empresa está desenvolvendo esse negócio. Eles ganham dinheiro com isso. De fato, seu trabalho, ou melhor, esta série de publicações, não é mais voltado para desenvolvedores, mas mais para aqueles que gerenciam desenvolvedores. Isso é essencialmente código puro, estilização. Esta é a nossa tarefa, mas também a tarefa dos líderes, líderes de equipe. Você está planejando popularizar essa linha de mídia aqui, em grandes recursos para que as pessoas a leiam e a apresentem a suas equipes? E não batemos por baixo.
Resposta: Eu tinha um plano. Obrigado pela sugestão. Eu tinha planos de escrever um artigo abrangente como esse discurso, mas em mais detalhes e amplamente ao longo do ano. Talvez eu escreva em russo e em inglês.