Отчёт о проверке безопасности открытого и проприетарного кода за 2011-ый год.

Это... как его... не могу понять... средние показатели free - 0.45, prop - 0.64, а во всей индустрии 1.0

Попробую угадать ход их мыслей. Вся индустрия складывается из проприетарного ПО и из свободного ПО, так?

Поэтому они сложили (0.64 + 0.45) и округлили. Или сначала округлили, а потом сложили и отбросили лишнее.

Из отчета можно сделать только один вывод: чем меньше в проекте строк тем он надежнее. Авторы не из Британии случаем?

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

К эклипсу я на работе привык. Там навигация по коду удобная. Не могу после него в студии работать. А иногда приходится в ней что-то делать. Чтобы компактифицировать эклипс можно просто нажать Ctrl+M, когда курсор находится в окне с текстом.

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

Чтобы компактифицировать эклипс можно просто нажать Ctrl+M, когда курсор находится в окне с текстом.

А что при этом происходит? В студии просто можно для всех нужных панелей сделать автоскрытие, ненужные панели вообще убрать, а тулбар повесить справа от меню, тогда он вместе с меню будет занимать одну строку. В итоге всё умещается даже на 1024x600. Могу завтра вечером скриншот сделать.

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

Не помню где читал (кажется «Искусство программирования под Unix», fragment мне все-равно скажет, что вброс...), следующие мнение - в логически завершенных блоках (функция, модуль, класс и т.п.) кода до 200 строк количество ошибок стремится к 0, от 200 до 600 растет линейно и к 600 приближается к единице. Выше 600 строк количество ошибок переваливает через 1 и начинает расти ускоренно (как не помню). Вот где-то так. Там же по этой причине советовали не писать блоки больше 600 строк и не нарезать блоки меньше 200 просто так, от нефиг делать - типа не имеет смысла. Кроме того, говорилось, что это хоть и зависит от ЯП, но для всех крутится примерно вокруг этих цифер и пропорций. Конкретно эти числа вроде бы были названы для C.

Комбинация раскрывает текущую «панель» на все окно эклипса. Если веделенная будет консоль, то она будет на весь эклипс. Я эту комбинацию пользую только для текстового редактора.

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

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

свой продукт с блюющими лошадьми

очень лошадки заинтриговали. Что ээто?

с федорой аналогичнго разлива

каким образом тестовый дистр может разливаться из одной бочки со стейбл дистром? и тем более федора с дебианом?

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

«Что вполне логично, ведь код действительно стал сложнее и его стало намного больше. Сравни операционные системы конца 80-х и сейчас, хотя бы по объёму» qnx?

«На Шindoшs. Я к тому что безглючного софта не бывает, если это только не хеллоуворлд.» TeX?

Правда работает оно только под Visual Studio 2005, 2008, 2010 више Express http://www.viva64.com/ru/pvs-studio/ http://habrahabr.ru/tag/pvs-studio/

PHP 5.3 и ..... признаны открытым ПО с высоким качеством кода,

этот тот самый PHP 5.3 в котором 30% юниттестов, написанных самим же разработчкиами, не проходят проверки?

А я недавно поставил мсоффис 2007 и риббон мне очень понравился. Удобная вещь.

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

Linux 2.6, PHP 5.3 и PostgreSQL 9.1 признаны открытым ПО с высоким качеством кода, их показатели средней дефективности кода составляют 0,62, 0,20 и 0,21 соответственно. Всего в Linux 2.6 была выявлена 4261 ошибка, из которых 1249 признаны очень опасными или критическими. В РНР 5.3 и PostgreSQL 9.1 эти показатели составляют 97/15 и 233/116 соответственно.

Это похоже на троллинг PHP. А чего они не взяли Linux 2.6.32.57 ? Тогда бы показатель был бы 0.05! ИМХО, авторы статьи полные не адекваты.

Существует еще какой-то вид ПО с такими дикими багами, которые перевешивают средний показатель?

да просто сложили, наверно, 0.45 и 0.64, а поделить на два забыли :)

То есть «мы нашли в линуксе 4261 ошибку, но мы не скажем где»?

конечно не скажут!
иначе все поймут, что за «ошибки» они там находят своим «статическим анализатором кода, который стоит много-много убитых енотов», и поток енотов резко закончится

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

#!/usr/bin/perl

print 'Just another Perl hacker\n';

или тут:

#include <stdio.h>

int main (void) {
printf ("Hello world\n");
return 0;
}

Намекают на ошибках в самом интерпретаторе/компиляторе, системных библиотеках, ядре, etc. Понятия несколько подменились :)

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

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

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

В эклипсе есть понятие - перспектива - набор вьюшек (окон), их расположение, размеры. Для дебага своя перспектива, для 100500 других режимов - своя. Переключаются по Ctrl+F8 вроде.

Я знаю. Жутко неудобная концепция.

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

Компания Coverity, лидер автоматизированного тестирования....

Филиал Похороникса? :)

Отчёт - такая БАЛДА, что даже смеяться грешно! Лажа на лаже и чепухой погоняет.

Средний размер никому не интересен ввиду бесполезности. Касательно же ошибок, крайне трудно выявить их все, особенно во всяких Си-с-костылями, посему сравниваются какие-то примерные цифры, да ещё и без объяснений «критичности» ошибок.
«ошибок на 1000 строк» - чепуха. Есть 100 строк библиотеки, на которой зиждется остальной проект - вот там КАЖДАЯ ошибка - пипец всей системе. А есть просто утечка памяти в окне About - серьёзная разница.
Льстить же ФОССникам, что «их программы не лажовее коммерческих» - не вижу смысла в этом вранье. Очевидно же, что профи, работающий 8 часов за деньги, работает стократ качественнее студента, по вечерам пишущего очередной редактор.

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

Спасибо за информацию, очень интересно. Давайте и я в вас классикой кину, что ли: Фредерик Брукс «Мифический человеко-месяц»

Вариант на «С» не то что бы не правилен, но не точен - однозначно. Самый распространенный пример простейшей программки содержит одну фактическую неточность. Дело в том, что printf возвращает значение равное количеству выведенных символов, а в случае ошибки - некоторое отрицательное число. И если в результате printf вернул -1, на консоли ничего не отобразилось, а ваша программка тихо, ничего никому не сообщив, по прежнему завершилась с нулем, то например скрипт, разбирающий вывод, никаким образом не поймет в чем проблема.

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

У Вас странное представление о том, что значит слово «профи». :-)

Ваше профи видимо не напрягается получить звонок в час ночи с воплем «оно упало!» и потом до утра разгребать случившееся?

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

В eclipse вроде нельзя повесить тулбар повесить справа от меню, но все остальное - можно. Я неправ?

т.е падает от каждого чиха.

зачем чихать в открытый системный блок ?

Ты всё воспринимаешь буквально?!

Ну я же говорю - хреновый из меня программист ^_~

Хотя, часто ли в коде проверяют, что вернул printf? А то перловский вариант он тоже возвращает

kuu@Cloudsdale:~$ perl -e 'print STDOUT (print "Just another Perl hacker\n") . "\n";'
Just another Perl hacker
1

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

Нужно ли проверять что вернул print, если предварительно проверено содержимое переменной которую он выводит?

А нужно ли проверять что фактически вывел print если проверена и переменная и то что он вернул?

А правильное ли значение вернул print?

Не изменилась ли переменная в результате проверки ее содержимого?

Сколько проверок вообще надо делать?

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

Вот тут и начинается самое интересное: а надо ли делать проверку результата работы printf? Ответить на этот вопрос без подробных спеков, техзадания или хотя бы формулировки области применения невозможно. Поэтому тестировать программу в отрыве от ее ТЗ задача бессмысленная. Сильно пордозреваю, что ни о чем подобном эти горе-исследователи даже понятия не имеют.

Не так все сложно, вот более правильный вариант:

#include <stdio.h>
int main()
{
    return printf("Hello world!\n") < 0 ? 1 : 0;
}

Техзадание не хеллоуворлд - это сильно... Задача того сишного HW была вывести на экране строчку «Hello world» и перевести строку. Кажется, она вполне с ней справляется. Наверное возможны какие-то внешние проблемы, по которым она не сможет напечатать в STDOUT, но это уже не проблема «ошибок в коде».

К тому же, как быть с кодом, который вроде бы работает, но как-то через одно место?

Не изменилась ли переменная в результате проверки ее содержимого?

Напомнило:

print "Файл существовал :(\n" if unlink $file;

Проект является закрытым и разрешения на открытия кода проекта subj не получил (и не пытался ;) ). Даже название проекта оглашать запрещено.

а-а-а! так вот где собака зарыта! т.е. проприетарщики отдавали на проверку только тот код, который хотели? тогда понятно почему они такие «надежные» :)))

Проект является закрытым и разрешения на открытия кода проекта subj не получил (и не пытался ;) ). Даже название проекта оглашать запрещено.

а-а-а! так вот где собака зарыта! т.е. проприетарщики отдавали на проверку только тот код, который хотели? тогда понятно почему они такие «надежные» :)))

тролль.

К тому же, как быть с кодом, который вроде бы работает, но как-то через одно место?

Да, был очевидцем кода дарйвера написанного на С ассемблерным программистом. В этом коде кроме if и goto вообще структурных операторов не было. Драйвер таки работал но когда перестал его просто выкинули, сопровождать такое мазохистов не нашлось.

С другой стороны, вот пример кода который с точки зрения одних, написан через одно место

for(q=0; x; ++q) x &= x-1;

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

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

Очевидно же, что профи, работающий 8 часов за деньги, работает стократ качественнее студента, по вечерам пишущего очередной редактор.

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

OMFG!

Очевидно же, что профи, работающий 8 часов за деньги, работает стократ качественнее студента, по вечерам пишущего очередной редактор.

Кому очевидно? Профи надо вложиться в time estimation, да и вообще — чем больше продуктивность, тем больше з/п. А при кодинге по вечерам нет ни временных ограничений, ни вообще-то и квалификационных.

Ваше профи видимо не напрягается получить звонок в час ночи с воплем «оно упало!» и потом до утра разгребать случившееся?

И много программистов с таким графиком? Обычно больше по закоммиттиться и забыть.

«У Вас странное представление о том, что значит слово „профи“. :-)

Ваше профи видимо не напрягается получить звонок в час ночи с воплем „оно упало!“ и потом до утра разгребать случившееся?» это у вас странное представление о том как работают профессиональные разработчики «по 8 часов в сутки». между ним и тем «что упало» три-четыре слоя. самое больше что он получит - письмо в ящик и/или тикет в системе. который неспеша посмотрит утром после и кофе и будет неспеша фиксить... если грамотный - посмотрит откуда он что взял и подумает когда по тем проектам заявки придут... собстенно что в исследовании и отмечается - опенсоурсные разработчики действительно «бегут фиксить». а профессионал который работет по 8 часов - нафига ему бежать? денег он от этого больше не получит. +$50 в конце квартала это не деньги. и даже +$500.

«Кому очевидно? Профи надо вложиться в time estimation, да и вообще — чем больше продуктивность, тем больше з/п.» а в чем мы меряем продуктивность? правильно в килослоках. поэтому copy-paste и не напрягайся. и 10 одинаковых ошибок которые при желании закрываются за то же время что и одна они тоже полезны. а какже - вон за недели сколько багов закрыли... начальника .. премию давай, да...