From 060e9bffdcc19ae101dd66724c0c10e13257a042 Mon Sep 17 00:00:00 2001 From: Kirill Mokevnin Date: Fri, 14 Aug 2026 07:42:21 -0400 Subject: [PATCH] =?UTF-8?q?docs(linting):=20FEEDBACK-252=20=D0=B8=D1=81?= =?UTF-8?q?=D0=BF=D0=B0=D0=BD=D1=81=D0=BA=D0=B0=D1=8F=20=D0=BA=D0=BE=D0=BF?= =?UTF-8?q?=D0=B8=D1=8F=20=D1=83=D1=80=D0=BE=D0=BA=D0=B0=20=D1=80=D0=B0?= =?UTF-8?q?=D1=81=D1=81=D0=BA=D0=B0=D0=B7=D1=8B=D0=B2=D0=B0=D0=B5=D1=82=20?= =?UTF-8?q?=D0=BF=D1=80=D0=BE=20=D1=84=D0=BE=D1=80=D0=BC=D0=B0=D1=82=D1=82?= =?UTF-8?q?=D0=B5=D1=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Перенос правки из ru-копии (коммит 6fd2a4c) в es. Текст урока дублируется в двух файлах, es/README.md и description.es.yml, поэтому правка внесена в оба. Java-проекты Хекслета перешли с checkstyle на spotless с google-java-format, и урок про линтер об этом молчал. Заодно снято обещание, что линтер работает в практиках: он там не работает, проверка стиля живёт в проектах. Co-Authored-By: Claude Opus 5 (1M context) --- modules/20-arithmetics/80-linting/description.es.yml | 6 +++++- modules/20-arithmetics/80-linting/es/README.md | 6 +++++- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/modules/20-arithmetics/80-linting/description.es.yml b/modules/20-arithmetics/80-linting/description.es.yml index cde1eeb..697eacd 100644 --- a/modules/20-arithmetics/80-linting/description.es.yml +++ b/modules/20-arithmetics/80-linting/description.es.yml @@ -38,7 +38,11 @@ theory: | Ahora el linter no mostrará errores. ¿Qué conclusión podemos sacar? El linter ayuda a escribir código que es más fácil de leer y analizar. - Recuerda que tener un linter no reemplaza el análisis y la simplificación independiente del código. En tus futuras prácticas en [Hexlet](https://ru.hexlet.io/?utm_source=code-basics&utm_medium=referral&utm_campaign=programs&utm_content=lesson) y en el desarrollo real, el linter funcionará y te informará sobre cualquier violación. + El linter solo informa de la infracción. Para corregir el código se utilizan los formateadores, programas que ajustan el código al estándar por sí mismos. + + En Java el formateo se configura con el plugin [spotless](https://github.com/diffplug/spotless). El formato en sí lo define [google-java-format](https://github.com/google/google-java-format), el estándar de estilo de Google. Basta un comando para que todo el código del proyecto quede uniforme, así que no hace falta discutir en el equipo dónde van los espacios y los saltos de línea. + + Recuerda que tener un linter no reemplaza el análisis y la simplificación independiente del código. En los proyectos de [Hexlet](https://ru.hexlet.io/?utm_source=code-basics&utm_medium=referral&utm_campaign=programs&utm_content=lesson) y en el desarrollo real la comprobación del estilo forma parte de la compilación, y el código con infracciones no llega a la revisión. instructions: | diff --git a/modules/20-arithmetics/80-linting/es/README.md b/modules/20-arithmetics/80-linting/es/README.md index 2fd42ce..c9b153f 100644 --- a/modules/20-arithmetics/80-linting/es/README.md +++ b/modules/20-arithmetics/80-linting/es/README.md @@ -34,4 +34,8 @@ System.out.println("I'm a developer!"); Ahora el linter no mostrará errores. ¿Qué conclusión podemos sacar? El linter ayuda a escribir código que es más fácil de leer y analizar. -Recuerda que tener un linter no reemplaza el análisis y la simplificación independiente del código. En tus futuras prácticas en [Hexlet](https://ru.hexlet.io/?utm_source=code-basics&utm_medium=referral&utm_campaign=programs&utm_content=lesson) y en el desarrollo real, el linter funcionará y te informará sobre cualquier violación. +El linter solo informa de la infracción. Para corregir el código se utilizan los formateadores, programas que ajustan el código al estándar por sí mismos. + +En Java el formateo se configura con el plugin [spotless](https://github.com/diffplug/spotless). El formato en sí lo define [google-java-format](https://github.com/google/google-java-format), el estándar de estilo de Google. Basta un comando para que todo el código del proyecto quede uniforme, así que no hace falta discutir en el equipo dónde van los espacios y los saltos de línea. + +Recuerda que tener un linter no reemplaza el análisis y la simplificación independiente del código. En los proyectos de [Hexlet](https://ru.hexlet.io/?utm_source=code-basics&utm_medium=referral&utm_campaign=programs&utm_content=lesson) y en el desarrollo real la comprobación del estilo forma parte de la compilación, y el código con infracciones no llega a la revisión.