c++ - En formato clang, ¿qué hacen las penalizaciones?
clang-format (2)
La documentación de las opciones de estilo de clang-format incluye una serie de opciones llamadas PenaltyXXX. La documentación no explica cómo deben usarse estas sanciones. ¿Puede describir cómo usar estos valores de penalización y qué efecto logran (quizás con un ejemplo)?
¿Puede describir cómo usar estos valores de penalización y qué efecto logran (quizás con un ejemplo)?
Puede ver un ejemplo en este clang-format de clang-format Git 2.15 (Q4 2017) para el proyecto de Git escrito en C:
Ver commit 42efde4 (29 de septiembre de 2017) por Johannes Schindelin ( dscho ) .
(Combinado por Johannes Schindelin - dscho - in commit 42efde4 , 01 oct 2017)
Puedes ver los valores antiguos y nuevos aquí:
Para ilustrar esos valores:
clang-format: ajustar las penalizaciones de salto de líneaRealmente, realmente, realmente queremos limitar las columnas a 80 por línea: uno de los pocos comentarios de estilo consistentes en la lista de correo de Git es que las líneas no deben tener más de 80 columnas / línea (incluso si 79 columnas / línea lo harían). más sentido, dado que el código se ve con frecuencia como dif, y diff agrega un carácter adicional).
Sin embargo, la penalización de 5 por el exceso de caracteres es demasiado baja para garantizarlo, como lo señaló Brandon Williams.
( Ver este hilo )
De los ejemplos y la documentación existentes en formato Clang, parece que 100 es una penalización que se considera apropiada para las
Stuff You Really Don''t Want, así que asignémosla como la penalización por "exceso de caracteres", es decir, líneas demasiado largas.Mientras lo hace, ajuste las penalizaciones aún más: en realidad no estamos tan interesados en evitar nuevos saltos de línea en los comentarios o en los literales de cadena, por lo que la penalización de 100 parece terriblemente alta.
Del mismo modo, no somos tan firmes en cuanto a mantener los saltos de línea lejos de los operadores de asignación (muchos de los códigos de Git se separan inmediatamente después del carácter
=solo para mantener ese límite de 80 columnas / línea).Fruncimos el ceño un poco más sobre los tipos de retorno de las funciones que están en su propia línea de lo que sugiere la penalización 0, por lo que esto también se ajustó.
Finalmente, no nos gusta particularmente romper el primer parámetro en una llamada, pero si mantiene la línea más corta que 80 columnas / línea, eso es lo que hacemos, así que reduzcamos la penalización por interrumpir el primer parámetro de una llamada, pero no tanto. tanto como introducir nuevos saltos de línea a los comentarios.
Cuando tienes una línea que supera el límite de longitud de la línea, el formato de Clang necesitará insertar uno o más saltos en algún lugar . Puede pensar en las penalizaciones como una forma de desalentar cierto comportamiento de ruptura de líneas. Por ejemplo, digamos que tienes:
Namespaces::Are::Pervasive::SomeReallyVerySuperDuperLongFunctionName(args);
// and the column limit is here: ^
El formato de Clang probablemente se formateará para parecer un poco extraño:
Namespaces::Are::Pervasive::SomeReallyVerySuperDuperLongFunctionName(
args);
Puede decidir que está dispuesto a violar la longitud de la línea con un carácter o dos para casos como este, por lo que puede dirigir eso al establecer el PenaltyExcessCharacter en un número bajo y PenaltyBreakBeforeFirstCallParameter en un número más alto.
Personalmente, realmente no me gusta cuando el tipo de retorno está en su propia línea, así que establezco PenaltyReturnTypeOnItsOwnLine a un número absurdamente grande.
Además, este sistema fue heredado de Latex, que le permite especificar todo tipo de penalizaciones por ruptura de línea, paginación y guiones.