Definitelytyped: ¿Pestañas vs espacios?

No hay batalla. Utilice pestañas.

¡Voto espacios!

¡Que comience el conflicto interno! :sonrisa:

ja ja. no lo necesitamos. Pero ya sabes ... no estaríamos teniendo esta conversación si estuviéramos usando pestañas y cada desarrollador aún tendría su código perfectamente alineado de la manera que quisiera (2 espacios o 4 espacios). Solo digo.

Me gusta la pestaña.
pero creo que deberíamos adherirnos a la configuración predeterminada de VisualStudio.

Espacios con un tamaño de sangría de 4 (valores predeterminados de VS).
Configure su IDE para que haga pestañas virtuales para usted y para todos.
Simplemente no me gusta ver [tabulación] [tabulación] [espacio] [espacio] [espacio] para el código que quiere alinearse con una palabra en la línea de arriba.

Si alguien tiene ganas de escribir una regla TSLint para imponer un estilo coherente (por ejemplo: pestañas o 4 espacios, pero no ambos), lo ejecutaríamos en un nuevo probador (tiene soporte TSLint).

Véase también https://github.com/palantir/tslint/issues/122

Espacios! FWIW JS libs usan espacios (angular / jquery)

Esto probablemente se debió a Crockford: http://javascript.crockford.com/code.html

La unidad de sangría son cuatro espacios. Se debe evitar el uso de pestañas porque (a partir de este escrito en el siglo XXI) todavía no existe un estándar para la ubicación de las pestañas. El uso de espacios puede producir un mayor tamaño, pero el tamaño no es significativo en las redes locales, y la diferencia se elimina mediante la minificación.

Dado que TS es JS, realmente deberíamos conformarnos.

Bueno, Crockford es un viejo gruñón, así que lo tomo con un grano de sal.

Hace un tiempo, hubo una estadística en Reddit en la que alguien analizó una parte decente de Github y fue como un 60% / 40% a favor de los espacios. Yo y todos los lugares en los que trabajé hasta ahora eran pestañas (aunque gran parte de eso era AS3). Funciona totalmente bien. La alineación del código es una pérdida de tiempo, pero si es necesario, las pestañas inteligentes también funcionan bien.

La verdadera pesadilla de la que quiero deshacerme son los _indents_ mixtos. Antes de volvernos termonucleares en uno u otro en todo el repositorio, al menos debe ser coherente _por archivo_.

En algún momento haremos # 2228, pero eso es un gran paso (arruina muchas atribuciones para que podamos dejar que @ dt-bot lo haga).

Bueno, Crockford es un viejo gruñón, así que lo tomo con un grano de sal.

acordado

Si alguna vez te aburres, te aconsejo que leas las solicitudes de extracción realizadas a JSON.js. invariablemente son sometidos por personas que no conocen las maneras un poco cascarrabias de Doug. Todos son rechazados a quemarropa :-)

Acabo de ver esto: https://github.com/iplabs/typescript/blob/languageService-v2/src/services/languageService.ts#L199 -L213 los valores predeterminados son 4 espacios con pestañas convertidas en espacios

    export class EditorOptions {
        public IndentSize: number = 4;
        public TabSize: number = 4;
        public NewLineCharacter: string = "\r\n";
        public ConvertTabsToSpaces: boolean = true;

        public static clone(objectToClone: EditorOptions): EditorOptions {
            var editorOptions = new EditorOptions();
            editorOptions.IndentSize = objectToClone.IndentSize;
            editorOptions.TabSize = objectToClone.TabSize;
            editorOptions.NewLineCharacter = objectToClone.NewLineCharacter;
            editorOptions.ConvertTabsToSpaces = objectToClone.ConvertTabsToSpaces;
            return editorOptions;
        }
    }

¡Qué satisfactorio @basarat!

Los CRLF son un poco estúpidos, pero lo que sea.

Quizás deberíamos ir a por ello. Intentaré ejecutar mecanografiado-formateador en todo y veré qué sucede.

Estimado señor, qué matadero ... 562 archivos .d.ts en total, con 446 archivos cambiados ...

https://github.com/Bartvds/DefinitelyTyped/tree/34907936bfc22562f30bb09ee82282ca0515b8b3

https://github.com/Bartvds/DefinitelyTyped/commit/34907936bfc22562f30bb09ee82282ca0515b8b3

Lo sentimos, no pudimos mostrar la diferencia completa porque cambiaron demasiados archivos (446)

Je.

Y también hicieron las pruebas:

https://github.com/Bartvds/DefinitelyTyped/tree/46f9d17b2b074c887bff35b06112070b28924248

https://github.com/Bartvds/DefinitelyTyped/commit/46f9d17b2b074c887bff35b06112070b28924248

Lo sentimos, no pudimos mostrar la diferencia completa porque cambiaron demasiados archivos (442).

Bonito. Así que tenemos la tecnología, esa fue la parte fácil. Pero ahora tenemos que decidir si esto es algo que queremos porque tendrá un impacto serio.

Por una línea, la atribución se está yendo al infierno. Y si aceptamos eso, probablemente deberíamos aplicar el formato en el probador. Tengo la configuración de TSLint en el probador (pero está deshabilitado), por lo que puedo hacer mucho.

Tal vez deberíamos mejorar el probador a una utilidad CLI que pueda ejecutar el formateador y ejecutar las pruebas, de una manera agradablemente utilizable (en cierto modo, ahora funciona localmente, pero debería mejorarse con una API CLI limpia, etc.).

Yo digo que cuanto antes mejor. Pero la buena noticia es que no perderá el historial de culpas . Desearía que GitHub también hubiera implementado esta función en su vista de diferencias.

Sí, pero apesta que git blame -w -M no funcione en línea. Acabo de enviar un correo electrónico al soporte de Github al respecto.

@Bartvds , ¿alguna respuesta de GitHub?

Ignorar los espacios en blanco en la vista de culpa de GitHub no es posible actualmente, pero podríamos agregarlo en el futuro. Gracias por la sugerencia, la agregaré a la Lista de solicitudes de funciones para que el equipo pueda verla.

Así que podría llevar un tiempo, si es que alguna vez lo hiciera.

No me importa lo que digan los supuestos sabelotodo o las guías de estilo: las pestañas para la sangría son la única forma de preservar la intención del desarrollador cuando se trata de alineación. Vea la publicación de mi blog al respecto .

el concepto de alineación de código (alinear en var y = en su caso) es bueno. Pero uno difícil de mantener en refactorizaciones. Así que simplemente no lo uso. Además, las herramientas de formato automático no lo respetan, por ejemplo , el código de formato automático en TypeScript

También por

  public string FirstName { get; set; }        =>  public  string  FirstName { get; set; }    
  public string Surname { get; set; }          =>  public  string  Surname   { get; set; }
  public int Age { get; private set; }         =>  public  int     Age       { get; private set; }
  private Address Address { get;  set; }       =>  private Address Address   { get; set; } 

Agregue una nueva propiedad y necesita _reformatear_ todas estas líneas. No es un buen cambio de código para revisar.

Su flujo de trabajo puede ser diferente y podría permitirlo. Hace que sea mucho más fácil de leer (código como arte) pero no he logrado experimentar que los equipos lo muevan.

Es la cosa más extraña. Mi reacción instintiva a la idea de mezclar pestañas y espacios es estremecerme y pensar "¡eso es asqueroso!"

Completamente irracional, lo sé, pero completamente sincero. Los humanos son raros ...

@johnnyreilly eres víctima de un error común . Usar tabulaciones para sangría y espacios para alineación NO es lo mismo que _mezcla_ tabulaciones con espacios. Claramente no leíste la publicación del blog.

El uso de pestañas para la alineación es la razón por la que tantos se han desactivado de las pestañas, porque la gente lo estaba haciendo mal. Si lo hubieran estado haciendo correctamente en primer lugar, nadie se habría dado cuenta cuando cambiaron la preferencia de su editor para mostrar el ancho de la pestaña en un tamaño diferente. Esto es lo que el gif animado, arriba, está tratando de demostrar, cómo la gente lo ha estado haciendo mal.

@basarat , estoy totalmente de acuerdo contigo. Rara vez trabajo en proyectos con alineación de código, pero lo veo de vez en cuando. Si de alguna manera pudiera hacer cumplir que los desarrolladores de su proyecto no usen la alineación en absoluto, entonces diría que lo haga. De lo contrario, con espacios para la sangría, no hay forma de que las herramientas de deshilachado, entre otras, distingan entre lo que se pretendía para la sangría y lo que se pretendía para la alineación, fuera de analizar el código en CST (exceso de velocidad).

Por supuesto, hay muchas otras razones para no usar espacios para sangrar en esta era moderna. Los editores manejan bien las pestañas, pero nunca lo han hecho con los espacios. Navegación con las teclas de flecha, eliminar, retroceder: simplemente no tratan una sangría de espacios como una unidad. He usado Visual Studio, Sublime, PHPStorm y Notepad ++, pero todos tienen este problema fundamental con los espacios para la sangría.

Navegación con las teclas de flecha, eliminar, retroceder: simplemente no tratan una sangría de espacios como una unidad.

Navegación: uso ctrl + teclas de flecha. Saltan espacios (todos los espacios en blanco en realidad) + palabras.

Para eliminar / retroceder: para la selección de palabras, utilizo expandir palabra (ctrl + w de los valores predeterminados de reajuste) y no expandir la selección (ctrl + shift + w). Sin embargo, rara vez necesito seleccionar un espacio en blanco _inside_, solo use la pestaña (aumentar la sangría) y la pestaña de desplazamiento (disminuir la sangría).

@jedmao en realidad entendí tu punto, solo estaba compartiendo mi reacción instintiva (e irracional). No dije que tuviera sentido: sonríe:

@johnnyreilly te tengo .

@basarat Yo uso las Home y End en algunos de sus escenarios de espacios en blanco. He intentado utilizar la navegación Ctrl + arrow key pero no siempre funciona. Es por eso que rara vez lo uso por coherencia mental. Considere el siguiente ejemplo:

for (var i = 0; i < 10; i++) {
    if (i > 5) {
        console.log('I am greater than 5');
    }
}

Digamos que mi cursor está al comienzo de la línea 3 y quiero navegar hasta el comienzo de la línea 2.

Usando tu técnica en Sublime, podría hacerlo de dos maneras:

• Up , Hold Ctrl , Left , Release Ctrl (4 pasos lógicos)
• Hold Ctrl , Left , Release Ctrl , Up , Hold Ctrl , Right , Left , Release Ctrl (8 pasos lógicos)

En Visual Studio, el segundo escenario se puede reducir a 7 pasos lógicos.

• Hold Ctrl , Left , Release Ctrl , Up , Hold Ctrl , Right , Release Ctrl (7 pasos lógicos)

Con los caracteres de tabulación reales, la ruta más corta es de solo 2 pasos lógicos sin teclas modificadoras. No podría ser más sencillo.

• Left , Up

No veo cómo la selección de palabras ayudaría a eliminar o retroceder una sangría espaciada. Lo estoy probando en Visual Studio sin éxito. Es por eso que creé el complemento TabSanity para Visual Studio . Desafortunadamente, no tengo conocimiento de este tipo de complementos para otros editores.

Con los caracteres de tabulación reales, siempre son 2 pasos lógicos sin teclas modificadoras. No podría ser más simple

: +1: Veo tu ventaja. Sin embargo, a medida que edito este comentario, ctrl, etc.funciona igual que mi VS, por lo que mis hábitos se trasladan;)

No veo cómo la selección de palabras ayudaría a eliminar o retroceder una sangría espaciada

Mi mal, mi descripción era confusa. Ignore el bit de selección de "palabra". Solo concéntrate en I rarely need to select inside whitespace though, just use tab (increase indent) and shift tab (decrease indent). Funciona bien con sangrías espaciadas.

Con los caracteres de tabulación reales, siempre son 2 pasos lógicos sin teclas modificadoras.

Qué pasa :

public  string  FirstName { get; set; }    
public  string  Surname   { get; set; }
public  int     Age       { get; private set; }
private Address Address   { get; set; } 

¿No ir desde el principio de Age a cambiar el tipo de Surname es decir, el string en la línea anterior sería lo mismo que el escenario Ctrl ?

@basarat Yo uso Tab y Shift+Tab religiosamente; aunque, por lo general, para varias líneas de código. Supongo que se podría decir que Shift+Tab es un buen alias para presionar una tecla backspace en una pestaña, pero claramente no es tan simple o intuitivo como backspace .

Ctrl+Delete sería el alias más cercano a la clave Delete , pero tiene el potencial de eliminar más de una sangría; mientras que una simple tecla Delete en una pestaña elimina solo una sangría. Trabajar unas veces y otras no es la razón por la que no lo uso en absoluto (consistencia mental).

Yo, como usted, también rara vez, si es que alguna vez, necesito seleccionar dentro de un espacio en blanco. Nunca sugerí que lo haría. No estoy seleccionando el espacio en blanco, sino navegando por él para llegar a algún lugar. Su ejemplo de alineación anterior es definitivamente cuando usaría la navegación Ctrl + arrow key . Es por eso que, como dije antes, rara vez uso la navegación Ctrl + arrow key porque el escenario que señaló es probablemente el único caso en el que lo usaría.

Al final del día, lo que más me molesta es que tienes que cambiar totalmente tu memoria muscular cuando cambias entre un archivo con pestañas para sangría versus espacios para sangría. Lo que es eficiente (la menor cantidad de pasos lógicos) en un archivo con pestañas para sangría simplemente no funciona en un archivo con espacios para sangría. Podría culpar a los editores por no brindarle una experiencia perfecta, pero eso no es justo porque es literalmente imposible (sin CST) que los editores hagan suposiciones en un archivo con espacios para sangría sobre qué es una sangría y qué es alineación.

Lo que es aún más frustrante es que a la gente le resulta muy difícil reconocerlo. Los espacios para la hendidura son pura maldad ... con cuernos.

¿Conclusión final? Solo quiero contribuir, ¿qué diablos estás usando?

¿Conclusión final? Solo quiero contribuir, ¿qué diablos estás usando?

Consistente por archivo. No mezcle estos en un archivo

@basarat el cómic está mal. Todos sabemos que el tipo de Apple usaría espacios y el tipo de Microsoft usaría pestañas.

@jedmao soy un tipo ms y uso espacios :)

Creo que el # 4211 es una buena propuesta.

Propondría usar 2 espacios como se hace en la guía de estilo de airbnb / javascript ...

Sugerencia: Utilice los estándares de codificación establecidos por la biblioteca que se está escribiendo. Si la biblioteca que se está escribiendo utiliza espacios, comillas simples y LF, haga lo mismo en la definición de tipo. De esta forma podemos evitar el argumento de espacios vs tabulaciones.

El único problema es que no será fácil hacer cumplir esta regla. Si necesita aplicarlo y tener una coherencia total, le recomendaría seguir las convenciones más populares. Según este sitio web, son espacios y comillas simples.

Mi preferencia personal son los espacios (4) y las comillas _double_, pero estoy de acuerdo con el uso de comillas simples si eso significa que todo es consistente.

¿Podrían los usuarios de pro-tab y pro-tab-space aceptar un compromiso similar?

Mi preferencia personal son los espacios (4) y las comillas dobles, pero estoy de acuerdo con usar comillas simples si eso significa que todo es consistente.

@ glen-84 puramente para su diversión ... aquí por qué el equipo del compilador usó comillas dobles: https://github.com/Microsoft/TypeScript/issues/5811#issuecomment -160187924

• JSON
• Funciona en todos los idiomas, por lo que es una carga cognitiva menor

Yo personalmente utilizo comillas simples, ya que me encuentro haciendo más y más TypeScript exclusivamente: rose:

Creo que también es un poco más legible, y fue del 57% frente al 43% (no es una gran diferencia), pero supongo que tienes que trazar la línea en alguna parte. =)

Me gusta el punto de @jedmao en las pestañas para la sangría y los espacios para la alineación.

Divulgación completa: vengo de Go-land donde tenemos go fmt y no hay discusiones sobre pestañas o espacios nunca ... Son pestañas para sangría y espacios para alineación y funciona muy, muy bien: +1:

Espacios por supuesto. Porque nadie sabe cómo se representan exactamente las pestañas en diferentes editores si se utilizan en otros lugares.

@hinell ¿

Prefiero las pestañas, especialmente por esto: http://nickgravgaard.com/elastic-tabstops/

Resulta que hay una razón aún mayor para usar pestañas: la accesibilidad del desarrollador .

• https://github.com/prettier/prettier/issues/7475
• https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/