"continua" e "interrompe" per l'analisi statica

3

So che ci sono state un certo numero di discussioni sul fatto che la rottura e il proseguimento debbano essere considerati dannosi in generale (con il risultato finale - più o meno - che dipende, in alcuni casi aumentano la chiarezza e la leggibilità, ma in altri casi non lo fanno).

Supponiamo che un nuovo progetto stia iniziando lo sviluppo, con piani per le build notturne compresa una corsa attraverso un analizzatore statico. Dovrebbe essere parte delle linee guida di codifica per il progetto evitare (o scoraggiare strongmente) l'uso di continue e break , anche se può sacrificare un po 'la leggibilità e richiedere un'indentazione eccessiva? Sono molto interessato a come questo si applica al codice C.

In sostanza, l'uso di questi operatori di controllo può complicare in modo significativo l'analisi statica del codice che potrebbe comportare ulteriori falsi negativi, che altrimenti registrerebbero un potenziale errore se non fossero utilizzati break o continue?

(Naturalmente un'analisi statica completa che provi la correttezza di un programma alternativo è una proposizione indecidibile, quindi ti preghiamo di mantenere le risposte su qualsiasi esperienza pratica con questo che hai, e non su impossibilità teoriche)

Grazie in anticipo!

    
posta B. VB. 17.05.2012 - 18:50
fonte

2 risposte

4

Ho usato Coverity su un numero di basi di codice abbastanza grandi e non ho trovato l'uso occasionale della pausa o continuo a causare falsi positivi. Comunque nella maggior parte delle basi di codice che ho lavorato con break e continue sono state usate solo in modo leggero e generalmente solo in modi abbastanza semplici.

La mia preoccupazione per l'uso di interruzione e continuazione sarebbe la leggibilità del codice. In generale, sospetto che gli strumenti di analisi statica si adattino meglio delle persone nel gestire il loro uso. Li scoraggerei per questo motivo, non per l'analisi statica.

In pratica ho scoperto che il codice che richiede l'uso di break e continue o di indentazione eccessiva può probabilmente essere scritto comunque in un modo migliore, anche se ci sono casi in cui può aiutare significativamente la leggibilità.

    
risposta data 17.05.2012 - 19:21
fonte
0

Penso che questo dipenda esattamente da come viene eseguita l'analisi statica. Ad esempio, in Java molte analisi statiche vengono eseguite su bytecode Java, piuttosto che direttamente sull'origine Java. Ciò semplifica molti aspetti dell'analisi perché utilizza un flusso di controllo non strutturato (cioè con ramificazione condizionale e incondizionata). Qui le istruzioni break e continue vengono compilate in rami incondizionati e quindi l'analizzatore non le nota nemmeno.

Tuttavia, se l'analisi statica funziona direttamente sul codice sorgente, le istruzioni break e continue possono causare una perdita di precisione. Ma, allo stesso modo, non possono.

    
risposta data 20.06.2012 - 23:15
fonte

Leggi altre domande sui tag