¿Deberíamos almacenar cadenas de formato en los recursos?

Para el proyecto en el que estoy actualmente, tengo que entregar cadenas especialmente formateadas a un servicio de terceros para su procesamiento. Y por lo que estoy construyendo las cadenas de este modo:¿Deberíamos almacenar cadenas de formato en los recursos?

string someString = string.Format("{0}{1}{2}: Some message. Some percentage: {3}%", token1, token2, token3, number);

En lugar de codificar la cadena, que estaba pensando en movimiento en los recursos del proyecto:

string someString = string.Format(Properties.Resources.SomeString, token1, token2, token3, number);

La segunda opción es en mi opinión , no tan legible como el primero, es decir, la persona que lee el código debería tirar de los recursos de cadena para determinar cómo debería ser el resultado final.

¿Cómo puedo evitar esto? ¿Es la cadena de formato codificada un mal necesario en este caso?

Fuente

2009-06-08 jpoh

Creo que es un mal necesario, uno que he usado con frecuencia. Algo huele mal lo que hago, es:

// "{0}{1}{2}: Some message. Some percentage: {3}%" 
string someString = string.Format(Properties.Resources.SomeString 
            ,token1, token2, token3, number);

..at menos hasta que el código es lo suficientemente estable que podría ser incómodo tener que visto por otros.

Fuente

2009-06-08 02:43:24

También debe agregue comentarios al archivo de recursos para decir cuáles son los parámetros. Esto es muy útil para los localizadores si el archivo alguna vez va a la traducción. –

@CodingMonkey: de acuerdo. Haga la vida más fácil para los ingenieros de localización que pueda. No quieres conjeturas de traducción. –

@MichaelPetrotta> ¿Cómo estabilizarías el código para que estas {0} cadenas ya no sean necesarias? Personalmente, estoy pensando en no usar 'string.Format' pero uso:' "begin {middle} end" .Replace ("{middle}", middle) '. Por supuesto, este enfoque tiene sus propios problemas ... – Laoujin

No veo por qué incluir la cadena de formato en el programa es algo malo. A diferencia de los números mágicos tradicionales no documentados, es bastante obvio lo que hace a primera vista. Por supuesto, si está utilizando la cadena de formato en múltiples lugares, definitivamente debe almacenarse en una variable de solo lectura apropiada para evitar la redundancia.

Acepto que mantenerlo en los recursos es una indirección innecesaria aquí. Una posible excepción sería si su programa necesita ser localizado, y está localizando a través de archivos de recursos.

Fuente

2009-06-08 02:45:14

Sí, es un dolor, pero alguna forma de redirección es casi esencial para la localización. He trabajado al otro lado de esa valla, en la localización del software, y créeme, tú * no * quieres enviarnos el código. O intente fusionar los cambios de nuevo en el código. –

Sí, pero la localización gettext-style permite mantener las cadenas originales en código, mientras que aún envía solo un archivo de plantilla (plantilla) a los traductores. Entonces, los archivos de recursos no son la única opción. –

Existen varias razones por las que desearía hacer esto, pero la única gran razón es si va a ubicar su aplicación en otro idioma.

Si está utilizando cadenas de recursos, hay un par de cosas que debe tener en cuenta.

Incluya cadenas de formato siempre que sea posible en el conjunto de cadenas de recursos que desea localizar. Esto permitirá al traductor reordenar la posición de los elementos formateados para que se ajusten mejor en el contexto del texto traducido.
Evite tener cadenas en su formato tokens que están en su idioma. Es mejor usar estos para los números. Por ejemplo, el mensaje:

"El valor que ha especificado debe estar entre {0} y {1}"

es grande si {0}, y son números como 5 y 10. Si formatea {1} en cadenas como "cinco" y "diez", esto dificultará la localización.
Puede solucionar el problema de legibilidad del que habla simplemente nombrando sus recursos.

cadena someString = string.Format (Properties.Resources.IntegerRangeError, minValue, maxValue);
Evalúe si está generando cadenas visibles para el usuario en el nivel de abstracción correcto en su código. En general, tiendo a agrupar todas las cadenas visibles del usuario en el código más cercano a la interfaz de usuario como sea posible.Si algún código de E/S de archivo de nivel bajo necesita proporcionar errores, debería hacerlo con excepciones que maneje en su aplicación y mensajes de error consistentes. Esto también consolidará todas sus cadenas que requieren localización en lugar de tenerlas salpicadas a lo largo de su código.

Fuente

2009-06-08 03:01:14

Una cosa que puede hacer para ayudar a agregar cadenas codificadas duro o incluso acelerar la adición de cadenas a un archivo de recursos es usar CodeRush Xpress, que se puede descargar de aquí libremente: http://www.devexpress.com/Products/Visual_Studio_Add-in/CodeRushX/

Una vez que usted escribe su cadena puede acceder al menú de CodeRush y extraer a un archivo de recursos en un solo paso. Muy agradable.

Resharper tiene similar functionality.

Fuente

2009-06-08 03:10:17

Eso no es una solución a largo plazo. Su código aún se rellenará con 'Properties.Resources.SomeString'nnn cuando visite su código ** después de ** la conversión, como durante el mantenimiento – MickyD

Este comentario era bastante antiguo. Sin embargo, 'Properties.Resources.SomeString' es la forma en que accedería a las cadenas en un proyecto de C# en ese momento y la localización de resources.dll en un proceso externo era correcta. No siempre quiere localizar directamente el archivo binario, por lo que tener el texto en un archivo de recursos era la clave. –

sí se puede

nueva permite ver cómo

String.Format(Resource_en.PhoneNumberForEmployeeAlreadyExist,letterForm.EmployeeName[i])

esta voluntad me dio mensaje dinámico cada vez que

por la forma en que estoy useing ResXManager

Fuente

2016-09-21 17:39:31

¿Deberíamos almacenar cadenas de formato en los recursos?

Respuesta

Cuestiones relacionadas