Простой способ надежного определения кода в тексте?

GMail имеет эту функцию, где он будет предупреждать вас, если вы попытаетесь отправить электронное письмо, которое, по его мнению, может иметь вложение.

Поскольку GMail обнаружил строку see the attachedв электронном письме, но фактического вложения не было, он предупреждает меня с помощью диалогового окна OK / Отмена, когда я нажимаю кнопку Отправить.

У нас есть проблема, связанная с переполнением стека. То есть, когда пользователь вводит сообщение, подобное этому :

моя проблема в том, что мне нужно изменить базу данных, но я не буду создавать 
новое соединение. пример:

DataSet dsMasterInfo = new DataSet ();
База данных db = DatabaseFactory.CreateDatabase ("ConnectionString");
DbCommand dbCommand = db.GetStoredProcCommand ("uspGetMasterName");

Этот пользователь не форматировал свой код как код!

То есть они не делали отступ на 4 пробела на Markdown и не использовали кнопку кода (или сочетание клавиш ctrl+ k), которое делает это для них.

Таким образом, наша система принимает много правок, в которые люди должны войти и вручную отформатировать код для людей, которые каким-то образом не могут понять это. Это приводит к большой боли в животе . Мы несколько раз улучшали помощь редактора, но если не подъезжать к дому пользователя и нажимать для него правильные кнопки на клавиатуре, мы не можем понять, что делать дальше.

Вот почему мы рассматриваем предупреждение в стиле Google GMail:

Вы хотели разместить код?

Вы написали материал, который, по нашему мнению, выглядит как код, но вы не отформатировали его как код, сделав отступ в 4 пробела, используя кнопку кода панели инструментов или команду ctrl+ kcode formatting.

Однако представление этого предупреждения требует, чтобы мы обнаружили наличие в вопросе того, что мы считаем неформатированным кодом . Каков простой, полу-надежный способ сделать это?

• В соответствии с Markdown , код всегда имеет отступ в 4 пробела или в обратных кавычках, поэтому все правильно отформатированные данные могут быть немедленно исключены из проверки.
• Это всего лишь предупреждение, и оно будет применяться только к пользователям с низкой репутацией, задающим свои первые вопросы (или предоставляющим свои первые ответы), поэтому некоторые ложные срабатывания в порядке, если они составляют около 5% или менее.
• Вопросы о переполнении стека могут быть на любом языке, хотя мы можем реально ограничить нашу проверку, скажем, языками «большой десятки». На странице тегов это будет C #, Java, PHP, JavaScript, Objective-C, C, C ++, Python, Ruby.
• Используйте дамп данных Creative Commons переполнение стека для аудита вашего потенциального решения (или просто выберите несколько вопросов в топ-10 тегов на переполнение стека) и посмотреть, как это происходит.
• Псевдокод в порядке, но мы используем c #, если вы хотите быть более дружелюбным.
• Чем проще, тем лучше (пока это работает). ПОЦЕЛУЙ! Если ваше решение требует, чтобы мы попытались скомпилировать посты в 10 различных компиляторах, или группа людей, чтобы вручную обучить механизм байесовского вывода, это ... не совсем то, что мы имели в виду.

Правильным решением, вероятно, будет некоторая обученная / статистическая модель, но вот несколько забавных идей:

1. Точка с запятой в конце строки . Одно это поймало бы целую кучу языков.
2. Скобки сразу после текста без пробела для его разделения: myFunc()
3. Точка или стрелка между двумя словами: foo.bar = ptr->val
4. Наличие фигурных скобок, скобок: while (true) { bar[i]; }
5. Наличие синтаксиса комментария (/ *, // и т. Д.): /* multi-line comment */
6. Необычные персонажи / операторы: +, *, &, &&, |, ||, <, >, ==, !=, >=, <=, >>, <<, ::, __
7. Запустите подсветку синтаксиса для текста. Если это в конечном итоге выделит какой-то высокий процент, это, вероятно, код.
8. camelCase текст в посте.
9. вложенные скобки, скобки и / или скобки.

Можно отслеживать, сколько раз каждый из них появляется, и их можно использовать в качестве функций в алгоритме машинного обучения, таком как персептрон , как это делает SpamAssassin.

Мне было бы любопытно посмотреть, каковы средние показатели написанного английского с одной стороны, и кода с другой стороны.

• длина абзацев
• длина линий
• размер слов
• использованные символы
• соотношение букв, цифр и других символов
• количество символов в слове
• и т.п.

Может быть, это уже могло бы провести различие между кодом и остальным. По крайней мере, я полагаю, что код, независимо от языка, будет показывать некоторые заметно отличающиеся показатели во многих случаях.

Хорошая новость: у вас уже есть достаточно данных для построения вашей статистики.

Хорошо, я вернулся с некоторыми данными, чтобы подтвердить свои предположения. :-)

Я сделал быстрый и грязный тест на собственном посте и на первый пост я нашел на StackOverflow , с довольно продвинутым инструментом: wc.

Вот что я имел после выполнения wcтекстовой части и части кода этих двух примеров:

Сначала давайте посмотрим на английскую часть :

• Английская часть вашего поста (2635 символов, 468 слов, 32 строки)
  • 5 символов / слово, 82 символа / строка, 14 слов / строка
• Английская часть другого поста (1499 символов, 237 слов, 12 строк)
  • 6 символов / слово, 124 символа / строка, 19 слов / строка

Довольно похоже не так ли?

Теперь давайте посмотрим на часть кода !

• Кодовая часть вашего поста (174 символа, 13 слов, 3 строки)
  • 13 символов / слово, 58 символов / строка, 4 слова / строка
• Кодовая часть другого поста (4181 символ, 287 слов, 151 строка)
  • 14 символов / слово, 27 символов / строка, 2 слова / строка

Посмотрите, насколько эти метрики не так отличаются, но, что более важно, насколько они отличаются от английских метрик? И это только с помощью ограниченного инструмента. Теперь я уверен, что вы можете получить что-то действительно точное, измеряя больше метрик (я имею в виду, в частности, статистику символов).

Я могу испечь печенье?

Как правило, цепи Маркова используются для генерации текста, но они также могут использоваться для прогнозирования сходства текста (в соответствии с CE Shannon 1950 ) с обученной моделью. Я рекомендую несколько цепей Маркова.

Для каждого распространенного языка обучите марковскую цепочку на большой репрезентативной выборке кода на языке. Затем для публикации переполнения стека, для которой вы хотите обнаружить код, выполните следующие действия для каждой из цепочек:

• Цикл по строкам в посте.
  • Объявите две переменные: ACTUAL = 1.0 и HIGHEST = 1.0
  • Переберите каждый символ в строке.
    • Для каждого символа найдите вероятность в цепочке Маркова, что текущий символ является тем, который следует за предыдущими N символами. Установите ACTUAL = ACTUAL * PROB ₁ . Если текущий символ отсутствует в цепочке, используйте для PROB ₁ маленькое значение , например 0,000001.
    • Теперь найдите символ, который с наибольшей вероятностью (т. Е. С наибольшей вероятностью) будет следовать за предыдущими N символами. Установите HIGHEST = HIGHEST * PROB ₂ .
    • Очевидно, PROB ₂ > = PROB ₁

Для каждой строки вы должны иметь значение ACTUAL и HIGHEST. Разделите ФАКТИЧЕСКИЙ на ВЫСОКИЙ. Это даст вам оценку пригодности относительно того, является ли конкретная строка исходным кодом. Это связывает число с каждой из строк в приведенном вами примере:

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

Наконец, вам нужно выбрать порог, чтобы определить, когда в посте есть код. Это может быть просто число, выбранное наблюдением, которое дает высокую производительность. Также может учитываться количество строк с высокой оценкой.

Тренировка

Для обучения приобретите большой репрезентативный образец кода на языке. Напишите программу для циклического перемещения по кодовому тексту и сопоставьте каждый N-грамм в файле (диапазон для N должен быть параметризован) со статистической частотой последующего символа. Это приведет к множеству возможных состояний символов, следующих за биграммой, каждое из которых связано с вероятностью. Например, биграмма "()" может иметь следующие вероятности символов:

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

Первый должен читаться, например, как «Вероятность того, что точка с запятой следует за пустой круглой скобкой, равна 0,5».

Для тренировок я рекомендую N-грамм размера от двух до пяти. Когда я проводил некоторые исследования по этому вопросу , мы обнаружили, что N-граммы размера от двух до пяти хорошо работали на английском языке. Поскольку большая часть исходного кода похожа на английский, я бы посоветовал начать с этого диапазона и затем настроить его, чтобы найти оптимальные значения параметров, когда вы найдете то, что работает.

Предостережение: на модель будут влиять идентификаторы, имена методов, пробелы и т. Д. Однако вы можете настроить тренировку так, чтобы пропустить определенные функции обучающей выборки. Например, вы можете свернуть все ненужные пробелы. Наличие пробелов во входных данных (сообщение переполнения стека) также можно игнорировать. Вы также можете игнорировать алфавитный регистр, который был бы более устойчивым перед лицом различных соглашений об именовании идентификаторов.

Во время моего исследования мы обнаружили, что наши методы хорошо работают как для испанского, так и для английского языка. Я не понимаю, почему это не сработает и для исходного кода. Исходный код даже более структурирован и предсказуем, чем человеческий язык.

Могу ли я предложить принципиально иной подход? В SO единственным допустимым человеческим языком является английский, поэтому все, что не является английским, имеет 99,9% шансов быть фрагментом кода .

Поэтому мое решение будет таким: используйте один из множества средств проверки английского языка (просто убедитесь, что они также сигнализируют - помимо ошибок с орфографическими ошибками - синтаксические ошибки, такие как двойные точки, или неязыковые символы, такие как #или ~). Тогда любая строка / параграф, который выбрасывает большое количество ошибок и предупреждений, должна вызывать "это код?" вопрос.

Этот подход также может быть адаптирован для тех сайтов StackExchange, которые используют другие языки, кроме английского, конечно.

Просто мои 2 ¢ ...

Я, вероятно, получу несколько голосов за это, но я думаю, что вы подходите к этому с неправильной точки зрения.

Эта строка досталась мне:

люди должны войти и вручную отформатировать код для людей, которые так или иначе не могут понять это

ИМО, эта точка зрения довольно высокомерна. Я нахожу это много в дизайне программного обеспечения, когда программисты и дизайнеры раздражаются пользователями, которые не могут понять, как правильно использовать программное обеспечение, когда проблема не в пользователе, а в самом программном обеспечении или, по крайней мере, в интерфейсе пользователя.

Основной причиной этой проблемы является не пользователь, а тот факт, что им не очевидно, что они могут это сделать.

Как насчет изменения в пользовательском интерфейсе, чтобы сделать это более очевидным? Наверняка это будет:

1. для новых пользователей более очевидно, что именно им нужно делать
2. Вам легче создавать, а не писать сложные алгоритмы для обнаружения логики кода множества языков.

Пример:

Псевдокод будет представлять собой реальную проблему, потому что все языки программирования зависят от специальных символов, таких как '[],'; ',' () 'и т. Д. Просто посчитайте вхождение этих специальных символов. Точно так же, как вы обнаружили бы двоичный файл (более 5% выборки содержит значение байта 0).

Я думаю, что вам может потребоваться нацелиться на это только для определенных языков, в общем, эта проблема, вероятно, трудно решаема, поскольку вы можете получить языки, которые очень похожи на английский (например, inform7 ). но, к счастью, наиболее используемые из них могут быть покрыты довольно легко.

Моим первым шагом было бы найти последовательность "; \ n", которая бы хорошо подходила для C, C ++, Java, C # и любого другого языка, который использует похожий синтаксис и действительно прост. Это также менее вероятно, будет использоваться на английском языке, чем; без перевода строки

Кто-то упоминал, что смотрел на теги, а затем искал синтаксис для этого, но он был сбит, потому что он нацелен на новых пользователей.

Возможно, лучшим решением было бы поискать названия языков в основной части вопроса, а затем применить ту же стратегию. Если я упомяну «Javascript», «Java» или «C #», то, скорее всего, именно в этом и заключается вопрос, и код в вопросе, вероятно, будет на этом языке.

Во-первых, запустите его через проверку орфографии, он найдет очень мало правильных английских слов, однако должно быть много слов, которые система проверки правописания предложит разделить.

Тогда есть знаки препинания / специальные символы, не типичные для простого английского языка, типичные для кода:

• something(); просто не может быть простым английским языком;
• $somethingгде somethingне все числовые;
• -> между словами без пробелов;
• . между словами без пробела;

Конечно, чтобы это работало хорошо, вы можете захотеть иметь байесовский классификатор, построенный на основе этих характеристик.

Есть несколько наборов языков с одинаковым синтаксисом. На большинство языков повлияло несколько языков, поэтому языки [AMPL, AWK, csh, C ++, C--, C #, Objective-C, BitC, D, Go, Java, JavaScript, Limbo, LPC, Perl, PHP, Pike, Processing [все были под влиянием C, поэтому, если вы обнаружите C, вы, вероятно, обнаружите все эти языки. так что вам нужно всего лишь написать простой шаблон для обнаружения этого языкового набора.

я также разделил бы текст на блоки, потому что большая часть кода будет разделена двумя новыми строками или подобными от других текстовых блоков в посте.

это легко сделать с помощью javascript (очень простой неполный пример для семейства 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 + "]");
   }
}

Просто посчитайте слова / знаки препинания для каждой строки. Английский будет иметь 4 или более, код меньше 2.

Например, в абзаце выше 18 слов и 4 знака препинания. Этот пункт имеет 19 слов и 4 пунктуации, поэтому в пределах ожиданий.

Конечно, это должно быть проверено на вопросы начинающих плохо говорящих по-английски, и, возможно, в этих случаях статистика искажается.

Я ожидаю, что [non-whitespace]. [Whitespace or newline] очень редко встречается в коде, но распространено в английском, так что это можно считать словами, а не пунктуацией.

Я думаю, что самой большой проблемой будет встроенный код, где кто-то задает такой вопрос:

Если я скажу для (i = 0; i> 100; i ++) {}, что это значит?

Это код и английский, и должны быть помечены как обратные галочки:

Если я скажу, for (i=0; i>100; i++) {}что это значит?

Я думаю, что вы должны сначала провести различие между (достаточно) отформатированным кодом, который нужно только фактически обозначить как таковой, и (слишком) плохо отформатированным кодом, который в любом случае требует ручного форматирования.

Отформатированный код имеет разрывы и отступы. То есть: если перед строкой стоит один разрыв, у вас есть хороший кандидат. Если над ним стоят пробелы, у вас есть очень хороший кандидат.

В обычном тексте для форматирования используются две или две строки перерыва и одна линия перерыва, поэтому существует четкий критерий различия.

В коде LISP вы не найдете точки с запятой, в коде Ruby вы не можете найти круглые скобки, в псевдокоде вы можете вообще ничего не найти. Но на любом (не эзотерическом) языке вы найдете приличный код, отформатированный с помощью разрывов и отступов. Нет ничего более универсального, чем это. Потому что в конце код написан для чтения людьми.

Итак, во-первых, поиск потенциальных строк кода . Кроме того, строки кода обычно приходят группами. Если у вас есть, есть хороший шанс, что тот, что выше или ниже, также является строкой кода.

После того как вы выделили потенциальные строки кода, вы можете проверить их по количественным критериям и выбрать некоторый порог :

• частота несловесных символов
• частота идентификаторов: очень короткие слова или очень длинные слова в стиле CamelCase или under_score
• повторение необычных слов

Кроме того, теперь, когда есть программисты и cs, область действия stackoverflow явно сужена. Можно рассмотреть возможность обозначения всех языковых тегов как языков. А при публикации вас попросят либо выбрать хотя бы один языковой тег, либо выбрать language-agnosticтег, либо явно пропустить его.

В первом случае вы знаете, какие языки искать, во втором случае вам может понадобиться поиск псевдокода, а в последнем случае, вероятно, не будет никакого кода, потому что это вопрос, связанный с какой-либо технологией или рамки или такие.

Вы можете создать парсер для каждого языка, который вы хотите обнаружить (определения языка для ANTLR обычно легко найти), а затем пропустить каждую строку вопроса через каждый парсер. Если какая-либо строка анализируется правильно, у вас, вероятно, есть код.

Проблема заключается в том, что некоторые предложения на английском (естественном языке) могут анализироваться как код, поэтому вы можете включить некоторые другие идеи или ограничить положительные результаты, только если более одной или двух последовательных строк правильно анализируются с тот же синтаксический анализатор языка.

Другая потенциальная проблема состоит в том, что это, вероятно, не поднимет псевдокод, но это может быть хорошо.

Что может оказаться наиболее перспективным и потребовать наименьшей ручной корректировки в долгосрочной перспективе, так как другие языки (которые выглядят несколько иначе, чем языки программирования, используемые в настоящее время) становятся более популярными, а используемые в настоящее время языки становятся менее популярными, - это сделать что-то вроде того, что делает Google Translate (см. параграф «Как это работает?»), вместо того, чтобы искать определенные вещи, такие как ab и a () и т. д.

Другими словами, вместо того, чтобы вручную думать о шаблонах, найденных в коде, который нужно искать, компьютер может сам разобраться в этом . Это можно сделать, имея

1. много кода на разных языках программирования

   • Предложение: автоматически брать образцы кода из веб-хранилищ исходного кода, таких как Google Code или Github, или даже из вещей в Stackoverflow, уже помеченных как код

   • Примечание: это может быть хорошей идеей для анализа комментариев кода

2. много английского текста взяты из статей в сети

   • хотя не из статей о программировании (в противном случае они могут содержать код и смешивать систему :-))

и наличие некоторого алгоритма для автоматического поиска в коде шаблонов, которых нет на английском, и наоборот, и использование этих шаблонов для определения того, что является кодом, а что нет, путем запуска алгоритма в сообщениях.

(Однако я не уверен, как будет работать такой алгоритм. Другие ответы на текущий вопрос могут иметь для этого полезную информацию.)

Затем система может повторно сканировать код время от времени, чтобы учесть изменения в том, как код смотрит на данный момент времени.