==== Введение ==== В данной статье пойдёт речь о правилах кодирования. У каждого программиста может быть свой стиль, но какие-то обще принятые правила он должен соблюдать, чтобы другие смогли понять его код. Как правило, эти правила, разделяют на две категории: \\ 1) Законы, чётко сформулированные и подкреплённые правилами.\\ 2) Условия, невысказанные, появляющиеся спонтанно.\\ В данной работе ориентируются в качестве первого шага ориентируются на задание имён и форматирование. Вводится фреймворк стандартизация, который решает проблемы кодирования в рамках правил. Когда коды не отражают согласованности по правила кодирования, данный фреймворк не рекомендует ничего, потому что ничему не научился. Требования стандартизация включают ряд новых инструментов для повышения производительности труда разработчиков и качества кода:\\ 1) Предварительно совершить сценарий, который противоречит ожиданию, что серьезно нарушает соглашения кодовой базы; \\ 2) Инструмент для преобразования выведенного результата в правило для использования кода форматирования; \\ 3) Эклипс плагин, который разработчик может использовать, чтобы проверить, является ли ее изменение необычным (непредвиденным); \\ 4) Стиль профайлера, который подчеркивает стилистику непоследовательного фрагмента кода для кода рецензента.\\ Синтаксический уникальный принцип (SUP): уникальные имена должны быть сохранены, когда они появляются в уникальных контекстах. стандартизация полезна для таких языков, как Java, CSS, HTML и JavaScript.\\ Итак, постулаты для работы в данной статье следующие:\\ • Мы создали стандартизацию, первые рамки для решения проблемы кодирования логического вывода для частного случая, в том числе идентификатор присвоения имен и форматирование, и предлагаем изменения, чтобы увеличить соблюдение кодовой базы для своих собственных соглашений;\\ • Мы предлагаем четыре инструмента, опирающиеся на стандартизацию, во главе которой стоит релиз-менеджмент всего процесса развития\\ • Стандартизация 1) достигает 94% точности в своих лучших предложениях по заданию имен идентификаторов и 2) никогда не опускается ниже средней точности 96% при принятии решения форматирования;\\ • Мы показываем, что правила кодирования играют важную роль для команд, показав, что 1) эмпирически, программисты в жизнь конвенции в значительной степени за счет обратной связи код обзора и корректирующие совершает, и 2) участки, которые были настроены на стандартизацию предложения были включены в 5 самых популярных открытые Java-проектов источника GitHub - из 18 патчей что мы представили, 14 были приняты.\\ Инструменты доступны по ссылке http://groups.inf.ed.ac.uk/naturalize/ ==== Примеры мотивации ==== Рассмотрим пример класса, представленного на рисунке 1, который является частью изменения, представленного для анализа разработчикам Microsoft 17-го февраля 2014. В то время как класс функционирует нормально, он нарушает правила кодирования команды. Второй разработчик рассмотрел изменения и предположил, что res и str не передают параметры в полной мере, строка конструктора слишком длинна и должна быть обернута. В загруженном изменении все они были направлены с названиями параметров, измененными на queryResults и queryStrings.\\ Однако, если бы разработчик выполнил все правила стандартизации, то он мог бы быть уверен, что его изменение согласуется с нормами команды и, скорее всего, будут утверждено в ходе обзора. {{:mdd:ппс3.png|}} === Случаи использования и инструменты === Правила кодирования имеют решающее значение в процессе релиза. Правила кодирования особенно здесь уместны, и применимы в трех случаях: 1) разработчик готовит свой собственный коммит в ветку для просмотра кода или его продвижения; 2) инженер-релиз пытается отфильтровать ненужное стилистическое разнообразие от лишних изменений; 3) смотритель желает убедиться в качестве патча и его соответствия нормам. \\ Для поддержания пользовательских кейсов, построено 4 инструмента:\\ **devstyle** Плагин для Eclipse IDE, который дает предложения для идентификатора переименования и форматирования как для одного идентификатора или точки формата так и для идентификаторов , которые выбраны в коде. **styleprofile** Помощник проверки кода, который производит профиль который равен сумме похожих фрагментов кода для кодирования и предлагает переименование и форматирование, чтобы сделать отрывок более стилистически последовательным для проекта. **genrule** Правило создания кода форматера в Eclipse, который генерирует правила для тех правил, которые стандартизации умеет выводить в кодовый формат. **stylish?** Высокая точность предварительной фиксации сценария для Git, не воспринимающая фиксаций, которые имеют весьма противоречивое и противоестественное имя или форматирование в рамках проекта. ==== Основы(или рамки) стандартизация ==== NATURALISE является общей и может быть применена к любому языку, для которого существуют лексический и синтаксический анализfтор, так как используются символические последовательности и абстрактные синтаксические деревья (ASTS) во время анализа. Рисунок 3 иллюстрирует эту архитектуру. {{:mdd:ппс4.png|}} === Ядро Стандартизации === Архитектура содержит два основных элемента: инициаторы и результирующая функция. Инициаторы изменяют входной фрагмент кода, составляют список кандидатов для предложений, которые могут заменить входные фрагменты. В примере на рисунке.1, каждый кандидат заменяет все вхождения res с другим именем, используемые в подобных контекстах в других частях проекта, например, результаты или queryResults. В принципе, могут поступить многие неправдоподобные предложения, так что, на практике, Инициаторы содержит логику фильтрации. Используется PA(y), чтобы указать вероятность того, что языковая модель Р, обученная на наборе А, сопоставляет последовательность y. s - результирующая функция s(y,PA) = (1/N) log PA(y) (1) //gap function// g(y,z,P) = s(y,P)−s(z,P) (2) Функция suggest(х, С, k, t), которая возвращает топ-кандидатов в соответствии с результирующей функцией, s(c1) ≥ s(c2) ≥ ... ≥ s(cr). **Binary Decision** G(x,P) = max l∈L max c∈C`g(c, x) (2) === Выбор результирующей функции === {{:mdd:ппс8.png?400|}} **Multiple Point Suggestion** Несложно адаптировать систему под множество точек предположения. Правда результат функции будет хуже, чем при одиночной проблеме. Стандартизация адаптирована под множественный. === Естественной форматирование === Стандартизация применяется для построения такого языка программирования, который автоматически подстраивается под соглашения и формирует правила использования кода ==== Оценка ==== //**Методология**// Наше собрание - это набор известных открытых источников на Java. Из GitHub4 мы получили список всех проектов java. Среднее число зрителей и разветвлений отличаются, поэтому, чтобы объединить их, мы предполагали, что эти цифры следуют нормальному распределению и подвел их Z-оценки. Мы подобрали топ-10 проектов скоринга. В таблице 1 показаны результаты выбранных проектов. {{:mdd:ппс5.png|}} === Важность правил кодирования === В таблице 2 приведены наши выводы из рассмотрения тестирующиеся комммиты и обзоры кодов. Также представлено 95% доверительных интервалы на основании результатов выборки. Эти результаты показывают, что изменения, в нетривиальной степени, нарушают правила кодирования, даже после того,мавторы считают их полными и также, что члены команды ожидают, что эти нарушения будут исправлены. Исправления в процессе развития являются не очевидными. Последний столбец в таблице 2 содержит р-значения для наших тестов, что свидетельствует о том, что нулевая гипотеза может быть отвергнута со статистически значимой поддержки. ==== Предложение ==== В этом разделе речь пойдёт об оценки точности предложений стандартизация.\\ **Single Point Suggestion** Мы оцениваем стандартизацию на единственной точке предложений, то есть, когда пользователь попросил предложения имен для одного идентификатора.\\ Рисунок 5 представляет собой отчёты по качеству предложений. Каждая точка на этих кривых соответствует различной величине уверенности порога t. Ось абсцисс показывает частоту предложений, Y-ось показывает точность предложение. {{:mdd:ппс6.png|}} **Multiple Point Selection** Для оценки точности стандартизации на кратной точке предложение, например, в devstyle или styleprofile, мы имитируют фрагменты кода, в которых одно название нарушает соглашение по проекту.\\ **Single Point Suggestion for Formatting** Для оценки представления стандартизации на внесение предложений форматирования, мы следуем такой же процедура, как **the single-point naming experiment** для проверки того, как стандартизация правильно восстанавливает исходное форматирование из контекста.\\ **Binary Snippet Decisions** Оцениваем способность **stylish?** отличать коды, которые следуют соглашению и те, которые содержат нестандартные имена или форматирование. {{:mdd:ппс7.png|}} === Работоспособность предложений === Покажем, что стандартизация позволяет избежать двух возможных ошибок в идентификатора предложения:\\ 1)Мусор, который появляется во многих контекста (Junk Names)\\ 2)Сохраняет необычные имена, которые показывают необычные функциональные возможности, придерживаясь SUP (Sympathetic Uniqueness) === Предложение принятия проектов === Если использовать стандартизацию, мы определили высокий доверительный интервал. В таблице 1 показано получить запросы идентификаторы и их текущее состояние. ==== Соответствующая работа ==== В данной работе рассматриваются правила кодирования в целом, и проявляется гибкий подход, управляемый данными. Стандартизация уникальна тем, что она не требует соглашений на жесткие правила, а только мягкие правила, которые используются в коде. Мягкие правила, о которых НАТУРАЛИЗОВАТЬ очень уверен, может быть извлеченных для форматирования. Внимание сосредоточено на управление релизами и улучшение кода посредством соглашения. ==== Заключение ==== Представлена стандартизация, первый инструмент, который делает единым кодовый стиль. Показано, что стандартизация эффективно делает естественные предложения, достигая 94% точности.