Js-beautify: Admite el primer estilo de declaración de variable con coma

Teniendo en cuenta que admitimos tanto JS como Python, el parche (que está muy desactualizado) está incompleto, en el mejor de los casos.

Estamos abiertos a solicitudes de extracción, pero personalmente considero que "primero coma" es un antipatrón. En esencia, js-beautifier tiene opiniones sobre cómo debería verse JS, con opciones razonables que se ajustan en gran medida al JS "idiomático" ampliamente aceptado. Comma-first, en mi opinión, no es hermoso ni está ampliamente aceptado. Además, complicará gravemente el código de embellecimiento (que ya es increíblemente complicado) con muy poca ganancia.

Con indent=4 establecido, ¿qué sangría es apropiada? Desde un punto de vista de coherencia, diría esto:

var a = 1
    , b = "foo"
    , c = false;

Que claramente no es el resultado esperado. ¿Y cómo se vería con tabulaciones?

¿Dónde vive el punto y coma? ¿Al final? ¿En ningún lugar? (He visto ambos y más)

Esta esencia está igualmente desactualizada, pero facilita la comprensión del cambio deseado: https://gist.github.com/nemtsov/2864266/revisions

Esto es similar al # 80, por lo que pensé que las razones podrían ser las mismas: diferenciar y reordenar más fácilmente.

Pero en este escenario, a diferencia del n. ° 80, existe una solución alternativa viable que cumple con esos requisitos:

var a = 1;
var b = "foo";
var c = false;

Es un poco más detallado, pero no horrendo.

Por supuesto, si alguien implementa el # 80, el cambio más simple probablemente también cubriría este escenario.
Como dijo @evocateur , las solicitudes de extracción son bienvenidas.

@evocateur : Tienes derecho a tu opinión y la respeto. En lo personal siempre he disgustaba coma primer estilo, pero durante los años, he llegado a apreciar la facilidad de movimiento, sacando (comentando, borrado, etc.) y como dice @bitwiseman - diffing. Así que estoy dispuesto a dejar esto como una opción y dejar que el usuario haga lo que prefiera. A veces, no está en sus manos y tiene que seguir los estándares ya establecidos. ¡Sí, feo pero realidad!

@bitwiseman : En cualquier nivel de sangría (2 o 4), supongo que así es como debería verse:

var a = 1
  , b = "foo"
  , c = false;

Creo que esto también es coherente con la forma en que lo hacen algunos de los editores de SQL (donde la coma primero es más frecuente).

Y aunque no estoy abogando por promover malos diseños, supongo que siempre hay una delgada línea entre ser idiomático y dogmático (piense en Crockford aquí). Es posible que la coma primero no sea frecuente porque muchos de los formateadores no la admiten, sea cual sea el motivo.

Estás más familiarizado con el estado de las cosas en lo que respecta al código, así que estoy perfectamente de acuerdo con tu argumento de ROI. Sin embargo, pensé en preguntar para que podamos sacar estas cosas a la luz, tener un quórum para discutir las cosas y si hay demanda de la comunidad, tal vez ustedes puedan reconsiderarlo.

PD: Pasé un par de horas tratando de ver si podía sacar algo rápidamente y no tuve mucho éxito. Tal vez lo intente en otro momento.

@mrchief Mis disculpas por ser brusco ayer, estaba tomando un descanso de una frustrante sesión de depuración. Haces buenos puntos y quiero dejar claro que también respeto tu elección. Yo mismo intento mantener el estilo de un proyecto dado si estoy contribuyendo con un parche (primero con coma, sin punto y coma, otras locuras), y estoy de acuerdo en que opciones como estas pueden al menos ayudar a hacer cumplir un poco de coherencia en los proyectos que eligen emplearlos.

+1. Utilizo el patrón de coma primero por sus ventajas al diferenciar y fusionar.

En cuanto a la posición del punto y coma: lo puse en una nueva línea, en línea con la palabra clave var , así:

var a
  , b
  , c
;

He visto varios proyectos que usan el mismo patrón.

Además, en mi humilde opinión, creo que sería bueno poder mantener cada variable en una línea separada, aunque no se proporciona un valor al lado de la declaración. En el ejemplo anterior, el embellecedor agruparía todo en una línea var a, b, c; que también rompe todo el propósito de usar el estilo de puño de coma.

+1 para soporte de coma primero.

Con sangría de 2 espacios, es la forma más ordenada de organizar las variables:

var foo = true
  , bar = 'hello'
  , something;

¿Qué hay de 4 espacios por pestaña? ¿Pestañas reales?

El viernes 8 de noviembre de 2013 a las 9:36 a.m., Luke Martin [email protected]
escribió:

+1 para soporte de coma primero.
Con sangría de 2 espacios, es la forma más ordenada de organizar las variables
var foo = verdadero
, bar = 'hola'

, alguna cosa;

Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/einars/js-beautify/issues/245#issuecomment -28081629

Supongo que el quid de la cuestión de las comas primero se reduce a la preferencia de pestaña.

Utilizo pestañas de 2 espacios, y la coma antes es la única forma de organizar las variables sin agregar espacios en blanco innecesarios (~ representan espacios adicionales agregados para alinear las cosas):

// eww
var foo = true,
  ~~bar = 'hello',
  ~~something;

// yum
var foo = true
  , bar = 'hello'
  , something;

Por el contrario, si usa pestañas de 4 espacios, la coma antes se verá mal y, naturalmente, no le importará el soporte.

// also eww
var foo = true
    , bar = 'hello'
    , something;

Entonces hay una discusión sobre la coma, antes de que sea más fácil comentar y depurar y bla, bla, bla. Pero para mí, todo se reduce a la estética. Utilizo pestañas de 2 espacios, por lo que necesito usar coma antes. Actualmente no puedo usar beautify porque prefiero las pestañas de 2 espacios.

Ahora sé que probablemente soy una minoría y no estoy exigiendo absolutamente ningún apoyo para mi pequeña preferencia. Solo estaba agregando mi +1 a la conversación. Incluso podría considerar agregar apoyo yo mismo si tengo tiempo.

Salud :)

Me gustaría ver esto para los objetos json.

 var a = ({
 a: 1
 , b: 2
 });

@lukemartin ¡ Esa es una perspectiva interesante! : +1:

Otro +1 para el soporte de la coma primero, para la declaración de variables, así como para matrices y objetos: https://gist.github.com/isaacs/357981

He estado trabajando en un parche para admitir esta función "a pedido" (el usuario puede habilitar o deshabilitar la opción de usar la coma primero con una configuración que he creado).

Logré el siguiente formato para la declaración de variables (usando 2 espacios):

var firstVar = 1
  , secondVar = 2
  , thirdVar = 3
;

Pero tengo algunas dudas.

¿Cómo debemos tratar las declaraciones de matrices, objetos y argumentos? Últimamente he estado usando el siguiente formato:

myArray = [
  item1
, item2
, item3
];

myObject = {
  prop1: 1
, prop2: 2
, prop3: 3
}

El cual, como puede ver, no es exactamente el mismo que el formato de declaración de variable: este último incluye un nivel de sangría +1 para la segunda variable (observe los dos espacios antes de la coma que no están presentes antes de la coma para "item2" ni para el de "prop2"). Las declaraciones de var usan esta sangría adicional para alinear en la misma columna el inicio de cada nombre de variable como lo indica @lukemartin.

Las razones para usar el formato que se muestra en el código anterior son:

1.- Para evitar los errores de pelusa que arrojaría jshint (errores de sangría). Por ejemplo:

myArray = [
    item1
  , item2
];

Lanza "Se esperaba] para tener una sangría en 3, en lugar de 1". Si seguimos la sugerencia, obtenemos un resultado muy feo.

2.- Mantener la ventaja de alinear el inicio de cada nombre de propiedad, elemento de matriz, etc. Por ejemplo:

myArray = [
  item1
  , item2
];

Tampoco produce un error de pelusa, pero no se ve tan bien como los ejemplos anteriores.

Con una idea más clara de cómo debo tratar esos casos, podría finalizar la implementación de esta función y emitir una solicitud de extracción.

¿Es posible soportar todo lo anterior? Todo lo que enumeró es técnicamente "coma primero".

Creo que podría ser posible, pero sería necesario implementar más configuraciones que permitan al usuario lograr el resultado deseado. Por ejemplo, sería necesario decirle al formateador si desea usar 2 niveles de sangría para matrices, objetos y argumentos o solo uno.

Creo que sería mejor lograr primero la funcionalidad básica y luego extenderla con más configuraciones. Creo que no tendría problemas para implementarlos en un segundo parche.

Como dices, la funcionalidad básica está bien. Es un _no objetivo_ de este proyecto admitir _todas_ las opciones de formato. :sonrisa:

// 2-space indents
var itemA = 1
  , itemB: 2
  , itemC: 3;

myObj = {
  itemA: 1
  , itemB: 2
}

myArray = [
  item1
  , item2
];

// 4-space indents
var itemA = 1
    , itemB: 2
    , itemC: 3;

myObj = {
    itemA: 1
    , itemB: 2
}

myArray = [
    item1
    , item2
];

Estos deben mantener su código simple, el formato consistente sin importar qué sangrías se usen, y nos permite cerrar este problema y abrir un nuevo problema para "Columnizar identificadores con coma primero" (o lo que sea) que se puede especificar e implementar por separado. .

¡Espero ver tu solicitud de extracción!

@tgirardi Gran trabajo. No puedo esperar para probar esto.

Todos los comentarios son bienvenidos :-) !!!

Mi idea es ajustar el código hasta que se considere la solución correcta y luego proceder con la siguiente lista de TODO:

1.- Crea pruebas para esta nueva característica
2.- Aplicar la función en la versión de Python (si alguien se ofrece voluntario para esto, ¡incluso mejor! ... No tengo mucha experiencia con Python).
3.- Discutir otras posibles variaciones de estilos de coma primero

Sangría de 4 espacios

var x = a
    , y = b
;
obj = {
    attr1: "value1"
    , attr2: "value2"
    , attr3: "value3"
};

No es necesario alinear los nombres de las variables y los nombres de los atributos. Esto no afecta la legibilidad en absoluto. En mi opinión, la razón principal para usar la columna primero es facilitar los comentarios, la eliminación e inserción de líneas. Simplemente se alinea cuando se usa sangría de 2 espacios.

La semicolumna debe estar en su propia línea después de la declaración de múltiples variables para que sea más fácil agregar una nueva variable después de 'y'. En este caso en VIM, 'o' + ', z = c' en lugar de '$ a,'+' z = c '

@lewisdiamond Estoy de acuerdo con su comentario de punto y coma. Tenerlo en su propia línea asegura que la última variable también se pueda editar fácilmente (eliminar, reemplazar, insertar línea después / antes, etc.).

Pero también se ha observado que:

1.- No es el objetivo del proyecto soportar todo tipo de formato.
2.- Agregar demasiada complejidad a la vez es una mala idea. Por lo tanto, podría ser mejor mantener esta función lo más simple posible primero y comenzar a mejorarla después de que haya alcanzado un estado de lanzamiento y se haya probado durante algún tiempo.

+1 para el soporte primero con coma, y ​​estoy de acuerdo con la opinión de lewisdiamond de que garantizar que las pestañas se alineen correctamente no debería ser el objetivo final, ya que existen razones pragmáticas para el estilo del primer coma. También me encantaría el soporte para json. Actualmente tengo un truco en el código js-beautify global para hacer muchas alternativas de puntuación primero (para los operadores ternarios era una necesidad).

Para todos los que hicieron +1 en esto: echen un vistazo a la sucursal https://github.com/beautify-web/js-beautify/tree/feature/comma-first .

Dime si este es un primer paso suficiente hacia lo que quieres, que debería agregarlo a la próxima versión.

@olsonpm , @lukemartin , @mrchief , ¿ podrían echar un vistazo a la sucursal https://github.com/beautify-web/js-beautify/tree/feature/comma-first ?

Esta noche dedicaré 30 minutos a ello y responderé con pensamientos. Gracias por hacer un seguimiento.

Me puse a hacerlo esta mañana. Todo me parece bien gracias a tus pruebas. Tengo una rama personal con mucha funcionalidad de primer operador: puse mis pruebas de coma primero a través de su rama y todas no pasaron ningún problema, lo cual es una gran noticia.

Cuando creé mi rama personal, decidí que el operador de coma primero sería pasivo, es decir, lo siguiente:

var a,
    b;

no se cambiaría. Usted indicó claramente que este no es el caso en el mensaje de confirmación, solo creo que vale la pena discutir con otros qué comportamiento esperarían si optaran por usar opt.comma_first.

Otra cosa, <Output> .previous_line y flags.previous_text son lo mismo que creo, lo cual me confundió al principio pero tenía sentido en cómo lo usaste.

Aparte de eso, la principal diferencia entre nuestras implementaciones es que optó por modificar la línea anterior. Estaba tratando de no "volver atrás y editar cosas" porque pensé que era más confuso desarrollarlo. Ahora tu forma es más concisa que la mía, se lee fácilmente y comentaste todo. El código existente también edita tokens anteriores para que su código esté perfectamente alineado; honestamente, solo lo menciono porque me gustaría saber cuáles son sus pensamientos. En resumen, mi opinión es que este programa sería mucho más fácil de depurar si los tokens solo estuvieran a cargo del espacio en blanco delante de ellos en función de los siguientes tokens.

¡Gracias por abordar esto!

Editar: Mi error: <Output> .previous_line y flags.previous_text son completamente diferentes.

Es preferible solo reenvío. Miré la bola de pelo de cómo y dónde decidimos qué hacer con / sobre las comas, ya hay lugares en los que recortamos la salida para colocarlos en el lugar correcto. Decidí hacer algo un poco simplista, obtener algunas pruebas que verifiquen el comportamiento simplista y luego ver cómo ajustarlo y refactorizarlo más tarde.

El ejemplo que mencionas:

var a,
    b;

Sería un ejemplo de tuning que se podría comentar más adelante.

Suena bien. Agradezco los comentarios.

Y muchas gracias por revisarlo. Si tiene alguna prueba que desee agregar, sería de gran ayuda.