GUI:
- персонажи..... ссылка
- фон.............. ссылка
Логика:
- ИИ................ ссылка
- сохранение.... ссылка
- диалоги......... ссылка
Приемлемое количество строк в файле с кодом
Сколько строк должно стать в вашем файле с кодом (модуле, исполнимом файле, хедере, скрипте), что бы вам в нём стало неуютно?
Предполагаю, что не очень длинные по тексту файлы повышают читаемость, но довольно часто приходится видеть длиннющие файлы. Особенно часто такое встречается в скриптах. Может есть какие-то доводы за то, что бы весь код располагался в одном файле?
Меня, например, после 150 строк начинает сильно мучить совесть... после ста начинается некоторое беспокойство. Хотя если бы файлы с кодом были не чисто текстовые, а поддерживали разделы, содержание с ссылками на разделы, то может было бы и не так страшно (хотя некоторые редакторы обеспечивают переход к функциям, классам, так что...). Ну и свёртка блоков наверное кого-то успокаивает.
Минусом в "длинных" файлах может быть ещё более длительное время на компиляцию, большая нагрузка на компьютер. Хотя и в этом случае специальный редактор (скорее даже IDE) мог бы помочь.
Предполагаю, что не очень длинные по тексту файлы повышают читаемость, но довольно часто приходится видеть длиннющие файлы. Особенно часто такое встречается в скриптах. Может есть какие-то доводы за то, что бы весь код располагался в одном файле?
Меня, например, после 150 строк начинает сильно мучить совесть... после ста начинается некоторое беспокойство. Хотя если бы файлы с кодом были не чисто текстовые, а поддерживали разделы, содержание с ссылками на разделы, то может было бы и не так страшно (хотя некоторые редакторы обеспечивают переход к функциям, классам, так что...). Ну и свёртка блоков наверное кого-то успокаивает.
Минусом в "длинных" файлах может быть ещё более длительное время на компиляцию, большая нагрузка на компьютер. Хотя и в этом случае специальный редактор (скорее даже IDE) мог бы помочь.
свёртка блоков меня, например, очень успокаивает :)
а вообще, на мой взгляд, 150...ну 200 строк - предел приятным ощущениям, потом начинает появляться [COLOR="Indigo"]то самое [/COLOR]чувство...
а насчет времени компиляции, разницу наверное [COLOR="DimGray"](сам не проверял)[/COLOR] можно почувствовать между 100 и 1000 строками, но не между 100 и 150..:)
а вообще, на мой взгляд, 150...ну 200 строк - предел приятным ощущениям, потом начинает появляться [COLOR="Indigo"]то самое [/COLOR]чувство...
а насчет времени компиляции, разницу наверное [COLOR="DimGray"](сам не проверял)[/COLOR] можно почувствовать между 100 и 1000 строками, но не между 100 и 150..:)
не знаю, меня объем не напрягает! если в файле код логически обособлен\структурирован, то не вижу особого резона заморачиваться. мне попадались асмовские листинги по тысячи строк в модуле, но в силу того, что код был структурирован(к примеру в одном файле находились 1200 строк кода работы с текстурами), документирован, грамотно оформлен, то как бэ это ни разу не напрягало. вот как то так!=)
а вообще не более 200 наверное, все зависит от конкретной ситуации...=)
а вообще не более 200 наверное, все зависит от конкретной ситуации...=)
Вот пример:
http://svn.berlios.de/svnroot/repos/codeblocks/setup/setup.nsi
тут всё структурировано, прокомментировано. Однако, меня такие файлы пугают. Не могу точно объяснить почему. Своей монолитностью что-ли. Вроде нормальное ПО должно быть как конструктор: вынул детальку, заменил на другую, автоматически протестировал и почти спокоен. А тут полчаса ищи эту детальку, потом вытащишь и оно всё рухнет...
http://svn.berlios.de/svnroot/repos/codeblocks/setup/setup.nsi
тут всё структурировано, прокомментировано. Однако, меня такие файлы пугают. Не могу точно объяснить почему. Своей монолитностью что-ли. Вроде нормальное ПО должно быть как конструктор: вынул детальку, заменил на другую, автоматически протестировал и почти спокоен. А тут полчаса ищи эту детальку, потом вытащишь и оно всё рухнет...
опять же все зависит от ситуации... если пишешь на асме и у тебя модуль в 1000 взаимосвязанных строк кода, то разносить глупо, бо будешь путаться в куче файлов. или если с++\с# класс, ну вот выходит он за 200 строк, ну и чего делать то? тут скорее всего вопрос не в эстетическом количестве кода в файле, а в грамотном проектировании, в грамотном распределении обязанностей между классами, дабы монстров не получалось, грамотное разбиение на модули(в случае структурного программирования), дабы в каждом файле располагалось логически обособленное\автономное количество кода... ну эт мое скромное мнение!=)
да если даже разбить (грамотно разбить) огромный код на множество классов/функций/etc, но они по структуре алгоритма будут тесно взаимосвязаны и необходимо будет постоянно крутиться между этими частями, сам процесс прыжков будет напрягать...и тут неважно скольки-тысячный код получился, если постоянно необходимо смотреть/сверять/подправлять что-то во всех частях, это будет напрягать....[COLOR="SlateGray"]имхо :)[/COLOR]
Свертка кода рулит.
Цитата: z0rch
да если даже разбить (грамотно разбить) огромный код на множество классов/функций/etc, но они по структуре алгоритма будут тесно взаимосвязаны и необходимо будет постоянно крутиться между этими частями, сам процесс прыжков будет напрягать...и тут неважно скольки-тысячный код получился, если постоянно необходимо смотреть/сверять/подправлять что-то во всех частях, это будет напрягать
Не, что-то тут неправильно. Если надо всё время прыгать, то, скорее всего код разбит неправильно. Ну, может мне везёт, но я обычно работаю в пределах одного куска кода, который с другими связан узкими каналами. А когда они связываются сильнее, то опять дроблю. В идеале, надо стремиться разделить большую задачу на много маленьких студенческих задачек, которые между собой почти не связаны.
эх, думал-думал, какой бы пример привести, так и не придумал :)
наверное возможны два варианта - или действительно неправильно разбит, или (если правильно) редактировать части по очереди, не суетясь между ними, а если редактировать по очереди невозможно, goto пункт 1 :)
наверное возможны два варианта - или действительно неправильно разбит, или (если правильно) редактировать части по очереди, не суетясь между ними, а если редактировать по очереди невозможно, goto пункт 1 :)
свертываемый кож и регионы кода - рулят.
а так конечно, длинные куски с С/С++/С#/Java - неблаголепно. Хочется плюнуть и сходить на пиво.:)
Нет, реально путаться начинаешь. Поэтому все разношу. В ООЯП ваще благолепие: один класс - один файл.
Количество строк, после которых начинается "дражэ" не считал. В чем каюсь, конечьно.:)
Вспомнил случай. Когда в ПТУ изусали Си, то летом, на каникулах, решил игрушку написать. Ничего сложного - казино (рулетка, блэк-джек, шлюхи:)). Кароч, я ж типа самый хитрый, кроме main решил другие функции не плодить. В итоге компилятор таки ругнулся, что я офанарел, размер кода в функции превышает нормы.:)
а так конечно, длинные куски с С/С++/С#/Java - неблаголепно. Хочется плюнуть и сходить на пиво.:)
Нет, реально путаться начинаешь. Поэтому все разношу. В ООЯП ваще благолепие: один класс - один файл.
Количество строк, после которых начинается "дражэ" не считал. В чем каюсь, конечьно.:)
Вспомнил случай. Когда в ПТУ изусали Си, то летом, на каникулах, решил игрушку написать. Ничего сложного - казино (рулетка, блэк-джек, шлюхи:)). Кароч, я ж типа самый хитрый, кроме main решил другие функции не плодить. В итоге компилятор таки ругнулся, что я офанарел, размер кода в функции превышает нормы.:)
Цитата: Iktomy
В итоге компилятор таки ругнулся, что я офанарел, размер кода в функции превышает нормы.:)
Однажді видел как компилятор ругался на слишком большую JSP страницу. По сути тоже сводится к слишком большому методу. Джамп не получался :)
Kogrom, я вот не пойму - неужели удобнее скакать между открытыми окнами/вкладками с кодом, чем просто елозить прокруткой в одном файле? По идее самоцелью не должно быть ограничение количества строк в файле, а скорее выделение в файл логической единицы кода программы. А уж на сколько строк он потянет... Впрочем, это же очевидные вещи.
Свертка кода - по мне так это очень большое зло, поскольку очень сильно ухудшает чтение кода. Опять же, свернуть/развернуть - лишние телодвижения. ИМХО, максимум, где это может пригодится - свертка большого комментария к методу/функции/некоего куска кода, поскольку мне, как автору, он не всегда нужен, но частенько ухудшает чтение.
Свертка кода - по мне так это очень большое зло, поскольку очень сильно ухудшает чтение кода. Опять же, свернуть/развернуть - лишние телодвижения. ИМХО, максимум, где это может пригодится - свертка большого комментария к методу/функции/некоего куска кода, поскольку мне, как автору, он не всегда нужен, но частенько ухудшает чтение.
Цитата: makbeth
я вот не пойму - неужели удобнее скакать между открытыми окнами/вкладками с кодом, чем просто елозить прокруткой в одном файле?
На самом то деле если у вас есть нормальный инструмент розроботки и вы его используете не как нотепад, а как инструмент розроботки то и то и то не составляет труда.
Вот к примеру Еклипс:
Ctrl+T - поискать клас и открить его сорсь
Ctrl+O - поискать и перейти к методу альбо филду
Посему соглашусь с Магбетом. Лиж бы оно было правильно по функционалу порезано. А делать гости на количество строк - ересь.
Правильное деление по функционалу, кстати, очень поможет при роботе со всякими сорс-верщен-контроллерами.
Цитата: makbeth
Свертка кода - по мне так это очень большое зло, поскольку очень сильно ухудшает чтение кода. Опять же, свернуть/развернуть - лишние телодвижения. ИМХО, максимум, где это может пригодится - свертка большого комментария к методу/функции/некоего куска кода, поскольку мне, как автору, он не всегда нужен, но частенько ухудшает чтение.
Ой, ну нафиг! Свертка рулит, особенно когда надо в разных местах полистать файлы типа такого (особенно советую взглянуть на слово partial). :D
За partial давить сразу. Он не для собственного кода задуман. Кроме очевидного отделения объявления компонентов формы/кастом контрола в классе от, собственно, логики работы с ними (как, к примеру, делает редактор VS), ИМХО, его можно использовать только для выделения объявления вложенного класса в отдельный файл. Да и то, ежели он "толстенький". А так - не-е-е.. давить, давить.. :)
Цитата: makbeth
А так - не-е-е.. давить, давить.. :)
Бггг, ну, то братья поляки писали - щас уже не задавишь. А мы вот теперь поддерживаем, рефакторим и допиливаем сие (Nemerle). :o
Ох уж мне этот код... :)
Вообще я некомфортно себя начинаю чувствовать когда количество кода превосходит 2-2.5 экрана (ну это мне так кажется). Т.е. вообще почти ничего. Более-менее я себя чувствую пока вслепую можно попасть на ползунок прокрутки :). Дальше совсем невесело, но вот ведь какая шляпа - огромная куча файлов в проекте тоже жутко раздражает. Но я за то, чтобы повторно используемые фрагменты кода логически связаными хранились в одном файле (ну может и в нескольких, но в смысле без лишнего добра). Я против copy/paste, я за Additional Directories и папочки типа common и components, откуда все повторно используемое и засасывается. Но тема организации кода по размеру/смыслу/файлам все равно всегда больная.
Вообще я некомфортно себя начинаю чувствовать когда количество кода превосходит 2-2.5 экрана (ну это мне так кажется). Т.е. вообще почти ничего. Более-менее я себя чувствую пока вслепую можно попасть на ползунок прокрутки :). Дальше совсем невесело, но вот ведь какая шляпа - огромная куча файлов в проекте тоже жутко раздражает. Но я за то, чтобы повторно используемые фрагменты кода логически связаными хранились в одном файле (ну может и в нескольких, но в смысле без лишнего добра). Я против copy/paste, я за Additional Directories и папочки типа common и components, откуда все повторно используемое и засасывается. Но тема организации кода по размеру/смыслу/файлам все равно всегда больная.
Цитата: makbeth
Kogrom, я вот не пойму - неужели удобнее скакать между открытыми окнами/вкладками с кодом, чем просто елозить прокруткой в одном файле?
Удобнее - не скакать и не елозить. Но скакать удобнее. Например, мне проще найти что-то в книге, которая разбита на разделы, подразделы и т.д., в которой есть содержание.
То есть, даже если файл один, то тоже лучше скакать. Например, pdf-документ с содержанием намного удобнее, чем без содержания. Ещё лучше, если содержание будет в отдельном фрейме и с ссылками.
А структура с папками и файлами - это что-то вроде содержания.
Цитата: makbeth
По идее самоцелью не должно быть ограничение количества строк в файле, а скорее выделение в файл логической единицы кода программы. А уж на сколько строк он потянет... Впрочем, это же очевидные вещи.
Не совсем так. Мне очевидно, что функции должны быть короткие, чтобы их было возможно быстро понять. Мне очевидно, что каждый класс должен иметь мало обязанностей, чтобы он меньше зависел от других классов, но проще к ним прилеплялся.
Далее. Свойство классов по обязанностям распространяется и на модули (почти файлы). То есть, если модуль разрастается, то обычно это сигнал о том, что он содержит плохо связанные классы, что классы наваливают на себя слишком много обязанностей.
Но файл - не модуль. Теоретически файл может содержать несколько модулей. Но так обычно не делают.
Цитата: Rebbit
На самом то деле если у вас есть нормальный инструмент розроботки и вы его используете не как нотепад, а как инструмент розроботки то и то и то не составляет труда.
Вот к примеру Еклипс:
Ctrl+T - поискать клас и открить его сорсь
Ctrl+O - поискать и перейти к методу альбо филду
Вот к примеру Еклипс:
Ctrl+T - поискать клас и открить его сорсь
Ctrl+O - поискать и перейти к методу альбо филду
А откуда я знаю имя класса который мне нужен? Вот, например, у меня здоровенный однофайловый исходник, содержащий игрушку. Мне надо поменять поведение какого-то безымянного элемента фона. Как я отгадаю его имя?
Цитата: Kogrom
А откуда я знаю имя класса который мне нужен? Вот, например, у меня здоровенный однофайловый исходник, содержащий игрушку. Мне надо поменять поведение какого-то безымянного элемента фона. Как я отгадаю его имя?
Я зачастую решаю такую задачу когда нужно исправить ошибку в компиляторе. Это особенно "увлекательно" при условии наличия ИДЕ недостаточного качества. :(
Цитата: Kogrom
А откуда я знаю имя класса который мне нужен? Вот, например, у меня здоровенный однофайловый исходник, содержащий игрушку. Мне надо поменять поведение какого-то безымянного элемента фона. Как я отгадаю его имя?
Я же сказал что по функционалу резать нужно :) Гую от логики отличить просто. Вот уже область поиска и сузиласть.
А теперь если он (етот елемент фона выделен в отдельний класс даже с осмысленным названием) то что его найти просто чтоли будет среди тучи файлов? Тоже придется пересмотреть кучу названий. Также как если бы по оутлайну искать.
Цитата: Rebbit
Гую от логики отличить просто. Вот уже область поиска и сузиласть.
Тут ещё отличать надо в монолите. А там уже все разделено, разложено по полочкам.
То есть, если в монолитном файле есть содержание типа (грубый пример, ибо в играх не смыслю):
Код:
то да, поиск проводить не сложнее, чем в структуре с файлами. Иначе - нет.
Цитата: Rebbit
А теперь если он (етот елемент фона выделен в отдельний класс даже с осмысленным названием) то что его найти просто чтоли будет среди тучи файлов? Тоже придется пересмотреть кучу названий. Также как если бы по оутлайну искать.
Ну, пока я не силён в двоичных деревьях (и не двоичных). И в оценке сложностей алгоритмов. Но вроде бы поиск в двоичном дереве производится за log(n). Если без дерева, то просто n. Если с угадыванием имени - то поиск может занять непредсказуемое время.