È considerata una cattiva pratica importare i simboli in blocco in uno spazio dei nomi globale indipendentemente dal linguaggio di programmazione?

Question

È considerata una cattiva pratica importare i simboli in blocco in uno spazio dei nomi globale indipendentemente dal linguaggio di programmazione?

#1 da (3 voti)
#2 da (2 voti)
#3 da (2 voti)

1

Nella comunità C ++ è considerata una pratica estremamente scorretta scrivere:

using namespace something;

nell'ambito del file per qualsiasi motivo, anche se la dimensione del progetto è al massimo di poche centinaia di righe.

Tuttavia, altri linguaggi offrono costrutti analoghi. Ad esempio, possiamo farlo in Python:

from some.thing import *

E questo in Java:

import some.thing.*

etc, ecc.

Eppure non sento CHE MOLTO aggrotta la fronte a questi costrutti analoghi in altri linguaggi come in C ++.

Lo sta facendo in altre lingue altrettanto sconsiderate come in C ++ e se no, allora perché?

language-agnostic namespace

posta gaazkam 29.09.2017 - 19:14

fonte

3 risposte

Leggi altre domande sui tag language-agnostic namespace

Controlla se un controller sta facendo troppe cose Perché i Costruttori nominati stanno diventando popolari non dovrebbe essere un antipattern?

score 3 · Answer 1

Per quanto ne so, l'importazione di un pacchetto completo nello spazio dei nomi corrente non è disapprovata tanto in Python e Java quanto in C ++.

Penso che questo abbia a che fare con il modo in cui i namespace sono integrati nelle diverse lingue.

In Java e Python, i pacchetti sono legati a una struttura di directory e ogni pacchetto contiene un numero abbastanza limitato di nomi (nell'ordine da decine a poche centinaia per pacchetti molto grandi). Inoltre, non è facile aggiungere nomi in seguito senza modificare i pacchetti originali.

D'altra parte, in C ++, un singolo spazio dei nomi copre in genere una libreria completa con centinaia o migliaia di nomi e una struttura interna molto piccola. Inoltre, qualsiasi file sorgente può riaprire una dichiarazione dello spazio dei nomi e aggiungere altri nomi. Ciò significa che se fai using namespace something; , non puoi letteralmente sapere quali nomi stai scaricando nel tuo attuale spazio dei nomi.

score 2 · Answer 2

(Userò la terminologia Java nella mia risposta).

Le importazioni con caratteri jolly sono un rischio di manutenzione completamente non necessario. Per esempio. la funzione "Riorganizza le importazioni" di IDE di Eclipse li sostituisce con quelli espliciti, per una buona ragione.

Il problema con una tale importazione di caratteri jolly è che oltre ai simboli di cui hai veramente bisogno ottieni anche tutti gli altri simboli dal pacchetto. E se successivamente qualcuno aggiunge un simbolo al pacchetto (nuova versione estesa della libreria che usi), potresti ottenere un conflitto di nomi.

Con un import some.thing.*; , QUALSIASI simbolo nel tuo codice potrebbe cambiare il suo significato, se qualcun altro aggiunge una classe con questo nome al pacchetto some.thing .

Con le importazioni esplicite come import some.thing.Special; , viene influenzato solo il simbolo Special (in modo non ambiguo significa some.thing.Special ), quindi non esiste tale rischio.

Forse nella comunità Java, le importazioni di caratteri jolly non sono male alla sorte perché IDE come Eclipse tipicamente generano le importazioni al volo, non utilizzando mai i caratteri jolly, quindi nel codice di produzione probabilmente non troverai le importazioni di caratteri jolly.

score 2 · Answer 3

Ci sono due problemi a cui posso pensare con using namespace something; in C ++.

using e #include sono transitivi. Se scrivi un file di intestazione pubblico, che utilizza uno spazio dei nomi o include un altro file di intestazione, tutti gli utenti del file di intestazione useranno anche questi spazi dei nomi e includeranno quei file di intestazione. Questo ti rende una piccola "comodità" che ha un impatto molto più ampio del previsto. Questo non è il caso per Java o Python.
Quando si importano così tanti simboli in massa, si presenta il rischio che un aggiornamento di libreria / piattaforma possa introdurre una collisione di simboli. Ho riscontrato un problema con questo problema una volta, utilizzando import java.util.* , solo per ArrayList , List e alcune altre classi comuni. Quando ho aggiornato a Java 8, il mio riferimento a Optional (la mia classe) è diventato ambizioso, perché la mia importazione con caratteri jolly ha causato l'importazione di java.util.Optional .

In C ++, Python e Java, suggerirei di utilizzare l'IDE per generare istruzioni using / import per ciascuna delle tue dipendenze, senza utilizzare il carattere jolly. Per esempio. using std::vector;