¿Colocar marcadores de texto dentro de las cadenas es un mal estilo? ¿Hay una alternativa?

10

Trabajo con cadenas masivas que necesitan mucha manipulación.

Por ejemplo, podría generar una cadena como esta:

Parte 1
Barco

Sección A
Programación

Parte 2
Particionar barcos para la programación.

Sección AA
Sección Entradas SQL.

La cadena sería demasiado grande para verificar manualmente cada parte de ella. Ahora necesito splitesto stringen stringlistsecciones y partes. Se me ocurren dos opciones:

Una expresión regular:

QStringList sl = s.split(QRegularExpression("\n(?=Part [0-9]+|Section [A-Z]+)"));

Parece que debería funcionar, pero a veces las excepciones se deslizan (IE: Section SQL Entrieserróneamente se dividiría)

De lo contrario, lo que podría hacer es colocar un marcador cuando genere la cadena inicial:

🚤💻Parte 1
Barco

🚤💻Sección A
Programación

🚤💻Parte 2
Partición de embarcaciones para la programación.

🚤💻Sección AA
Sección Entradas SQL.

Lo que significa que dividir la cadena sería fácil:

QStringList sl = s.split("🚤💻"));

Sin embargo, algo me dice que ninguno de estos son buenos estilos o prácticas de programación, pero hasta ahora no lo he discutido ni he encontrado una alternativa.

Si fuera mi gerente de proyecto, ¿aceptaría alguno de estos métodos?
Si no es así, ¿qué sugeriría que haga como mejor práctica?

— Akiva
fuente

66

Si su programa sabe dónde colocar estos marcadores, ¿por qué no generar las secciones como cadenas separadas para empezar?

— Jacob Raihle

No creo que una buena idea sea un marcador que no se traduzca bien en su codificación actual.

— Tulains Córdova

2

los símbolos reales utilizados son en gran medida irrelevantes, lo que va a marcar la diferencia es la gramática de lo que está tratando de analizar

— jk.

44

@Akiva, ¿estás seguro del éxito? En cualquier caso, está trabajando con la misma cantidad de datos, dudo que haya una diferencia significativa. Componga las miles de funciones en una función, invoque eso en un bucle y tome algunas medidas.

— Jacob Raihle

2

@ Akiva Recuperar y reemplazar elementos en una lista debería ser, en el peor de los casos, comparable a dividir una cadena grande.

— Jacob Raihle

17

No es una mala práctica tener la codificación del documento incrustada como texto en una cadena. Piense en markdown, HTML, XML, JSON, YAML, LaTeX, etc.

Lo que es una mala práctica es reinventar la rueda. En lugar de escribir su propio procesador de texto, piense en usar un estándar existente. Hay un montón de software gratuito que hace gran parte del análisis por usted, y muchos tienen una licencia no restrictiva que le permite usar dicho software en su propio software propietario.

— David Hammen
fuente

En mi caso, estoy inventando una rueda, si lo que intento hacer es construir un intérprete único para un lenguaje de descuento. Por ejemplo, uno de mis proyectos fue interpretar Latex como SSML que el oído humano puede leer: meta.wikimedia.org/wiki/Grants:IdeaLab/… . << Hay un punto al final de esa URL, de lo contrario no funcionará

— Akiva

2

@ Akiva Tengo que trabajar con un formato de texto personalizado desarrollado por mi lugar de trabajo que literalmente reinventa la rueda. Tengo que mantener 4 analizadores en 3 idiomas (Javascript, Java y Objective-C) para ello, y es una pesadilla aterradora . Haga lo correcto ahora y elimine este absurdo formato de texto personalizado . No puedo expresar con palabras lo enorme de una pesadilla de mantenimiento esto se convertirá en un par de años en el camino. Utilice formatos estructurados existentes, XML, JSON, etc.

— Chris Cirefice

@ChrisCirefice ¿Puedes darme un ejemplo de cómo es una pesadilla?

— Akiva

1

@ Akiva Creo que el hecho de que tenga que mantener incluso un analizador (en mi caso varios y en diferentes idiomas) es horrible. Los formatos estándar existen por una razón: pueden representar los datos que usted necesita, y con un esfuerzo extremadamente pequeño de su parte, porque esos analizadores han sido construidos, refinados y mantenidos. El formato de texto personalizado también es un conocimiento extremadamente especializado, lo que significa que generalmente uno o dos desarrolladores estarán lo suficientemente familiarizados con el formato para mantenerlo con éxito. Eso debería decir mucho. La mayoría de las personas están familiarizadas con CML, JSON; pocas conocen formatos personalizados.

— Chris Cirefice

1

@Akiva De hecho! El formato Markdown (lo que SE y muchos otros sitios usan para formatear texto) es algo estándar , como lo es SQL. Pero hay muchos 'sabores' diferentes con extensiones personalizadas (por ejemplo, como SE). Hay una biblioteca estándar que analiza el 'núcleo', luego extiende la biblioteca si desea funciones adicionales. Pero construir y mantener su propio formateador sería ridículo: ya existen varios (rebajas, código BB, etc.), entonces, ¿por qué reinventar la rueda y mantener todo ese código? También

— podría

8

El uso de un separador común debería funcionar bien al dividir cadenas arbitrarias más grandes, pero recomendaría no usar un símbolo arbitrario. Alguien que lea esa cadena como texto sin formato podría confundirse, sin mencionar los problemas con UTF y si el símbolo aparece o no dentro de las secciones.

La parte más importante de esto es que cada sección permanece intacta, mientras que cada "encabezado de sección" debe identificarse adecuadamente.

¿Por qué no usar un separador común pero mantenerlo legible? Algo como:

[SECTION]
Part 1
Boat

[SECTION]
Section A
Programming

[SECTION]
Part 2
Partitioning boats for programming.

[SECTION]
Section AA
Section SQL Entries.

El problema es decidir cuál debe ser el separador , ya que debe ser algo que garantice que no se mostrará ninguna sección. Puede identificarlo más como un separador al requerir que esté al comienzo de una línea y que sea el único texto en esa línea .

Sin un mayor conocimiento de qué texto se espera en cada sección, es difícil hacer una recomendación sobre qué separador común sería mejor en este caso.

— Erdrik Ironrose
fuente

Me gusta el énfasis de tu respuesta en la legibilidad. Las cadenas se generan a través del raspado de datos del texto generado por el usuario, por ejemplo, el lenguaje de marcado utilizado en SE para escribir preguntas y respuestas. Por lo tanto, podría imaginar fácilmente qué tipo de problemas de manipulación de cadenas podrían entrar en juego.

— Akiva

5

La respuesta aceptada parece haber perdido lo que escribió en un comentario:

La razón es que gran parte de la manipulación que hago requiere la cadena completa

y dio esto como un ejemplo:

s.replace ("barco", "programación");

Si eso es lo que quiere, en mi humilde opinión, es una muy mala idea usar un "markdown" o un separador de texto para toda su cadena, esto siempre tiene un cierto riesgo de interferir con la manipulación y no conducirá a un código robusto. Especialmente cuando intenta comenzar a usar expresiones regulares en una cadena combinada de este tipo, es probable que encuentre los mismos problemas que la gente observó al intentar analizar HTLM o XML con expresiones regulares .

Especialmente porque usted escribió que podría haber "miles de funciones [de manipulación]", ese riesgo podría convertirse en un problema real. Incluso si usa algunas rebajas como XML para almacenar la lista de cadenas internamente, debe asegurarse de que la manipulación procesará solo el contenido, no la rebaja, por lo que eso significaría dividir la cadena en partes antes de realizar cualquier procesamiento, y unirse luego, nuevamente, por lo que tendrá un alto riesgo de tener un mal desempeño.

La mejor alternativa de diseño aquí es proporcionar un tipo de datos abstracto (use una clase si lo desea), llamemos MyStringListy proporcione un pequeño conjunto de operaciones básicas que le permitan implementar sus "miles de funciones" en términos de esas operaciones. Por ejemplo, puede haber operaciones genéricas findy replace, o una mapoperación funcional genérica . También puede agregar algo como una JoinToStringoperación si realmente necesita la lista completa en una cadena para ciertos propósitos.

Al usar estas operaciones, su temor de que el código se vuelva más complicado porque "todo tendría que hacerse en un bucle for" se vuelve inútil, porque los únicos forbucles que obtiene están encapsulados dentro de las operaciones del tipo de datos. Y no me preocuparía el rendimiento hasta que tenga un impacto real y medible en el rendimiento (que dudo que obtenga si implementa las operaciones básicas correctamente).

— Doc Brown
fuente

Vota porque realmente creé algo así. Me permite establecer paréntesis personalizados, por ejemplo, <y >, y tomará cada instancia de esa cadena donde pueda eliminar fácilmente las instancias que no quiero, y manipularlas limpiamente de la manera que quiero. Esto es bueno porque las expresiones regulares por sí mismas no manejan subcadenas como esta: <boat <programming>>bueno, donde hay varias capas de corchetes.

— Akiva

1

El formato que se describe es muy similar a los archivos INI:

https://en.wikipedia.org/wiki/INI_file

En ese caso, la sección está encerrada entre corchetes [], por lo que lo que describe tiene sentido al marcar la sección de alguna manera para agregar significado adicional a ese texto.

— Jon Raynor
fuente

0

Por ejemplo, podría generar una cadena como esta:

Pregunta: ¿De qué "genera" esta cadena?

¿Sería eso más fácil de manipular?

— Phill W.
fuente

La cadena se genera a partir del contenido de usuario de Datascraping de un sitio web.

— Akiva

1

Esta no es una forma confiable de recuperar datos de un sitio web, simplemente porque cambian y las cosas se mueven o desaparecen por completo. Sería mucho mejor recuperar los datos de algún tipo de API publicada (y, por lo tanto, confiable). Además, el uso de muchos sitios web comerciales prohíbe específicamente este tipo de cosas.

— Phill W.

A veces no puedo elegir qué datos son valiosos para mí, por lo que siempre es necesario hacer verificaciones de integridad de lo que está viendo, o simplemente comprometer y esperar lo mejor. Por ejemplo: Escribí una LaTeXde SSMLintérprete, y uno de los problemas es que se puede generar imágenes idénticas con código muy diferente, por lo que es casi imposible de ser consistente si el usuario elige maneras pobres o esotéricos de la generación de sus fórmulas. Todo lo que significa al final del día es que las personas que no utilizan las buenas prácticas no tendrán una interpretación decente de sus guiones.

— Akiva