Ошибки, которых можно избежать с помощью стандартов кодирования [закрыто]

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

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

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

• Список 10 лучших программ по уменьшению дефектов программного обеспечения , в котором рассматриваются улучшения в эмпирической разработке программного обеспечения с 1987
• Критический анализ процесса обработки данных PSP , который изучает статистику, собранную в процессе персонального программного обеспечения, и влияние PSP на распространенные причины ошибок программного обеспечения

Кодирование «стандартов» ... Существует множество областей разработки, которые можно стандартизировать. Мы говорим о соглашениях по кодированию, таких как стандарты именования и т. Д.? Или мы говорим о чем-то более глубоком, таком как TDD / BDD, CI и т. Д.?

Я могу вам сказать, что следование методологии «сначала тест», когда CI обеспечивает прохождение тестов и хорошее покрытие кода, действительно уменьшает количество ошибок, обнаруженных клиентом. Автоматическое тестирование, как разработчиком, так и QA, также является относительно «дешевым» способом поиска ошибок, поскольку обычно у них очень короткое время обратной связи. Вы можете знать, что вы не написали то, что думали, что написали, запустив около 45 секунд модульных тестов. Пару часов интеграционных тестов позволят найти места, где объединение элементов не прошло как запланировано, а сквозное и автоматическое тестирование пользовательского интерфейса может быстро обнаружить функциональные сбои в программном обеспечении на очень высоком уровне.

Они также предотвращают регрессию. Вы нашли ошибку. Вы пишете тест, который докажет, что поведение больше не возникает, вы кодируете его до тех пор, пока тест не пройдет, и теперь у вас есть тест, который с этого момента гарантирует, что ошибка больше никогда не будет проблемой. По моему опыту, это основной источник новых ошибок; исправление одной вещи нарушает другую, и тестирование исправления вашим разработчиком может не охватить ту другую ситуацию, которая сейчас нарушена. Разбивать вещи, которые раньше работали, - ОГРОМНЫЙ красный флаг для ваших клиентов.

Наконец, эта автоматизированная структура тестирования, которую вы создаете в рамках этой методологии, очень легко создаст среду, в которой вы сможете выпустить новую сборку программного обеспечения буквально за мгновение. «Эй, эта ошибка, которую вы только что исправили, вызывала некоторые настоящие головные боли; когда вы будете готовы в новой версии?» нажмите «О, примерно через 5 минут, когда сервер сборки завершит публикацию его на странице загрузки».

Что касается базовых правил кодирования, таких как стандартизация имен переменных и т. Д., Я обнаружил, что большая часть этого является менее полезной и более раздражающей. Это те стандарты, которые «прекрасны, потому что есть из чего выбирать». То, что вы воспринимаете как разницу между идентификатором PascalCased и camelCased, может не совпадать с мнением другого человека. Основные подчеркивания, ограничения длины имени (или требования, которые имена методов / полей рассказывают историю); кроме соглашений, применяемых компилятором или обычно встречающихся в коде библиотеки для конкретного языка, современная IDE может рассказать вам все, что вам нужно знать о переменной или функции, включая то, следует ли вам использовать ее в конкретном случае или нет. обстоятельство. Кроме того, при выполнении проверки соглашения о коде часто возникают проблемы с кодом, который вы не можете или не можете не хочу меняться, как сторонняя библиотека, использующая другой набор стандартов, или код взаимодействия, который может соответствовать стандартам именования Win API вместо стандартов вашего родного языка. В конечном итоге вы добавляете в свой код Cruft, чтобы сообщить своему инструменту, что он игнорирует код.

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

Любую уязвимость переполнения буфера можно было бы предотвратить с помощью стандарта кодирования. Статистика по ним, вероятно, тоже доступна.