Le sugiero que se familiarice con la transcripción del informe de Denis Isaev jirfag "Linter in Go. Cómo cocinarlos".
En go 50+ linter: ¿cuál es su beneficio y cómo integrarlos de manera efectiva en el proceso de desarrollo? El informe será útil tanto para aquellos que aún no usan linter, como para aquellos que ya los usan: revelaré trucos y prácticas poco conocidos para trabajar con linter.
A quién le importa, por favor, debajo del gato.
Hola Me llamo Dennis Isaev. Hablaremos sobre cómo cocinar linters en Go. El informe será interesante tanto para principiantes que aún no han usado linter como para profesionales. Te contaré algunos trucos poco conocidos.
Un poco sobre mi. Soy el autor del proyecto de código abierto Golangci-lint. Trabajó en mail.ru. Ahora trabajo como TeamLead en el backend en Yandex.Taxi. Mi informe se basa en la experiencia con cientos de usuarios de Golangci-lint. Sobre cómo usaron la interfaz, qué dificultades tuvieron y la experiencia de implementar Go linters en mail.ru y Yandex.
Cubriremos 5 temas clave en el informe.
A menudo veo que las linters no se usan en absoluto. Levante la mano a quienes usan el linter en todos los proyectos sin excepción. No todo
Hablemos de por qué no se usan. La mayoría de las veces, cuando les pregunto por qué no los usan, dicen que linter interfiere con nosotros. Solo ralentizan el desarrollo. No hay nada bueno en ellos. Esto es en parte cierto. Si no conoce las sutilezas de la afinación, entonces realmente pueden interferir. Hablaremos de esto un poco más tarde.
Además, la gente a menudo piensa que el linter encuentra solo una pequeña cosa, algo estilístico, algunos errores no críticos y, de hecho, no vale la pena. ¿Es más fácil perder el tiempo?
Contraejemplos inmediatos. Se encontró un error en Docker usando go vet. Llamada olvidada para cancelar la función. Debido a esto, la rutina de fondo puede no terminar.
Un error en el proyecto Etcd. El genial intérprete crítico de go encontró que las cadenas. El argumento HasPrefix es confuso. La comprobación de medios para el protocolo HTTP inseguro no funcionará.
En Go, el error es que el elemento i es comparado por el i-ésimo, aunque debería compararse con el i-ésimo. También encontrado por linter.
Tres ejemplos en grandes proyectos de código abierto encontrados por linters. Algunos preguntarán: Ok, ¿y qué? Encuentra algunos errores críticos. Para un error crítico, encuentra 100 positivos no críticos o falsos. Puedo dar mis estadísticas empíricas: generalmente tengo alrededor del 80 por ciento de todos los problemas que informan: algunos problemas de estilo, por ejemplo, las variables no se utilizan, y así sucesivamente, el 15 por ciento son errores reales y alrededor del 5 por ciento son falsos positivos.
Ahora hablemos de por qué se necesitan linters. La ventaja más importante es que los linters ahorran tiempo. Y el tiempo es dinero. Cuanto antes encuentre errores, más baratos le costarán a su empresa. En la diapositiva hay un gráfico del costo aproximado de arreglar el error dependiendo de la etapa en la que se encuentre. En consecuencia, desde cada etapa desde el desarrollo hasta la producción, el costo aumenta tres veces. Encuentre errores temprano, idealmente en el IDE y ahorre dinero a la empresa.
A menudo sucede que en CodeReview, los desarrolladores informarán algunos problemas que las linters podrían encontrar. Por qué hacen esto es incomprensible. Primero, el autor del código debe esperar hasta que pase CodeReview. En segundo lugar, el examinador mismo necesita pasar tiempo buscando problemas mecánicos. Podía confiarle esto a Linter. Cuando me doy cuenta de esto, siempre lo fuerzo y acordamos en el equipo que no podemos ver la revisión de todo lo que puede encontrar el linter. Si confiamos en todo esto para linter. Además, si encontramos algunos problemas que a menudo ocurren en la revisión y no hay linters en ellos, tratamos de encontrar linters que puedan atraparlos en teoría. Por lo tanto, no perdemos tiempo en la revisión.
Los linters nos permiten garantizar de alguna manera y tener una calidad de código predecible en el proyecto. Por ejemplo, en este caso, estos son argumentos de función no utilizados.
Linters le permiten encontrar errores críticos lo antes posible, ahorre tiempo de CodeReview. Al mismo tiempo, garantice cierta calidad del código para el proyecto.
Go tiene más de 50 cartas, pero las más populares son 4. Estas son las que están en la diapositiva. Se usan simplemente porque son geniales. El resto generalmente no quiere tratar. Ahora quiero mostrar con ejemplos qué tipo de linters hay. Quiero demostrar 25 ejemplos de linter. Ahora probablemente será lo más importante en el informe.
Comencemos con formateadores que verifican formateadores. Gofmt no es esencialmente un linter. Pero podemos considerarlo como un linter. Él sabe cómo decirnos que no hay suficientes avances de línea, en algún lugar espacios adicionales. En general, este es el estándar para verificar y mantener el formato del código.
Gofmt también tiene una opción -s poco conocida, que le permite simplificar expresiones.
Goimports contiene todo lo que contiene gofmt, pero además aún sabe cómo reordenar las importaciones, eliminar y agregar las importaciones necesarias.
Unindent es un linter tan maravilloso que puede reducir el nivel de anidación de código. En este caso, nos dice que si combinamos los dos ifs en uno, tendremos una caída en el nivel de anidación de uno en uno.
Consideremos linters comprobando la complejidad del código. El más genial de ellos es el gocyclo. El es el más aburrido. Muchos lo odian. Comprueba la complejidad ciclomática del código y jura cuando esta complejidad de la función supera algún umbral. El umbral es configurable. Si se simplifica, la complejidad ciclomática es la cantidad de if en el código. Aquí él es demasiado grande y la pelicula jura.
Nakedret es un linter que puede decir que usa return sin valores y al mismo tiempo lo usa en una función que es demasiado larga. Según la guía oficial, no se recomiendan dichas devoluciones.
Hay un grupo de estilo de prueba de linter. Por ejemplo, gochecknoglobals verifica que no esté utilizando variables globales. Por supuesto, no necesitan ser utilizados.
Golint jura por la misma variable apiUrl. Dice url debe usarse en mayúsculas. Desde esta abreviatura.
Gochecknoinits se asegura de que no estés usando las funciones init. Las funciones de inicio no deben usarse por ciertas razones.
Gosimple genial linter. Parte de staticheck o megacheck. Dentro de sí mismo contiene una gran cantidad de patrones para simplificar el código. En este caso, puede observar que strings.HasPrefix no es necesario, ya que strings.TrimPrefix ya contiene las comprobaciones necesarias y puede eliminarlas.
Goconst verifica que no tenga literales de cadena duplicados en su código que puedan extraerse en constantes. El número de estas repeticiones son configurables. En este caso, dos.
Linter de ortografía, que comprueba que no tiene errores tipográficos en el código en los comentarios. En este caso, la diapositiva contiene un error tipográfico de la palabra en el texto del comentario. Puede personalizar el dialecto del inglés: estadounidense, británico.
Desconvertir linter, que verifica que no hagas conversiones innecesarias. En este caso, la variable ya es de tipo cadena. No tiene sentido convertirlo.
Ahora veamos las linters que verifican el código no utilizado. El primero es varcheck. Comprueba las variables no utilizadas.
No utilizado puede maldecir en los campos de estructuras no utilizados.
Deadcode nos dice si no se usa un tipo.
O la función no se utiliza.
Unparam puede informar cuando los argumentos de la función no se usan en el cuerpo de la función.
Ineffassign informa cuando un cambio por una variable no se usa más en el código. Este es el resultado de algún tipo de refactorización. En algún lugar se olvidaron de limpiar algo o un error. En este ejemplo, el recuento se incrementa. Además, no se usa más. Esto es muy similar a un error.
Hay un grupo de rendimiento de prueba de linter. Por ejemplo, difamado nos dice que una determinada estructura testStruck se puede comprimir en tamaño reordenando los campos. Además, si lo ejecuta como parte de golangci-lint, tiene una opción que le permite imprimir inmediatamente el orden deseado de los campos, para no elegirlos usted mismo.
Hay una pelusa gocrítica tan genial. Tiene muchos cheques adentro. Uno de ellos es hugeParam. Ella sabe cómo informarnos sobre la copia de estructuras de datos pesados. En este caso, heavyStruct se copia por valor y solo necesitamos pasarlo como un puntero.
Prealloc puede encontrarnos lugares en el código donde podemos implementar previamente el segmento. Lo encuentra para buscar dónde hacemos iteraciones constantes por hora en el segmento. Y en ellos se añaden los asuntos. En este caso, puede preasignar la variable ret para la longitud del segmento ss y ahorrar memoria y CPU.
Y finalmente, linters que encuentran errores. Scopelint probablemente encuentra que el error más frecuente para los principiantes en ir es capturar la variable de rango de un bucle por referencia. En este caso, la variable de bucle arg se captura por referencia. En la próxima iteración, ya habrá un significado diferente.
Comprobación estática Solía llamarse megacheck. Ahora ha sido renombrado. Debido a esto, hay una pequeña confusión en la comunidad. Staticcheck puede encontrar toneladas de errores diferentes. Esto es algo realmente genial. Como ir al veterinario. Uno de ellos en la diapositiva es una carrera. Por supuesto, necesitamos incrementar sync.WaitGroup antes de ingresar a goroutine.
Ir veterinario encuentra principalmente errores. En este caso, la variable i se compara para que el resultado siempre sea verdadero. Por lo tanto, obviamente hay un error. En general, siempre debes usar go vet.
Gosec es sinónimo de seguridad. Encuentra posibles problemas de seguridad en Go. En este caso, los datos del usuario pueden llegar en arg. Por lo tanto, puede infiltrarse en el comando rm shell. Y aquí quizás shell en acción, por ejemplo. Observo que la seguridad con frecuencia produce falso positivo. Por lo tanto, a veces lo apago.
Errchek encuentra lugares donde olvidamos la comprobación de errores. Un estilo de programación bueno y seguro siempre está en todas partes para verificar todos los errores.
Dos linter deben notarse por separado: staticcheck y go-critico. Porque dentro de cada uno de ellos contiene docenas, si no cientos, de cheques. Por lo tanto, asegúrese de probarlos.
Ahora hemos examinado 25 ejemplos de linter. Y también dije que tenemos más de 50 cartas en Go. ¿Cuál usar? Te aconsejo que uses todo al máximo. Solo incluye todas las cartas que puedas. Luego, pasa una hora y comienza a apagarlos uno a la vez. Apaga los que te parezcan insignificantes. Por ejemplo, encuentra algunas optimizaciones de rendimiento que no le interesan en absoluto. Pasará una hora y creará su propia lista de linter para usted y podrá seguir viviendo con ella.
El catálogo completo de todas las listas está disponible en el enlace de la diapositiva.
Hablemos sobre cómo ejecutar linter. A veces, las linters se lanzan usando tales makefiles. El problema es que es lento. Todo se ejecuta secuencialmente.
Podemos hacer la ejecución en paralelo a través de xargs -P. También hay un problema. En primer lugar, estos son solo 4 linters. Y ya 10 líneas de código. ¿Qué sucede si activamos 20 cartas? En segundo lugar, esta paralelización es, por decirlo suavemente, no la más óptima.
Gometalinter viene al rescate. Gometalinter es un agregador de linters que puede ejecutarse literalmente en un par de comandos. En la diapositiva, el comando para iniciar la misma interfaz es similar a la diapositiva anterior. Pero no necesitan instalarse de forma independiente y no necesitan ser chamanizados con lanzamiento paralelo. Gometalinter ya está paralelizando todo bajo el capó. Pero tiene un problema fundamental. Comienza cada linter como un proceso separado. Lo bifurca. Si agregamos a esto el conocimiento de que cada linter dentro de sí mismo pasa el 80 por ciento del tiempo analizando el código y solo el 20 por ciento en el análisis en sí, resulta que desperdiciamos el 80 por ciento del trabajo. Y no reutilice los datos. Podríamos analizar el programa 1 vez y luego alimentar 50 linter.
Afortunadamente, hay golangci-lint que hace exactamente eso. Él analiza una vez. Tipos una vez. Otros analizadores corren sobre ellos. Debido a esto, funciona mucho más rápido. Un comando de lanzamiento similar en una diapositiva.
Puedes ver el gráfico en uno de mis proyectos 30 mil líneas de código. Un proyecto pequeño y solo 4 linter. Puedes notar una gran diferencia en la velocidad del trabajo a veces, tanto entre el lanzamiento secuencial como entre gometalinter y golangci-lint. Si estos linter no son 4, sino 20, la diferencia será mucho mayor.
Aclaración importante sobre gometalinter. Desde el 7 de abril, el autor del proyecto gometalinter declarándolo obsoleto. El repositorio se archivó y se aconseja a todos que cambien a golangci-lint, ya que es más rápido y tiene más beneficios allí. Por ejemplo, soporte para módulos go, etc.
Y además del rendimiento y los módulos Go, golangci-lint tiene bollos como la configuración YAML, la capacidad de omitir advertencias, excluirlas, etc.
Golangci-lint se configura utilizando el archivo golangci-lint.yaml. Un ejemplo de este archivo con una descripción de todas las opciones está en el enlace de la diapositiva. Considere, por ejemplo, la sección de configuración de linters. En esta sección vamos a configurar la importación. Tiene una opción tan rara de prefijos locales. En él, puede especificar la ruta al proyecto actual. En este caso, por ejemplo, github.com/local/repo.
Cuando goimports vea las importaciones locales en github.com/local/repo, se asegurará de que estén en una sección separada.
Para que estén al final. Para que estén separados de todas las importaciones externas. Esto facilita la distinción visual entre importaciones externas e internas. Si se da cuenta de que esto no es así, entonces lo jurará.
Y si también usa la opción golangci-lint run --fix, golangci-lint lo reparará automáticamente y volverá a ordenar las importaciones.
Hablemos sobre qué linters hay en la terminología golangci-lint. Linter se divide en rápido y lento. Los rápidos se llaman rápidos, marcados con la bandera rápida en ayuda. Se diferencian en que los linters rápidos requieren una representación bastante limitada del programa, por ejemplo, el árbol AST y alguna información de tipo. Mientras que los linters de cobre aún requieren el envío de SSA por parte del programa y reutilizan menos caché. Solo hay seis lentillas lentas. Están marcados en la diapositiva. Hay ciertos casos en los que tiene sentido ejecutar solo linter rápido.
Puede notar una diferencia en la velocidad. Es tremendo tres veces entre inicio rápido y lento. En realidad, golangci-lint run: solo se lanzan rápidas linters rápidos.
Sobre el caché de compilación. Existe tal cosa como construir caché. Este es el caché que el binario Go construye cuando compila el programa cuando se cargan los tipos, de modo que la próxima vez esta compilación sea más rápida. Los linters reutilizan el mismo caché para analizar programas para construir información de tipo. Puede notar que si borra el caché, el primer nuevo inicio será bastante largo. Y el próximo será 3 veces más rápido. Presta atención a tu primer lanzamiento de linter en tu proyecto. Siempre será mucho más lento.
Aquí puede concluir que tiene sentido en CI entre los lanzamientos de CI para reutilizar su caché. No solo acelerará las linters, sino que también acelerará las pruebas en ejecución, solo compilará y tal vez algo más. Aconsejo a todos.
No puedo hablar sobre ir análisis. Este es un nuevo marco que ha aparecido desde Go 1.12. Unifica las interfaces de tal manera que linter se vuelve fácil de escribir, linter es fácil de usar, ejecutar. Go veterinario comienza 1.12 en total, cambió por completo para ir al análisis. Obviamente, este es el futuro. Que cambiará enormemente todo el ecosistema de Go. Pero por ahora, generalmente es bastante temprano para hablar de eso. Entonces, ¿qué pasará después? Debido a que solo vi unos pocos linters en el análisis y casi ninguno de los existentes se ha cambiado todavía.
Si hace una breve conclusión sobre la sección de cómo ejecutar linters, entonces aconsejo a todos que usen golangci-lint. Rápidamente ejecutará linters convenientemente. No necesita chamán con otras instrucciones, comandos.
Hablemos sobre cómo implementar linter en el proyecto. Creo que todos los que intentaron introducir linters enfrentaron tal problema. Aquí tienes un proyecto para un millón de líneas de código con historial. Has convencido a TeamLead para implementar linters. Lanzamiento y ver un millón de mensajes. Comprende que no tienes tiempo para sentarte durante semanas para arreglarlo todo. Que hacer Puedes rendirte y dejarlo todo. O puedes pensar en algo.
En primer lugar, la opción más fácil, puede intentar excluir algunos comentarios de linters en el texto de forma regular utilizando la configuración golangci-lint.yaml. Si ve que hay comentarios que juran por los comentarios, pero generalmente no le importan estos comentarios, puede agregar a las excepciones.
Se pueden excluir formas. Por ejemplo, tiene un directorio de terceros y su código no está allí. No necesita verificarlo. Se puede excluir por nombres de archivo.
Si no desea excluir todo el archivo, puede excluir la función con nolint antes de la función. Para nolint, puede especificar a través de los dos puntos una lista de linters para los que actúa como una excepción. O no especificar, entonces todos los linter serán ignorados.
¿Cuándo usar nolint? Por ejemplo, uso nolint: deepguard, que puede capturar importaciones, es decir Las importaciones no pueden ser utilizadas. Sorprendí la importación de la biblioteca logrus para no usarla accidentalmente en lugar de mi registrador deseado. Pero en mi propio registrador uso logrus. Por lo tanto, solo necesito un lugar en el proyecto para hacer que solo un archivo se importe. Lo etiqueto con nolint.
Supongamos que hizo todo esto, agregue excluir, nolint affix. Vemos que todavía quedan miles de mensajes. Arreglalo unos días. Hay un truco genial. Veamos un ejemplo. Hay un archivo main.go en el que la quinta línea se agregó hace mucho tiempo, y la sexta línea se agrega solo hoy. Que podemos hacer
Podemos usar revgrep. Revgrep nos permite especificar una revisión de git, después de lo cual debemos buscar errores. Es decir, deje un mensaje para linter solo después de una revisión dada. Si la sexta línea se cambia después del origen maestro, entonces solo lo arreglará. Y todos los mensajes anteriores, no informará la quinta línea. . . . 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 . . . , .
Hablamos sobre la introducción de linter en cualquier proyecto. Ahora hablemos de la conveniencia del trabajo. Primero, debe lograr la reproducibilidad en CI. Tan pronto como agregue un linter a CI, necesita que sea estable. Nunca vayas a buscarlo. Porque no está versionado. Linter cambió en cualquier momento, se actualizó y todas sus compilaciones de CI comenzaron a fallar. He visto esto docenas de veces. Siempre use versiones específicas. Mejor con wget ponerlo. Ella será aún más rápida. Además, no recomiendo usar la opción --- enable-all para linter, porque en un día actualizas golangci-lint, por ejemplo, agregas 5 linter nuevos y toda tu compilación comienza a fallar. Porque accidentalmente encendiste estos linter. Es mejor prescribir explícitamente qué linters incluye.
Lo bueno es el gancho previo al compromiso. ¿Quién usa el gancho previo al compromiso levanta las manos? Bastante pequeño Pre-commit hook es un archivo git que le permite ejecutar código arbitrario después de que desea confirmar. Pero antes de que este compromiso tenga éxito. Si el enlace previo a la confirmación devuelve un error, la confirmación fallará. Por lo general, es conveniente incorporar pruebas rápidas, análisis estático, etc. Aconsejo a todos que incorporen golangci-lint. Puede hacerlo manualmente a través del script de shell. Es posible a través de la utilidad pre-commit. Un ejemplo de cómo configurar en una diapositiva. Instala pre-commit con pip, una utilidad para instalar paquetes de Python. pip install pre-commit instala la configuración. Golangci-lint ya admite la integración con pre-commit.
La opción --fast. Regresamos con ella. Aconsejo a todos que lo usen en el IDE. En general, el IDE, por supuesto, debe usar la integración con linters. Para que su IDE no se congele, asegúrese de usar la opción --fast.
Creo que esto es bastante obvio. En CI, las linters deben estar integradas. Si no los inserta, habrá una imagen clásica: "martilleemos ahora, ahora tenemos un lanzamiento, no antes de eso". Gradualmente tendrás más y más comentarios. Simplemente deja de mirar las linters como clase. Por lo tanto, estrictamente en CI. Además, simplemente puede instalar linters en CI, con la falla de compilación, subimos al registro de compilación, buscamos por qué cayó allí. ¿Dónde está el comentario, en qué línea? Esto no es muy conveniente.
Hay una forma más genial. Puede hacer que linter actúe como persona, como revisor. Pueden comentar sobre usted en github.com, gitlab.com para obtener una línea de código de error en su solicitud Pull. Linter puede escribir que encontró un problema. Esto es increíblemente genial. Esto ahorra tiempo al código de los autores. Porque no tienes que ir al registro de compilación. Además, una persona puede comentar si no está de acuerdo con este comentario de la pelicula. En el ejemplo de la diapositiva, esto se hace utilizando la utilidad reviewdog. Utilidad de código abierto. Ella es libre Puedes instalarlo tú mismo.
Además de reviewdog, también hay proyectos como GolangCI, Code Climate, Hound. Le permiten conectar estos linters con solo un clic a su almacén abierto o repositorios privados y comentar en línea en Solicitud de extracción. Todavía hay algo genial SonarQube.
No puedo mencionar goreportcard todavía. Este proyecto le permite crear un informe en su repositorio. Ponen calificaciones allí, dan una insignia, escriben qué tan bueno es su código para una docena de linter clean. También te aconsejo.
Me gustaría que vinieras a trabajar el lunes y pudieras aplicar algo de lo que dije. Aquí hay un resumen de lo que puede solicitar. Primero instale golangci-lint. Encienda todas las linters allí. Luego pasa 1 hora. Durante esta hora, apague todas las linters que le parezcan delirantes. Después de eso, incrustar golangci-lint en el CI, en el IDE y configurar el enlace de precompromiso. Justo después de eso, puede configurar --new-from-rev e indicar que desde la confirmación actual estamos buscando errores. Y todos los errores anteriores se solucionarán más adelante por separado. Después de eso, opcionalmente configure el reviewdog para que aún le comente en su github o en gitlab. Aumentará enormemente la calidad del proyecto con esto. Deleite a todo el equipo.
Gracias a todos por su atención. Mis contactos en la diapositiva.
Pregunta: Dígame, ¿tiene archivos de configuración listos para usar que puede poner en acceso abierto y que simplemente puede descargar y usar para no entender la tonelada de configuraciones de golangci-lint? Lo que recomiendas
Respuesta: buena idea. Golangci-lint ya tiene su propio golangci-lint.yaml, que utiliza. Puedes usarlo como punto de partida.
Pregunta: En la diapositiva sobre la memoria caché de compilación, consulte la memoria caché para módulos. En la memoria caché, especifique la memoria caché completa de los módulos. Puede especificar .cache / descargas, entonces habrá una diferencia bastante grande: 400 megabytes frente a 10. Esto es suficiente para simplemente extraer los módulos. Pero esto es solo si se utiliza el módulo.
Pregunta: ¿Apoyará también los módulos go o dep o entrará en algo en uno?
Respuesta: No es necesario uno apoya. Ahora hay una biblioteca de paquetes go. Ella se dedica a cargar el código fuente. Es compatible tanto con módulos como sin módulos. Todavía no lo hará, pero eliminará el soporte para los no módulos.
Pregunta: ¿Planea hacer varios complementos para la integración no solo con Travis, sino también con otros servidores de automatización?
Respuesta: golangci-lint no hace ninguna integración. Para ejecutar en CI, simplemente llame a golangci-lint --run.
Pregunta: Para analizar algunos informes, por ejemplo, en Jenkins, guardamos un archivo html.
Respuesta: Hay un formato de salida junit, csv, json xml. Todo esto ya se puede analizar.
Pregunta: utilizamos gometalinter antes y era lento. Luego cambiamos a un linter llamado revive. No lo mencionaste en absoluto. Y por mi parte, no soy un experto en el tema en absoluto. No sabía sobre tu linter, que estabas diciendo. ¿Podría escribir al final, digamos las ventajas de su linter o las ventajas de revivir?
Respuesta: revivir es un golint reescrito. Este es solo uno de los linter. Hay configuraciones. También agregó algunos linter, algunos cheques. Golangci-lint está dentro de sí mismo 30-50 linter. Este es un revivir una pelusa y media. Revive es genial porque toma golint y lo hace paralelo. Revive el trabajo más rápido que golint. Pero esto es solo un linter. Revive se puede hacer parte de golangci-lint.
Pregunta: Tuviste una diapositiva en la revisión de linters sobre gocritic: hugeParam, que se recomienda para transferir estructuras en negrita por puntero. Pero esto conducirá al hecho de que todas estas estructuras se asignarán exclusivamente en HEAP. ¿Y esto no conducirá a mayores problemas que ventajas? Si tales estructuras, por ejemplo, se transmiten mucho.
Respuesta: estoy completamente de acuerdo. No debe usar estas advertencias y no solo seguirlas. Puede ser como una optimización prematura, puede dañar el proyecto. Por lo general, apago esta clase de linters en general si no tengo el desempeño de una tarea crítica. donde encuentro debilidades con el perfilador.
Pregunta: Soy de Yandex. Usamos su linter en un gran repositorio. Notamos que ya está comenzando a trabajar muy rápidamente para un repositorio grande. En solo un par de días, escribieron una sencilla utilidad que a través de go package encuentra paquetes que han cambiado desde la introducción de la rama desde el asistente y paquetes que dependen de ellos. Y ejecute el linter solo sobre ellos. Y el chequeo de linter se aceleró varias veces.
Respuesta: Tal vez creará un idssue, adjuntará un script, y muy posiblemente incrustaré todo esto en golangci-lint.
Pregunta: ¿Se han planificado los niveles de seriedad de los comentarios para poder incluir algunos en el informe, pero no falsifica el proceso de CI? Por ejemplo, a través del código de finalización.
Respuesta: Mucha gente preguntó y diré de inmediato la dificultad de que estos niveles de seriedad los respalden a todos, hay 3 o 4 de cada 30 linter. ¿Qué hacer con el acero? No está claro Es necesario analizar manualmente sus comentarios, marcarlos de alguna manera. Manejar falsos positivos. Esto es generalmente una gran cantidad de trabajo. No estoy seguro de qué se hará cuando. Hay otras formas de lograr el mismo objetivo.
Pregunta: hay artículos en el centro Más precisamente, una serie de artículos sobre C ++ linter. La compañía está desarrollando este negocio. Ganan dinero con eso. De hecho, su trabajo, o más bien esta serie de publicaciones, ya no está dirigido a desarrolladores, sino más bien a aquellos que administran desarrolladores. Esto es esencialmente código puro, estilización. Esta es nuestra tarea, pero también la tarea de líderes, líderes de equipo. ¿Planea popularizar esta línea de medios aquí, en grandes recursos, para que la gente la lea y luego la presente a sus equipos? Y no tocamos desde abajo.
Respuesta: tenía un plan. Gracias por la sugerencia Tenía planes de escribir un artículo completo como este discurso, pero allí con más detalle y ampliamente durante todo el año. Quizás escribiré en ruso y en inglés.