Dovrei evitare di usare "break" durante un'intervista di codifica? [duplicare]

Una volta ho fatto questa domanda ad un amico che è attualmente impiegato al microsoft (all'epoca era impiegato nel team che lavorava su Project Volta, ora noto come "Reactive Extensions"), perché all'università i miei docenti erano soliti dire che "le pause sono cattive". Fece una risatina e disse che probabilmente era un professore che non scrisse mai codice di settore.

Visto che usano le interruzioni nel codice, non vedo perché scrivere in un'intervista rifletta male, purché comprendiate i vantaggi e / o gli svantaggi nello scenario che vi hanno chiesto di elaborare.

Essere in grado di sapere perché hai optato per l'una o l'altra mostrerà intuizione, che è importante. Immagina la tua visione del problema e la soluzione generale è stata ottima, ma hai usato un'interruzione, che è facile da risolvere. Ti dicono solo di non usare più le pause. D'altra parte, se non hai usato le pause, ma l'algoritmo era altrimenti sciatto, sarebbe peggio per le tue probabilità.

Dipenderà anche dal problema in questione, e come l'ingegnere mondiale ha scritto come commento, anche su molte altre variabili.

Oltre all'uso del punto e virgola in Javascript, se utilizzare vi o emacs nel mondo Unix e se utilizzare una singola dichiarazione di ritorno in una funzione è una controversia che spesso non ha senso per molti programmatori di produzione. Se ha senso usarlo e il codice rimane chiaro, allora penso che starai bene. Se no, allora non usarlo.

Ora sapere gli argomenti a favore e contro l'interruzione è probabilmente più utile se viene sollevato in un'intervista.

Questo è il mio consiglio e non ha nulla a che fare se usare break è buono o cattivo: codifica il codice tu . Vogliono sapere come codifichi , non come pensi che codifichino .

Potresti pensare che è meglio superare in astuzia l'intervistatore dicendo loro quello che vogliono sentire. Nel peggiore dei casi ti assumeranno, e poi sembrerai un idiota perché hai dato un'impressione sbagliata e non hai scritto lo stesso tipo di codice che si aspettavano, e ti licenzieranno qualche mese miserabile dopo per non essere all'altezza delle loro aspettative.

Sii onesto in un'intervista. Se non ti assumono a causa del tuo stile di codifica, è una vittoria tutt'intorno. Non ottengono qualcuno che non si adatta al loro modo di lavorare, e non rimani bloccato in un lavoro in cui devi scrivere codice in un modo che non ti è familiare, dove sei ridicolizzato per la tua codifica stile, e dove sei costantemente preoccupato scopriranno che non sei quello che fingevi di essere durante l'intervista.

Questo, e sii pronto a spiegare perché hai usato la pausa, e perché pensi che sia stata la scelta giusta o sbagliata. Come intervistatore, non mi interessa molto di ciò che i candidati dicono o scrivono sulla lavagna, a patto che possano darmi una spiegazione razionale della loro scelta.

Questa domanda è a rischio di essere un duplicato di Sono 'break 'e' continua 'cattive pratiche di programmazione? ma proverò a dare una spiegazione più teorica.

Ho dimenticato il riferimento ma sarei grato se qualcuno lo trovasse e saremo lieti di includerlo qui, oppure puoi modificare la mia risposta senza chiedere se hai i rappresentanti.

La spiegazione teorica è stata originariamente fornita per supportare alcuni uso limitato di goto , e la giustificazione a questi usi limitati ha dato origine alle dichiarazioni di flusso di controllo strutturate che abbiamo familiarità oggi.

La giustificazione è questa. Esegui il seguente esercizio su carta:

• Ai fini di questo esercizio, considera tutti i trasferimenti di controllo (sia incondizionati che condizionali) come goto .
• Elenca il codice del programma per una singola funzione. Se si desidera analizzare più di una funzione, incorporarla nella funzione di primo livello.
• Disegna frecce per connettere ogni goto alla destinazione del ramo.
  • Metti tutte le frecce di diramazione a ritroso (verso l'alto) a sinistra dell'elenco del programma.
  • Metti tutte le frecce dirette in avanti (verso il basso) a destra dell'elenco del programma.
• Se riesci a trovare un modo per sistemare quelle frecce senza incrociarsi tra loro due, il tuo codice si dice abbia una struttura di trasferimento del controllo ragionevole.

(La terminologia usata qui potrebbe essere diversa dal riferimento originale.)

Ora esaminiamo le due parole chiave interrogate: break e continue .

Suppongo che tu stia facendo riferimento al loro uso all'interno dei loop. Come altri sottolineano, break è obbligatorio nelle dichiarazioni switch (o almeno gli standard di codifica del tuo futuro datore di lavoro lo avrebbero reso obbligatorio), quindi non ha senso discutere.

• break è semplicemente un trasferimento di controllo verso il fondo (uscita) del ciclo. Pertanto non attraversa il flusso di controllo del loop stesso.
• continue trasferimenti all'inizio (loop advance e condition test) del loop. Se il test condizione è falso, esce anche il ciclo. Notare che la parte "se il test delle condizioni fallisce ..." è un flusso di controllo diverso . continue deve solo trasferirsi all'inizio.

In poche parole, break e continue utilizzati all'interno di un ciclo non violano la struttura del flusso di controllo sensibile. Questo è il motivo per cui sono consentiti in primo luogo in linguaggi storicamente significativi come Pascal, ecc. dove la progettazione della lingua supera considerazioni pratiche.

Ora, per quanto riguarda alcuni post che affermano che break è sbagliato se appare nel mezzo di un codice senza effetti collaterali, direi sì e no.

La maggior parte delle volte, se vedi che succede, è perché deve essere così. La realtà rende questo argomento discutibile.

Esempio: in alcuni dei tuoi codici, devi farlo all'interno di un ciclo:

• Controlla prima la condizione A. Se fallisce puoi fare break (o continue , a seconda dell'attività).
• Solo se la condizione A è soddisfatta, puoi iniziare a calcolare qualche valore B.
• Con B calcolato, controllerai anche la condizione B (utilizzando il valore di B).

Puoi spostare il controllo delle condizioni B all'inizio del ciclo? Non puoi È dettato dalla natura del compito che stai implementando. Quindi l'argomento è discutibile. Se questo argomento, favorisce scomporre le funzioni lunghe in subroutine più brevi , piuttosto che argomentare per un posizionamento accurato dell'uso delle istruzioni break .

Personalmente, avrei disapprovato break al di fuori delle istruzioni switch. Ma detto questo, avrei aggrottato le ciglia di più se il codice fosse sbagliato. Se break è quello a cui sei abituato e puoi produrre codice funzionale con esso, impazzisci. Non dovrebbe squalificarti da qualsiasi lavoro.

È abbastanza difficile trovare programmatori competenti. I programmatori competenti che codificano nel mio stile preferito sono più simili agli unicorni.