Taba o espacios para el sangrado? Estadísticas de 3.8 millones de Perl archivos creados por 24 años

Uno de los vetustos preguntas en la programación — ¿qué son los símbolos a utilizar en el código del programa para el sangrado — taba o espacios.

A veces no hay opción. Por ejemplo, en Makefile asegúrese de utilizar taba. En el lenguaje de programación go existe un oficial de la utilidad de gofmt que formatea el código y esta utilidad utiliza taba para el sangrado. B эзотерическом lenguaje de programación Whitespace taba y espacios no debe sustituir a un amigo sí. Pero muchos lenguajes de programación no se imponen a la selección, y permiten al programador decidir qué caracteres a utilizar.

No es suficiente la opinión popular de los personajes a utilizar para el sangrado. La opinión de los siguientes: no es importante que los uso principal de restricciones de integridad. Si vas a usar taba, es necesario siempre usar. Si usa espacios en blanco, solo se deben utilizar espacios en blanco y no utilizar la taba.

Incluso hay шуточный шуточный cómic sobre este tema:

(dos personas completamente no está de acuerdo el uno con el otro, ¿es necesario utilizar taba o espacios, pero absolutamente de acuerdo en que se debe utilizar sólo uno):

Y como están las cosas en el mundo real? Lo que realmente se utilizan?

Es bastante fácil de averiguar. Es necesario tomar el código fuente de los programas, contar ¿qué son los símbolos que se utilizan y ver los resultados.

Este artículo es el resultado de una pequeña investigación sobre el uso de табов y espacios en el mundo del lenguaje de programación Perl. Hay un enorme repositorio donde se almacenan Perl la biblioteca — CPAN. Me he descargado todas las versiones de todas las bibliotecas que hay ahora en el CPAN (su eran cerca de 135 mil) y expresó la opinión de los caracteres que se utiliza para el sangrado.

Antes de seguir leyendo, te sugiero que por un momento para reflexionar y tratar de suponer que el aplauso para el sangrado:

  • taba
  • espacios
  • o una mezcla de табов y espacios

?

La escritura de código

Así, la tarea de entender. Es necesario tomar todas las bibliotecas de CPAN y comprobar que se utiliza para el sangrado.

Para empezar, es necesario descargar todo el CPAN. Esto se hace con un comando:

time /usr/bin/rsync -av --delete cpan-rsync.perl.org::CPAN /project/CPAN/

3 horas y CPAN скачен. Se tarda alrededor de 27 GB.

CPAN es un conjunto de archivos que se organizan en una estructura. He aquí un fragmento:

CPAN/authors/id
├── A
│   ├── AA
│   │   ├── AADLER
│   │   │   ├── CHECKSUMS
│   │   │   ├── Games-LogicPuzzle-0.10.readme
│   │   │   ├── Games-LogicPuzzle-0.10.tar.gz
│   │   │   ├── Games-LogicPuzzle-0.12.readme
│   │   │   ├── Games-LogicPuzzle-0.12.tar.gz

En este ejemplo, AADLER — es un nombre de usuario del autor, y Games-LogicPuzzle-0.10.tar.gz y Games-LogicPuzzle-0.12.tar.gz es de los comunicados.

Ahora en CPAN hay más de 7 mil de los autores que han descargado de la biblioteca en CPAN. Para no almacenar los 7 miles de carpetas en la misma carpeta, agregó aún más niveles (sistema de control de versiones git almacena sus datos de manera similar).

En CPAN se puede descargar de la biblioteca, que pueden estar incluidos diferentes archivadores.

Empecé con lo que consideró el número de diferentes extensiones de archivos en la carpeta CPAN/authors/id/. He aquí la secuencia de comandos y el resultado de su trabajo . Top de las extensiones de los archivos:

  • .tar.gz 135571
  • .tgz 903
  • .zip 652
  • .gz 612
  • .bz2 243

.tar.gz gana con tal margen de que he decidido que será suficiente con contar ¿qué símbolos se utilizan en отступах sólo en las bibliotecas, que pueden estar incluidos en .tar.gz

Lejos me escribió varios scripts. Inicialmente no me hasta el final de la era comprensible en qué forma me gustaría obtener información sobre табах y lagunas, por lo que me decidí a hacer el sistema consta de varios componentes. Primero procesar las 135 miles de archivos con versiones y poner los datos sobre la табах y lagunas en la base de datos. Espero que esto será por mucho tiempo. Y luego utilizar los datos de la base de datos para obtener datos rápidamente en diferentes formatos de archivo.

Finalmente ha resultado script fill_db . Este script inundaba los datos en la base de poco más de cinco horas. Pero estos cinco horas es cuando ya todo estaba organizado. No la primera vez, el script funciona bien. Los principales problemas han sido con Unicode. Primero fue el problema con un lanzamiento μ-0.01.tar.gz autor APEIRON, luego hubo un problema con los archivos de la vista t/words_with_ß.dat de lanzamiento Lingua-DE-ASCII-0.06 autor BIGJ. Pero al final todos los problemas han sido resueltos y el script correctamente dado una vuelta por todos .tar.gz tómese.

El script va por todo .tar.gz los archivos en CPAN. Descomprime .tar.gz en una carpeta temporal. Encuentra en esta carpeta de archivos temporales de todos los archivos que tienen la extensión de .pm, .pl, .t o .pod, lee las sangrías y comprueba si en estos отступах espacios y o de taba. En las versiones vienen y otros los archivos, pero he decidido limitarme a mencionar sólo los archivos que explícitamente se refieren a Perl.

El resultado del trabajo de este script es el 2 de la tabla en la base de datos. He aquí un ejemplo de los datos:

mysql> select * from releases limit 1;
+------------+--------+---------------------------------------------------------------+------------+
| release_id | author | file_name                                                     | timestamp  |
+------------+--------+---------------------------------------------------------------+------------+
|          1 | RUFF   | /cpan/authors/id/R/RU/RUFF/DJabberd-Authen-Dovecot-0.1.tar.gz | 1359325895 |
+------------+--------+---------------------------------------------------------------+------------+
1 row in set (0.00 sec)

mysql> select * from files where release_id = 1;
+---------+------------+--------------------------------------------------------+------+---------------------+-------------------+
| file_id | release_id | file_name                                              | size | has_space_beginning | has_tab_beginning |
+---------+------------+--------------------------------------------------------+------+---------------------+-------------------+
|       1 |          1 | DJabberd-Authen-Dovecot/lib/DJabberd/Authen/Dovecot.pm | 2047 |                   1 |                 1 |
|       2 |          1 | DJabberd-Authen-Dovecot/t/compiles.t                   |   64 |                   0 |                 0 |
+---------+------------+--------------------------------------------------------+------+---------------------+-------------------+
2 rows in set (0.02 sec)

mysql> mysql> selec(*) from releases;
+----------+
| count(*) |
+----------+
|   135343 |
+----------+
1 row in set (0.04 sec)

mysql> select count(*) from files;
+----------+
| count(*) |
+----------+
|  3828079 |
+----------+
1 row in set (5.71 sec)

Solo espacios en blanco, sólo taba, taba y espacios, y...

Total en la base de datos sobre cada archivo en el comunicado se compone de 2 bandera:

  • ¿se utilizan los espacios en отступах
  • ¿se utilizan taba en отступах

Respectivamente de dos indicadores puede ser de 4 combinaciones:

  • 11 — se utilizan y los espacios y de taba
  • 10 — sólo se utilizan los espacios
  • 01 — solo se utilizan taba
  • 00 — no se utilizan espacios en blanco ni taba

Las tres primeras opciones es completamente esperados de la situación, es decir, su yo y quería encontrar y saber que el más popular. Y aquí está la opción de 00 — "no se utilizan ni de taba, ni espacios en blanco" — eso es lo que yo no pensaba, pero resultó que así también sucede. "¿Cómo?" — pregunte. He aquí un ejemplo.

mysql> select releases.release_id, files.file_name, files.size, has_space_beginning, has_tab_beginning from releases join files on releases.release_id = files.release_id and author = 'KOHA';
+------------+---------------------------------------------------+------+---------------------+-------------------+
| release_id | file_name                                         | size | has_space_beginning | has_tab_beginning |
+------------+---------------------------------------------------+------+---------------------+-------------------+
|     118147 | Bundle-KohaSupport-0.31/lib/Bundle/KohaSupport.pm | 2169 |                   0 |                 0 |
|     118147 | Bundle-KohaSupport-0.31/t/Bundle-KohaSupport.t    |  487 |                   0 |                 0 |
|     118147 | Bundle-KohaSupport-0.31/t/pod.t                   |  130 |                   0 |                 0 |
+------------+---------------------------------------------------+------+---------------------+-------------------+
3 rows in set (0.05 sec)

El autor de KOHA es la liberación de Bundle-KohaSupport-0.31. En esta versión hay 3 archivos que tienen una extensión de la lista .pm, .pl, .t o .pod. Sobre todos estos archivos en la base está escrito que en su отступах no hay ni espacios, ni табов. ¿Cómo puede ser?

Resulta que todos murieran. Si de por si ver estos archivos, en ellos, simplemente, no hay sangrado. He aquí, por ejemplo, el contenido de un archivo t/Bundle-KohaSupport.t:

# Before `make install' is performed this script should be runnable with
# `make test'. After `make install' it should work as `perl Bundle-KohaSupport.t'

#########################

# change 'tests => 1' to 'tests => last_test_to_print';

use Test::More tests => 1;
BEGIN { use_ok('Bundle::KohaSupport') };

#########################

# Insert your test code below, the Test::More module is use()ed here so read
# its man page ( perldoc Test::More ) for help writing this test script.

Así que además de las tres completamente previstos situaciones:

  • sólo se utilizan los espacios
  • sólo se utilizan taba
  • se utilizan, y los espacios y de taba

todavía, y es la situación:

  • no se utilizan ni espacios en blanco y no se utilizan de taba

Los datos de los autores

Después de que me han aparecido los datos procesados en la base decidí ver de todo autor que se utiliza para el sangrado.

Yo esperaba que el más popular es el uso de sólo las lagunas, en el segundo lugar de popularidad se uso solo табов, y en el tercer lugar de popularidad será el uso simultáneo de табов y lagunas.

Pero resultó que yo estaba completamente equivocado.

He escrito un script . Este script ha comprobado qué símbolos se utilizan los autores en todos los archivos de .pm, .pl, .t, .pod, que hay en todas sus versiones que hay ahora en CPAN.

Eso es lo que pasó:

$ cat app/data/users.log | perl -nalE 'say if /^##/'
## 00 (nothing) - 50 (0.7%)
## 01 (only tabs) - 51 (0.7%)
## 10 (only spaces) - 1543 (21.9%)
## 11 (both) - 5410 (76.7%)

Los datos no como yo esperaba!

  • Más del 75% de los autores utilizan una mezcla de espacios y табов para el sangrado.
  • Solo espacios en blanco en el segundo lugar, algo más del 20%,
  • y los autores que utilizan sólo la taba menos de un por ciento.
  • El número de autores que en general no se usan sangrías prácticamente es el mismo que el número de autores que utilizan sólo la taba.

Una lista completa de todos los autores en la desglosados sobre los grupos hay en el archivo en GitHub .

Y he aquí jupyter notebook  mediante el cual se construyó este gráfico circular.

Pero los datos generados por todos tómese, que ahora hay en CPAN. Estos comunicados se crearon a lo largo de los últimos 24 años. Puede ser con el paso del tiempo, la relación de algo está cambiando?

Los datos sobre el tiempo

Cada archivo con un lanzamiento en CPAN la fecha de modificación es el tiempo cuando esta versión se ha cargado en CPAN. Estos datos cargados en la base de datos. Ahora en CPAN la más antigua versión — Ioctl-0.5 — se ha descargado en el CPAN 1995-08-20:

mysql> select author, file_name, from_unixtime(timestamp) from releases where timestamp = (select min(timestamp) from releases);
+--------+----------------------------------------------+--------------------------+
| author | file_name                                    | from_unixtime(timestamp) |
+--------+----------------------------------------------+--------------------------+
| KJALB  | /cpan/authors/id/K/KJ/KJALB/Ioctl-0.5.tar.gz | 1995-08-20 07:26:09      |
+--------+----------------------------------------------+--------------------------+
1 row in set (0.08 sec)

Y en este día estaba cubierto de inmediato, el 8 de lanzamientos:

mysql> select * from releases where from_unixtime(timestamp) < '1995-08-21' order by timestamp;
+------------+--------+--------------------------------------------------------------+-----------+
| release_id | author | file_name                                                    | timestamp |
+------------+--------+--------------------------------------------------------------+-----------+
|     112505 | KJALB  | /cpan/authors/id/K/KJ/KJALB/Ioctl-0.5.tar.gz                 | 808903569 |
|      23026 | TYEMQ  | /cpan/authors/id/T/TY/TYEMQ/FileKGlob.tar.gz                 | 808903636 |
|     134031 | WPS    | /cpan/authors/id/W/WP/WPS/Curses-a8.tar.gz                   | 808903647 |
|     112546 | KJALB  | /cpan/authors/id/K/KJ/KJALB/Term-Info-1.0.tar.gz             | 808903748 |
|      70278 | MICB   | /cpan/authors/id/M/MI/MICB/TclTk-b1.tar.gz                   | 808910379 |
|      70274 | MICB   | /cpan/authors/id/M/MI/MICB/Tcl-b1.tar.gz                     | 808910514 |
|      19408 | GBOSS  | /cpan/authors/id/G/GB/GBOSS/perl_archie.1.5.tar.gz           | 808930091 |
|      81551 | JKAST  | /cpan/authors/id/J/JK/JKAST/StatisticsDescriptive-1.1.tar.gz | 808950837 |
+------------+--------+--------------------------------------------------------------+-----------+
8 rows in set (0.06 sec)

Me decidí a ver como cambia la distribución de la utilización de símbolos diferentes para el sangrado de tiempo. Para ello, escribí un script .

He aquí un fragmento de archivos de datos que ha creado el script:

$ cat app/data/releases_date.csv | head
date,00,01,10,11
1995-08-20,0,1,0,7
1995-08-21,0,0,0,0
1995-08-22,0,0,0,0
1995-08-23,0,0,0,0
1995-08-24,0,0,0,1
1995-08-25,0,0,0,0
1995-08-26,0,0,0,0
1995-08-27,0,0,0,0
1995-08-28,0,0,0,0

Es decir, sobre cada fecha a partir de 1995-08-20 se dispone de datos acerca de la cantidad de comunicados, desglosados por tipo ¿qué son los símbolos utilizados para el sangrado.

  • 00 — en отступах no hay ni espacios, ni табов
  • 01 — en отступах sólo se utilizan taba
  • 10 — en отступах sólo se utilizan los espacios
  • 11 — en отсутпах se utilizan y de taba y espacios

Lejos me escribió jupyter notebook  en el que ha dibujado el gráfico. En el gráfico he отображаю absoluto del número de lanzamientos, con desglose por tipo de sangría, además, el porcentaje del número total de lanzamientos en este día:

En el gráfico se muestra casi 9 mil días. Se ve que hay una tendencia, pero el horario ruidoso y mal todo se ve. Porque en lugar de días empecé a группировал comunicados por mes.:

Es increíble pero se observa una tendencia. El número de lanzamientos en los que se utilizan solo taba o no se usan sangrías prácticamente no cambia, pero la proporción de los comunicados, en los que sólo se utilizan los espacios crece constantemente y este crecimiento se produce a expensas de la proporción de los comunicados, en los cuales se utilizan una mezcla de табов y lagunas.

¿Por qué crece "espacios". La hipótesis número 1

Miré a los datos y me ha surgido una hipótesis de por qué se reduce el número de lanzamientos en los que se utiliza y de los problemas y de taba. Mi pensamiento sobre el Perl de la biblioteca Module::Install . Si al escribir su usa la biblioteca Module::Install, en el comunicado en el CPAN se incluyen los archivos de la biblioteca. Y en estos archivos se utiliza una mezcla de espacios y табов. He aquí un ejemplo de los archivos del módulo::Install en el comunicado Devel-PeekPoke-0.04:

mysql> select * from files where release_id = 284 and file_name like '%inc/Module/Install%';
+---------+------------+----------------------------------------------------+-------+---------------------+-------------------+
| file_id | release_id | file_name                                          | size  | has_space_beginning | has_tab_beginning |
+---------+------------+----------------------------------------------------+-------+---------------------+-------------------+
|   10328 |        284 | Devel-PeekPoke-0.04/inc/Module/Install.pm          | 12381 |                   1 |                 1 |
|   10329 |        284 | Devel-PeekPoke-0.04/inc/Module/Install/Metadata.pm | 18111 |                   1 |                 1 |
|   10330 |        284 | Devel-PeekPoke-0.04/inc/Module/Install/Fetch.pm    |  2455 |                   1 |                 1 |
|   10331 |        284 | Devel-PeekPoke-0.04/inc/Module/Install/Makefile.pm | 12063 |                   1 |                 1 |
|   10332 |        284 | Devel-PeekPoke-0.04/inc/Module/Install/Base.pm     |  1127 |                   0 |                 1 |
|   10333 |        284 | Devel-PeekPoke-0.04/inc/Module/Install/WriteAll.pm |  1278 |                   0 |                 1 |
|   10334 |        284 | Devel-PeekPoke-0.04/inc/Module/Install/Win32.pm    |  1795 |                   1 |                 1 |
|   10335 |        284 | Devel-PeekPoke-0.04/inc/Module/Install/Can.pm      |  3183 |                   1 |                 1 |
+---------+------------+----------------------------------------------------+-------+---------------------+-------------------+
8 rows in set (0.03 sec)

Mi hipótesis es que los desarrolladores utilizan espacios para el sangrado, sino por el hecho de que en el comunicado está Module::Install en las estadísticas tienen en cuenta los espacios y de taba. Module::Install menos utilizar (ya que han aparecido todo tipo de Dist::Zilla, Dist::Milla, Minilla) y, por lo tanto Module::Install dejado de dar la distorsión.

Esta hipótesis es necesario comprobar. Primero decidí ver si realmente Module::Install se usan cada vez menos y menos. He construido una tabla. Cada punto es el número de lanzamientos para el mes en el que se utilizó Module::Install. Se ve que parte de la hipótesis es correcta, de hecho, Module::Install comenzaron a utilizar menos.

Pero realmente, ¿el uso de Module::Install afecta a la proporción de uso de espacios o табов y espacios para el el sangrado. Para poder hacerlo, he dibujado dos gráficos. Es el número de diferentes tipos de sangría en las versiones por meses. En el primer gráfico sólo comunicados en los que se utiliza Module::Install, en el segundo gráfico sólo comunicados en los que no se utiliza.

Aquí se ve que, en efecto, si se utiliza la biblioteca Module::Install, lo más a menudo en la biblioteca se utiliza es una mezcla de табов y lagunas.

Y aquí está el gráfico que muestra sólo los comunicados en los que no se utiliza Module::Install. Si se compara este el calendario con el calendario en el que se dirigen todos los comunicados, la diferencia que hay, pero nada radicalmente no cambia.

Resulta que la hipótesis es falsa. Si la actualización se utiliza Module::Install, el lanzamiento más a menudo cae en el grupo de "taba y lagunas", pero si no tener en cuenta todos los comunicados en los que se utiliza Module::Install, de todas formas hay una tendencia — el porcentaje de lanzamientos en los que se utilizan solo taba como sangría crece a expensas de la fracción de lanzamientos en el que se utilizan la mezcla de табов y lagunas.

¿Por qué crece "espacios". La hipótesis número 2

¿Por qué todavía crece el número de lanzamientos en los que se utilizan solo taba? Puede ser que hay algo más allá de activa el autor, que producen mucho de los comunicados y de estos el autor porque afectan a toda la información de estadísticas?

He intentado comprobarlo. Dibujó un gráfico que muestra el porcentaje de lanzamientos en los que sólo se utilizaron los espacios, pero con el desglose de la primera letra del nombre del autor. Si realmente algún tipo de el autor aportaba más allá de su gran contribución en las estadísticas generales, es una línea muy bruscamente habría arriba. En el gráfico que he visto, todas las líneas de más o menos lisas. Así que la confirmación de esta hipótesis, yo no fue capaz de obtener.

¿Por qué crece "espacios". La hipótesis número 3

Por los graficos se ve que con el paso del tiempo se hace cada vez más comunicados en los que se utilizan sólo espacios para el sangrado. Y este porcentaje crece a expensas de los comunicados, en los que se utiliza una mezcla de espacios y табов.

Mi primera suposición fue que lo es por el hecho de que en los comunicados antes activamente incluyeron el código de la biblioteca Module::Install en los que se utilice una mezcla de espacios y табов, esta biblioteca utilizan cada vez menos, y por lo tanto, el porcentaje de lanzamientos en los que se utiliza una mezcla de табов y de vacíos disminuye. Resultó que una parte de verdad en esto, pero incluso si quitáramos de la consideración de todos los comunicados en los que se utiliza Module::Install, la tendencia general esto no cambia — de todos modos, la proporción de los comunicados, en los que sólo espacios crece a expensas de la proporción de los comunicados, en los que utiliza una mezcla de espacios y табов.

Mi segunda hipótesis de que tanto influyen en las estadísticas de muy pequeño conjunto muy activos, de los autores. No soy capaz de encontrar la confirmación de esta hipótesis.

Mi tercera hipótesis es que los autores aparecen más fáciles de editores de texto y el IDE, con que se hace más fácil de usar консистентно sólo los espacios, y no una mezcla de espacios y табов. Pero, por desgracia, las ideas de cómo comprobar esta hipótesis no tengo. En los datos que se encuentran en CPAN, no hay información sobre cuál es el tipo de el editor se utilizó para crear esta versión. He mirado la fecha del lanzamiento populares editores/IDE:

  • Emacs — 1985
  • vim — 1991
  • IntelliJ IDEA — январяь 2001
  • Eclipse — noviembre de 2001
  • Sublime Text — enero 2008
  • Atom — febrero 2014
  • VS Code — abril 2015

Los datos de los autores por el año 2019

Los gráficos se ve que con el paso del tiempo se hace cada vez más comunicados en los que se utilizan los espacios, y no una mezcla de табов con espacios. Por lo tanto, me decidí a ver la distribución de ¿qué tipos de sangría utilizado por los autores únicamente sobre la base de sus lanzamientos por año 2019.

Los datos de los resultados del trabajo del script :

$ cat app/data/users_2019.log | perl -nalE 'say if /^##/'
## 00 (nothing) - 12 (1.4%)
## 01 (only tabs) - 9 (1.0%)
## 10 (only spaces) - 355 (41.2%)
## 11 (both) - 486 (56.4%)

Si comparamos los datos de los autores por el año 2019 y los datos de todos los años, se puede observar que el porcentaje de autores que sólo utiliza taba casi no cambia, pero la proporción de los autores que utilizan sólo los espacios un fuerte incremento.

El código fuente para este gráfico circular:

Factores que influyen en la exactitud de los datos

Para la formación de los números y los gráficos se han utilizado todo .tar.gz comunicados de prensa, que estaban en el CPAN en el momento de escribir este artículo, además de los comunicados de la propia el lenguaje de programación Perl.

CPAN permite eliminar de prensa, en los datos que se muestran en este artículo eliminados de prensa no participaron. No está claro cuánto se intercambiarán los datos si tener en cuenta los caracteres de espaciado en los ya remotos versiones. Es posible que los datos cambian fuertemente. Existe un archivo comprimido backpan  que almacena todos los comunicados, que fueron en CPAN. Así que en teoría existe la posibilidad de contar todos los teniendo en cuenta el número de lanzamientos que ya no está en el CPAN.

El segundo momento, que influye en la exactitud de los datos es algo que se tengan en cuenta los caracteres sangría sólo en las versiones que se pueden estar incluidos en el .tar.gz el archivo comprimido. Otros tipos de los archivos no utilizados. La gran mayoría de lanzamientos es .tar.gz por lo se ha hecho dicha hipótesis. Si contar los datos de todos los archivos de datos seguramente cambiarán. Supongo que el cambio no más de unos pocos por ciento.

El código fuente

Todo el conjunto de scripts que se utilizaron para la recopilación de datos, los datos de y jupyter portátiles, todo está disponible en el repositorio en GitHub.

El código que está escrito — él mismo se está muy lejos de la perfección. Todo lo que está escrito es está escrito con ideas lo más rápido posible para obtener un resultado, y no crear un código perfecto.

Resumen

En el momento de escribir este texto en el repositorio de Perl de las bibliotecas bibliotecas se encontraba cerca de 135 mil los comunicados. La primera versión fue hace 24 años atrás (1995-08-20). En estas versiones se encuentra casi 4 millones de archivos con las extensiones de .pm, .pl, .t o .pod.

Si se tiene en cuenta los datos de todos los tiempo, resultará que el 76.7%% de los autores en отступах utilizan una mezcla de espacios y табов, 21.9% utilizan en отступах sólo los espacios, y 0.7% solo taba.

Pero si se tiene en cuenta únicamente los datos de 2019, se hace cada vez más los autores que sólo utiliza los espacios en blanco para sangría, pero aun así, la mayoría utiliza una mezcla табов y lagunas (56.4% — utilizan y de taba y espacios en blanco,espacios en blanco 41.2% solo espacios, 1.0% solo taba).

Y si miramos el gráfico de los cambios de la proporción de uso de los diferentes tipos de sangría, se puede observar que el porcentaje de el uso de sólo las lagunas crece y este porcentaje crece a expensas de la proporción de aquellos que utiliza una mezcla de табов y espacios para el sangrado.

No se sabe exactamente por qué este porcentaje va en aumento. Es posible que esto ocurre debido al hecho de que los autores de utilizan más fáciles de editores de texto, que permiten el fácil y seguro de instalar los personajes a utilizar para el sangrado.

Otros artículos