isset($_POST) всегда выдаст true Херня. Только что лично проверил. Вот пустой файл test.php PHP: <?php if(isset($_POST)) { echo 'истина где-то рядом'; } Спорим, что фраза будет на экране?
isset - проверяет была ли определена переменная. Если переменная была определена, но ей было присвоено значение NULL, то функция вернёт false. Определённый массив всегда true.
isset можно проверять конкретный элемент, а поскольку _POST — пустой массив, то PHP: <?php if($_POST) { // ( ... ) } ?> выдаст false. И это нормально, isset не для этого делали =)
Чем проще тем лучше. Если возможно не использовать функцию то ее лучше не использовать. Поэтому я использую if($_POST) и if($_GET) Никакой лишней мишуры. Обертки и прокладки усложняют систему
mpak ага и TDD в жопу и, и то, что оно даёт туда же... Если есть возможно абстрагироваться ПО ДЕЛУ то это вполне достойно!
да там другие бяки будут. например PHP: if($_GET['id'] && empty($_GET['oid']) && $_POST){ //////////////// } if($_GET['id']){ //////////////// }else{ ////////////////// } PHP: $conf['tpl']['opros'] = mpql(mpqw("SELECT * FROM {$conf['db']['prefix']}{$arg['modpath']} WHERE id=".(int)$_GET['id']), 0); $conf['tpl']['vopros'] = mpql(mpqw("SELECT * FROM {$conf['db']['prefix']}{$arg['modpath']}_vopros WHERE oid=".(int)$_GET['id']. " ORDER BY sort")); $conf['tpl']['select'] = mpql(mpqw("SELECT t.* FROM {$conf['db']['prefix']}{$arg['modpath']}_vopros AS v, {$conf['db']['prefix']}{$arg['modpath']}_variant AS t WHERE v.id=t.vid AND v.oid=".(int)$_GET['id']." ORDER BY t.sort")); $conf['tpl']['result'] = spisok("SELECT vid, value FROM {$conf['db']['prefix']}{$arg['modpath']}_result WHERE aid=".(int)$conf['tpl']['anket']['id']);
А собственно в чем проблема? Можно конечно этот код размазать на две страницы и использовать два тесятка промежуточных переменных. Считаешь что так он лучше будет выглядеть? Я про второй пример. Табы не правильно расставлены. К примеру первая строка Код (Text): $sql = "SELECT * FROM {$conf['db']['prefix']}{$arg['modpath']} WHERE id="; $sql .= (int)$_GET['id']; $res = mpqw($sql, 0); $conf['tpl']['opros'] = mpql($res); На мой взгляд одной строкой это лучше выглядит. Да и по логике. Ты знаешь что запрос в одной строке. Зачем его размазывать в 4 строки? И это еще не все. Можно еще после каждой строки пустых строк повставлять. Тогда это будет вообще на пол страницы. Да и промежуточных переменных как грязи. Индусовский стиль записи. когда от обьема кода получают.
1. Нет. 2. Нет. 3. Нотис - не ошибка. Круто его советовать и при этом не понимать принцип работы функции. Не обижайся, пожалуйста, но ты обезьяничаешь - услышал где-то "это хорошо, это плохо" и повторяешь.
mpak А так слабо? $user = $userMapper->find($this->getRequest()->getPost('user_id')); if (!$user->isExists()) { echo 'Я тебя не знаю'; } else { echo 'Привет' . $user->login; }
Костян, давай от противного, противный. Что я не подразумеваю под ошибкой: не объявленная переменная, отсутствующий ключ в массиве. Нотис, ё.
Это же все прокладки. Они нагружают систему. Даже обращение к $this->getRequest()->getPost('user_id') иди $_GET['user_id'] Что проще и быстрее работает? Помимо быстроты работы, простоты еще есть наглыднойть. Ты сразу видишь откуда берется этот параметр. А не запихиваешь в какую нибудь жопу какого нибудь жопошного класса строку private function getPost($id){ return $_GET['user_id']; } В еще замечаете тенденции писать прокладки на прокладки? Есть такие кто на эти интерфейсы свои напишит и обернет их в еще одну прокладку. И будет утверждать что данный класс это отстой и его реализация круче. Из за того что она использует методы с другими названиями.
mpak, прокладки в кране, а это абстракция. Важный элемент, хотя и не обязательный. С абстракцией лучше, потому что каждая "прокладка" может быть подменена на другую не затрагивая финальный код. К тому же, тесты удобнее проводить на маленьких компонентах - на каждую часть абстракции свой. Тестировать итоговый код - совокупность всего крайне сложно, а значит больше дырок (багов).
А про прокладку на прокладку что скажешь? Хотя наверно и это не предел. Уверен если поискать можно найти прокладки в кубе. Какую они несут функцию? В плане понимания как это работает вообще молчу. Для меня это прокладки. Как раз чем больше таких прокладок тем больше багов и дырок. Потому что мало кто представляет как это все работает. И чем больше "абстракция" тем это безнадежнее. Я понимаю почему разработчики пхп на чистом C написали и без использования абстракций. Потому что если они еще будут абстракции юзать да и мы то пользователь устанет ждать когда его страница "Hello World" переварит все это говно. В моем же случае есть два варианта. Либо код работает либо не работает. Никаких абстракций (читать как багов и дырок).
Абстракция она в единственном числе потому что понятие такое. А вот измерять её можно - да - почти любым количеством слоёв. Не стоит выпячивать своё непонимание, а уж тем более делать это аргументом. Потому что ты не видишь полной картины. Ты трогаешь слона за хвост и говоришь, то слон это верёвка. Что такое жёсткий диск? Это пластины, винты, магнит. Но это ещё и древо директорий и файлов. Они и есть абстракция. Или ты считаешь, что если сломать жёсткий диск оттуда вываляться файлы и каталоги?
код написать не проблема, проблема его поддерживать и развивать. если $_GET['id'] не будет задан - быстрее найти ошибку в одной большой или в 4х маленьких строчках? если при исправлении/написании кода была допущена логическая ошибка - быстрее найти ошибку в одной большой или в 4х маленьких строчках?
Свежие высказывания Торвальдса о C++ навели на мысли о причинах маргинальности Код на C легко читать, в нем нет неявных зависимостей от “контекста”. Если человек видит вызов sctp_connect(), он сразу понимает, о чем идет речь. Тогда как обращение к connect() в C++ном коде может означать все, что угодно. Этим-то C++ и плох. Если кто-то находится “в теме”, то в C++ном коде ему будет разобраться несложно. Но вот всем остальным на это потребуется гораздо больше времени и сил для того, чтобы сначала разобраться с контекстом, а затем уже с самим кодом. Плюс к вышеперечисленному разработка ядра – это очень специфическая вещь, для которой C является очень хорошим инструментом. Но это вовсе не значит, что C должен использоваться везде и всюду без разбору. эти слова, на мой взгляд, очень хорошо описывают не только то, почему C++ слабо представлен в Linux-овом ядре. Вот кто захочет придти на проект, который развивался в течении 5-7 лет средней руки программистами, в условиях меняющихся требований, цейтнотов, исправленных на скорую руку просчетов, с кучей workaround-ов для сторонних компонентов, исходник которого будет представлять из себя плохозакомментированную многоэтажную математическую формулу? Этот пример - мой случай. Я делаю ядро системы где все навороты ООП просто не нужны. Зачем они если общее количество функций не переваливает за полтора детсятка половина из которых используется редко? А вся логика это последовательное выполнение заранее известных действий. Коннект с бд, авторизация пользователя, подгрузка модуля и блоков. На этапе работы операционной системы вам часто приходится поддерживать и развивать код ядра? Думаю их присутствующих - никому. Поэтому и не стоит в нем делать каких то лишних телодвижений. Абстрагируйтесь работой с модулями. И в них уже делайте что хотите. Работайте с хорошо организованной периферией, благо что ошибки с ядра выгребаются уже несколько лет и новых в нем найти не так просто. Как и новые возможности в нем тоже не нужны. Все вынесено в модули.
Для меня лично не имеет значение будет одна большая строка или четыре маленьких. Больше парит что 80% экрана свободно но приходится просматривать 4 страницы, и то что одна логически законченная операция а именно запрос к БД размазана по четырем строчкам. Значительно лучше когда весь код перед глазами. Мне комфортно когда экран заполнен процентов на 80. Данные строки как раз заполняют это пространство поэтому разбивать их на более мелкие не считаю нужным. Представьте если бы вам пришлось читать книгу по 1 слову в строке. Это похоже на стишки для маленьких детей. Когда дочитывают до конца строки забывают что прочитали в начале. Так им проще воспринимать информацию. Много незнакомых букв их пугает.
Слон так и останется верёвкой пока не сделаешь пару шагов и не увидишь картину в целом. Нежелания понимать вызваны либо упрямством, либо глупостью. Что, по сути, одно и то же. P.S. Цитата Торвальдса чушь какая-то. Это вольный пересказ что ли?
Извини. Бил Гейтс для меня не авторитет Не желание видеть очевидные вещи вообще не могу объяснить. До Торвальдса нам всем еще как до китая. Человек на чьем коде работает 91% всех суперкомпьютеров в мире и 65% веб серверов. Непонятные вещи в его словах я бы списал на собственную ограниченность и нехватку опыта. В популярности C++ играет роль фактор сложности языка и ощущения "могущества" от его использования. ну и Fun. ИМХО, конечно. Повторюсь я не против С++ и ООП и тем более тех кто на нем пишет. Есть места где он действительно нужен. Помогает реализовать сложную логику, разбить сложный проект на составляющие или согласовать работу команды разработчиков. Но меня раздражает когда его пытаются воткнуть в каждую дыру. Когда строку $_GET['id'] заворачивают в метод класса уже обернутый другим классом. И представляют это как чудо которое непосвященные не способны понять и оценить. Нахрена козе баян? Зачем абстракция там, где и без того ничего сложного нет. Если человек испытывает затруднения в прочтении кода строки запроса не разбитую на четыре строки, то это его трудности.