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

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?

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.

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.

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).

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.

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

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

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