💡 Идея: Весь код проекта в одном файле (Плагин для IDE)
Публичный постПроблема:
Я не хочу отвлекаться на абстракцию файловой системы, я хочу писать код.
Названия файлов HomePage.js и tasks.py не сильно отличаются от class HomePage или @task() def send_emails семантически, но все равно создают лишнюю нагрузку.
Почему, когда я хочу создать класс, мне нужно:
а) создать новый файл
б) придумать, как его назвать
в) выбрать папку, куда его положить
г) задуматься, какое у него должно быть расширение.
Пускай за меня думает машина?
Концепт:
Весь код лежит в одном большом полотне, где его можно скроллить туда сюда. "Под капотом" это все равно работа с файлами, просто они динамически приклеиваются при скролле.
Плюсы:
- Создание нового файла это просто нажать три раза на Enter. Если хочется явно указать, что это точно новый файл, есть разделитель типа
// # MARK - src/Home/FeedItem.jsx
- Вместо поиска нужного файла через дерево директорий можно просто делать Ctrl+F по полотну.
Почему же тогда раньше от этого отказались? Почему сейчас никто не пишет весь код в App.tsx?
Три главных возражения
- Если у тебя больше мелких файлов, то у тебя меньше проблем потом с конфликтами в git.
Да, именно поэтому умный шредер сам нарежет мое полотно на файлы. Я пока не знаю, как умно нарезать файлы по директориям, но как промежуточное решение, это можно указывать вручную специальными комментариями.
- Один большой файл с маркерами дает только линейную структуру, а для больших проектов нужна древовидная.
Это хороший аргумент, но это полотно не обязано быть статическим. Сразу три варианта решения:
- Выпадающие списки для каждой директории, как сейчас мы можем "сворачивать" методы, чтоб лучше видеть весь файл (никогда не видел, чтоб кто-то этим пользовался)
- Двумерный скролл – слева более глобальный вид: директории и названия классов, справа конкретный код
- Выбирать "галочками", какие файлы отображать в полотне в каждый момент
- Один большой файл будет дико тормозить.
Сейчас у нас эта вкладка с текстовым редактором тратит больше ресурсов, чем вся IDE 10 лет назад. Плавно скроллить 20 тысяч строк текста не такая уж сложная задача.
Примерно как Айфон, когда скроллит твиты, на самом деле не выводит все на экран, а незаметно подгружает новые, когда чувствует, что вы почти дошли до предела.
Референсы:
- В
Objective-Cтак было принято: из-за того, что один файл = один класс, а иногда в класс типаLoginViewControllerнужно было много чего напихать, там есть штука, которая позволяет быстро ориентироваться в полотне методов класса
// #MARK: - LoginDelegate implementation
- В Figma весь дизайн лежит на одном полотне. Это удобно по той же причине – можно быстро отойти в сторону и найти нужный кусок.
P.S.
Не знаю, возможно это только у меня такая проблема, но Мак про 2015 года с SSD открывает или сохраняет новые файлы секунд 5-10. Да и в целом, IDE типа Atom или VSCode какие-то не очень приятные, когда дело касается файлов. Может, мне просто нужен новый компьютер ))
😱 Комментарий удален его автором...
/dev/sda - тоже файл.
У вас какого размера был последний проект?
Вот есть у меня проект, в котором штук пять смысловых частей — работа с бд, с сетью, парсер протокола, еще что-нибудь. Если я работаю над одной частью, мне не надо видеть остальные — я хочу перемещаться в пределах одной части, и знать, что если промотаю наверх, или поищу "create", то увижу первую функцию модуля работы с бд, и функцию "create_tuple", а не "сreate_file".
А что мне делать в описанном подходе? Держать все в одном "файле"? Так неудобно. Разбивать на разные части? А чем это отличается от того, что у меня сейчас?
Я бы, на самом деле, предложил другое: возможность обьединять файлы в один виртуальный файл. Например, в си .h и .c файлы относятся к одному модулю, и их можно слить вместе в IDE, чтобы не переключаться между ними. Вверху заголовки, внизу функции, удобно. Сборка при этом не ломается, так как мы все так же храним два файла и заголовки прекрасно подключаются к чему угодно.
Странно видеть, что кто-то пишет комментарии здесь...
Несколько проблем:
Непонятно, что это реально приносит в воркфлоу.
Отнимает свободу выбора инструмента, если это в одном файле.
Не проще ли тогда сделать наоборот и -склеивать- в один файл для презентации тогда?
Я все думал в сторону и бд по типу neo4j или couchDB, и какой-то плоской структуры с тэгами в своё время. Увы, это почти никуда не интегрируется, и в этом главная проблема
В ряде ЯП файлы - это first type object и эрзац неймспейсов. Это тупо, но это факт и под это заточен даже не визуал, а сами технологии. Сука, оно реально собирается файликами. Так что такая история там просто не получится или будет вызывать кучу трудноуловимых ошибок.
Ну и про удобство уже выше все сказали, в реальности это неудобно.