делимся полезностями :)

а в чем удобство то?

 

я создал фуннкцию для var_dmp()
чтобы постоянно вывод не форматировать и знак какой именно переменной дамп

Код (PHP):

1. /* * *
2.  * Функция форматированного var_dimp() информаций о переменной чей дамп.
3.  */
4.  
5. function vdf($param, $info) {
6.     echo"<pre>";
7.     echo "***********<br>";
8.     echo "<b><i>$info</i></b>\n";
9.     var_dump($param);
10.     echo "***********<br>";
11.     echo "</pre>";
12. }
13.  
14.  

 

200/30 - если файл разрастается до 200 строк или метод до 30, то пора его дробить.

 

mahmuzar, попробуйте var_dump заменить на подобное:

Код (PHP):

1.     function VarDump($v) {
2.         ob_start();
3.         var_dump($v);
4.         echo preg_replace('/\]=>.+\b/sU', ']=> ', ob_get_clean());
5.     }
6.  

Добавлено спустя 1 минуту 38 секунд:

Бред.

 

Ну, если вам нравится месяца через 3 смотреть 500-строчные простынки кода, пытаясь вспомнить и понять куда впихнуть очередной костыль, то да, бред. А я пас )

 

Нет критериев 200, 500 или 10 тысяч строк. Есть критерий "необходимость" конкретики. А уж по каким признакам эта необходимость будет - личное дело каждого.
Один из вариантов, предпочитаемых мною, алгоритмические блоки (1 алгоритм = 1 блок). А уж сколько там будет строк, 10 или 1000, дело десятое.

 

Не завидую я тому, кто будет за вами поддерживать "1000 строк алгоритмического блока", который по неким религиозным соображениям нельзя разделить на функциональные части. Ограничения на количество строк, их ширину и оформление кода в целом придумали не случайно:
1. Метод выполняет конкретную задачу
2. Соответственно по названию сразу понятно что он делает
3. Все это вместе с phpdoc`ом умещается всяко в один экран
4. Можно легко отследить в каких местах этот метод дергается, что полезно при рефакторинге
5. Другой человек не будет в тайне желать вашей смерти при изменении и/или внесении нового функционала.

И да, я разве утверждал что это некий догмат и за 201 строку нужно расстреливать? ) Просто правило сигнализирующие о том что код начинает попахивать.

Добавлено спустя 9 минут 2 секунды:
mahmuzar, можно сделать ещё одну функцию, но с die() в конце, часто бывает полезным.

 

может наоборот, одно действие в одну функцию, другое в другую, по логике действий, и пускай даже все оно вызывается 1 раз.

 

А я думал , что дин так считаю....

 

У меня есть класс констант с ~1000 константами. Согласно Вашему правилу, его надо разбить на 5.
Тоже - конфигурационный класс с чуть менее 1000 параметров. (и там и там классы используются как структуры - просто удобно)
У меня есть объект "User" с более, чем 1000 строк кода и десятками методов. Согласно Вашему правилу, класс надо разбить на 6-7 классов (с учётом, что 1 класс = 1 файл).
и т.д. и т.п.

Где-то когда-то об этому уже говорил - разбивать код нужно, но только по правилу "всё хорошо, что в норму". И в каждом конкретном случае, норма будет своя. В общем, догматы 80-х годов прошлого столетия уже давно не есть "норма" для всего и вся.

 

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

 

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

спасибо.

Вообще изначально Chushkin и не говорит что не нужно делить сложное, как я его понял он про то что функцию не делят исходя из строк кода, может есть и исключения тоже.

имхо...

 

Кто сказал, что все классы должны быть объёмными? Повторюсь, - всё зависит от конкретики. У меня есть классы в десяток строк, есть в пару сотен, есть и более тысячи строк. Если уж хотите считать в попугаях, в смысле в строках, то считайте в среднем, а не крайние значения.

А вообще, - "я прокукарекал, а там хош рассветай хош не рассветай"
п.с.
Когда-то, очень давно, я был такой же - использовал множество догматов вычитанных в книгах. А потом, с годами практики и опыта, постепенно пришёл к неким нормам, которые отличаются от "стандартов", навязываемые нам с 80-х годов. И последние лет 15 этим пользуюсь, естественно с поправкой на более современное железо и средства RAD. В моих нормах нет ограничения на число строк, длины, формата кода и т.п. Есть только одно ограничение/требование (по поводу стилистики) - "читабельность". А оно уже определяет всё остальное - "что читабельнее, то и пользуй, товарищ разраб".
Единственное ограничение - когда работаешь в команде, то приходится придерживаться правил, которые приняты в ней.

Добавлено спустя 2 минуты 3 секунды:

Смешно.

 

Код (PHP):

1. if(!isset($_POST['value'])) or die(var_dump("что-то")); 

что-то типа этого?

 

В общем и целом правильно поняли. Деление по числу строк это последнее, что надо делать. И не факт, что надо.

 

А теперь представь, что тебе придется разобрать такой код и внести ряд нужных заказчику фич ))

Тут дело не в "используемости" и не в 21 строчке, дело в прозрачности логики производимых действий. Вот, вчерашний пример в 500 строк. Да, там обрабатывается пользовательский запрос и больше ни где кроме как в этом контроллере код не нужен. Да, там тот самый читабельный алгоритмический блок (ну, по мнению автора кода). Но его, судя по постам автора топика, ни кто в интернетах так и не осилил.

А теперь представим, что код разбит на составные части:
1. Валидируем присланное от пользователя
2. Грузим нужные модельки и что-там ещё нам нужно, формируем запрос к базе
3. Добавляем фильтры, сортировки и прочее.
4. Подгружаем все что нам нужно обычно для шаблона и отдаем его в браузер.

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

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

p.s. с меня хватит, у мну больше нет аргументов против конфига в 1000 параметров.

 

romach, Вы привели пример и аргументы ЗА как раз о том, о чём я говорил выше - алгомитрическое деление.
Если сможете привести подобные ЗА для деления по числу строк, это будет интересно. Возможно, поучительно.