мы ж технари

а не фанатики

На самом деле проще разбираться в лапше, чем в тысяче файлов. Даже структура с папками сильно не спасет. Для меня норма это 200-300 строчек в файле

надо понимать откуда у этих правил ноги растут

Да оттуда же — чтобы было легко читать и удалять

легко это все относительно

coupling & cohesion

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

и таких функци 100

то тебе не помогает их размер

или один модуль на 1000 строк, с единой точкой входа

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

Вынеси их наружу в общую обёртку

или один модуль на 1000 строк, с единой точкой входа

Разбей на куски

зачем лол?

В общем, даже если бы мне попался какой-нибудь код обьемом 800 строчек, но который весь работает с каким-нибудь http, например, я бы оставил в одном файле. Я даже не знаю как его разделить так, чтобы понятно было что в каком искать

Затем что у него есть логические куски, которые мало связаны между собой

И каждый раз когда ты что-то в нём правишь, это трогает только один такой кусок

А остальные тебе в этот момент не нужны и отвлекают

Затем что у него есть логические куски, которые мало связаны между собой

Если абстрагировать такие куски, то в проекте будет каша. Непонятно где что искать, очень тяжело читать и поддерживать

Ну тоже верно

Надо как всегда компромисс искать

Мне мелкие модули на 1 задачу очень удобны

Становится не нужным — удаляешь его и тест к нему

И всё

Весь рефакторинг

Странные у вас проекты ребята если 60 строк в файле

И 1 функция

Это не у нас, а у черепушки выше

Может это особый такой подход

Но в целом, по мне, адекватно когда до 300 строк, это с комментами

400 уже выглядит тяжеловато, больше - плохо

Это не у нас, а у черепушки выше

лил

Но в целом, по мне, адекватно когда до 300 строк, это с комментами

У меня нет комментариев

При этом 25% могут быть комменты

Без комментов - 200-300

При этом 25% могут быть комменты

но зачем?

Типизация

Описание всех параметров

Функций

Класса

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

И прочее

ничего себе вы там

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

Энтерпрайзненько

CMMetadataFormatDescriptionCreateWithMetadataFormatDescriptionAndMetadataSpecifications();

Люблю это

Java detected

Какие то рельсы

Такой нейминг говорит о том что нужно разрезать класс на несколько классав

ахах, у меня аж слеза накатала

Plain C

Ruby.createAppAndDeployItPSDontForgetToDoThis()

И там сразу нейминг становится в 2-3 слова

MultiHyperSerializatorr

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

Но может и другое - там цепочка действий исполняется

Тогда класс, да

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

Обычно если посмотреть на имена методов популярных Obj-C библиотек, там вот подобные методы

Тлен и боль

Впрочем, есть ещё 1 кейс

Самодокументирование

Вместо комментов - делать длиннющие имена методов

Которые явно указывают на то что происходит

Самодокументирование

Анти-паттерн

Есть люди что считают иначе

Не то чтобы я поддерживаю это

Есть люди что считают иначе

Самодокументировние - это способ уменьшить объем коммментов, с помощью правильно подобранных имен.

необязательно длиннющие, но не надо делать function f()

Анти-паттерн

почему анти-паттерн?

почему анти-паттерн?

все - анти-паттерн, если используется неправильно :)

это и про 60 строк на функцию, и про самодокументирование, и про tdd будет правильно

ThisisaFunctionThatReturnsColor = function() { return this.color; }

🌚

вот так и живем)))

)

Кто юзает #ternjs?

зачем в вебшторме ternjs?

Я ибу?

Я на атоме.

Я ибу?

нинад

Я на атоме.

ну он не нужен