Metodo semplice per rilevare in modo affidabile il codice nel testo?

GMail ha questa funzione in cui ti avvertirà se provi a inviare una email che pensa possa avere un allegato.

Poiché GMail ha rilevato la stringa see the attachednell'e-mail, ma nessun allegato reale, mi avvisa con una finestra di dialogo OK / Annulla quando faccio clic sul pulsante Invia.

Abbiamo un problema correlato a StackTranslate.it. Cioè, quando un utente inserisce un post come questo :

il mio problema è che devo cambiare il database ma non voglio crearlo 
una nuova connessione. esempio:

DataSet dsMasterInfo = new DataSet ();
Database db = DatabaseFactory.CreateDatabase ("ConnectionString");
DbCommand dbCommand = db.GetStoredProcCommand ("uspGetMasterName");

Questo utente non ha formattato il proprio codice come codice!

Cioè, non sono stati rientrati di 4 spazi per Markdown, né hanno usato il pulsante del codice (o la scorciatoia da tastiera ctrl+ k) che lo fa per loro.

Pertanto, il nostro sistema sta accettando molte modifiche in cui le persone devono entrare e formattare manualmente il codice per le persone che in qualche modo non sono in grado di capirlo. Questo porta a un sacco di mal di pancia . Abbiamo migliorato l'aiuto dell'editor diverse volte, ma a meno di non andare a casa dell'utente e premere i pulsanti corretti sulla tastiera per loro, non riusciamo a vedere cosa fare dopo.

Ecco perché stiamo prendendo in considerazione un avviso in stile GMail di Google:

Intendevi postare il codice?

Hai scritto cose che pensiamo assomiglino a codice, ma non lo hai formattato come codice rientrando in 4 spazi, usando il pulsante del codice della barra degli strumenti o il comando di formattazione ctrl+ kcodice.

Tuttavia, la presentazione di questo avviso richiede di rilevare la presenza di ciò che riteniamo codice non formattato in una domanda . Qual è un modo semplice e semi-affidabile per farlo?

• Per Markdown , il codice è sempre indentato da 4 spazi o all'interno di backtick, quindi qualsiasi cosa correttamente formattata può essere immediatamente scartata dal controllo.
• Questo è solo un avvertimento e si applicherà solo agli utenti di bassa reputazione che fanno le loro prime domande (o che forniscono le loro prime risposte), quindi alcuni falsi positivi sono OK, purché siano circa il 5% o meno.
• Le domande su Stack Overflow possono essere in qualsiasi lingua, sebbene possiamo limitare realisticamente il nostro controllo, diciamo, alle lingue "big ten". Per la pagina dei tag che sarebbe C #, Java, PHP, JavaScript, Objective-C, C, C ++, Python, Ruby.
• Utilizza il dump dei dati comuni della creatività Stack Overflow per controllare la tua potenziale soluzione (o scegli solo alcune domande tra i primi 10 tag su Stack Overflow) e guarda come funziona.
• Lo pseudocodice va bene, ma usiamo c # se vuoi essere più amichevole.
• Più semplice è, meglio è (purché funzioni). BACIO! Se la tua soluzione ci impone di tentare di compilare post in 10 diversi compilatori o un esercito di persone per addestrare manualmente un motore di inferenza bayesiana, non è esattamente quello che avevamo in mente.

Una soluzione adeguata sarebbe probabilmente un modello appreso / statistico, ma qui ci sono alcune idee divertenti:

1. Punto e virgola alla fine di una linea . Solo questo catturerebbe un sacco di lingue.
2. Le parentesi che seguono direttamente il testo senza spazio per separarlo: myFunc()
3. Un punto o una freccia tra due parole: foo.bar = ptr->val
4. Presenza di parentesi graffe, parentesi: while (true) { bar[i]; }
5. Presenza di sintassi "commento" (/ *, //, ecc.): /* multi-line comment */
6. Caratteri / operatori non comuni: +, *, &, &&, |, ||, <, >, ==, !=, >=, <=, >>, <<, ::, __
7. Esegui l'evidenziatore della sintassi sul testo. Se finisce per evidenziarne una percentuale elevata, probabilmente è un codice.
8. camelCase testo nel post.
9. parentesi, parentesi graffe e / o parentesi nidificate.

Si potrebbe tenere traccia del numero di volte in cui ciascuno di questi appare, e questi potrebbero essere usati come caratteristiche in un algoritmo di apprendimento automatico come perceptron , come fa SpamAssassin.

Sarei curioso di vedere quali sono le metriche medie dell'inglese scritto da un lato e il codice dall'altro lato.

• lunghezza dei paragrafi
• lunghezza delle linee
• dimensione delle parole
• caratteri usati
• rapporto tra caratteri alfabetici, numerici e altri simboli
• numero di simboli per parola
• eccetera.

Forse quello da solo potrebbe già discriminare tra il codice e il resto. Almeno credo che il codice, indipendentemente dalla lingua, mostrerebbe alcune metriche notevolmente diverse in molti casi.

La buona notizia è: hai già un sacco di dati su cui costruire le tue statistiche.

Ok, sono tornato con alcuni dati per sostenere le mie ipotesi. :-)

Ho fatto un test rapido e sporco sul proprio palo e il primo post che ho trovato su StackOverflow , con uno strumento piuttosto avanzata: wc.

Ecco cosa ho avuto dopo aver eseguito wcla parte di testo e la parte di codice di questi due esempi:

Per prima cosa diamo un'occhiata alla parte inglese :

• La parte inglese del tuo post (2635 caratteri, 468 parole, 32 righe)
  • 5 caratteri / parola, 82 caratteri / linea, 14 parole / linea
• La parte inglese dell'altro post (1499 caratteri, 237 parole, 12 righe)
  • 6 caratteri / parola, 124 caratteri / linea, 19 parole / linea

Abbastanza simile non credi?

Ora diamo un'occhiata alla parte del codice !

• La parte del codice del tuo post (174 caratteri, 13 parole, 3 righe)
  • 13 caratteri / parola, 58 caratteri / linea, 4 parole / linea
• La parte di codice dell'altro post (4181 caratteri, 287 parole, 151 righe)
  • 14 caratteri / parola, 27 caratteri / linea, 2 parole / linea

Vedi come non sono così diverse quelle metriche, ma soprattutto, quanto sono diverse dalle metriche inglesi? E questo sta solo usando uno strumento limitato. Ora sono sicuro che puoi ottenere qualcosa di veramente preciso misurando più metriche (sto pensando in particolare alle statistiche sui caratteri).

Posso cookie Haz?

In genere, le catene di Markov vengono utilizzate per generare testo, ma possono anche essere utilizzate per prevedere la somiglianza del testo (secondo CE Shannon 1950 ) con un modello addestrato. Raccomando più catene Markov.

Per ogni lingua prevalente, forma una catena di Markov su un campione ampio e rappresentativo di codice nella lingua. Quindi, per un post Stack Overflow per il quale si desidera rilevare il codice, effettuare le seguenti operazioni per ciascuna delle catene:

• Passa attraverso le linee del post.
  • Dichiarare due variabili: ACTUAL = 1.0 e HIGHEST = 1.0
  • Passa attraverso ogni personaggio della linea.
    • Per ogni personaggio, trova la probabilità nella catena Markov che il personaggio attuale sia quello che segue i precedenti N caratteri. Impostare ACTUAL = ACTUAL * PROB ₁ . Se il carattere corrente non è presente nella catena, utilizzare un valore minuscolo per PROB ₁ , come 0,000001.
    • Ora, trova il personaggio più probabile (ovvero la probabilità più alta) di seguire i precedenti N caratteri. Imposta ALTA = ALTA * PROB ₂ .
    • Ovviamente, PROB ₂ > = PROB ₁

Per ogni riga, dovresti avere un valore REALE e UN ALTRO. Dividi ATTUALE per PIÙ ALTO. Questo ti darà il punteggio di fitness se una determinata riga è il codice sorgente. Ciò assocerebbe un numero a ciascuna delle righe nell'esempio che hai fornito:

my problem is I need to change the database but I don't won't to create // 0.0032
a new connection. example: // 0.0023

DataSet dsMasterInfo = new DataSet(); // 0.04
Database db = DatabaseFactory.CreateDatabase("ConnectionString");   // 0.05
DbCommand dbCommand = db.GetStoredProcCommand("uspGetMasterName");  // 0.04

Infine, dovrai selezionare una soglia per determinare quando c'è del codice nel post. Questo potrebbe essere semplicemente un numero selezionato dall'osservazione che produce alte prestazioni. Potrebbe anche tenere conto del numero di righe con un punteggio elevato.

Formazione

Per allenarsi, procurati un campione ampio e rappresentativo di codice nella lingua. Scrivi un programma per scorrere il testo del codice e associare ogni N-grammo nel file (l'intervallo per N dovrebbe essere parametrizzato) con la frequenza statistica del carattere successivo. Ciò produrrà molteplici possibili stati di personaggi che seguono il bigram, ciascuno associato a una probabilità. Ad esempio, il bigram "()" potrebbe avere le seguenti probabilità di carattere di:

"()" 0.5-> ";"
"()" 0.2-> "."
"()" 0.3-> "{"

Il primo dovrebbe essere letto, ad esempio come "La probabilità che un punto e virgola segua un parentetico vuoto è 0,5".

Per l'allenamento, raccomando N-grammi di dimensioni da due a cinque. Quando ho fatto qualche ricerca su questo , abbiamo scoperto che gli N-grammi di dimensioni da due a cinque funzionavano bene per l'inglese. Dal momento che gran parte del codice sorgente è inglese, suggerirei di iniziare con quell'intervallo e poi di regolarmi per trovare i valori dei parametri ottimali mentre trovi ciò che funziona.

Un avvertimento: il modello sarà influenzato da identificatori, nomi dei metodi, spazi bianchi e così via. Tuttavia, è possibile ottimizzare l'allenamento per omettere alcune caratteristiche del campione di allenamento. Ad esempio, è possibile comprimere tutti gli spazi bianchi non necessari. Anche la presenza di spazi bianchi nell'input (il post Stack Overflow) può essere ignorata. Potresti anche ignorare il caso alfabetico, che sarebbe più resistente di fronte alle diverse convenzioni di denominazione degli identificatori.

Durante la mia ricerca , abbiamo scoperto che i nostri metodi hanno funzionato bene per lo spagnolo e l'inglese. Non vedo perché questo non funzionerebbe bene anche per il codice sorgente. Il codice sorgente è ancora più strutturato e prevedibile del linguaggio umano.

Posso suggerire un approccio radicalmente diverso? Su SO l'unica lingua umana consentita è l'inglese, quindi tutto ciò che non è inglese ha il 99,9% di possibilità di essere uno snippet di codice .

Quindi la mia soluzione sarebbe: usare uno dei tanti correttori di lingua inglese là fuori (assicurati solo che segnalino - oltre agli errori di ortografia - errori di sintassi come punti doppi o simboli non linguistici come #o ~). Quindi qualsiasi riga / paragrafo che genera una grande quantità di errori e avvisi dovrebbe attivare il "è questo codice?" domanda.

Questo approccio può anche essere adattato per quei siti StackExchange che usano lingue diverse dall'inglese, ovviamente.

Solo il mio 2 ¢ ...

Probabilmente otterrò alcuni voti negativi per questo, ma penso che ti stai avvicinando da un'angolazione sbagliata.

Questa linea mi ha fatto:

le persone devono entrare e formattare manualmente il codice per le persone che in qualche modo non sono in grado di capirlo

IMO che punto di vista è un po 'arrogante. Lo trovo molto nella progettazione del software in cui programmatori e designer si infastidiscono con gli utenti che non riescono a capire come utilizzare correttamente il software, quando il problema non è l'utente ma il software stesso - o almeno l'interfaccia utente.

La causa principale di questo problema non è l'utente ma il fatto che non è ovvio per loro che possono farlo.

Che ne dici di un cambiamento nell'interfaccia utente per renderlo più ovvio? Sicuramente questo sarà:

1. più ovvio per i nuovi utenti esattamente cosa devono fare
2. più facile da costruire piuttosto che scrivere algoritmi complessi per rilevare la logica del codice di una moltitudine di lingue

Esempio:

Lo pseudo codice costituirebbe una vera sfida perché tutto il linguaggio di programmazione dipende da caratteri speciali come '[]', ';', '()', ecc. Basta contare l'occorrenza di questi caratteri speciali. Proprio come rileveresti un file binario (oltre il 5% di un campione contiene un valore di byte 0).

Penso che potrebbe essere necessario indirizzarlo solo su lingue specifiche, in generale questo problema è probabilmente irrisolvibile in quanto è possibile ottenere lingue che sono abbastanza simili all'inglese (ad esempio inform7 ). ma per fortuna quelli più usati potrebbero essere coperti abbastanza facilmente.

Il mio primo taglio sarebbe quello di cercare la sequenza "; \ n" che ti darebbe una buona corrispondenza per C, C ++, Java, C # e qualsiasi altro linguaggio che utilizza una sintassi simile ed è davvero semplice. È anche meno probabile che venga utilizzato in inglese rispetto a un; senza una nuova riga

Qualcuno ha detto di aver guardato i tag e di aver cercato la sintassi per questo, ma questo è stato abbattuto perché è rivolto a nuovi utenti.

Una possibile soluzione migliore sarebbe quella di cercare i nomi delle lingue nel corpo della domanda, quindi applicare la stessa strategia. Se menziono "Javascript", "Java" o "C #", è probabile che sia questa la domanda e che probabilmente il codice nella domanda sarà in quella lingua.

Per prima cosa, esegui il controllo ortografico, troverà pochissime parole inglesi appropriate, tuttavia ci dovrebbero essere molte parole che il controllo ortografico suggerirà di dividere.

Quindi ci sono punteggiatura / caratteri speciali non tipici dell'inglese normale, tipici del codice:

• something(); semplicemente non può essere un inglese semplice;
• $somethingdove somethingnon è tutto numerico;
• -> tra parole senza spazi;
• . tra parole senza spazio;

Naturalmente per farlo funzionare bene, potresti voler avere il classificatore bayesiano costruito sopra queste caratteristiche.

ci sono diversi insiemi di lingue che condividono una sintassi simile. la maggior parte delle lingue è stata influenzata da alcune lingue, quindi le lingue [AMPL, AWK, csh, C ++, C--, C #, Objective-C, BitC, D, Go, Java, JavaScript, Limbo, LPC, Perl, PHP, Pike, Processing [sono stati tutti influenzati da C, quindi se rilevi C probabilmente rileverai tutte queste lingue. quindi devi solo scrivere un modello semplice per rilevare questo set di lingue.

vorrei anche dividere il testo in blocchi perché la maggior parte del codice sarà divisa da due nuove righe o simili dagli altri blocchi di testo nel post.

questo può essere fatto facilmente con javascript (un esempio incompleto supersemplice per la famiglia c):

var txt = "my problem is I need to change the database but I don't won't to create a new connection. example:\n\nDataSet dsMasterInfo = new DataSet();Database db = DatabaseFactory.CreateDatabase("ConnectionString");DbCommand dbCommand = db.GetStoredProcCommand("uspGetMasterName");";
var blocks = txt.split(/\n\n/gi); console.dir(blocks);
var i = blocks.length;
var cReg = /if\s*\(.+?\)|.*(?:int|char|string|short|long).*?=.+|while\s*\(.+?\)/gi;

while ( i-- ){
   var current = blocks[i];
   if ( cReg.test( current ) ){
      console.log("found code in block[" +  i + "]");
   }
}

Basta contare le parole / il segno di punteggiatura per ogni riga. L'inglese tenderà ad avere 4 o più, il codice meno di 2.

Il paragrafo sopra ha 18 parole e 4 caratteri di punteggiatura, per esempio. Questo paragrafo ha 19 parole e 4 punteggiatura, quindi entro le aspettative.

Certamente, questo dovrebbe essere testato contro le domande dei neofiti in inglese poco chiari, e può darsi che in quei casi le statistiche siano distorte.

Mi aspetto che [non-whitespace]. [Whitespace o newline] sia molto raro nel codice, ma comune in inglese, quindi questo potrebbe essere conteggiato come parole, non punteggiatura.

Penso che il problema più grande sarà il codice inline, in cui qualcuno fa una domanda come:

Se dico per (i = 0; i> 100; i ++) {} cosa significa?

Questo è codice e inglese, e dovrebbe essere contrassegnato come con i segni di spunta:

Se dico for (i=0; i>100; i++) {}cosa significa?

Penso che dovresti prima fare una distinzione tra codice (sufficientemente) formattato che deve essere effettivamente designato come tale e (troppo) codice mal formattato, che necessita comunque di una formattazione manuale.

Il codice formattato presenta interruzioni e rientri. Cioè: se una linea è preceduta da una singola linea di discontinuità, hai un buon candidato. Se ha spazi bianchi in testa, hai un ottimo candidato.

Il testo normale utilizza due linee di discontinuità o due spazi e una linea di discontinuità per la formattazione, quindi esiste un criterio chiaro per la distinzione.

Nel codice LISP non troverai i punti e virgola, nel codice Ruby potresti non trovare la parentesi, nello pseudo codice potresti non trovare molto. Ma in qualsiasi lingua (non esoterica) troverai codice decente da formattare con breakline e rientri. Non c'è niente di così universale. Perché alla fine il codice è, scritto per essere letto dagli umani.

Quindi, prima, cerca potenziali righe di codice . Inoltre, le righe di codice vengono generalmente in gruppi. Se ne hai uno, c'è una buona probabilità che anche quello sopra o sotto sia una riga di codice.

Una volta individuate le potenziali righe di codice, è possibile verificarle in base a criteri quantificabili e selezionare una soglia :

• frequenza di caratteri non di parole
• frequenza di identificatori: parole molto brevi o parole molto lunghe con stile CamelCase o under_score
• ripetizione di parole non comuni

Inoltre, ora che ci sono programmatori e CS, l'ambito di StackOverflow è chiaramente ristretto. Si potrebbe considerare di indicare tutti i tag di lingua come lingue. E quando pubblichi, ti verrà chiesto di scegliere almeno un tag di lingua, scegliere il language-agnostictag o ometterlo esplicitamente.

Nel primo caso sai quali lingue cercare, nel secondo caso potresti voler cercare pseudo-codice e nell'ultimo caso, probabilmente non ci sarà alcun codice, perché è una domanda relativa ad alcune tecnologie o quadro o tale.

È possibile creare un parser per ogni lingua che si desidera rilevare (le definizioni della lingua per ANTLR sono in genere facili da trovare), quindi eseguire ogni riga della domanda attraverso ciascun parser. Se una riga viene analizzata correttamente, probabilmente hai il codice.

Il problema è che alcune frasi in inglese (lingua naturale) possono essere analizzate come codice, quindi potresti voler includere anche alcune delle altre idee, oppure potresti limitare i risultati positivi solo se più di una o due righe consecutive vengono analizzate correttamente con lo stesso parser di lingua.

L'altro potenziale problema è che questo probabilmente non raccoglierà lo pseudocodice, ma potrebbe essere OK.

Quale potrebbe essere il più a prova di futuro e richiedere la minima regolazione manuale a lungo termine, poiché altri linguaggi (che sembrano in qualche modo diversi dai linguaggi di programmazione usati più ora) diventano più popolari e le lingue attualmente utilizzate diventano meno popolari, è fare qualcosa di simile a quello che fa Google Translate (vedi il paragrafo "Come funziona?"), invece di cercare certe cose come ab e a (), ecc.

In altre parole, invece di pensare manualmente ai modelli trovati nel codice da cercare, il computer può capirlo da solo . Questo può essere fatto avendo

1. un sacco di codice in molti linguaggi di programmazione diversi

   • Suggerimento: prelevare automaticamente esempi di codice dai repository di codice sorgente basati su Web come Google Code o Github, o anche da cose su Stackoverflow già contrassegnate come codice

   • Nota: potrebbe essere una buona idea analizzare i commenti sul codice

2. un sacco di testo inglese tratto da articoli sul web

   • anche se non dagli articoli sulla programmazione (altrimenti potrebbero contenere del codice e confondere il sistema :-))

e avere un qualche tipo di algoritmo trova automaticamente schemi nel codice che non sono in inglese, e viceversa, e usa quegli schemi per rilevare ciò che è codice e cosa non è codice eseguendo l'algoritmo sui post.

(Tuttavia, non sono sicuro di come funzionerebbe un tale algoritmo. Altre risposte alla domanda attuale potrebbero avere informazioni utili per questo.)

Quindi il sistema può eseguire nuovamente la scansione del codice ogni tanto per tenere conto delle modifiche apportate al modo in cui il codice viene visualizzato in quel momento.