Esistono prove del fatto che Intellisense riduce la produttività? [duplicare]

Probabilmente il tuo amico sottintende che intellisense consente agli sviluppatori di non memorizzare mai tutte le proprietà e i metodi di ogni tipo di oggetto, il che a sua volta riduce la velocità con cui scrivono il codice.

Ma per chiunque abbia mai usato un tipo, controllo, classe o oggetto con cui non era familiare, l'intellisense è infinitamente utile per ridurre il tempo sprecato dovuto alla lettura dell'intera classe.

Quindi, in fondo, secondo me, il tuo amico ha generalmente torto.

Come può ridurre la produttività? Immagina di dover cercare nella documentazione ogni volta che cerchi uno spazio dei nomi, una classe, un metodo o una proprietà.

Intellisense è uno dei the grandi progressi negli editor di IDE.

Riduce la produttività facendo credere a Microsoft che sia corretto progettare funzioni con 10 o 12 parametri, quindi praticamente nessuno potrà mai avvicinarsi o imparare a usarle senza l'aiuto di (qualcosa di simile) Intellisense.

Modifica: Ok, diamo un'occhiata all'esempio di CreateAnimatedSprite . In primo luogo, un nome di funzione con due verbi è un segno quasi certo di scarsa separazione delle preoccupazioni - cioè, hai una singola funzione che fa davvero due cose. Il nostro primo passo è quello di risolvere il problema in modo da ottenere un CreateSprite (o, dal momento che apparentemente viene caricato da un file, probabilmente dovrebbe essere LoadSprite ) e un AnimateSprite . Per il momento, supponiamo anche che @Mason sia sbagliato, e hai davvero bisogno di tutti quei parametri - ma quando abbiamo separato le preoccupazioni in modo decente, apparentemente abbiamo lasciato qualcosa del tipo:

sprite LoadSprite(std::string filename, int imageHeight, int imageWidth);
void AnimageSprite(sprite s, int frameWidth, int frameHeight, int numColumns, bool isLooped);

Dal mio conteggio, ora abbiamo il conto alla rovescia dei parametri fino a un massimo di 5 - metà del numero che ho menzionato come eccessivo.

Lo considererei comunque a corto di ideale. Prima di tutto, sconsiglio di usare un bool come parametro di funzione nei casi più . Basta dare un'occhiata a una chiamata alla funzione, non è immediatamente ovvio a cosa farebbe riferimento a true o false . Sarebbe meglio avere qualcosa del tipo:

enum {LOOP, NOLOOP};

Quando qualcuno sta leggendo una chiamata alla funzione, LOOP è molto più significativo di true . A seconda della situazione, ci sono un paio di altre possibilità da considerare. Uno userebbe l'orientamento agli oggetti, quindi avremmo:

class Sprite {
public:
    enum looping { LOOP, NOLOOP };

    load(std::string filename, int imageWidth, int imageHeight);
    animate(int frameWidth, int frameHeight, int numColumns, looping doLoop);
};

Questo ci porta solo a quattro parametri per una funzione, fornendo comunque i dati che ritenevi necessari.

In realtà, probabilmente possiamo fare ancora meglio. Prima di tutto, il file da cui cariciamo il nostro sprite può memorizzare la dimensione delle immagini che contiene, quindi potremmo non aver bisogno di fornirle (è utile soprattutto se stiamo selezionando uno sprite da un file che potrebbe contenere parecchi). In secondo luogo, come sottolineato da @Mason, probabilmente non è necessario fornire frameWidth / frameHeight o numColumns. Inoltre, l'animazione a passaggio singolo e l'animazione in loop sono abbastanza diversi da rendere spesso più ragionevole fornire quelli come due funzioni separate. Infine, potrebbe avere senso passare semplicemente il nome del file da cui andremo a leggere lo sprite come parametro per il ctor. Incorporando tutti questi elementi, otteniamo:

class Sprite {
public:
    Sprite(std::string const &filename);
    animate(page const &target);
    loop(page const &target);
};

Quindi per caricare un animate di uno sprite, ora abbiamo bisogno di qualcosa come:

Sprite x("somefile.spr");
x.loop(animPage);

Ricorda che la memoria a breve termine delle persone varia da circa 4 elementi per una persona di intelligenza media a circa 8 per i migliori geni.

Questo significa che 10 parametri sono quasi sempre irragionevoli. 7 parametri lo mettono a portata di pochi, ma onestamente solo alcuni. 4 lo mette alla portata di quasi tutti i programmatori, e 1 (o anche 3, se davvero hai bisogno di specificare la risoluzione) lo mette nella semplice lista dei morti.

Lo stesso tipo di argomenti si verificano attorno al controllo ortografico e all'uso di calcolatrici nelle scuole. L'idea è che gli studenti che hanno libero accesso alle calcolatrici riducono la loro capacità aritmetica mentale.

Sono d'accordo sul fatto che tale effetto sia probabilmente vero e sosterrei che non è importante. I calcolatori sono sempre disponibili, quindi sarebbe più produttivo spendere tempo imparando a risolvere equazioni differenziali del secondo ordine piuttosto che imparare a fare complicate divisioni nella tua testa.

Se usi un IDE con una buona implementazione di qualcosa come Intellisense, allora sì, certe abilità svaniranno, e questo perché passerai più tempo a fare altre cose. Cose che sono più produttive per il tuo codice che ricordare il nome preciso di una particolare funzione membro.

Se prevedi di tornare a un IDE non Intellisense, potresti avere un problema. In tal caso, spegnilo. Per il resto di noi che pensano che gli IDE avanzeranno, siamo OK.

Sì, Intellisense potrebbe incoraggiare i progettisti di API a inserire troppi argomenti, ma scrivere qualcosa come C ++ richiede molta disciplina per non fare nessuna delle molte cose brutte che ti permette di fare, e questo è solo un altro.

Un'ultima analogia: non disattivi l'evidenziazione della sintassi solo nel caso in cui dovessi modificare un file nel blocco note più tardi, vero?

In realtà può ridurre la produttività - fuori di Visual Studio, perché devi cercare molto nella documentazione. A causa dell'intelligenza, potresti non aver mai imparato a memoria i metodi e le lezioni importanti.

Sono passati alcuni anni da quando ho lavorato in C #, quindi darò la mia risposta w.r.t. Eclipse e Java. Il completamento in Eclipse non riduce la mia produttività. La necessità di completamento a causa dell'incoerenza dell'API Java riduce notevolmente la mia produttività. Ad esempio, Java ha matrici, elenchi, serie ordinate e flussi. Sono tutti simili alle liste e in pratica non hanno metodi in comune. È lo stesso per le mappe, i parametri di richiesta HTTP ei parametri di query SQL e le righe in un set di risultati SQL e JavaBeans. Sono tutti simili a una mappa, ma hanno API diverse e la conversione tra loro è dolorosa. Faccio bene senza il completamento in lingue in cui le API sono coerenti, in cui tutto ciò che assomiglia a una lista è una lista e tutto ciò che assomiglia a una mappa è una mappa.

Secondo me, l'unica volta in cui può ridurre la produttività è quando devi fare qualcosa in cui l'intellisense non è disponibile (ad esempio quando fai qualcosa di dinamico). Sei così abituato ad essere lì che pensi che qualcosa non va quando non c'è.

Usi lo strumento che senti ti rende più produttivo e l'altro può usare lo strumento che sente farlo sentire più produttivo. Non succederà mai, ma un mondo senza "il mio strumento è il migliore perché lo uso quindi devo forzarlo su tutti gli altri" la mentalità sarebbe davvero grandiosa.

Su un vettore correlato, ho notato che le persone che usano strumenti che evidenziano la sintassi tendono ad essere meno dello stile "cattivo ungherese", non c'è bisogno di avere mThis, mThat, aThing e aNother se hai colori a ti dico lo scope.

Mi sono imbattuto in una situazione dove ha ottenuto IntelliSense così confuso da macro annidate in un particolare file di intestazione che ogni operazione di modifica impiegava più di 30 secondi. Questo sicuramente ha ridotto la mia produttività.

modifica

Si scopre che il colpevole non era IntelliSense, ma un plug-in di refactoring che faceva anche analisi della sorgente in background. Quindi continuo a dire che è possibile che presunti stimolatori della produttività rallentino, ma non ho un caso specifico contro IntelliSense.

A volte IntelliSense ama essere un po 'troppo zelante con il completamento automatico. Ad esempio, se voglio scrivere qualcosa di IntelliSense non ne so ancora (principalmente a causa di alcuni tasti che usa per il completamento automatico non ha molto senso).

Dire che ho un file C # in cui voglio usare la classe File per copiare qualcosa. Non ho ancora incluso "using System.IO" ancora.

Digito "File". e mentre colpisco il periodo, si passa immediatamente "Aha! So cosa vuoi, vuoi FileStyleUriParser". Quindi devo andare a cancellare la parola e provare a digitare di nuovo. Dimentico che il periodo si accende automaticamente e accidentalmente ripeto la stessa cosa. Alla fine premo il tasto ESC al momento giusto e lo digito.

Questo perché so cosa voglio digitare e non ho bisogno di IntelliSense per questo. Inoltre, non voglio passare il tempo in cima al file per inserire l'istruzione using in (ancora).

Ora, per essere onesti, puoi disattivare questo comportamento. A volte mi piace questo comportamento e odio gli altri (che è il motivo per cui non l'ho spento).