He estado programando en varios idiomas durante unos 10 años. Y todavía no he descubierto cuándo es una buena idea importar algo al espacio de nombres global ( using x::y
en C ++, from x import y
en Python, etc.), por lo que casi nunca lo hago.
Casi siempre me parece una mala idea, aunque solo sea porque limita el conjunto de nombres de variables que puedo usar. Por ejemplo: dónde usarlo using namespace std;
o using std::string;
en C ++, ya no podría usarlo string
como un nombre de variable, lo que ocasionalmente hago (por ejemplo, para funciones de utilidad de cadena).
Pero me pregunto: ¿hay algunas situaciones en las que importar un nombre en el espacio de nombres global realmente tiene sentido? ¿Alguna regla general?
Respuestas:
En C ++, generalmente está mal visto, especialmente
using namespace std
. Esestd
espacio de nombres tiene tantos nombres, muchos de los cuales son algoritmos muy genéricos, cuando puede obtener algunas sorpresas extremadamente desagradablesusing namespace std
. Algo asíusing std::cout;
no es tan malo. Pero nunca, nunca,using
nada en el espacio de nombres global en un archivo de encabezado. Eso es un delito de pelotón de fusilamiento.fuente
Deberías hacerlo cuando simplifique tu código. No debe hacerlo cuando causaría conflictos de nomenclatura, o cuando más tarde podría llevarse a ámbitos donde causaría conflictos de nomenclatura, como un archivo de encabezado.
Algunas personas piensan que debería ser raro. Creo que (fuera de los archivos de encabezado) no usarlo debería ser raro, porque el prefijo del espacio de nombres generalmente no agrega ninguna información útil, como usar el nombre completo de alguien cada vez que se dirige a ellos.
Déjame ponerlo de esta manera. Cuando ves
string
como un nombre de clase, ¿piensas automáticamentestd::string
omycustom::string
? Es como el viejo adagio. Cuando escuchas el sonido de los cascos, piensas en caballos, no en cebras. En otras palabras,using namespace std
casi siempre no es gran cosa.using namespace mycustom
Del mismo modo, generalmente no es un gran problema, a menos que contenga un conflictostd
, en cuyo caso su espacio de nombres personalizado es el que desea que siempre requiera el prefijo.fuente
mycustom
contiene unastring
clase. En la cima tuusing namespace mycustom;
. A través del resto del código que ahora usastring
. Todos los que leen el código piensan questd::string
solo usted (y algunas personas muy observadoras) están pensandomycustom::string
. Aquí has puesto las cebras en el potrero. Ver también stackoverflow.com/q/1452721/14065mycustom
conflictosstd
contigo siempre deben requerir elmycustom::
prefijo.doStuff(int)
. Y una versión más nueva demycustom
agregadoStuff(double)
todo el significado de cualquier llamada a losdoStuff(5.5);
cambios (potencialmente sin que te des cuenta).Al trabajar en Python, uso de x import y (como z) constantemente, para tener nombres claros y concisos para hacer referencia a las importaciones.
Las importaciones son invaluables en una base de código con una jerarquía de espacio de nombres profunda. Esto es especialmente cierto cuando el estándar de estilo para la base de código es PEP 8 , que limita la longitud de la línea a menos de 80 caracteres.
Por ejemplo, considere:
Lo que en cambio podría escribirse:
Dado que los identificadores de Python distinguen entre mayúsculas y minúsculas y tienen una longitud ilimitada , no nos quedaremos sin nombres, independientemente de cuántos importamos.
Si queremos usar el mismo nombre en nuestro módulo como uno de los módulos que deseamos importar, podemos usar un alias para la importación:
fuente
Depende del programador cuándo usarlo. En mi humilde opinión, es mejor no usarlos en absoluto, especialmente en los archivos de encabezado. Pero hay varios casos cuando lo uso
Cuando quiero presentar algo a otro espacio de nombres, por ejemplo
Para habilitar ADL para algunos algoritmos de otro espacio de nombres
Si no quiero escribir nombres largos de espacios de nombres en .cpp, siempre puedo hacer un alias
fuente