¿Método simple para detectar de manera confiable el código en el texto?

GMail tiene esta característica donde le avisará si intenta enviar un correo electrónico que cree que podría tener un archivo adjunto.

Debido a que GMail detectó la cadena see the attacheden el correo electrónico, pero no el archivo adjunto real, me advierte con un cuadro de diálogo Aceptar / Cancelar cuando hago clic en el botón Enviar.

Tenemos un problema relacionado con el desbordamiento de pila. Es decir, cuando un usuario ingresa a una publicación como esta :

mi problema es que necesito cambiar la base de datos pero no quiero crear 
Una nueva conexión. ejemplo:

DataSet dsMasterInfo = nuevo DataSet ();
Base de datos db = DatabaseFactory.CreateDatabase ("ConnectionString");
DbCommand dbCommand = db.GetStoredProcCommand ("uspGetMasterName");

¡Este usuario no formateó su código como código!

Es decir, no sangraron 4 espacios por Markdown, ni usaron el botón de código (o el atajo de teclado ctrl+ k) que hace eso por ellos.

Por lo tanto, nuestro sistema acepta muchas ediciones donde las personas tienen que ingresar y formatear manualmente el código para las personas que de alguna manera no pueden resolver esto. Esto lleva a muchos dolores de barriga . Hemos mejorado la ayuda del editor varias veces, pero a falta de conducir hasta la casa del usuario y presionar los botones correctos en su teclado para ellos, no podemos ver qué hacer a continuación.

Es por eso que estamos considerando una advertencia de estilo Google GMail:

¿Querías publicar código?

Escribiste cosas que creemos que se parecen a código, pero no lo formateaste como código al sangrar 4 espacios, usando el botón de código de la barra de herramientas o el comando de formateo de código ctrl+ k.

Sin embargo, presentar esta advertencia requiere que detectemos la presencia de lo que creemos que es código sin formato en una pregunta . ¿Cuál es una forma simple y semi confiable de hacer esto?

• Según Markdown , el código siempre está sangrado por 4 espacios o dentro de los backticks, por lo que cualquier cosa formateada correctamente puede descartarse de la verificación de inmediato.
• Esto es solo una advertencia y solo se aplicará a los usuarios de baja reputación que hagan sus primeras preguntas (o proporcionen sus primeras respuestas), por lo que algunos falsos positivos están bien, siempre que sean aproximadamente el 5% o menos.
• Las preguntas sobre Stack Overflow pueden estar en cualquier idioma, aunque podemos limitar de manera realista nuestro cheque a, por ejemplo, los "diez grandes" idiomas. Según la página de etiquetas que sería C #, Java, PHP, JavaScript, Objective-C, C, C ++, Python, Ruby.
• Use el volcado de datos de Creative Commons de Stack Overflow para auditar su solución potencial (o simplemente elija algunas preguntas en las 10 etiquetas principales en Stack Overflow) y vea cómo funciona.
• El pseudocódigo está bien, pero usamos c # si quieres ser más amigable.
• Cuanto más simple, mejor (siempre que funcione). ¡BESO! Si su solución requiere que intentemos compilar publicaciones en 10 compiladores diferentes, o un ejército de personas para entrenar manualmente un motor de inferencia bayesiano, eso ... no es exactamente lo que teníamos en mente.

Una solución adecuada probablemente sería algún modelo aprendido / estadístico, pero aquí hay algunas ideas divertidas:

1. Semicolones al final de una línea . Esto solo atraparía un montón de idiomas.
2. Paréntesis directamente después del texto sin espacio para separarlo: myFunc()
3. Un punto o flecha entre dos palabras: foo.bar = ptr->val
4. Presencia de llaves, llaves: while (true) { bar[i]; }
5. Presencia de sintaxis de "comentario" (/ *, //, etc.): /* multi-line comment */
6. Caracteres / operadores poco comunes: +, *, &, &&, |, ||, <, >, ==, !=, >=, <=, >>, <<, ::, __
7. Ejecute su resaltador de sintaxis en el texto. Si termina destacando un alto porcentaje, probablemente sea código.
8. CamelCase texto en la publicación.
9. paréntesis, llaves y / o corchetes anidados.

Uno podría realizar un seguimiento de la cantidad de veces que aparece cada uno de estos, y estos podrían usarse como características en un algoritmo de aprendizaje automático como el perceptrón , como lo hace SpamAssassin.

Me gustaría ver cuáles son las métricas promedio de inglés escrito en un lado y el código en el otro lado.

• longitud de párrafos
• longitud de líneas
• tamaño de las palabras
• caracteres utilizados
• relación entre caracteres alfabéticos, numéricos y otros símbolos
• cantidad de símbolos por palabra
• etc.

Tal vez eso solo podría discriminar ya entre el código y el resto. Al menos creo que el código, independientemente del idioma, mostraría algunas métricas notablemente diferentes en muchos casos.

La buena noticia es que ya tiene muchos datos para construir sus estadísticas.

Ok, he vuelto con algunos datos para respaldar mis suposiciones. :-)

Hice una prueba rápida y sucia en su propio puesto y en el primer post que encontré en StackOverflow , con una herramienta muy avanzada: wc.

Esto es lo que tenía después de ejecutar wcen la parte de texto y en la parte del código de esos dos ejemplos:

Primero echemos un vistazo a la parte en inglés :

• La parte en inglés de tu publicación (2635 caracteres, 468 palabras, 32 líneas)
  • 5 caracteres / palabra, 82 caracteres / línea, 14 palabras / línea
• La parte inglesa de la otra publicación (1499 caracteres, 237 palabras, 12 líneas)
  • 6 caracteres / palabra, 124 caracteres / línea, 19 palabras / línea

Bastante similar, ¿no te parece?

¡Ahora echemos un vistazo a la parte del código !

• El código parte de tu publicación (174 caracteres, 13 palabras, 3 líneas)
  • 13 caracteres / palabra, 58 caracteres / línea, 4 palabras / línea
• El código parte de la otra publicación (4181 caracteres, 287 palabras, 151 líneas)
  • 14 caracteres / palabra, 27 caracteres / línea, 2 palabras / línea

Vea qué tan diferentes son esas métricas, pero lo más importante, ¿qué tan diferentes son de las métricas en inglés? Y esto solo está usando una herramienta limitada. Ahora estoy seguro de que puede obtener algo realmente preciso midiendo más métricas (estoy pensando en particular en las estadísticas de caracteres).

¿Puedo hacer galletas?

Típicamente, las cadenas de Markov se usan para generar texto, pero también se pueden usar para predecir la similitud del texto (según CE Shannon 1950 ) con un modelo entrenado. Recomiendo múltiples cadenas de Markov.

Para cada idioma prevaleciente, entrene una cadena de Markov en una muestra grande y representativa de código en el idioma. Luego, para una publicación de desbordamiento de pila para la que desea detectar código, haga lo siguiente para cada una de las cadenas:

• Recorre las líneas en la publicación.
  • Declare dos variables: ACTUAL = 1.0 y HIGHEST = 1.0
  • Recorre cada personaje en la línea.
    • Para cada personaje, encuentre la probabilidad en la cadena de Markov de que el personaje actual sea el que sigue a los N caracteres anteriores. Establezca ACTUAL = ACTUAL * PROB ₁ . Si el carácter actual no está presente en la cadena, utilice un valor pequeño para PROB ₁ , como 0.000001.
    • Ahora, encuentre el carácter más probable (es decir, la probabilidad más alta) de seguir los N caracteres anteriores. Establezca HIGHEST = HIGHEST * PROB ₂ .
    • Obviamente, PROB ₂ > = PROB ₁

Para cada línea, debe tener un valor REAL y un valor MÁS ALTO. Dividir ACTUAL por ALTO Eso le dará la calificación de aptitud en cuanto a si una línea en particular es el código fuente. Eso asociaría un número con cada una de las líneas en el ejemplo que dio:

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

Finalmente, deberá seleccionar un umbral para determinar cuándo hay código en la publicación. Esto podría ser simplemente un número seleccionado por observación que produce un alto rendimiento. También podría tener en cuenta el número de líneas con una puntuación alta.

Formación

Para capacitar, obtenga una muestra de código grande y representativa en el idioma. Escriba un programa para recorrer el texto del código y asocie cada N-gramo en el archivo (el rango para N debe parametrizarse) con la frecuencia estadística del carácter subsiguiente. Esto producirá múltiples estados posibles de caracteres que siguen al bigram, cada uno asociado con una probabilidad. Por ejemplo, el bigram "()" podría tener algunas probabilidades de caracteres siguientes de:

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

El primero debe leerse, por ejemplo, como "La probabilidad de que un punto y coma siga a un paréntesis vacío es 0.5".

Para el entrenamiento, recomiendo N-gramos de tamaño dos a cinco. Cuando investigué un poco sobre esto , descubrimos que los N-gramos de tamaño dos a cinco funcionaban bien para el inglés. Dado que gran parte del código fuente es inglés, sugeriría comenzar con ese rango y luego ajustarlo para encontrar los valores de parámetros óptimos a medida que encuentre lo que funciona.

Una advertencia: el modelo se verá afectado por identificadores, nombres de métodos, espacios en blanco, etc. Sin embargo, puede ajustar el entrenamiento para omitir ciertas características de la muestra de entrenamiento. Por ejemplo, podría colapsar todos los espacios en blanco innecesarios. La presencia de espacios en blanco en la entrada (la publicación de desbordamiento de pila) también se puede ignorar. También podría ignorar el caso alfabético, que sería más resistente frente a las convenciones de nombres de identificadores variables.

Durante mi investigación , descubrimos que nuestros métodos funcionaban bien tanto en español como en inglés. No veo por qué esto tampoco funcionaría bien para el código fuente. El código fuente es aún más estructurado y predecible que el lenguaje humano.

¿Puedo sugerir un enfoque radicalmente diferente? En SO, el único idioma humano permitido es el inglés, por lo que cualquier cosa que no sea inglés tiene un 99.9% de posibilidades de ser un fragmento de código .

Entonces, mi solución sería: usar uno de los muchos verificadores de idioma inglés (solo asegúrese de que también señalen, además de errores ortográficos, errores de sintaxis como puntos dobles o símbolos que no sean del idioma como #o ~). Entonces, cualquier línea / párrafo que arroje una gran cantidad de errores y advertencias debería activar el "¿es este código?" pregunta.

Este enfoque también se puede adaptar para aquellos sitios de StackExchange que usan otros idiomas además del inglés, por supuesto.

Solo mis 2 ¢ ...

Probablemente voy a obtener algunos votos negativos por esto, pero creo que te estás acercando a esto desde el ángulo equivocado.

Esta línea me tiene:

las personas tienen que ingresar y formatear manualmente el código para las personas que de alguna manera no pueden resolver esto

En mi opinión, ese punto de vista es arrogante. Encuentro esto mucho en el diseño de software, donde los programadores y diseñadores se molestan con los usuarios que no pueden descubrir cómo usar el software correctamente, cuando el problema no es el usuario sino el software en sí, o al menos la interfaz de usuario.

La causa raíz de este problema no es el usuario, sino el hecho de que no les resulta obvio que puedan hacerlo.

¿Qué tal un cambio en la interfaz de usuario para hacer esto más obvio? Seguramente esto será:

1. Es más obvio para los nuevos usuarios exactamente lo que deben hacer
2. es más fácil para usted construir en lugar de escribir algoritmos complejos para detectar la lógica de código de una multitud de idiomas

Ejemplo:

El pseudocódigo representaría un verdadero desafío porque todo el lenguaje de programación depende de caracteres especiales como '[]', ';', '()', etc. Simplemente cuente la aparición de estos caracteres especiales. Al igual que detectaría un archivo binario (más del 5% de una muestra contiene el valor de byte 0).

Creo que es posible que deba enfocar esto solo en idiomas específicos, en general, este problema es probablemente insoluble, ya que puede obtener idiomas que son bastante similares al inglés (por ejemplo, inform7 ). pero afortunadamente los más utilizados podrían cubrirse con bastante facilidad.

Mi primer corte sería buscar la secuencia "; \ n", que le daría una buena coincidencia para C, C ++, Java, C # y cualquier otro lenguaje que use una sintaxis similar y sea realmente simple. También es menos probable que se use en inglés que a; sin una nueva línea

Alguien mencionó que miraba las etiquetas y luego buscaba la sintaxis para eso, pero eso fue rechazado porque está dirigido a nuevos usuarios.

Una posible mejor solución sería buscar nombres de idiomas en el cuerpo de la pregunta y luego aplicar la misma estrategia. Si menciono "Javascript", "Java" o "C #", entonces es probable que de eso se trate la pregunta, y es probable que el código de la pregunta esté en ese idioma.

Primero, ejecute el corrector ortográfico, encontrará muy pocas palabras en inglés adecuadas, sin embargo, debería haber muchas palabras que el corrector ortográfico sugiera dividir.

Luego hay signos de puntuación / especiales que no son típicos del inglés simple, típicos del código:

• something(); simplemente no puede ser inglés simple;
• $somethingdonde somethingno todo es numérico;
• -> entre palabras sin espacios;
• . entre palabras sin espacio;

Por supuesto, para que funcione bien, es posible que desee tener un clasificador bayesiano construido sobre estas características.

Hay varios conjuntos de idiomas que comparten una sintaxis similar. la mayoría de los idiomas se vieron influenciados por algunos idiomas, por lo que los idiomas [AMPL, AWK, csh, C ++, C--, C #, Objective-C, BitC, D, Go, Java, JavaScript, Limbo, LPC, Perl, PHP, Pike, Processing [fueron influenciados por C, por lo que si detecta C probablemente detectará todos estos lenguajes. así que solo tiene que escribir un patrón simple para detectar estos conjuntos de idiomas.

También dividiría el texto en bloques porque la mayoría del código se dividirá en dos líneas nuevas o similares de los otros bloques de texto en la publicación.

Esto se puede hacer fácilmente con javascript (una muestra incompleta supersimple para la familia 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 + "]");
   }
}

Simplemente cuente las palabras / caracteres de puntuación para cada línea. El inglés tenderá a tener 4 o más, código menos de 2.

El párrafo anterior tiene 18 palabras y 4 caracteres de puntuación, por ejemplo. Este párrafo tiene 19 palabras y 4 signos de puntuación, por lo que está dentro de las expectativas.

Por supuesto, esto debería probarse con las preguntas de los novatos que no hablan inglés, y puede ser que en esos casos, las estadísticas estén sesgadas.

Espero que [no espacio en blanco]. [Espacio en blanco o nueva línea] sea muy raro en el código, pero común en inglés, por lo que esto podría contarse como palabras, no como puntuación.

Creo que el mayor problema será el código en línea, donde alguien hace una pregunta como:

Si digo para (i = 0; i> 100; i ++) {} ¿qué significa eso?

Ese es el código y el inglés, y debe estar marcado como con ticks de retroceso:

Si digo for (i=0; i>100; i++) {}lo que significa eso?

Creo que primero debe hacer una distinción entre el código (suficientemente) formateado que solo necesita ser designado como tal, y (también) el código mal formateado, que de todos modos necesita un formateo manual.

El código formateado tiene líneas de corte y sangría. Es decir: si una línea está precedida por una sola línea de corte, tiene un buen candidato. Si tiene espacios en blanco principales además de eso, tienes un muy buen candidato.

El texto normal usa dos líneas de corte o dos espacios y una línea de corte para formatear, por lo que hay un criterio claro para la distinción.

En el código LISP no encontrará punto y coma, en el código Ruby puede no encontrar paréntesis, en el pseudocódigo puede que no encuentre mucho. Pero en cualquier lenguaje (no esotérico) encontrará un código decente para formatear con líneas de corte y sangría. No hay nada tan universal como eso. Porque al final el código es, escrito para ser leído por humanos.

Primero, busque posibles líneas de código . Además, las líneas de código generalmente vienen en grupos. Si tiene uno, existe una buena posibilidad de que el de arriba o el de abajo también sea una línea de código.

Una vez que haya seleccionado las posibles líneas de código, puede verificarlas con criterios cuantificables y elegir algún umbral :

• frecuencia de caracteres que no son palabras
• frecuencia de identificadores: palabras muy cortas o muy largas con estilo CamelCase o under_score
• repetición de palabras poco comunes

Además, ahora que hay programadores y cs, el alcance de stackoverflow está claramente reducido. Uno podría considerar denotar todas las etiquetas de idioma como idiomas. Y cuando publique, se le pedirá que elija al menos una etiqueta de idioma, elija la language-agnosticetiqueta o que la omita explícitamente.

En el primer caso, usted sabe qué idiomas buscar, en el segundo caso, es posible que desee buscar un pseudocódigo y en el último caso, probablemente no habrá ningún código, porque es una pregunta relacionada con alguna tecnología o marco o tal.

Puede crear un analizador para cada idioma que desee detectar (las definiciones de idioma para ANTLR suelen ser fáciles de encontrar), luego ejecutar cada línea de la pregunta a través de cada analizador. Si alguna línea se analiza correctamente, probablemente tenga código.

El problema con esto es que algunas oraciones en inglés (lenguaje natural) pueden analizarse como código, por lo que es posible que también desee incluir algunas de las otras ideas, o puede limitar los resultados positivos solo si más de una o dos líneas consecutivas se analizan correctamente con el mismo analizador de idiomas.

El otro problema potencial es que esto probablemente no recogerá el pseudocódigo, pero eso puede estar bien.

Lo que puede ser el más a prueba de futuro y requiere el menor ajuste manual a largo plazo, ya que otros lenguajes (que se ven algo diferentes a los lenguajes de programación más utilizados ahora) se vuelven más populares y los lenguajes utilizados actualmente se vuelven menos populares. algo así como lo que hace Google Translate (consulte el párrafo titulado "¿Cómo funciona?"), en lugar de buscar ciertas cosas como ab y a (), etc.

En otras palabras, en lugar de pensar manualmente en los patrones que se encuentran en el código para buscar, la computadora puede resolverlo por sí misma . Esto se puede hacer teniendo

1. mucho código en muchos lenguajes de programación diferentes

   • Sugerencia: tome automáticamente muestras de código de repositorios de código fuente basados ​​en la web como Google Code o Github, o incluso de cosas en Stackoverflow ya marcadas como código

   • Nota: puede ser una buena idea analizar los comentarios de código

2. mucho texto en inglés tomado de artículos en la web

   • aunque no de artículos sobre programación (de lo contrario, pueden tener código y mezclar el sistema :-))

y tener algún tipo de algoritmo encuentra automáticamente patrones en el código que no están en inglés, y viceversa, y usa esos patrones para detectar qué es código y qué no es código ejecutando el algoritmo en las publicaciones.

(Sin embargo, no estoy seguro de cómo funcionaría tal algoritmo. Otras respuestas a la pregunta actual pueden tener información útil para eso).

Luego, el sistema puede volver a escanear el código de vez en cuando para tener en cuenta los cambios en el aspecto del código en ese momento.