Плюсую аналогично опирались на метрики:
Количество замечаний на ревью на число строк кода/патча, количество найденых багов на число строк.
В итоге оценка давала основания более пристально посмотреть на ревью, было ли оно на самом деле или чисто формально поставили «ревью ОК», позволяла оценить качество. Примерно позволяла оценить качество QA (извините за каламбур)
Метрика была примерно 1 критическое замечание на каждые 80 строк кода, и затем один критический баг на каждую тысячу строк. Отклонения от этих цифр конечно возможны допустимы. Они просто дают повод взглянуть на ситуацию и определить причину отклонения. Толи слишком плохо тестили, то ли промахнулись с оценкой сроков, то ли затянули разработку, а может имеет смысл повысить разработчика :)
Я бы даже сказал чем Катастрофичнее выглядит баг, тем тупее ошибка.
Самый фееричный баг который я фиксил приводил к глухому зависанию и затем ребуту телефона в некоторых случаях и зывался поставленной точкой с запятой после пары десятков пробелов на строке вместе с for :)
У всех разные отношения и понимание что есть Code Review :) Ктото считает что это когда второй Гуру говорит «То что ты написал это лажа и надо было написать вот так» Причем так как он гуру то первый должен обязательно следовать его советам.
К сожалению.
Использовать можно что угодно для чего угодно, надо только понимать что делаешь и какие это будет иметь последствия.
Понятно что про потоки стандарт ничего не будет упоминать, это все таки к языку отношения не имеет.
Я просто вел речь про более простые и наверно чаще всего сталкивающиеся с этим примеры.
Сначала ничего не знают про мутексы и работают с тупыми флагами — все глючит, лечат sleep-ами.
Потом узнают про всякие мутексы — радуются используют мутексы и убирают слипы — все начинает тормозить
Далее начинают понимать что есть гонка и опять возвращаются к глобальным переменным, но уже юзают их «локально» заинкапсулировав до безобразия — программа в дебаге и в релизе начинает работать по разному, причем в релизе «то работает то нет»
Ну и следующие шаги просвящения — volatile ну и высшая ступень — барьеры…
Но в целом один из Великих сказал: «Я понимаю, что я ничего не понимаю» так что чем лучше знаешь Си (да и Си-кресты) тем меньше ставишь себе самооценку. Ибо знаешь уже столько партизан в этом лесу, что начинаешь предполагать сколько их еще там прячется.
А про джуниора. Ну вот я нутром чую что не стоит передавать по указателю два адреса. И использовать long* и int* одновременно и использовать два разных типа там где достаточно одного
А volatile частично отключает оптимизацию — запрещает оптимизировать блоки использующие переменную так она может изменяться из нескольких потоков…
Например оптимизатор может выкинуть блок цикла заменив условие цикла на if если увидит что внутри него счетчик цикла не меняется. volatile запрещает это делать.
Если я правильно помню еще отключается кеширование значения переменной и вынуждает каждый раз читать его.
а как связана проблема strict aliasing и собственно си? Сначала увидели возможности оптимизации, заюзали ее, потом бац увидали косячок… ну значит придумаем правило для оптимизации. Кому то очевидно кому то нет.
Так можно гораздо более жизненные примеры привести с не volatile флагом и циклом ожидания его в соседнем потоке
я про пример 5 речь с 2 Gb вел. Но с трудом представляю как можно считать 2Gb матрицы не представляя диапазон интов. Тут просто вопрос кому доверили такое писать.
ну а типовые грабли на то и типовые, что опытный программер на них уже наступил.
Странно, почему нету баянчика с бесконечным циклом при увеличении float на 1
Это глупости программерские. Работал 2,5 года с индусами и японцами. И тоже видел много разного кода из реальных программ. Если програмер не понимает чего он делает, то он хреновый программер.
Если мои попробуют в проекте написать что то подобное 3, или им по архитектуре понадобиться strlen для 2Gb строки (или просто списки число которых не поместятся в 2G и они по ним будут циклами бегать), или написать чтото подобное 6 — получат «Review Failed» по рукам, и я даже разбираться не буду че там defined, а что undefined.
Если код такой что требуются знания тонких материй чтобы понять как он работает (исключая случаи вырожденной оптимизации) — то это говнокод, и совершенно не важно какой там использовался язык.
Не умаляю ваших заслуг, но так поиграть мышцами перед очередным кандидатом на собеседовании — годиться. Ну а реальность она на то и реальность. И быстро пофикшенное, косяком не считается :).
нет не отличается.
Подойдем с другого конца переменную локальную можно только определить.
Глобальную переменную тоже можно определить (точнее нужно и только 1 раз), но кроме того ее можно и декларировать, те намекнуть компилятору что будет где то далее она определена.
Только и всего. Проблемы начинают возникать когда программеры начинают про это забывть и думать что объявление и определение это одно и тоже
да не это просто дело привычки. Иногда смотришь в код — не понимаешь что же тебе в нем не нравиться но пятой точкой чуешь что где то подвох.
Ну и потом это таки низкоуровневый язык и чето я не припомню там много всяких «undefined» приведеные выше из разряда «не надо так делать, а если уж сделали ...».
Ну например ТС с лукавил в примере №2. Т.е. прога падать при разыменовании нуля не должна, но при этом оптимизатор таки должен был вынести блок if :).
Знатокам железа: «я не знаю архитектуру PC»: Пример №1: в DVI порт втыкаем пъезозажигалку и нажимаем кнопку: сгорит память на видюхе? или только проц?
Да ладно тебе. Автор привел примеры «как не надо писать код», не спорю некоторые могут появиться в виду неопытности или не знания особенностей языка. А уж специфика оптимизаторов эт вообще к языку отношения никакого не имеет.
Боюсь если я сейчас сяду писать на питоне, то тоже нагорожу огорода и тоже будут примеры «как не надо писать на питоне»
Да объявлений глобальных может быть сколько угодно в месте объявления не выполняется никаких операций с памятью (собственно и места то никакого нет). (это если в одном модуле, если в разных то следует добавлять extern )
А вот в случае локального объявления (даже без инициализации) требуется выделить место на стеке и тут уже «бяда-бяда огорчение» ему что 2 раза там место выделять? вот и ругается.
Количество замечаний на ревью на число строк кода/патча, количество найденых багов на число строк.
В итоге оценка давала основания более пристально посмотреть на ревью, было ли оно на самом деле или чисто формально поставили «ревью ОК», позволяла оценить качество. Примерно позволяла оценить качество QA (извините за каламбур)
Метрика была примерно 1 критическое замечание на каждые 80 строк кода, и затем один критический баг на каждую тысячу строк. Отклонения от этих цифр конечно возможны допустимы. Они просто дают повод взглянуть на ситуацию и определить причину отклонения. Толи слишком плохо тестили, то ли промахнулись с оценкой сроков, то ли затянули разработку, а может имеет смысл повысить разработчика :)
Самый фееричный баг который я фиксил приводил к глухому зависанию и затем ребуту телефона в некоторых случаях и зывался поставленной точкой с запятой после пары десятков пробелов на строке вместе с for :)
К сожалению.
Понятно что про потоки стандарт ничего не будет упоминать, это все таки к языку отношения не имеет.
Я просто вел речь про более простые и наверно чаще всего сталкивающиеся с этим примеры.
Сначала ничего не знают про мутексы и работают с тупыми флагами — все глючит, лечат sleep-ами.
Потом узнают про всякие мутексы — радуются используют мутексы и убирают слипы — все начинает тормозить
Далее начинают понимать что есть гонка и опять возвращаются к глобальным переменным, но уже юзают их «локально» заинкапсулировав до безобразия — программа в дебаге и в релизе начинает работать по разному, причем в релизе «то работает то нет»
Ну и следующие шаги просвящения — volatile ну и высшая ступень — барьеры…
Но в целом один из Великих сказал: «Я понимаю, что я ничего не понимаю» так что чем лучше знаешь Си (да и Си-кресты) тем меньше ставишь себе самооценку. Ибо знаешь уже столько партизан в этом лесу, что начинаешь предполагать сколько их еще там прячется.
А volatile частично отключает оптимизацию — запрещает оптимизировать блоки использующие переменную так она может изменяться из нескольких потоков…
Например оптимизатор может выкинуть блок цикла заменив условие цикла на if если увидит что внутри него счетчик цикла не меняется. volatile запрещает это делать.
Если я правильно помню еще отключается кеширование значения переменной и вынуждает каждый раз читать его.
habrahabr.ru/blogs/cpp/114117/ «Стандарт: N1124, 6.5(7)»
а как связана проблема strict aliasing и собственно си? Сначала увидели возможности оптимизации, заюзали ее, потом бац увидали косячок… ну значит придумаем правило для оптимизации. Кому то очевидно кому то нет.
Так можно гораздо более жизненные примеры привести с не volatile флагом и циклом ожидания его в соседнем потоке
ну а типовые грабли на то и типовые, что опытный программер на них уже наступил.
Странно, почему нету баянчика с бесконечным циклом при увеличении float на 1
Тогда этим всем надо посидеть еще в junior-coderах и почитать книжки.
Если мои попробуют в проекте написать что то подобное 3, или им по архитектуре понадобиться strlen для 2Gb строки (или просто списки число которых не поместятся в 2G и они по ним будут циклами бегать), или написать чтото подобное 6 — получат «Review Failed» по рукам, и я даже разбираться не буду че там defined, а что undefined.
Если код такой что требуются знания тонких материй чтобы понять как он работает (исключая случаи вырожденной оптимизации) — то это говнокод, и совершенно не важно какой там использовался язык.
Не умаляю ваших заслуг, но так поиграть мышцами перед очередным кандидатом на собеседовании — годиться. Ну а реальность она на то и реальность. И быстро пофикшенное, косяком не считается :).
Подойдем с другого конца переменную локальную можно только определить.
Глобальную переменную тоже можно определить (точнее нужно и только 1 раз), но кроме того ее можно и декларировать, те намекнуть компилятору что будет где то далее она определена.
Только и всего. Проблемы начинают возникать когда программеры начинают про это забывть и думать что объявление и определение это одно и тоже
Ну и потом это таки низкоуровневый язык и чето я не припомню там много всяких «undefined» приведеные выше из разряда «не надо так делать, а если уж сделали ...».
Ну например ТС с лукавил в примере №2. Т.е. прога падать при разыменовании нуля не должна, но при этом оптимизатор таки должен был вынести блок if :).
Знатокам железа: «я не знаю архитектуру PC»: Пример №1: в DVI порт втыкаем пъезозажигалку и нажимаем кнопку: сгорит память на видюхе? или только проц?
Боюсь если я сейчас сяду писать на питоне, то тоже нагорожу огорода и тоже будут примеры «как не надо писать на питоне»
А вот в случае локального объявления (даже без инициализации) требуется выделить место на стеке и тут уже «бяда-бяда огорчение» ему что 2 раза там место выделять? вот и ругается.