How to become an author
Search
Write a publication
Pull to refresh

Comments 33

У меня глупый вопрос — а сама VS (или тот компилятор, что используют авторы Хромиума) на:
  case PrimaryID::SMPTEST432_1:
    primary_id = gfx::ColorSpace::PrimaryID::SMPTEST432_1;
  case PrimaryID::EBU_3213_E:
    primary_id = gfx::ColorSpace::PrimaryID::INVALID;
    break;

не выдает варнинга типа: value assigned to primary_id never used…?
(я очень редко влезаю в C/CPP, поэтому сам не знаю)
This comment wasn’t rated yet0
Теперь выдаёт :)

Comment 1.
Add a FALLTHROUGH macro and get base/ to build with -Wimplicit-fallthrough.

Also fix a few missing breaks found by the warning in gpu/.
Total votes 1: ↑1 and ↓0+1
Не, я про саму Visual Studio (или я не так Вас понял?). Просто дельфятник в таком случае напишет подобное сам, т.к. в
primary_id = gfx::ColorSpace::PrimaryID::SMPTEST432_1;
значение присвоенное primary_id не используется — его сразу же переназначают.
Я это к тому, что, похоже, авторы Хромиума игнорируют варнинги компилятора.
PS: промахнулся с веткой :(
This comment wasn’t rated yet0
Компиляторы по умолчанию ничего не сообщают, так как отсутствие break это изначальная фишка языка. В двойном присваивании одной переменной тоже ничего особенного нет. Так очень часто пишут. Поэтому в диагностике V519, выявляющей повторное присваивание, есть множество различных исключений.

И я имел в виду, что раньше не использовался ключ, -Wimplicit-fallthrough (про него, кстати, говорится в статье). А теперь используется, что видно из общения в багтрекере разработчиков Chromium.

Двойные присваивания искать — дело совсем неблагодарное. Нужен умный инструмент, такой как PVS-Studio, чтобы снижать шум.
Total votes 1: ↑1 and ↓0+1
ооо мои глаза… никакие ревью от таких ошибок не защитят 8(
Total votes 6: ↑6 and ↓0+6
Любой язык программирования и его возможности — это всего лишь инструмент. Его неправильное использование (сознательно или в силу отсутствия опыта или знаний) — проблема того кто использует, а не проблема языка.

Эдак можно дойти до утверждения в духе «молотки сделаны неправильно — ими можно ударить по пальцу или убить кого-нибудь».

Именно по этой причине в мире «железных» вещей существуют правила, инструкции и техника безопасности, а при необходимости — те, кто следит за их исполнением, и которые наказывают нарушителей.

Мне кажется более логичным не ограничивать языки, а совершенствовать тех, кто их испольузет — прямо (обучение + опыт) или косвенно (статический + динамический анализы).

PS: Если бы у средств типа PVS-Studio была более либеральная ценовая политика, вероятно, это сильно бы улучшило качество кода и уменьшило количество ошибок для массы программистов. Большинство разработчиков, особенно в open source, не могут себе позволить платить $60/мес, в то время как действительно опытные разработчики в таких средствах не нуждаются вовсе.
Total votes 10: ↑1 and ↓9-8
действительно опытные разработчики в таких средствах не нуждаются вовсе.

Спорно. Даже самый опытный гуру может отвлечься/задуматься не о том/опечататься и т.д. и в результате получить в коде какую-то дичь. И далеко не всегда эта дичь вылезет сразу. Может оставаться в коде месяцами и годами.

Total votes 8: ↑8 and ↓0+8
Если этот гуру в единственном экземпляре — да. Если их несколько — то review кода уставшего/неспавшего гуру тем кто уже успел отдохнуть решает проблему, как правило. Главным условием является то что все гуру заняты одним проектом.
Total votes 8: ↑0 and ↓8-8

"Никогда не посылай человека туда, куда можно послать пулю" © Джеймс Бонд.
Зачем тратить время гуру на то, что можно проверить автоматически?

Total votes 6: ↑6 and ↓0+6
Пока автоматика не настолько совершенна, а ложное чувство что она увидит всё приводит к более серьезным проблемам (автопилот теслы тому пример).

В частности, логику проекта и его архитектуру проверить автоматически невозможно, то есть — отсутствие сообщений анализатора не говорит о том что ошибок нет, так что рано списывать гуру и заботится о его времени.
Total votes 5: ↑0 and ↓5-5

Вот в том-то и дело, что "рано списывать гуру". У него очень много дел, и не стоит загружать его ерундой.


Вообще сколько лет пишу на C и C++ — столько с тоской вспоминаю Паскаль каждый раз, как мне надо написать switch-case. 95% всех случаев "fallthrough" покрывались банальным перечислением констант через запятую или прописыванием диапазонов.


Ну и, опять же, если вернуться к аналогии с молотками — вариант с [[fallthrough]] не мешает вам ковырять молотком в носу, а лишь спрашивает вас — "вы действительно хотите это сделать"?.. По моему, хорошо. А вариант с оператором fallthrough вместо break — требует явно указывать "здесь ковырять в носу", зато избавляет от необходимости писать break каждый раз, как вам надо забить гвоздь.

Total votes 6: ↑6 and ↓0+6
Руководствуясь приведённой логикой, не следует развивать Spelling & Grammar чекер в Microsoft Office, лучше учить детей в школе языку. Лучше? Лучше. И что дальше?

В общем, подобные рассуждения не имеют практического смысла. Только наша команда нашла в Open Source проектах уже 13483 ошибки. Причём у нас никогда не было цели найти как можно больше ошибок и это просто побочны продукт процесса написания статей. Думаю, общее количество ошибок, которые исправлены благодаря нашему инструменту, исчисляется сотнями тысяч. Можно рассуждать теоретически о том, как сделать мир лучше и как сделать, чтобы программисты не ошибались. Но вот только всё равно они ошибаются и найденные нами ошибки это подтверждают. Поэтому использование PVS-Studio это практический шаг по улучшению качества и надёжности кода. А философию мы оставляем философам :)

Большинство разработчиков, особенно в open source, не могут себе позволить платить $60/мес, в то время как действительно опытные разработчики в таких средствах не нуждаются вовсе.
Как раз всё наоборот. Многим разработчикам open source приложений в инструментах статического анализа не нуждаются. В маленьких проектах низкая плотность ошибок и нет старого унаследованного кода, который никто не знает. Ну или на крайний случай можно воспользоваться бесплатным вариантом PVS-Studio. Зато этот инструмент нужен и полезен профессиональным разработчикам и компания может позволить им его купить.
Total votes 6: ↑6 and ↓0+6
Руководствуясь приведённой логикой, не следует развивать Spelling & Grammar чекер в Microsoft Office, лучше учить детей в школе языку. Лучше? Лучше. И что дальше?

Я этого не говорил. Если применить вашу логику к данной аналогии — то нужно запретить Microsoft Office писать в документах слова с ошибками (ну или сохранять их) — а это уже зверство. Предупредить, направить — да, но последнее слово должно оставаться за автором.

Spelling / Grammar checker как раз нужны — ибо они помогают совершенствоваться.

Поэтому использование PVS-Studio это практический шаг по улучшению качества и надёжности кода.

Простите, но именно это я и сказал — если вы внимательно вчитаетесь :) Я просто против «внедрения» правил в сами языки (особенно если их нельзя обойти).

Зато этот инструмент нужен и полезен профессиональным разработчикам и компания может позволить им его купить.

Не все работают на компании, и не все зарабатывают кодом — но как раз именно они и «производят» больше всего ошибок.

Именно это и является большой проблемой, на мой взгляд — непрофессионалы пишут что-то полезное (и оно даже работает), но делают это «как умеют», т.е. с типичными проблемами, потом другие (уже включая профессионалов с небольшим опытом) копипастят их творения и множат проблемы. Иногда после разбора ответов на Stack Overflow волосы дыбом встают, но факт остается фактом — ответ который выполняет задачу принимается как «лучший», даже несмотря на наличие в нём потенциальных проблем, а дальше по спирали.

Но, поскольку эти самые непрофессионалы редко зарабатывают своим кодом, они вряд-ли подпишутся на такой тулз который стоит в общем-то, немало (даже весь комплект всего для разработчиков от JetBrains стоит дешевле, и он, кстати, включает в себя элементы статического анализа, а в Visual Studio это входит вообще даром — но не все могут им пользоваться).
Total votes 7: ↑0 and ↓7-7
Я просто против «внедрения» правил в сами языки (особенно если их нельзя обойти).

Языки программирования это одни сплошные правила, которые нельзя обойти. Вам всего лишь не нравится какое-то из них. Но даже если так, какое это имеет отношение к break и fallthrough? Это не ограничение, все возможности на месте, только теперь предотвращена очень распространенная ошибка.
Total votes 2: ↑2 and ↓0+2
Аналогия некорректная. Молотками пользуются не все. А вот конструкциями switch все. А убить — осознанное действие. Удар по пальцам сразу заметен и поведение корректируется, а вот забыть break — типичная ошибка и невнимательность, которая будет жить долго.
Total votes 2: ↑2 and ↓0+2
Я считаю аналогию корректной по одной простой причине — несмотря на то что многие отбили себе пальцы, и не менее многие знают что можно отбить себе пальцы, всё же отбивание пальцев искоренить не удаётся (причём достаточно тех, кто делает это не один раз), но в то же время те кто свято соблюдает правила ТБ, ничего себе не отбивают — и прошу заметить, это не требует модификации молотков. А убить можно и случайно — если размахнуться молотком в момент когда кто-то стоит на траектории замаха.

К тому же, я уверен что молотками пользуется гораздо больше людей чем тех кто пользуется switch :)
Total votes 2: ↑0 and ↓2-2
Речь не идет о запрете некой возможности.
Речь идет о том, что по ошибке решили, что чаще будет использоваться одна конструкция, но в итоге оказалось, что она и нужна редко и приводит к куче ошибок. Всё что надо — перевернуть ситуацию. Где вы тут запрет увидели — совершенно не понятно.
Total votes 3: ↑3 and ↓0+3
Любой язык программирования и его возможности — это всего лишь инструмент.

Согласен, однако инструменты для одних и тех же целей могут быть с разной степенью безопасности. Циркулярная пила, например, может быть без защитного кожуха, а может быть и с ним.


Моя личная позиция по этому поводу: если можно сделать язык безопаснее на уровне базовых концепций — это должно быть сделано.

Total votes 3: ↑3 and ↓0+3
Чувакам в хромимум пишет пулреквесты кто-нибудь по этим ошибкам? Или посабмитить в свободное время? (Это не к автору поста вопрос)
Total votes 2: ↑2 and ↓0+2

А где во втором примере ошибка? Или последовательность if без else для проверки одной и той же переменной — это тоже ошибка?

Total votes 3: ↑0 and ↓3-3
Судя по названию переменных, там может быть всё правильно. Но вот коммента в коде, о том что так и задумывалось не хватает
Total votes 3: ↑0 and ↓3-3

Как где? В случае GL_ALPHA8_EXT будут последовательно выполнены *a=8; *a=16; *a=32;, что не имеет смысла.


А где вы там if и else нашли?

Total votes 1: ↑1 and ↓0+1
If без else — это аналогия. Но тут больше вопрос, с чего вдруг при GL_ALPHA8_EXT будут выполняться другие кейсы, отличные от default?
Total votes 2: ↑0 and ↓2-2
Да, вы правы. В C и унаследованных от него языков используется аналог дерева, т.е. переход осуществляется по первому сработавщему условию. Остальные условия игнорируются, так как являются не частью кода, а точками входа в код.
Total votes 2: ↑0 and ↓2-2
Это таки интересные вбросы у вас или что? В данный момент я скорее озадачен.
Total votes 3: ↑3 and ↓0+3
Всё просто. Я попутал. Swich-case действительно работает так, что там ошибка, так как внутри оператора switch пишется код, выполнение которого прерывается оператором break. А метки case используются как точки входа в этот код.
This comment wasn’t rated yet0
Не упомянут ещё один вариант пометки — применявшийся для классического lint: /* FALLTHROUGH */ или /* FALLTHRU */. Во многих исходниках на C/C++ он используется до сих пор. Там принимается ещё десяток опций — проверка стиля printf, использование аргументов и т.п. К сожалению, новые анализаторы не используют эти директивы (не знаю ни одного), а lint не умеет C++ или C99, поэтому такие директивы в новом коде не пишут — но ещё полно старого.
Рекомендую определять их наравне с новыми средствами в духе этого C++17.
This comment wasn’t rated yet0
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr