Да нет, я проверял только стандартные 12 веток по умолчанию. А Interupted checking как раз говорит о том, что --force я не трогал.
Я проводил сравнение анализаторов для своего работодателя около года назад. Тогда как раз и пришел к выводу, что Cppcheck работает долго и большая часть настоящих предупреждений относится к стилю. Почему и высказал замечание по поводу ваших результатов первым же комментарием. Я, кстати, нисколько не имел в виду какое-либо «украшательство» результатов, лишь то, что с набором проверок по умолчанию Cppcheck действительно малополезен.
Не совсем понял, как у вас вышло за 5 минут проверить source-sdk. Я взял все скопом с официального репозитория, запустил cppcheck на четырех ядрах i3-2330M — и он молотил код примерно 20 часов.
Получилось так:
2 — (error) Analysis failed
2 — (error) Internal error
2 — (error) Invalid number of character * when these macros are defined
2 — (error) Mismatching allocation and deallocation
2 — (error) Uninitialized variable
2 — (error) printf format string has * parameters but only * are given
2 — (portability) Extra qualification '*' unnecessary and considered an error by many compilers.
2 — (performance) Possible inefficient checking for '*' emptiness.
2 — (style) Found duplicate if expressions.
2 — (style) Variable '*' is allocated memory that is never used
2 — (warning) '*' should check for assignment to self
2 — (warning) Suspicious pointer subtraction
2 — (warning) memset() called to fill * bytes of '*'
4 — (style) Clarify calculation precedence for * and?
4 — (style) Checking if unsigned variable '*' is positive is always true.
4 — (style) Unused private function '*'
4 — (style) Variable '*' is not assigned a value
4 — (warning) Using char type as array index
6 — (error) Array '*' index * out of bounds
6 — (error) Memory leak
6 — (performance) Prefer prefix +±- operators for non-primitive types.
6 — (style) The struct '*' does not have a constructor.
6 — (warning) Redundant assignment of "*" to itself
8 — (error) Resource leak
8 — (style) Unused variable
10 — (warning) A boolean comparison with the string literal "*" is always true.
10 — (error) Null pointer dereference
12 — (style) Checking if unsigned variable '*' is less than zero.
24 — (style) struct or union member '*' is never used
32 — (style) Same expression on both sides of '*'.
38 — (error) Possible null pointer dereference
38 — (style) Consecutive return, break, continue, goto or throw statements are unnecessary
76 — (style) Statements following return, break, continue, goto or throw will never be executed
158 — (warning) scanf without field width limits can crash with huge input data
182 — (warning) Redundant code
256 — (style) Variable '*' is assigned a value that is never used
334 — (style) The scope of the variable '*' can be reduced
348 — (style) The class '*' does not have a constructor.
1438 — (information) Interrupted checking because of too many #ifdef configurations.
1728 — (style) C-style pointer casting
4720 — (warning) Member variable '*' is not initialized in the constructor.
Total: 9496
Ну в общем да, собственно ошибок немного. Очень много всего зато считается как style. Например, мертвый код после брейка, одинаковые выражения в сравнении и мои любимые проверки беззнаковых типов на отрицательность. Я согласен, что такая категоризация говорит не в пользу анализатора, но это все-таки не 27 срабатываний, заявленных в исследовании.
Ну, строго говоря, это нормальная практика. Klocwork тоже цены не публикует. Но всегда можно связаться с менеджером, договориться. Для такого рода продукта это нормально.
Fair enough. Действительно, разгребать всякие inconclusive, performance и portability может быть весьма непросто. Но как раз самые серьезные ляпы там и находятся. Например, у меня недавно было inconclusive срабатывание такого типа:
memset(ctx, 0, sizeof(ctx));
(warning, inconclusive) Size of pointer 'ctx' used instead of size of its data.
Это действительно ляп, ляп неприятный и плоходиагностируемый.
Или, например:
if(time_cicl<0)
time_cicl+=86400;
(style) The unsigned variable 'time_cicl' will never be negative
Очевидная ошибка программиста.
Или так: if((bResultRead[0].bPortValue1[28]&2)!=1)
(style) The expression '(X & 0x2) != 0x1' is always true
Очень много действительно важного идет как style. Практически все логические ошибки, дубли веток, мертвый код и так далее. Но да, вычленять это все среди рекомендаций непросто.
А почему для Cppсheck включены только errors и warnings? Если уж считать результативность анализа в найденных штуках, было бы честно сделать --enable=all, а неинтересные сообщения отсеивать через --suppress.
Он, кстати, будет работать значительно медленнее, если в проекте много вложенных веток препроцессора. Они обычно плодятся как раз в процессе отладки, а в более-менее финальной версии режутся. Поэтому если проверять чужие проекты — да, будет быстро. Если свои в самом разгаре рабочего процесса — быстро не получится. Можно, конечно, поотсекать отладочные ветки через -U, но это надо постоянно перенастраивать анализатор под проект. Да и не факт, что отладочные ветки не нуждаются в анализе.
CppCheck можно подключить к студии как внешний инструмент. Там есть флажок --template=vs как раз для форматирования вывода под студию. Работает с любой версией начиная с шестой.
Однако, иногда имена параметров излишни, поэтому в Objective-D их можно опустить.
Это не работает. Именованные параметры есть и в питоне, и в шарпе, и вообще много где. Но если их можно опускать, их будут опускать.
В Objective-C это в общем-то не именованные параметры (функции там сишные, в Си такой фичи нет), а часть синтаксиса сообщений. Обязательная, естественно. Имена невозможно опустить, поэтому приходится их продумывать. В итоге средний код на Objective-C читается прекрасно с минимальной подготовкой читающего. Огромное влияние на популярность языка оказывает то, что я могу за секунды нагуглить пример, понять его и переделать под свои нужды. Двадцать первый век же, никто не читает документацию. А так код сам себя документирует достаточно успешно.
Для С++, кстати, есть Cocos-2dx. Но он откровенно отстает от оригинала.
Идея-то интересная. Но типографике как дисциплине уже много сотен лет, все нюансы со знаками, кернингом, полями, интервалами отработаны очень большой практикой. А нюансы эти как раз и нужны для того, чтобы сделать текст легче читаемым. Вряд ли можно просто заменить буквы квадратами и оставить при этом все преимущества обычной книжной верстки.
По-моему, тут нужны принициально новые знаки препинания, правила переносов, пробелов и междустрочных интервалов.
Было бы еще интересно увидеть цифры какого-нибудь исследования. Мол, у такой-то группы читалось столько-то слов в минуту, после какого-то времени тренирововок стало читаться столько-то.
в реальной жизни, не всегда получается выдавать красивый и логичный код
то и
быть внимательным, и не забывать исправлять комментарии при исправлении кода
тоже не получится.
С одной стороны, комментарии — зло, хотя и зло разной степени необходимости. Я сейчас сталкиваюсь с проблемой, что даже в экстремуме: устаревший ассемблерный код, тонны его, — комментарии помогают и путают примерно одинаково. Нет абсолютно никакой гарантии, что в коде слева от комментария происходит именно то, что в нем написано. Все критичное приходится проверять и перепроверять в коде. Комментарии сильно помогают в том, чтобы понять общую суть, помогают ориентироваться в тексте программы, помогают быстро пролистать много страниц по диагонали. Но в деталях на них полагаться нельзя, а детали как раз и важны в первую очередь.
Проблема в том, что есть множество инструментов для валидации и верификации кода. Есть статические и динамические анализаторы, есть профайлеры и отладчики, есть модульное, интеграционное, регрессионное тестирование. А вот комментарии верифицировать можно только вручную и только через ревью.
Можно, конечно, формализировать ревью. Взять, к примеру, методику Фагана, она правда тоже для кода, а не комментариев. Но она требует участия минимум трех участников на протяжении часа-полутора и позволяет инспектировать 200-300 строк за сессию. Это очень долго, дорого и никогда не применяется для комментариев. Вообще никогда. А вот документация, например, там где надо, в рамках формальной процедуры верифицируется.
И конечно же прозрачный идеоматичный код с говорящими именами и легкочитаемыми конструкциями лучше, чем грязный код с комментариями. И все-таки двадцать первый век на дворе, на современных языках можно писать много выразительнее, чем на алголе и ассемблере. И да, внезапный комментарий действительно говорит о том, что с кодом что-то не так.
Но с другой стороны, с кодом всегда что-то не так. Такая уж природа ПО. Считается, что хороший софт имеет плотность дефектов менее одного на тысячу строк кода. То есть даже при самых жестких V&V процедурах, никто и не ожидает, что программа будет безошибочной. Всего лишь дефектной в рамках дозволенного. Даже если процедура утверждает, что дефектов нет, это означает только то, что они не были найдены в рамках конкретной процедуры. Нулевая плотность дефектов — это не гарантия, а обещание.
Поэтому если кто-то думает, что может делать свой код лучше принципиально не пользуясь комментариями, это самообман. Код костыли содержит всегда, и лучше их явно обозначать комментариями, чем умалчивать.
Но и если кто-то думает, что может сделать свой код лучше комментируя все подряд без очевидной необходимости, это тоже самообман. Поддержка комментариев стократно сложнее поддержки кода, а внимания ей уделяется несравнимо меньше.
Не надо трогать Герона. Можно взять сумму векторов векторных произведений от точки к вершинам (главное не потерять порядок) и сравнить квадрат ее нормы с квадратом нормы векторного произведения двух любых сторон. Это те же площади, но без корней и конских формул, а если компилятор позволяет, еще и с мультискалярными операциями на всех векторных вычислениях.
К слову сказать, Айверсон придумал APL (IBM) именно как разновидность математической нотации. Новая нотация должна быть проще, логичнее и удобно записываться в строчку. Ну и в целом у него получилось. К классической нотации даже до учебника по высшей математике привыкают лет десять, APL можно освоить за семестр или два.
J страдает не из-за плохой нотации, а из-за неподходящих средств ее выражения. Нотация хорошая. Но для того, чтобы читать J, надо не просто знать нотацию, а еще и то, как он ложится на ASCII. Это двойной барьер для восприятия, да. Хотя и преодолимый.
Проблема читаемости J в том, что это адаптация APL под ASCII. Нотация APL непривычная, но неплохая. Не хуже привычной математической. Конечно, если взять его графемы и «втиснуть» в алфавит телетайпа, получится плохо. Это примерно как писать по-русски латиницей, только в восемнадцать раз хуже.
И вот меня все не покидает одна забавная конфабуляция: APL на планшетах. Символы можно рисовать пальцем, например, можно выбирать на нарисованной клавиатуре. Хранить код в уникоде вообще не проблема. Краткость в условиях небольшого экрана — огромный плюс. Мне почему-то кажется, что для обработки каких-нибудь данных в полевых условиях это все было бы полезно и интересно.
Нетрудно заметить, что как мы думаем, так и записываем код
Обратное верно. Программированию стоит учиться, чтобы научиться думать больше и лучше.
Например, лисп, пролог, смолтолк и D несут в себе заряды идей, которые меняют во многом сам образ мышления. Пролог ломает голову декларативностью, лисп — макросами, смолтолк — объектами и интерфейсами, D — статическим метапрограммированием. Поломанная голова срастается и становится крепче, чем была когда-либо до этого. Суть такого обучения понятна и очевидна.
Фортран же, равно как и питон и даже С++ — языки практические и потому неинтересные. Они во многом впитывают чужие идеи, подстраивая их под свой синтаксис и свою инфраструктуру. Плюсы, например, имеют и объекты, и метапрограммирование, и функции как объекты первого рода, но все это намного больше похоже на эмуляцию, чем реализацию. Как говорил Алан Кей: «Я придумал термин „объектно-ориентированный“, и я уверяю вас, что не имел в виду C++».
Поэтому может Фортран и годится в качестве первого языка, но разве что первого. С дидактической точки зрения он не так уж ценен.
Офисное пространство на этом фоне может показаться просто рабочим раем — особенно часто такое мнение встречается среди тех, кто пробовал какое-то время работать удалённо, но не сумел правильно всё организовать и вернулся в офис.
Потому что офисное пространство и предназначается для работы. Сделать его раем — работа работодателя.
И да, личное общение очень важно. Нам, интровертам, приятно думать, что это не так, но это так. Одно совещание вживую способно решить проблему, которую можно в тимспике обсасывать месяц, а электропочтой футболить от полугода до вечности. Простой разговор с разработчиком проясняет проблему в разы лучше, чем любой чат или голос. Просто потому что когда я пришел ногами, я вроде как гость и живой человек, с которым можно пообщаться. А если я — телефонный звонок, то я отвлекающий фактор, который надо устранить.
Меня все время, что я работал удаленно, не покидало чувство, что я в танке заряжающий. Вроде как что-то происходит, кто-то побеждает, а я только снаряды забрасываю и гадаю на копоти: нас, или мы? Чтобы притупить это чувство пришлось съездить в Киев, поймать там лида, чтобы он мне за полчаса нарисовал на бумажках, что вообще происходит. Этот разговор оказался полезнее, чем вся проектная документация.
Я так думаю, если книга хорошая, то она увлекательная, аддиктивная. Если аддиктивная, то это наркотик. А если наркотик, то и распространять его надо через криминальную сеть пушеров. Тогда да, цены по 500 евро за том никого особо не удивят. И да, аресты, облавы, книжная мафия, изъято три тонны подпольной литературы, — вся эта романтика обязана присутствовать. Иначе за что платить-то?
А если книга плохая, то ее издавать и вовсе не стоит.
Я проводил сравнение анализаторов для своего работодателя около года назад. Тогда как раз и пришел к выводу, что Cppcheck работает долго и большая часть настоящих предупреждений относится к стилю. Почему и высказал замечание по поводу ваших результатов первым же комментарием. Я, кстати, нисколько не имел в виду какое-либо «украшательство» результатов, лишь то, что с набором проверок по умолчанию Cppcheck действительно малополезен.
Получилось так:
Ну в общем да, собственно ошибок немного. Очень много всего зато считается как style. Например, мертвый код после брейка, одинаковые выражения в сравнении и мои любимые проверки беззнаковых типов на отрицательность. Я согласен, что такая категоризация говорит не в пользу анализатора, но это все-таки не 27 срабатываний, заявленных в исследовании.
memset(ctx, 0, sizeof(ctx));Это действительно ляп, ляп неприятный и плоходиагностируемый.
Или, например:
if(time_cicl<0) time_cicl+=86400;Очевидная ошибка программиста.
Или так:
if((bResultRead[0].bPortValue1[28]&2)!=1)Очень много действительно важного идет как style. Практически все логические ошибки, дубли веток, мертвый код и так далее. Но да, вычленять это все среди рекомендаций непросто.
Он, кстати, будет работать значительно медленнее, если в проекте много вложенных веток препроцессора. Они обычно плодятся как раз в процессе отладки, а в более-менее финальной версии режутся. Поэтому если проверять чужие проекты — да, будет быстро. Если свои в самом разгаре рабочего процесса — быстро не получится. Можно, конечно, поотсекать отладочные ветки через -U, но это надо постоянно перенастраивать анализатор под проект. Да и не факт, что отладочные ветки не нуждаются в анализе.
Это не работает. Именованные параметры есть и в питоне, и в шарпе, и вообще много где. Но если их можно опускать, их будут опускать.
В Objective-C это в общем-то не именованные параметры (функции там сишные, в Си такой фичи нет), а часть синтаксиса сообщений. Обязательная, естественно. Имена невозможно опустить, поэтому приходится их продумывать. В итоге средний код на Objective-C читается прекрасно с минимальной подготовкой читающего. Огромное влияние на популярность языка оказывает то, что я могу за секунды нагуглить пример, понять его и переделать под свои нужды. Двадцать первый век же, никто не читает документацию. А так код сам себя документирует достаточно успешно.
Для С++, кстати, есть Cocos-2dx. Но он откровенно отстает от оригинала.
По-моему, тут нужны принициально новые знаки препинания, правила переносов, пробелов и междустрочных интервалов.
Было бы еще интересно увидеть цифры какого-нибудь исследования. Мол, у такой-то группы читалось столько-то слов в минуту, после какого-то времени тренирововок стало читаться столько-то.
то и
тоже не получится.
С одной стороны, комментарии — зло, хотя и зло разной степени необходимости. Я сейчас сталкиваюсь с проблемой, что даже в экстремуме: устаревший ассемблерный код, тонны его, — комментарии помогают и путают примерно одинаково. Нет абсолютно никакой гарантии, что в коде слева от комментария происходит именно то, что в нем написано. Все критичное приходится проверять и перепроверять в коде. Комментарии сильно помогают в том, чтобы понять общую суть, помогают ориентироваться в тексте программы, помогают быстро пролистать много страниц по диагонали. Но в деталях на них полагаться нельзя, а детали как раз и важны в первую очередь.
Проблема в том, что есть множество инструментов для валидации и верификации кода. Есть статические и динамические анализаторы, есть профайлеры и отладчики, есть модульное, интеграционное, регрессионное тестирование. А вот комментарии верифицировать можно только вручную и только через ревью.
Можно, конечно, формализировать ревью. Взять, к примеру, методику Фагана, она правда тоже для кода, а не комментариев. Но она требует участия минимум трех участников на протяжении часа-полутора и позволяет инспектировать 200-300 строк за сессию. Это очень долго, дорого и никогда не применяется для комментариев. Вообще никогда. А вот документация, например, там где надо, в рамках формальной процедуры верифицируется.
И конечно же прозрачный идеоматичный код с говорящими именами и легкочитаемыми конструкциями лучше, чем грязный код с комментариями. И все-таки двадцать первый век на дворе, на современных языках можно писать много выразительнее, чем на алголе и ассемблере. И да, внезапный комментарий действительно говорит о том, что с кодом что-то не так.
Но с другой стороны, с кодом всегда что-то не так. Такая уж природа ПО. Считается, что хороший софт имеет плотность дефектов менее одного на тысячу строк кода. То есть даже при самых жестких V&V процедурах, никто и не ожидает, что программа будет безошибочной. Всего лишь дефектной в рамках дозволенного. Даже если процедура утверждает, что дефектов нет, это означает только то, что они не были найдены в рамках конкретной процедуры. Нулевая плотность дефектов — это не гарантия, а обещание.
Поэтому если кто-то думает, что может делать свой код лучше принципиально не пользуясь комментариями, это самообман. Код костыли содержит всегда, и лучше их явно обозначать комментариями, чем умалчивать.
Но и если кто-то думает, что может сделать свой код лучше комментируя все подряд без очевидной необходимости, это тоже самообман. Поддержка комментариев стократно сложнее поддержки кода, а внимания ей уделяется несравнимо меньше.
J страдает не из-за плохой нотации, а из-за неподходящих средств ее выражения. Нотация хорошая. Но для того, чтобы читать J, надо не просто знать нотацию, а еще и то, как он ложится на ASCII. Это двойной барьер для восприятия, да. Хотя и преодолимый.
И вот меня все не покидает одна забавная конфабуляция: APL на планшетах. Символы можно рисовать пальцем, например, можно выбирать на нарисованной клавиатуре. Хранить код в уникоде вообще не проблема. Краткость в условиях небольшого экрана — огромный плюс. Мне почему-то кажется, что для обработки каких-нибудь данных в полевых условиях это все было бы полезно и интересно.
Но почему-то J под андройд есть, а APL нет.
Обратное верно. Программированию стоит учиться, чтобы научиться думать больше и лучше.
Например, лисп, пролог, смолтолк и D несут в себе заряды идей, которые меняют во многом сам образ мышления. Пролог ломает голову декларативностью, лисп — макросами, смолтолк — объектами и интерфейсами, D — статическим метапрограммированием. Поломанная голова срастается и становится крепче, чем была когда-либо до этого. Суть такого обучения понятна и очевидна.
Фортран же, равно как и питон и даже С++ — языки практические и потому неинтересные. Они во многом впитывают чужие идеи, подстраивая их под свой синтаксис и свою инфраструктуру. Плюсы, например, имеют и объекты, и метапрограммирование, и функции как объекты первого рода, но все это намного больше похоже на эмуляцию, чем реализацию. Как говорил Алан Кей: «Я придумал термин „объектно-ориентированный“, и я уверяю вас, что не имел в виду C++».
Поэтому может Фортран и годится в качестве первого языка, но разве что первого. С дидактической точки зрения он не так уж ценен.
Потому что офисное пространство и предназначается для работы. Сделать его раем — работа работодателя.
И да, личное общение очень важно. Нам, интровертам, приятно думать, что это не так, но это так. Одно совещание вживую способно решить проблему, которую можно в тимспике обсасывать месяц, а электропочтой футболить от полугода до вечности. Простой разговор с разработчиком проясняет проблему в разы лучше, чем любой чат или голос. Просто потому что когда я пришел ногами, я вроде как гость и живой человек, с которым можно пообщаться. А если я — телефонный звонок, то я отвлекающий фактор, который надо устранить.
Меня все время, что я работал удаленно, не покидало чувство, что я в танке заряжающий. Вроде как что-то происходит, кто-то побеждает, а я только снаряды забрасываю и гадаю на копоти: нас, или мы? Чтобы притупить это чувство пришлось съездить в Киев, поймать там лида, чтобы он мне за полчаса нарисовал на бумажках, что вообще происходит. Этот разговор оказался полезнее, чем вся проектная документация.
Книжечка, кстати, страниц тридцать со всеми формальностями.
А если книга плохая, то ее издавать и вовсе не стоит.