Есть ли какие-либо научно-строгие исследования принципов стиля кодирования? [закрыто]

Является ли принцип стиля кодирования - например, принцип единого выхода - действительно хорошей вещью? Всегда или просто иногда? Насколько это действительно важно?

Каковы бы ни были ваши мнения, это, очевидно, субъективные вопросы. Или они?

Кто-нибудь пытался провести объективное, с научной точки зрения тщательное изучение принципов стиля кодирования?

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

Я повторяю комментарий Deadalnix: прочитайте Code Complete 2 . Автор (Стив Макконнелл) подробно обсуждает стиль кодирования и часто ссылается на статьи и данные.

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

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

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

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

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

Ответ окончательный НЕТ! Являются ли `break` и` continue` методами программирования? это подмножество этого вопроса, поэтому я собираюсь начать с едва измененного ответа на этот вопрос ...

Вы можете [пере] писать программы без операторов прерывания (или возврата из середины циклов, которые делают то же самое). Но при этом вам, возможно, придется ввести дополнительные переменные и / или дублирование кода, которые обычно затрудняют понимание программы. По этой причине Pascal (язык программирования конца 1960-х) был очень плох, особенно для начинающих программистов.

Есть результат в области компьютерных наук, который называется иерархией управляющих структур Косараю, которая восходит к 1973 году и упоминается в (более) известной статье Кнута « Структурированное программирование с утверждениями 1974 года». То, что С. Рао Косараю доказал в 1973 году, - это то, что это не так. можно переписать все программы, имеющие многоуровневые разрывы глубины n, в программы с глубиной разрывов меньше n без введения дополнительных переменных. Но допустим, что это чисто теоретический результат. (Просто добавьте несколько дополнительных переменных ?! Конечно, вы можете сделать это, чтобы чувствовать себя внутри группы с пользователями 3K + на stackexchange ...)

Что гораздо более важно с точки зрения разработки программного обеспечения, это более поздняя статья Эрика С. Робертса 1995 года под названием « Выход из цикла и структурированное программирование: возобновление дебатов» (doi: 10.1145 / 199688.199815). Робертс суммирует несколько эмпирических исследований, проведенных другими до него. Например, когда группу студентов типа CS101 попросили написать код для функции, реализующей последовательный поиск в массиве, автор исследования сказал следующее о тех студентах, которые использовали разрыв / возврат для выхода из последовательного поиска. цикл поиска сразу, когда элемент был найден:

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

Робертс также говорит, что:

Студенты, которые пытались решить проблему, не используя явного возврата из цикла for, чувствовали себя намного хуже: только семь из 42 студентов, пытающихся использовать эту стратегию, смогли найти правильные решения. Эта цифра представляет собой показатель успеха менее 20%.

Да, вы можете быть более опытным, чем учащиеся CS101, но без использования оператора break (или, что эквивалентно, возврата / перехода из середины цикла), в конце концов вы напишите код, который, хотя номинально хорошо структурирован, достаточно сложен с точки зрения дополнительной логики Переменные и дублирование кода, что кто-то, вероятно, вы сами, добавите в него логические ошибки, пытаясь следовать некоторой устаревшей идее «правильного» стиля кодирования.

И здесь есть еще одна большая проблема, кроме операторов типа return / break-type, так что этот вопрос немного шире, чем вопрос о разрывах. Механизмы обработки исключений также нарушают парадигму единой точки выхода согласно некоторым

• http://msmvps.com/blogs/peterritchie/archive/2008/03/07/single-entry-single-exit-should-it-still-be-applicable-in-object-oriented-languages.aspx
• http://pragprog.com/magazines/2012-04/the-pragmatic-defense

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

Я вижу, откуда пришло понятие «только одно возвращение»?что распространенное мнение на этом сайте противоречит тому, что я разместил здесь, поэтому я полностью понимаю, почему за меня уже проголосовали, хотя я и здесь первый ответ, который фактически предоставил что-то, о чем спрашивал вопрос: некоторая информация о реальных тестах на юзабилити сосредоточена на проблеме с одним выходом. Я предполагаю, что не должен позволять знаниям мешать предвзятым представлениям, особенно на сайте геймификации. Теперь я собираюсь заняться редактированием Википедии. По крайней мере, информация из хороших источников ценится, а смутные или неправильные утверждения, притворяющиеся источниками, в конечном итоге вызывают запрет. На этом сайте происходит обратное: доминируют мнения, необоснованные фактами. Я ожидаю, что мод удалит эту последнюю часть, но, по крайней мере, этот чувак будет знать, почему вы потеряли меня навсегда как участник здесь.

http://dl.acm.org/citation.cfm?id=1241526

http://www.springerlink.com/content/n82qpt83n8735l7t/

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=661092

[На ваши вопросы, кажется, отвечает одно слово «да». Мне, однако, сказали, что предоставление коротких ответов является «пренебрежительным» вопросом. Если вы считаете, что я отказался от ответа, пометьте ответ, чтобы модератор мог его удалить.]

Это принцип стиля кодирования - например, принцип единого выхода

Люди, которые все еще обращают внимание на один выход или несколько выходов, все еще застряли в конце 1960-х годов. В то время такое обсуждение было важным, так как мы были в зачаточном состоянии структурированного программиста, и было довольно много лагерей, провозглашавших, что выводы, лежащие в основе теоремы Бома-Якопини о структурированных программах, не были универсально применимы ко всем конструкциям программирования.

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

Что касается остальных моих ответов, все относительно (что не в программном обеспечении?):

• действительно хорошая вещь?

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

Всегда или просто иногда?

Большую часть времени.

Насколько это действительно важно?

Зависит.

Читаемый код против нечитаемого кода. Увеличенная сложность (которую мы должны знать, теперь увеличивает вероятность появления ошибок) по сравнению с более простой сложностью (и, следовательно, меньшей вероятностью ошибок). Языки, компиляторы которых не добавляют неявный возврат (скажем, Pascal, Java или C #) и те, которые по умолчанию int (C и C ++).

В конце концов, это навык, отточенный в человеко-часах за клавиатурой. Иногда нормально иметь несколько операторов return, как здесь (в некотором псевдокоде Pascal'esque):

function foo() : someType
  begin
  if( test1 == true )
  then
    return x;
  end
  doSomethignElseThatShouldnHappenIfTest1IsTrue();
  return somethingElse();
end;

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

Иногда это не так (здесь используется C-подобный псевдокод):

switch(someVal)
{
case v1 : return x1;
case v2 : return x2:
case v3 : doSomething(); // fall-through
case v4: // fall-through
case v5: // fall-through
case v6: return someXthingie;
...
...
default:
   doSomething(); // no return statement yet
}

Здесь алгоритм не имеет простой структуры, и оператор switch (в стиле C) допускает переходные этапы, которые могут выполняться или не выполняться преднамеренно как часть алгоритма.

Возможно, алгоритм правильный, но плохо написан.

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

Может быть, это неправильно.

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

Предполагая, что фрагмент кода считается правильным:

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

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

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

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

Это тесно связано со сложностью рассматриваемого фрагмента кода. А это, в свою очередь, связано с мерами цикломатической сложности и сложности Холстеда. Из этого можно наблюдать следующее:

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

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

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

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