Guía para el código de tipificación para no programadores


13

Antecedentes

Soy autor de un artículo científico que contiene código y recientemente recibí las pruebas, es decir, lo que las máquinas de escribir de la revista crearon a partir de mi manuscrito. El resultado no fue aceptable: la sangría es inconsistente; hay un punto final al final de cada bloque de código; las comillas se han destruido, etc. Tenga en cuenta que todos los errores no fueron específicos del lenguaje de programación que utilicé.

Ahora, puedo ver por qué alguien que no tiene experiencia en programación y no tiene recursos externos cometería tales errores, pero en tiempos de Internet nadie debería estar sin recursos externos. Por lo tanto, consulté a mi motor de búsqueda favorito para buscar algo que sugerir y no encontré ... nada. Hay muchas guías para programadores sobre cómo escribir código bellamente en LaTeX o similar, lo cual es agradable y apropiado, pero esto obviamente no está hecho para la máquina de escribir que tiene que escribir el código de otra persona.

Pregunta

Estoy buscando un recurso que:

  • explica los conceptos básicos del código de composición tipográfica,
  • está dirigido a máquinas de escribir sin experiencia en programación.

La dificultad con esto es que depende del lenguaje y las convenciones utilizadas, por lo que la pregunta es bastante amplia, incluso si las respuestas solo vinculan un recurso
Zach Saucier

2
@Scott Bueno, con respecto a las comillas, los espacios, los caracteres; de hecho, uno puede generalizar bastante bien: deben conservarse.
Mikhail V

1
@MikhailV Simplemente siento que muchos lenguajes de código tienen más en común con los idiomas extranjeros que las pautas. Claro que puede determinar aproximadamente dónde deben colocarse los espacios y los saltos de línea, pero para ser exactos, realmente necesita comprender el lenguaje que está corrigiendo. Sí, puede decirle a los editores / revisores que se vayan "como están", lo que no significa que, en última instancia, sea correcto.
Scott

1
@Wrzlprmft Lo curioso es que no se puede copiar pegar el formulario PDF de Python sin perder todo el espacio en blanco anterior en Acrobat o Acrobat Reader. "Inteligentemente" los elimina. Del mismo modo, si pega código en muchos editores WYSIWYG como Word o INdesign, reemplazarán las comillas con comillas tipográficas (a menos que desactive dicha función), pero para el código eso es realmente MALO. Además, en idesign no puede realmente escribir correctamente el código sin introducir un carácter diferente para el salto de línea, lo que puede convertirse en algo malo si alguna vez copia el código.
joojaa

1
@ usr2564301: En primer lugar, algunos motores de búsqueda están encontrando esta pregunta y, por lo tanto, es más probable que cualquier máquina de escribir que tenga los mismos problemas que la mía pueda encontrar una respuesta potencial (y si no lo hacen, podría estar adecuadamente satisfecho) al respecto). Segundo, sí, incluiría un enlace en la respuesta a mis pruebas, porque puede evitar errores aún no comprometidos en la segunda ronda de pruebas. Tampoco hace daño tener una referencia si la máquina de escribir es terca. Finalmente, esta es una revista / editorial que rara vez tiene que lidiar con el código, por lo que es algo diferente de los escenarios que describe.
Wrzlprmft

Respuestas:


7

Quizás el punto real es que el código no debería estar realmente compuesto de la forma en que las personas entienden la composición. Por lo tanto, al poner código en un documento, debe colocarse allí literalmente , como en todos los espacios, pestañas, caracteres especiales o no especiales y saltos de línea intactos.

  • Las pestañas deben ser tan anchas como 4 u 8 espacios (siendo cuatro los más comunes)
  • La fuente debe ser una fuente de ancho fijo. Y casi universalmente tiene que ser.
  • ¡Asegúrese de que su aplicación no haga sustituciones!

    Eso significa que no hay ligaduras.

    Además, la aplicación de muchos programas (como Word e InDesign) cambia las comillas rectas a pares de tipógrafos. Asegúrese de que tales opciones estén deshabilitadas antes de colocar el código en su documento.

  • No permita que el código fluya automáticamente de una línea a otra. ¡No toques el código, no eres el experto!

El código no es texto del cuerpo, no sigue ninguna convención tipográfica. Pregúntese ¿escribiría texto en una ilustración?

Si eres un experto

Si usted es un experto y conoce el idioma en cuestión, se aplica lo siguiente.

Nota : No adivine ni infiera, lea lo que se dijo. Muchos idiomas tienen el mismo aspecto y el código puede ser un pseudo lenguaje que parece un código real. Entonces tú puedes:

  • Al editor le gusta colorear / poner en negrita / poner en cursiva las palabras clave si y solo si su sustitución tiene el mismo ancho fijo. Lo mejor es que un editor haga esto por usted (los editores como digamos que scintilla puede exportar el código formateado). Recuerde que el editor necesita saber el idioma, tal vez las bibliotecas también.

    Tenga en cuenta que si hace esto mal, causa más daño que bien.

Si eres un experto en dominios. Como en conocer el idioma y la biblioteca y comprender el código en cuestión:

  • Luego, puede volver a alinear el código en varias líneas si no se ajusta a su diseño. No haga esto a menos que realmente sepa lo que está haciendo, puede terminar haciendo un daño irreparable.

    La prueba de fuego es si podría haber escrito el código en cuestión. Si no, entonces no puedes juzgar. Pregúntale al autor.

    Como lidiar con esto? Los programadores entienden los estándares de estilo de código. Simplemente escriba en la guía de envío que solo puede caber X caracteres por línea. Los programadores pueden hacer esto por sí mismos. Los editores de código frecuentemente tienen herramientas para esto. Otra razón más para usar una fuente monoespaciada.

Pero entonces sabías todo esto, eras un experto después de todo. Mejor deje que el autor edite el código.

¿Línea de números?

Algunos lenguajes de programación y casos de uso pueden beneficiarse de los números de línea. Sin embargo, tenga cuidado aquí, ya que este es un paso en falso en algunos idiomas.

Problemas.

Tenga en cuenta que no importa lo que haga, de hecho puede enfrentar obstáculos técnicos imposibles. El código no debe estar realmente compuesto, solo debe ser texto sin formato. Esto lleva a problemas sorprendentes.

Por ejemplo: muchos visores de PDF no pueden manejar lenguajes como Python, como Adobe Acrobat. Si pega el código del archivo PDF, el editor decide no incluir el espacio anterior al copiar y pegar. Esto destruye la capacidad de pegar código desde PDF al editor. ¡Realmente no hay una buena manera de manejar esto!


@ usr2564301 ah sí tan cierto
joojaa

1
@ usr2564301 Hecho, de todos modos, creo que una elección de fuente legible es algo que un tipógrafo debería entender. De todos modos, uno que también distingue una letra minúscula i sin punto (sí, depuramos un código fo de una pieza durante un mes porque no sabíamos que una 'i' minúscula es diferente de una 'I' mayúscula en un entorno turco) forma un 1 también
joojaa

"No permita que el código fluya de una línea a otra" es un buen consejo en teoría. Pero si está componiendo para un formato de impresión estándar de 6x9 y tiene una línea de código con 600 caracteres, tendrá dificultades para prestarle atención.
Janus Bahs Jacquet

1
@JanusBahsJacquet Code generalmente se escribe con menos de 80 caracteres por línea. Entonces, si obtienes algo así, tal vez tus pautas de presentación apestan. Los programadores conocen las pautas de envío, después de todo eso son las bases de código. La cosa es que al romper las líneas puede terminar cambiando el significado del código.
joojaa

1
@JanusBahsJacquet Por eso le preguntas al autor, actualizas las pautas para que no tengas que hacerlo con demasiada frecuencia. bien, en cualquier caso, si el código no se puede dividir en líneas largas, el tipográfico tampoco puede hacer nada al respecto. Por cierto, ¿qué le haría una máquina de escribir a una imagen demasiado amplia que no se puede cambiar de tamaño o recortar? De todos modos, predeciré que los envíos de código serán más comunes en el futuro
joojaa

4

La respuesta, por supuesto, puede depender de muchos factores, pero si comenzamos con un código de texto plano correcto y bien formateado , entonces uno puede generalizar más o menos las cosas aquí.

El 'formato' inicial en el texto fuente será: nueva línea , espacio y caracteres de tabulación . Tenga en cuenta que la nueva línea y el salto de línea manual (como en el software DTP) no son lo mismo, y viceversa, algunos idiomas raros pueden permitir otros caracteres de formato, aunque nunca he oído hablar de ellos.

Los comentarios no son parte ejecutable del código, por lo que pueden formatearse sin mucho riesgo, si se sabe si realmente es un comentario. Entonces, lo primero que debe observar es cómo se etiquetan los comentarios.

Es bueno conocer algunos conceptos básicos sobre el formato de texto sin formato inicial. Por ejemplo, para Python, existe la guía de estilo PEP8 . Si bien está hecho para Python, esta guía de formato se puede utilizar como referencia para los principales lenguajes como C / C ++ y Java. Examinar varios proyectos de ejemplo puede ayudar en caso de duda.

Por lo tanto, el primer principio sería: No cambie el texto fuente. Revisaría una lista de verificación, asegúrese de que:

  • No se produce el reemplazo automático de caracteres en ninguna etapa.
  • No se realizan modificaciones en el texto (a menos que esté 100% seguro de que se deben hacer).
  • No aparecen líneas ajustadas.
  • Las sangrías se conservan visualmente y son consistentes (aproximadamente cuatro x  anchuras por nivel de sangría).
  • El nivel de sangría inicial (cero) debe ser visible.
  • Los estilos definidos no destruyen el formato de la sintaxis (si se utiliza el resaltado de sintaxis).
  • Tenga una copia de seguridad de la fuente en texto plano, para poder volver a verificar el formato original o comenzar de nuevo.
  • Los números de línea, si están presentes, deben estar intactos, especialmente si se mencionan en las explicaciones.

En realidad, si la fuente original está formateada correctamente, no debería haber ningún ajuste de línea. Si las líneas ajustadas siguen apareciendo y son inevitables, entonces una sangría colgante de un nivel es la solución más común (ver PEP vinculada anteriormente). Si es necesario romper la línea, mejor consulte la guía de estilo o al autor.

Todavía algunos caracteres menores de 'espacio en blanco' pueden requerir reemplazo. Dado que la fuente puede incluir caracteres de tabulación, esto significa, por supuesto, que la fuente debe asegurarse de que todas las tabulaciones al comienzo de cada línea sean consistentes, es decir, las sangrías anidadas se conservan visualmente y cada siguiente nivel de sangría es del mismo ancho (ca. cuatro x  anchos por un nivel de sangría).

Idealmente, las hendiduras que se hicieron con caracteres de espacio o espacios mixtos y pestañas deben reemplazarse con tabulación (o con lo que el software DTP puede hacer mejor para las sangrías anidadas), por lo que, si es necesario, ajustar las sangrías puede ser más fácil.
Por supuesto, uno puede dejar espacios, pero puede ser más difícil administrar su ancho al cambiar la fuente y más difícil alinear las hendiduras de la línea interna como en las columnas de la tabla.

Fuente monoespaciada + espacios

Tenga en cuenta que si la fuente está formateada con espacios intencionalmente y estaba destinada a leerse solo en fuentes monoespaciadas (por ejemplo, diagramas ASCII o arte ASCII), uno debe preservar los espacios sin cambios , pero esta decisión debe tomarse desde el principio. La fuente "Courier New" es más común en este caso. Sin embargo, si no es realmente necesario, desaconsejo el monoespacio, porque cada vez menos personas eligen el monoespaciado para la codificación hoy en día, y en caso de revisión, las fuentes proporcionales brindarán una mejor experiencia de lectura.

En general, las fuentes condensadas (por ejemplo, Arial estrechas) o más pequeñas pueden funcionar mejor: da más énfasis en contraste con el texto del cuerpo, hará que el código sea más compacto y, por lo tanto, sea menos probable que aparezca un ajuste de línea no deseado.

Creo que aquí se puede dibujar una línea, y si se hace lo anterior, entonces hay un 99% de probabilidad de que todo esté bien, al menos para un bloque de código de fuente simple sin colores.


Herramientas y formateo avanzado

Además, el aspecto se puede mejorar significativamente mediante el resaltado de sintaxis.

  • impresión en color o visualización en pantalla: en un diseño a todo color se pueden usar todas las funciones de resaltado, por lo que es el mejor de los casos, pero la impresión puede dar algunos cambios de color.

  • escala de grises o impresión en blanco y negro: aquí, por supuesto, uno puede usar negrita (por ejemplo, palabras clave) o cursiva (por ejemplo, comentarios), pero tenga en cuenta que los colores se convertirán a gris con todas las consecuencias. Por ejemplo, los comentarios en gris pueden verse bien en una pantalla, pero pueden volverse demasiado pálidos en el papel.

La pregunta más importante es si el creador de diseño tiene herramientas que puedan representar el código de forma legible. Afortunadamente, hay muchas herramientas gratuitas para la edición de código, las más destacadas (para Windows) son: Notepad ++, VSCode, Visual Studio . Pero tenga en cuenta las posibles autoconversiones implícitas de pestañas a espacios.

En Notepad ++ hay una opción para exportar el código como RTF , que preservará todo el formato y el resaltado de sintaxis de la fuente.

Si el diseño no requiere un cambio en el flujo de texto en la presentación del código, uno puede usar directamente imágenes (capturas de pantalla): no es tan flexible como el texto, pero conservará el formato al 100% y la numeración de líneas, y puede ahorrar mucho tiempo. Por ejemplo, los números de línea pueden ser difíciles de preservar en forma de texto. También exportar a PDF es una buena alternativa, pero no todo el software DTP puede incrustar archivos PDF y se puede perder algo de formato al imprimir en PDF.

Por ejemplo, mi configuración para el código Python en Notepad ++ se ve así:
ingrese la descripción de la imagen aquí

Esto es solo para ilustrar, que uno puede usar capturas de pantalla directamente y que en realidad puede ser el método más fácil. Hay varias herramientas que pueden ayudar con la captura de pantalla: una puede necesitar "coser" las pantallas para obtener imágenes de mayor resolución.

El esquema de color es, por supuesto, individual, definido en el configurador de estilo del editor, que ya conoce el lenguaje admitido, lo que dificulta el formateo falso incluso si uno no conoce la sintaxis. Aquí las reglas generales de tipografía deberían funcionar: no demasiados colores, fuentes consistentes, hendiduras, espacios de líneas cómodos.

También son comunes herramientas / complementos adicionales para definiciones de lenguaje personalizadas, pero requieren conocimiento de sintaxis.


Esta es una respuesta maravillosa y cuidadosamente pensada. Pero las capturas de pantalla pueden ser subóptimas si planea imprimir esto, debido a la resolución. Algo para tener en cuenta.
Jeremy Carlson

1
@JeremyCarlson en Np ++ también se puede ajustar el tamaño de fuente / espaciado de línea, por lo que en teoría no hay límite para la resolución de captura de pantalla, pero será más difícil de crear, especialmente en una pantalla pequeña. Puede haber incluso algún truco para usar la pantalla virtual y configurar un tamaño de ventana muy grande
Mikhail V

porque cada vez menos personas nuevas eligen monoespaciado para la codificación hoy en día . Esto puede ser, pero la gran mayoría sigue utilizando el monoespacio. No puede simplemente traducir las convenciones de composición tipográfica normales al código. Por ejemplo, los signos de puntuación son más importantes que en los textos normales (la mayoría de los argumentos de esta respuesta mía se traducen en esto). Un tipo de letra de código no monoespacial diferirá considerablemente de uno para el texto normal. Además, a menudo desea que ciertas estructuras similares estén alineadas horizontalmente, por ejemplo, a[i][j] = 1a[m][n] = 2.
Wrzlprmft

@Wrzlprmft gracias por las ediciones. Y sí, no hay tantas fuentes buenas optimizadas para código y matemáticas (Verdana está bien). De hecho, Times tiene un período pequeño y dos puntos y algunos otros problemas, pero lo uso todo el tiempo: "los beneficios superan los costos"
Mikhail V

-5

En HTML, hay un conjunto de etiquetas <code> ... </code> que le dice al lector / intérprete que trate el contenido absolutamente literalmente. Además, <pre> ... </pre> hace lo mismo. Como alguien que a menudo tenía que componer fórmulas, ecuaciones y códigos para su publicación, también abogo por el uso de IMÁGENES para hacer esto ... hacer un .gif o .jpg o .png del elemento problemático.

Otro factor es que el código se representa tradicionalmente en Courier monoespacio, u otra fuente monoespaciada, porque envía semáforos o telégrafos al lector de que no es texto del cuerpo. Me suscribo a esta elección de estilo, creo que tiene mucho sentido.

En la mayoría de los sistemas de composición tipográfica "heredados", las ecuaciones matemáticas de una complejidad razonablemente alta consumían mucho tiempo ... y estaban llenas de errores.


¡por supuesto, las imágenes no se pueden cortar y pegar!
dwoz

3
No entiendo cómo esto responde a la pregunta que se hace en absoluto
Zach Saucier,
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.