¿Cuál es el punto de hacer una distinción sintáctica entre los tipos estándar y los definidos por el usuario?


13

Aunque aquí me referiré específicamente a las convenciones de nomenclatura de C ++ y Bjarne Stroustrup , en principio, he visto que las personas usan reglas algo similares para otros lenguajes aquí y allá.

Entonces, la idea básica es que uno debería poder distinguir los tipos estándar de los tipos definidos por el usuario mientras lee el código. Por ejemplo, Bjarne Stroustrup sugiere que uno use

una letra mayúscula inicial para los tipos (p. ej., Cuadrado y Gráfico)

que teniendo en cuenta que

El lenguaje C ++ y la biblioteca estándar no usan letras mayúsculas

permite alcanzar el objetivo mencionado anteriormente.

Pero, ¿por qué necesitamos hacerlo? ¿Cuál puede ser el propósito de distinguir los tipos estándar y los definidos por el usuario?

No pude encontrar ningún razonamiento de Bjarne Stroustrup sobre este asunto, y además, yo mismo pienso de manera diametralmente opuesta. : DI lo sé, lo sé, "¿Quién soy yo para disputar Stroustrup?" Pero, escuche, un montón de características del lenguaje C ++, por ejemplo, sobrecarga del operador, tienen el propósito de permitir a los tipos definidos por el usuario un nivel similar de soporte sintáctico que los tipos estándar. Y luego todo esto está desconcertado por una disciplina de nombres diferente ...

PD: Sin mencionar que a menudo una palabra no es suficiente para nombrar una clase y una palabra separada por guiones bajos que comienza con una letra mayúscula parece muy extraña.


66
Al final, también podría llamarlo una forma de notación húngara (es decir, incrustar información sobre el tipo / uso en un nombre), que generalmente está mal visto. Por lo tanto: buena pregunta.
stijn

2
@stijn: Sí, pero ¿sabes por qué está mal visto? En el pasado, cuando todos usaban un editor de texto para escribir sus programas, era útil conocer el tipo mirando el identificador. Pero hoy, puede pasar el cursor sobre el identificador en cualquier IDE moderno y le indicará el tipo.
Robert Harvey

44
@RobertHarvey Excepto que la notación húngara también se evita en las comunidades que no tienen IDE potentes, o más bien, utilizan principalmente editores de texto sin formato.

1
@RobertHarvey No, soy consciente de ambos ("aplicaciones húngaras" y "sistemas húngaros"), y en mi experiencia ninguno de los dos es común, por ejemplo, en Python y Rust.

3
@RobertHarvey ¿Estás diciendo que la notación húngara solo existió en C, C ++ y VB? De todos modos, mi punto fue cuestionar la razón por la que está mal visto (que es redundante solo porque tenemos IDE que le indican el tipo) ya que esa razón no se aplica a los idiomas que no tienen tales ID y, por su razonamiento, debería beneficiarse del húngaro. Que Python se escriba dinámicamente no hace ninguna diferencia, de hecho, debería mejorar el razonamiento, ya que normalmente el programador conoce los tipos al escribir el código, pero no se pueden inferir automáticamente.

Respuestas:


5

No hay absolutamente ningún propósito o beneficio en tal. Uno de los objetivos de C ++ era tratar las UDT y las primitivas de manera intercambiable, y aunque no han tenido éxito por completo, esta es un área en la que no tiene que diferenciarse.

Cuando se trata de nombrar, Stroustrup es una locura, y este es un hecho científicamente probado.


2
Veré tu RAII y te criaré un SFINAE.
Robert Harvey

55
Pude ver cómo podría ser útil distinguir los tipos estándar de los UDT. No debe cambiar el código en una biblioteca estándar a menos que tenga una muy buena razón, así que ver la letra minúscula indica que usted no tiene que ir a ver el código porque, bueno, está en la biblioteca estándar.
Robert Harvey

44
@delnan: sí. Eso no es más que un llamado a la autoridad por parte de "Mucha gente". Si "Mucha gente" quiere venir aquí y discutir su razonamiento, son libres de hacerlo, y hasta entonces, no tienen nada que agregar. FTR, también uso mayúsculas para UDT ... pero también para primitivas cada vez que tengo un motivo para usar alias.
DeadMG

2
@RobertHarvey: Eso supone que no puedes reconocer los tipos estándar a la vista. O al pasar el mouse sobre ellos en su entorno y ver el "std ::". O usando Ir a definición o lo que sea. Entonces, básicamente, no se aplica.
DeadMG

1
Siempre pensé que el propósito era distinguir de los tipos estándar, antes del advenimiento de los espacios de nombres. Hoy en día, es solo una reliquia del viejo pensamiento (una "mejor práctica" que dejó de ser la mejor hace algún tiempo). FWIW, en mis proyectos personales, uso letras minúsculas snake_casepara mis clases y espacios de nombres y aún no he tenido problemas, o confusión, causados ​​por esto.
utnapistim 01 de

3

Las convenciones de nomenclatura tratan de apoyar la comprensión humana (es decir, programador y mantenedor) del código.

Los UDT se pueden especificar para que la declaración de variables, la inicialización, las expresiones y las declaraciones funcionen de manera diferente a la de los tipos estándar. Para encontrar problemas, es útil que el mantenedor tenga alguna señal de que alguna sección del código podría hacer cosas extrañas (por ejemplo, la implementación de un tipo integral definido por el usuario utilizado dentro de alguna función podría tener una falla en cómo se suma).

Hay muchas formas de proporcionar tales señales (comentarios, especificaciones de diseño, etc.). La ventaja de las convenciones de nomenclatura es que están presentes en el código, mientras que los comentarios pueden omitirse, estar desactualizados, etc.


2

Una razón por la que uso palabras en mayúsculas para los tipos es para distinguir las variables de los tipos. Esto permite declarar una variable con, además de las mayúsculas, el mismo nombre:

Foo foo;
Graph graph;

Esto puede ser útil para clases en las que solo se usa una instancia en cada contexto, por ejemplo, ajustes de configuración.


En mi humilde opinión esto no responde a la pregunta en el título. Quizás agregue "a este respecto, nombrar los tipos estándar con letras minúsculas era solo para compatibilidad con cstdlib".
Vorac
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.