Уголовный кодекс разработчика

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

Уголовный кодекс разработчика

Вот-вот. Буквально на днях сидел разбирался в коде passport-saml, функция SAML.prototype.validatePostResponse меня просто убила

Уголовный кодекс разработчика

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

Уголовный кодекс разработчика

Да с С конечно тяжело, но тоже есть варианты.
У вас там в switch часто повторяется последовательность действий

read_vint_block_skip(file);
MATROSKA_SWITCH_BREAK(code, code_len);

и еще несколько

их можно в функции,
а коды в массив

double someCodes1[] = {MATROSKA_SEGMENT_TRACK_FLAG_LACING, MATROSKA_SEGMENT_TRACK_FLAG_FORCED, ...};

+ функция isCodeInArray

получится что-то типа

if (isCodeInArray(code, someCodes1))
yourFunc

if (isCodeInArray(code, someCodes2))
yourFunc2

я думаю размер функций уменьшится в несколько раз
P.S. в С не силен

Уголовный кодекс разработчика

Для методов «делаем раз, делаем два» — уже то же написали несколько «если» другие комментаторы. Я могу добавить ещё. Дробление сложного метода на много коротких повышает понимание, ЧТО делает метод. Но к сожалению, часто уменьшается понимание КАК он это делает. В особенности, если итоговая вложенность методов сильно больше двух.

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

Уголовный кодекс разработчика

Есть ли смысл в погоне за снижением цикломатической сложности нарезать оставшиеся 2 тыс. на мелкие кусочки, если заведомо известно, что они в качестве самостоятельных единиц точно больше нигде и ни для чего не понадобятся? От слова «никогда»?

Тестирование, подумайте, насколько легче тестировать эти самые разрозненные кусочки, в отличие от монолита.

Уголовный кодекс разработчика

По 4-му, вам приятно читать функцию по 3 страницы? Что понятнее прочитать:

function (){
//1-ая страница кода
//2-ая страница кода
//3-я страница кода
}

или

function (){
делаемРаз();
делаемДва();
делаемТри();
}

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

Уголовный кодекс разработчика

Насчет комментариев это да. Изучая VueJs доставляли комментарии на китайском =)

Уголовный кодекс разработчика

В принципе по всем четырем пунктам можно придумать автоматизацию, которая будет перед комитом предупреждать разработчика.

Я отказался от кофе, и вот что произошло

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

Я отказался от кофе, и вот что произошло

Помимо дозы, я бы еще добавил про привычку. Если человек не может вставать каждый день без кофе (причем спал он вроде бы нормально), то это проблема, человек должен вставать нормально без стимуляторов, если не получается, то надо подумать о своем образе жизни. Если человек выпивает раз в неделю-две, например когда задерживается его самолет ночью в аэропорту, то почему бы и нет.

Использование выражений для фильтрации данных из БД

Ваш пример не показывает выгоды вашего решения, вместо 2-х функций написали 3.

Я работаю в ТехЦентре Дойче Банка

Чисто теоретически, если писать свой easing для UI, может понадобиться и вторая производная )))

Я работаю в ТехЦентре Дойче Банка

Каюсь, вопрос был с небольшим троллингом, намекающим на то, что в больших компаниях конечный разработчик очень далеко от конечных денег.

Я работаю в ТехЦентре Дойче Банка

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

Сколько досталось сотруднику в виде премии от неприличной суммы? или только гордость и почитание?

Что-то не то с тестированием в .NET (Java и т.д.)

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

Что-то не то с тестированием в .NET (Java и т.д.)

У вас DbContext должен инжектиться, а не репозиторий. При таком подходе и репозиторий можно протестить. Неправильная архитектура. Если используете EF для мока Db подойдет InMemoryDb.

ASP.NET Core: Создание первого веб-API с использованием ASP.NET Core MVC и Visual Studio

Как уже тут написали — Middleware, достаточно подробно описано в официальной документации

ASP.NET Core: Создание первого веб-API с использованием ASP.NET Core MVC и Visual Studio

Почему все последние примеры по ASP.NET core идут с IRepository? У нас же уже есть DbContext и DbSet?
Например:

public  class ToDoContext:DbContext
{
        public ToDoContext(DbContextOptions options):base(options){}

        public DbSet<ToDoItem> Todos { get; set; }
}

И все.
Там где вы не хотите работать с физической базой данных (например в тестах) вы создаете контекст с dbContextOptions.UseInMemoryDatabase, а если в проде Postgres, то вот так:

services.AddDbContext< ToDoContext >(options => options.UseNpgsql(settings.Data.ConnectionString));  

CMYK алгоритм поиска замкнутого контура на двумерной матрице

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