Хороший код и говнокод

Можно, можно я?!

Концептуально это выглядело как asio в одном потоке вперемешку с win32api(оконная подсистема и directx) прямо в одной функции(в десятке если быть честным). Этот код за пару месяцев набросал грамотный товарищь, и он давал на одном ядре(во времена четвёртых пней было написанно и ht было изыском) возможность смотреть видео снимаемое IP камерой онлайн, применять различные геометрические трансформации к этому видео в режиме «реального времени» и давал время на отрисовку всей остальной винды и приложения при загрузке процессора не более чем на 80%.

После того, как код перевели на многопоток и сделали удобочитаемым - на одном ядре, тем более 4ого пня это всё лагало совершенно безбожно, хотя оптимизировать пробовали долго.

Ага, забыл, в этом коде было куча магических чисел, в принципе они были связанны с квантом cpu под win32, размером буфера сокета и размерами видеопамяти трендовых видеокарт.

вам и карты в руки.

И зачем это мне?

про конечный автомат даже смотреть не буду. последний конечный автомат я в коде видел… лет 15 назад.

Т.е. вам не нужно, значит никому не нужно? Отличненько.

Если вам реально интересен именно мой опыт, то пожалуйста (часть ссылок на Хабр):

Достраиваем в RESTinio четвертый этаж из C++ных шаблонов. Зачем и как?

Немного C++ной шаблонной магии и CRTP для контроля за корректностью действий программиста в компайл-тайм

Задействовать для простых тестов наследование, полиморфизм и шаблоны? Почему бы и нет…

Пример использования policy-based design в С++ вместо копипасты и создания ООП-шых иерархий

Ну и вот здесь еще разное: https://eao197.blogspot.com/search?q=%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD%D1%8B+%D0%BF%D1%80%D0%BE%D1%82%D0%B8%D0%B2+%D0%BA%D0%BE%D0%BF%D0%B8%D0%BF%D0%B0%D1%81%D1%82%D1%8B

И да, я как раз из тех, кто рассказывает про трюки на конференциях по C++. Так что в мой код лучше не заголядывать, там нет ничего хорошего, кроме того, что обычно он таки работает.

Попечатал недавно python и c++ код на тренажёре слепой печати - интересное ощущение. На python код очень сильно более похож на plain text. Общие принципы они везде общие: например не сри там где кушаешь работает и в кодовой базе и на киче.

… а также смотри https://github.com/bkaradzic

Много полезного …

Владимир

После того, как код перевели на многопоток и сделали удобочитаемым - на одном ядре, тем более 4ого пня это всё лагало совершенно безбожно, хотя оптимизировать пробовали долго.

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

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

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

И да, я как раз из тех, кто рассказывает про трюки на конференциях по C++.

А насколько грязным трюком считается макрос в плюсах? Сложный такой макрос.

Вердикт скорее, что сделав чистый код, получили очень жёсткое пенальти к нефункциональным требованиям. Но в тот момент когда был проведён рефакторинг - на самой бедной типовой конфигурации всё летало, а на четвёртом с ht запущенно было скорее смеху для(и в основном смеху над рантаймом пинды).

нубвопрос - что такое нефункциональные требования?

gamedev Вот это зря добавил. Весь геймдев – кладезь говнокода.

Есть два типа активностей:

• рутина
• созидание

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

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

Довольно кайфовое ощущение когда писал что-то пару часов, потом ещё минут 15 потратил на то, что бы оно скомпилялось, запустилось и прошло тесты. Особенно кайфовы моменты, когда 15 минут тратить не пришлось, максимум пара помарок. Рекомендую.

Довольно кайфовое ощущение когда писал что-то пару часов.

На нашей полянке свои особенности, в частности про TDD только слышал каждый третий в лучшем случае, а что бы пользоваться… Поэтому иногда бывает что пишешь что то жутко заморочное несколько дней, потом компиляешь и оно с первого запуска работает. В такие моменты я себя боюсь, и это похоже общая реакция - аспирантка давеча тоже жаловалась на схожие ощущения;-)

Есть корректность работы алгоритма - это функциональные требовния. Типа «чего эта штука должна делать». Т.е. требования из «бизнесс» части.

Нефункциональные требования это те требования которые напрямую не относятся к корректности результата. Типа «насколько быстро эта штука должна работать или как мало памяти потреблять».

Бизнесс требования в первой части я взял в кавычки, т.к. когда есть нетривиальные нефункциональные требования, это обычно тоже бизнесс требования, просто нефункциональные.

Т.е. требования к игрушкам ‘i37xx nvidia gtx-чет там’ == ‘60fps на uhd’ это нефункциональные требования для примера.

Последнее время - я перехожу на голосовой ввод и отладку по skype.

Это как? То есть я такое могу представить, я иногда аспирантов в качестве терминала так использовал, но не для кодинга все таки…

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

Последнее время - я перехожу на голосовой ввод и отладку по skype.

тут поподробнее. я меня своя ide, могу в принципе любой ввод привернуть. а вы как вводите голосом? ежли линукс убунту..ставить там голосовой ввод?, который я выкинул нафиг. какие ощушения от голосового?

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

В плане ощущений - удобно, но не точно и долго.

А, воно оно как… дык я значит тоже в тренде!;-)

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

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

короче обман. там еще нужен искусственный интеллект посредине.

Я такой лифт с голосовым управлением еще двадцать с гаком лет на стройке видел. Подходишь к дверям, прижимаешься ротом и орешь со всей дури ДВЕНАДЦАТЫЙ. Через пару минут двери открываются, лифт приехал, а там бабка с газеткой на стуле сидит.

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

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

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

Зачем искусственный? Мы, за натур продукт!

Я такой лифт с голосовым управлением еще двадцать с гаком лет на стройке видел. Подходишь к дверям, прижимаешься ротом и орешь со всей дури ДВЕНАДЦАТЫЙ. Через пару минут двери открываются, лифт приехал, а там бабка с газеткой на стуле сидит.

ну щас время то другое. может уже хоть до десятого довезет. но идея интересная, буду думать

Особенно страшно - когда и тесты скомпилились, и код. Думаешь такой, блин, ну это примерный набросок был, ну хоть так… А потом ещё и all tests passed. В такие моменты очень сильно разыгрывается паранойя. Этим особенно плох python, т.к. там два этапа компиляции теряются и если после сохранения не пускать тесты, то вообще такие моменты с одной стороны тешат чсв, с другой думаешь не хернёй ли ты занимаешься или не подогнал ли ты где-то что-то к чему-то.

последний конечный автомат я в коде видел… лет 15 назад. причем примененный явно не к месту.

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

Тесты… вот за 20+ лет работы я второй раз в жизни задумался - а не пописать ли мне юнит-тестов в новом проекте?

У нас код чиселок накидал, ты из них график построил - а он с другим графиком совпадает! Полчаса бегаешь по потолку а потом лезешь гуглить список нобелевских премий;-)

Два блюдца молочка этому котегу, 99% современных систем чуть менее чем полностью состоят из этих автоматов или их частных случаев.

Имхо, хорошие тесты как раз для таких случаев. Чем меньше сайд эффектов, тем чище тесты. Но, для научного кода для которого есть спека - сценарии уже записаны в виде ОДЗ в спеке, надо небольшой ряд плохих случаев обычно обнаружить и связанны они в основном с вводом выводом. По моему опыту люди науки таким крайне редко заморачиваются достаточно серьёзно.

Однако, TDD и прочие DD предназначены более для крупных систем. Если алгоритм достаточно изолирован - то функциональных тестов уровня «графики сошлись» более чем достаточно. Однако, это про классический TDD уровня «написал тест, написал функцию, написал её реализацию». Если смотреть на это чуть более расслабленно - то TDD на функциональных тестах, это очень мощный инструмент, главное сначала подготовить окружение для тестировния, а потом писать реализацию, и тут даже shell/python скрипт который можно быстро запустить для проверки «всё в рамках модели» есть достаточный инструмент т.к. интерфейсных функций хорошо когда больше одной.

Тестировать под-функции - хорошее дело, но если жизненный цикл проекта не велик - деньги на ветер.

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

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

А насколько грязным трюком считается макрос в плюсах? Сложный такой макрос.

Временами без макросов не обойтись. Так что здесь все будет зависеть от уместности и чувства меры.

Есть еще определенные правила безопасности, например если тело макроса состоит из нескольких стейтментов, их надо завернуть в do { } while(0)

Есть еще определенные правила безопасности, например если тело макроса состоит из нескольких стейтментов, их надо завернуть в do { } while(0)

а просто в фигурные скобочки?

а просто в фигурные скобочки?

Тогда в вызывающем коде смогут забыть точку с запятой после вызова

if (something())
   MACRO(args) // <--
else
   doSomethingElse();

и будет некрасиво

if (something()) MACRO(args) // <–

будет же if() {…..} else … в чем проблема?

а просто в фигурные скобочки?

Вроде, для обхода проблемы с точкой с запятой в if (cond) MACRO(); else MACRO();.

Чтобы макрос выглядел и вызывался как нормальная функция.

Если просто фигурные скобки, то будет ругаться. Если do while(0) - то корректная конструкция.

Мне нужны были сэмплы качественного кода

Какие нахер сэмплы? Мы тебе тут что, клаберы - dj'и? Даже все советы выше могут быть уместны в одном случае и вообще никуда не всираться в другом. И речь еще даже не идёт про общую архитектуру проекта.

Так и решили: комментаторы хорошего (читабельного, не дублирующегося и написанного по правилам) кода не видели

Так-то тебе про это сразу сказали, да и правила устанавливает каждый себе сам.

Ладно, давай рассмотрим, например, код openxcom. Ну типа ок, работает, кошерно, реюзабильность и ооп во все поля, но он больше ни для чего особо не пригоден кроме как для openxcom движка. И местные сейчас еще пояснят, почему он говёный и где.
Можешь добавить туда dogfight, как в xenonatus, можешь приделать новый state с airstrike, но сделать чтобы в боях летело сразу несколько пуль - уже сложно.

Вот еще код openttd паровозиков. Адепты c-like скажут, что вот нормальный код, а адепты ооп будут блевать. По архитектуре не скажу, но вроде как без особых проблем вкорячили туда граф перевозок. Попробуй ради прикола поправить его так, чтобы работал как в simutrans (у которого, кстати, код довольно говёный) многое поймешь о разработке.

Однако, TDD и прочие DD предназначены более для крупных систем.

Самое крупное что я с коллегами писал это 15 тыс строк (на плюсах) + 4 тыс строк библиотека (правда у меня строки длинные). В три лица. Это я так понимаю по меркам обычной разработки ерунда? Обычно у нас проекты меньше и работает над ними 1-2 человека.

Я про TDD читаю с завистью, но блин - я вообще не представляю как это можно у нас внедрить. И еще нюанс, те кто пишут научный софт обычно не являются программистами. Нужно знать предметную область и численные методы, а на программирование что осталось то осталось. Да и навыки довольно специфические, скажем закодить и отладить несколько страниц формул а-ля арабская вязь…

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

Но регулярно возникает вопрос - кто напишет GUI для нашего замечательного софта? Заказчик дескать отказывается от CLI. Я обычно уворачиваюсь, это муторно и я это наверное такое плохо умею…

Измерять объём в строках кода - последнее дело. Вопрос скорее в сложности в плане изменения требований и продолжительности жизненного цикла ПО. Если ПО не меняется, то автоматизированные тесты ему особо и не нужны.

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

Тесты и TDD это как ни странно довольно слабо связанные вещи. Никто не мешает писать автоматизированные тесты после кода например.

TDD про то, что бы записать как ты будешь использовать это, до того как ты создал это. Т.е. всего лишь ещё один подход к проектированию сверху вниз. Сначала на каком-то удобном dsl накидываешь свои ожидания по соответствию входов и выходов, а потом педалишь реализацию до тех пор пока не совпало. По-факту обычно педалишь и реализацию и немножечко ещё тестов.

Насколько я знаю, большинство людей которые делают не gui рано или поздно, в той или иной мере начинают так делать, условно «мне надо сделать что бы файл А превратился в файл Б, возьму-ка я сразу А, и руками али ещё как запилю Б, и буду проверять а точно ли мой код А в Б превращает». Тесты просто позволяют сохранить артефакты от этого процесса.

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

Я бы подумал насчёт сотрудничества с настоящими QA.

Вот хороший (говно) код. Много кода. Тебе надолго хватит.

https://github.com/dotnet/runtime/blob/master/src/coreclr/src/gc/gc.cpp

Эталонный говнокод. В одном файле. Поделие некрософта. Теперь я видел всё :]

Скажем у нас за геттеры/сеттеры введённые без нужды бьют по пальцам

Это какой язык? Просто удивляет, что, например, в C# есть сокращённый синтаксис введения геттеров и сеттеров. Хотя, казалось бы, можно было бы обойтись обращением к параметру.

Тесты и TDD это как ни странно довольно слабо связанные вещи. Никто не мешает писать автоматизированные тесты после кода например.

Когда нибудь пробовал писать тесты для уже написанного (и работающего) кода, которого желательно не изменять (он же работает). Выглядит это так. Надо протестировать компонент A. Чтобы его создать, нужно проинициализировать компоненты B и C. А они тащат с собой половину всей системы. В результате тест получается говно. 90% теста это инициализация системы. Пора нанимать тестеров специально для этой работы.

В TDD всё наоборот. Надо написать компонент A. Сначала напишем тест, который покажет, как бы я хотел A использовать. В тесте я явно пол-системы загружать не хочу, поэтому напишу его так, чтобы A можно было создать с минимум затрат. После теста, я напишу реализацию A, которая будет ему удовлетворять.

Вот хороший (говно) код. Много кода. Тебе надолго хватит. https://github.com/dotnet/runtime/blob/master/src/coreclr/src/gc/gc.cpp

ничоси..скопировал его к себе в ide… там 39849 строк!

Хотя, казалось бы, можно было бы обойтись обращением к параметру.

Свойства позволяют изменять реализацию в будущем без слома api.

Если это безразлично, то конечно можно обращаться к параметру.

в режиме «реального времени»

Дык. Он явно пытался сделать это без кавычек, и что-то с чем-то синхронизировал.

перевели на многопоток и сделали удобочитаемым

Хипсторы, блин...

В принципе, то же верно для бидона, стоит посмотреть в сорцы какого-нибудь джанго. Битон красивый только на хелловорлдах

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

Хороший код и C++ это взаимоисключаемые параграфы

Конечно, нужно сравнивать код на C++ с кодом на C++.

Hazard pointers?

Hazard pointers - это вполне штатный инструмент, а не трюкачество, это «слабая блокировка» для снижения трений между потоками. Хотя, так-то весь lock-free многопоток - это сплошное трюкачество, и мало кто умеет его делать.

Нахрен ты оставляешь свои бессмысленные тексты? Или в тред с метапрогом и живи там.