[...] nadie logró explicarme claramente POR QUÉ es tan importante restringirse con un ámbito privado para evitar que otros programadores rompan algún tipo de consistencia de la organización de datos.
En un equipo lo suficientemente pequeño con una base de código lo suficientemente pequeña que está realmente bien coordinada con buenos estándares (podría ser una sola persona), a menudo puede encontrar un software confiable que simplemente deja todos los datos a la vista para que cualquiera pueda tocar todos los campos de datos de una structexposición abierta y con la structdefinición abierta para cualquier persona que incluya ese encabezado para acceder. La ley de Murphy no siempre se aplica en esos casos.
Pero he trabajado en el escenario opuesto de una enorme base de código con muchos millones de LOC que datan de los años 80 con un gran equipo de desarrolladores de todo el mundo donde solo nos reuníamos cara a cara cada pocos meses, coordinados de forma flexible, a veces apenas habla el mismo idioma, sin estándares de codificación, excepto el SDK que la gente a menudo no seguía de todos modos, sin pruebas de unidad / integración, usando SVN sin ramificación y a veces pasando 6 semanas sin registrar el código, solo para bombardearnos con errores, y No fue hasta entonces que realmente entendí el valor de ocultar información y mantener invariantes .
Me ocupé de errores en los que ni siquiera podía reproducir el problema de manera consistente en mi máquina, y a veces ninguno de nosotros podía hacerlo entre todo el equipo. Y cuando finalmente pude reproducir afortunadamente el problema informado por el usuario o algo que se parecía a él después de todo tipo de prueba y error (y la prueba y el error a menudo tomaron horas porque la ineficiencia de nuestro software se combinó con la ejecución de la depuración contra la producción del usuario final los datos a menudo tomaban más de 15 minutos solo para que los datos se cargaran), lo rastrearía a algo así como un structtipo de cadena que tenía un lenconjunto a un número negativo de basura, como una longitud de cadena de -921141282.
Eso nunca debería suceder, pero ¿quién lo hizo? Así que tuve que establecer puntos de interrupción de memoria y averiguarlo, y cuando finalmente lo hice, fue como una interacción en cascada de variables no inicializadas que se usan aritméticamente, que finalmente se sumaron a un lencampo de cadena que se estableció en un número de basura negativo, y ese código no había sido modificado en años. Voló por debajo del radar.
Y todo ese tiempo después de encontrar muchos errores como este, pensé para mí mismo, ¿cuánto más confiable sería nuestro software si solo se usara gettersy setters? Los captadores y establecedores son generalmente indicativos de los peores tipos de diseños de interfaz posibles, pero un establecedor podría al menos desencadenar una falla de aserción si alguien intenta establecer la longitud de una cadena en un valor negativo. Podríamos haber atrapado ese error añosantes en el momento preciso en que se introdujo en segundos, no en la culminación de horas de esfuerzo de investigación. Y eso es solo pensar egoístamente como desarrollador; no cubre todas las horas de dolor que podría haber salvado a los usuarios y al equipo de control de calidad también. Usted sabe que su sistema está en un lugar bastante malo cuando sueña con lo mejor que podría ser si usara setters y getters frente a los últimos 35 errores que pasó toda la noche arreglando.
Incluso tuvimos casos en los que structsse documentaron de manera tal que nadie más debería acceder a esos campos de datos, solo para encontrar lugares en el sistema que accedan a esos campos de datos.
Así que estos son los tipos de cosas que realmente solo puedes apreciar al máximo enfrentando el peor de los casos, pero a menudo lo harás a menos que tengas la suerte de pasar el resto de tu vida trabajando en bases de código más pequeñas con equipos bien coordinados y Fuertes estándares de codificación.
¿Qué es el código hermoso en C ++ [...]?
Esa es una dificil. Todavía estoy tratando de resolver eso. La mayor parte del código que considero hermoso que he escrito a lo largo de los años, o al menos confiable y relativamente intemporal y estable (no necesita / quiere cambios) fue escrito en C y recientemente en Lua. Todavía me cuesta escribir código C ++ que parece pasar la prueba del tiempo hasta el punto de no reflexionar sobre eso unos años más tarde y al menos desearía poder cambiarlo. Siento que se ha vuelto más fácil desde C ++ 11, pero necesito algunos años para descubrir qué tan bien mi código se las arregla para sobrevivir sin necesidad de cambios para asegurarlo. Para mí, la "belleza" definitiva es la "estabilidad", como en el código que no necesita y ni siquiera tienta a ningún cambio adicional, pero sigue siendo relevante y útil en los años venideros, ya que '