- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
function register()
{
if (!empty($_POST)) {
$msg = '';
if ($_POST['user_name']) {
if ($_POST['user_password_new']) {
if ($_POST['user_password_new'] === $_POST['user_password_repeat']) {
if (strlen($_POST['user_password_new']) > 5) {
if (strlen($_POST['user_name']) < 65 && strlen($_POST['user_name']) > 1) {
if (preg_match('/^[a-z\d]{2,64}$/i', $_POST['user_name'])) {
$user = read_user($_POST['user_name']);
if (!isset($user['user_name'])) {
if ($_POST['user_email']) {
if (strlen($_POST['user_email']) < 65) {
if (filter_var($_POST['user_email'], FILTER_VALIDATE_EMAIL)) {
create_user();
$_SESSION['msg'] = 'You are now registered so please login';
header('Location: ' . $_SERVER['PHP_SELF']);
exit();
} else $msg = 'You must provide a valid email address';
} else $msg = 'Email must be less than 64 characters';
} else $msg = 'Email cannot be empty';
} else $msg = 'Username already exists';
} else $msg = 'Username must be only a-z, A-Z, 0-9';
} else $msg = 'Username must be between 2 and 64 characters';
} else $msg = 'Password must be at least 6 characters';
} else $msg = 'Passwords do not match';
} else $msg = 'Empty Password';
} else $msg = 'Empty Username';
$_SESSION['msg'] = $msg;
}
return register_form();
}
Из рассылки PHPWeekly: "A Clean and Secure Open Source PHP Login Script"
https://github.com/panique/php-login/blob/master/0-one-file/index.php#L98
Что-то уж очень сильно "Clean".
Follow us!
То ли про && не слышал, то ли он в пыхе поломаный, то ли автор хотел проверить, докуда может дойти лесенка.
Так там же внизу else еще есть. И они везде разные. && тут ничем не поможет.
Тут нужны нормальные валидаторы :)
Или (пых там может в исключения?):
Тут варианта два
- либо кидать исключения.
- либо хранить состояние ошибки в переменной и проверять ее при дальнейших действиях
Тогда исключения использовать нельзя, ведь выброс исключения - вторая неявная точка выхода.
Сектант-одновозвратник в треде!
Говорить о том, что лишние точки возврата нежелательны, но при этом юзать throw это как-то странно ;) Тем более исключения могут вылететь в одной из вызываемых функций, и тем самым спровоцировать неожиданную точку возврата...
Да и нету ничего плохого в нескольких точках выхода. Так же как и в goto. Просто надо во всем знать меру, а не слепо следовать своей религии. Например, лично для меня, зачастую второй return удобней, чем лишний флаг/проверка (которые так любят лепить одновозвратники), читабельность от этого только улучшается.
Что, простите?
)))
Если больше одного ретурна в одном скоупе, то даже не скомпилится.
Как минимум, у M$ в T-SQL такое есть. Одна функция - один ретурн :(
Это теми считается кто не умеет их готовить. return отлично видно в функциях размером 20-25 строк.
Для языков, в которых нету ни RAII ни finally, эта фраза даже имеет смысл. В той же сишке это правило не от хорошей жизни соблюдают...
Для высокоуровневых языков же одновозвратничество обычно только усложняеет код, и превращается в банальное флагоёбство или лишние инварианты (да и, как я писал выше, исключения добавляют еще кучу потенциальных точек выхода, которые одновозвратнику придется учесть с помощью горы try'ев).
P.S. Если здесь есть одепты одновозвратничества, которые хотят оспорить мои слова - пожалуйста, приводите примеры кода (на высокоуровневом языке типа c++, java и т.п., не на сишке), и я с удовольствием с вами похоливарю.
Ну не только сишко. Общая проблема языков, в которых нет RAII, finally, или их аналогов.
Ну хорошего стиля тут, имхо, совсем немного. Обычно наоборот, в высокоуровневых языках код с одним return'ом смотрится хуже, чем с парой-тройкой. А там где получается понятней - там скорее всего гигантская функция на 50-100 строк.
А RAII (resource acquisition is initailization) это из крестов. Когда объект, управляющий каким-то ресурсом типа файла или сокета, закрывает его в своем деструкторе.
Почему же? можно дублировать код в try и catch блоках. Через анус, но сработает
Всегда найдутся упоротые^W люди, которые предпочтут явно продублировать код освобождения ресурса)
Те, кто ставят много return в одной функции - не научились пользоваться отладчиком.
Предпочитаете добавить лишний уровень отступов? :)
> переписывать так, чтобы функция возвращала в самом конце
Ради бряков похабить код?
> не научились пользоваться отладчиком.
В том же эклипсе есть exit брекпоинты, которые срабатывают на return'ах... И всяко они есть не только там...
Или может быть поперчить код флагами? :)
Множественные точки возврата - они как правило от неумения нормально сотавить контракт для функции / неумения описать для самого себя, что именно функция должна принимать и возвращать. Или C-подобного недоразумения, где "функции" вместо того, чтобы что-то возвращать чего-то там меняют в аргументах.
Что такое "-1"? Почему возвращается именно эта константа, а не -2 например?
Кнут, например, считает, что нужно возвращать первый индекс за пределами массива, что имеет определенный смысл, в то время как отрицательные индексы - просто бред, а кроме того заставляют расширить тип возвращаемых значений от только беззнаковых до знаковых + беззнаковых.
Более того, такой код делает предположение об однопоточности приложения, не давая ему возможности воспользоваться параллельным выполнением / затрудняя поиск инварианта, который бы хорошо распараллелился. (Скорее всего, что чтобы распараллелить поиск массив будет разделен на части и поиск будет в каждой из них, с последующим выбором наименьшего результата.)
Как бы переписал? Вместо первого return - break, вконце - return i. i соответственно, нужно было бы объявить за пределами цикла.
break не карается одновозвратниками? (не вброс)
Можно обернуть тело функции в цикл и пользоваться break.
> 10 - да, именно.
Здесь есть проблема - в отличие от специального значения, на эту десятку довольно сложно проверять. Вдруг мы не знаем длину массива в точке, в которой будет проверка?
Поэтому мне все-таки ближе подход шарпа и хаскеля. В шарпе есть "nullable<T>", он же "T?", добавляющий специальное значение null к типу T. В хаскеле похожий тип Maybe T, имеющий значения Just t и Nothing.
Кроме простых случаев, когда размер массива вшит в коде - нет, не знает. Откуда компилятору знать значения, которые будут известны только в рантайме?
В рантайме то его длина известна...
Потому что это, позвольте процитировать вас и Кнута, первый индекс за пределами массива.
То есть программа должна выполняться полностью даже если на начальном этапе ясен ответ? Люди так не мыслят
Например, едет человек в магазин, на встречу ему идет знакомый и говорит, что магазин закрыт. Что сделает человек? Упадет закатив глаза? Так сказать "прервет операцию похода в магазин". Ихмо для человека это естественно
Напишите, пожалуйста, какой-нибудь код в одновозвратном стиле, который убедит меня в превосходстве этого стиля.
> кто ставят много return в одной функции - не научились пользоваться отладчиком
кто ставит один - не научился не пользоваться отладчиком?
Если уж что-то брать в качестве примера, то лучше взять Яву + Идеию с ее интерфейсом.
Ах, да, еще забыл, GDB всегда однозначно и моментально находит нужный исходный код, который он сейчас рассматривает во время выполнения. И УГ макросы ему совсем не мешают это сделать.
Ну и вдобавок к замечательному языку уже ничего не оставалось кроме как написать замечательный отладчик - а что, ведь когда в языке вся информация уже есть, то отладчик написать - плевое дело.
Жабий отладчик я тоже иногда использую, иногда в удалённом режиме, отлаживая какой-нибудь сервлет на удалённом сервере в два часа ночи. Но почти о всех случаях использования отладчика я жалел, т.к. просто посидеть и хорошенько подумать было бы более продуктивно, чем прогонять программу по шагам (жабоотладка в удалённом режиме, кстати, невероятно тормозит).
Ок. Раскрутим стек: множественные ретурны это плохо, ибо мешает могучим осиляторам дебаггера делать свою работу, ведь дебаггер это очень важно.
Мне в моей работе дебаггер нафиг не нужен, ибо он не решает практически никаких проблем, с которыми мне приходится сталкиваться. Следовательно, "сложность работы с отладчиком" из-за множественных ретурнов - слабый аргумент для меня.
Удобство чтения кода для меня гораздо важнее, чем удобство его отладки в дебаггере, ибо первым я занимаюсь гораздо больше, чем вторым.
Потому что мне нравится закатывать солнце вручную! Специально поэтому я выбрал самый уебищный язык, в ктором любое действие, которое можно было бы автоматизировать, нужно делать вручную, в нем есть какие-то библиотеки, которые помогают это автоматизировать, но какой нормальный человек стал бы пользоваться этим языком? Поэтому библиотеки написаны такими же любителями закатывать солнце вручную.
Теперь, у меня в работе есть много проблем: как разогнать тучи руками, как посторить космический корабль из подручных инструментов, как обучить оленей передвигаться в условиях невесомости так, чтобы они при этом могли за собой еще и космический корабль потянуть.
И не важно, что можно было просто задернуть занавески - я ведь не за легкими путями шел сюда.
Лол, использование отладчика - вот где закат солнца вручную. Сессии дебаггера невозможно воспроизвести без участия человека, они не приносят никакой пользы проекту, ничего не документируют; они выбрасываются и забываются сразу после своего завершения. Модульные тесты не страдают от этих недостатков.
По поводу языка... Ну, сишка с крестами не фонтан, конечно. Известно, что это кроссплатформенный ассемблер, и милости от него ждать особо не стоит. Тем не менее, утечки ресурсов, проблемы с производительностью и потоками возможны практически во всех языках. Сборщика мусора иногда не хватает.
Действительно серьёзный софт сейчас пишется на C/C++/Java (В Google и Yandex, к примеру, c++ - основной язык). Все операционные системы написаны на этих языках, все базовые инструменты, даже небо, даже емакс. Если хочется писать что-то приличное, приходится использовать доступные инструменты. Да и не так уж они и плохи, как некоторые думают. Жить можно.
Выпады по поводу автоматизации мне, простите, уж совсем непонятны.
Да-да, расскажите еще про то, как сессии отладчика не воспроизводятся. Даже GDB имеет специально задокументированую возможность загрузить в него список команд, а жабий отладчик - так вообще может прям жабий код интерпретировать из файла.
Серьезный софт бла-бла-бла: миллиарды навозных мух не могут ошибаться. Серьезный софт это типа вебсайты верстать, или кнопки на формы расставлять? Или может быть все-таки серьезный софт, это исследовательские / научные / экспериментальные работы, где Ц++ и его брат-инвалид нахер не уперлись?
обычно такой софт даже пишется непрофессионалами программирования - а физиками, биологами, етц
им надо построить модель, и им обычно насрать на производительность - конечно тут ц++ не упрется, его изучать надо столько же, сколько предметную область
серьезный софт - это тот, который без отладчиков в продакшене способен работать 24/7/365 в миллионных тиражах
По такому определению серьезности софта секретарши, которые лабалют ВБА макросы для форматирования дат в Иксэле - самые серьезные программистки. Куда там профессуре с кафедры информатики.
+100500
ТЕЛЛ МИ МОАР АБАУТ РЕСУРС МЕНЕДЖМЕНТ ИН ЛИШП
А вы не управляете ресурсами вручную? Быть может, ваш язык имеет пакет telephaty и сам понимает, когда нужно закрывать файлы, сокеты, пайпы, когда нужно освобождать замапленные файлы, лочить/анлочить мутексы? loan pattern с коллбэком это, конечно, хорошо, только вот плюсовый RAII далает тоже самое без увеличения вложенности кода и накладных расходов на вызов функций. Да и не всегда удобна автоматизация в стиле loan pattern, поэтому в последнем крестовом стандарте внедрили rvalue-references и move-семантику. Память в куче - лишь капля в море ресурсов.
> Серьезный софт это типа вебсайты верстать, или кнопки на формы расставлять?
Ну я такими вещами вообще мало когда занимался, в основном ради собственного удовольствия. Серьёзный софт - это тот, который делает жизнь многих людей лучше, проще. Такой как мгновенный поиск данных в сети, общение, построение маршрутов. Или такой, реализация которого требует решения сложных инженерных задач.
> так вообще может прям жабий код интерпретировать из файла
чем это лучше модульного теста?
Рассказать про with-open-file? Гугл в помощь.
Серьезный софт - это такой, который решает сложные новые задачи. Воспроизведение готовых решений - не серьезный софт, это ширпотреб.
with-open-file и всего лишь экземпляр общей идеи, имя которой loan pattern. В Lisp он обычно реализуется макросом, что устраняет вызов функции в рантайме, но сути это не меняет.
> сложные новые задачи
Человеческие задачи не особо поменялись за тысячи лет, меняется лишь масштаб, качество и удобство решений.
Сферическая тафталогия в вакууме. Просто бессмысленное предложение о смысле бытия и тщете всего сущего. С таким образом мысли лучше в общество Рериха вступать, а не програмы писать.
> экземпляр общей идеи
А вот тут как раз честно, ничего нового не придумали, просто авторы Ц++ не осилили даже это. Им же побыстрее холопов запрячь нужно, больше текста писать, чтобы было чем руки занять. Иначе ж работа встанет! Холопы начнут книжки читать, а там гляди и мысли отступнические появятся.
Т.е. если несколько человек придумали новый полезный протокол и реализовали сервер, выдерживающий нагрузку максимум в 10 пользователей и падающий через день, а группа инженеров разработала отказоустойчивую распределённую систему, способную одновременно обслуживать миллионы пользователей круглосуточно каждый день, то последние не сделали ничего нового и интересного?
Ещё Брукс писал, что работа инженера-программиста, решающего задачу, поставленную архитектором, не менее творческая, интересная и сложная, чем работа самого архитектора. Просто задачи у них разные.
ok, отсортировать 1тб данных на одной машине с 8 гб озу - с этой задачей справиться любой дебил, ведь все эффективные алгоритмы сортировки уже придуманы, осталось только циферки в формулу подставить, ага.
Сыграть фортепианную сонату скрябина тоже любой идиот сможет, её же ведь уже сочинили и нотки записали, осталось только сесть и тупо повторить то, что записано.
ваш типичный слив "да вы меня все неправильно поняли, читайте что я написал много раз, обезьяны"
В отличие от моды, в программировании есть огромная разница между скопировать и смасштабировать.
То, что тебе хочется творческих задач, в общем-то понятно, но изобретение нового - это не всегда то, чем приходится заниматься инженеру.
А за лиспоблядство и быстрый обход массива пидары обычно не хотят платить.
не согласен. Программировать технически грамотно, качественно и красиво - это исскуство
Программирование отчасти искусство, но всё же мы решаем инженерные задачи. 50/50, как во многих инженерных ремёслах
Серьёзные программисты редко занимаются научными изысканиями, им просто некогда. А если и занимаются, то самый важный их софт не так уж и важен с научной точки зрения. У Столлмана, к примеру, есть научные работы в области computer science, написанные в MIT, но самый важный его вклад - написание ширпотребного компилятора Си, ширпотребного дебаггера Си и объединение ширпотребных макросов для ширпотребного редактора TECO в ширпотребный Emacs. Учёным же редко когда есть дело до красоты программ и парадигм программирования. Я полтора года тусовался в ИПФ РАН, 98% научных работников успешно пишут нужный им софт на FORTRAN 77.
Некогда думать! Кодить надо! Проставь типы всем функциям и переменным, типы сами не проставятся!
А вообще, у вас просто непонимание русского языка и постоянная подмена понятий. Может ли быть что-то важное и не творческое? - Например дома посуду помыть? Может ли быть что-то не важное и творческое? - Да, известный пример с человеком который научился бросать чечевицу сквозь маленькое отверстие (случай с Александром Македонским).
Думать это очень хорошо, но кодить тоже, к сожалению, приходится. Причём довольно много, независимо от языка. Ололо в лиспе надо писать меньше букв - миф.http://www.jwz.org/doc/worse-is-better.html
> Проставь типы всем функциям и переменным
Ну всем, конечно, перебор, но ничего плохого в проставлении типов нет.
> у вас просто непонимание русского языка
куда уж быдлу понять ваш полёт мысли
А не проще ли тестировать подфункции? Или составлять хорошие тесты?
Ок, давайте уточним терминологию. Что вы понимаете под отладчиком и под отладкой?
Классический пошаговый отладчик, или же REPL, в котором можно поиграться с функциями, и позапускать их в различных ситуациях?
Ну я эту мысль и пытаюсь выразить на протяжении этого треда... Но для этого мне нужно опровергнуть тезис о том, что одного возврата всегда достаточно.
> Лично я проще воспринимаю несколько выходов из функции.
Аналогично.
А одного - всегда достаточно) Любую функцию с множеством выходов можно свести к функции с одним. Хотя бы применяя систему условий и флагов. Это исключительно дело вкуса
В чем смысл выбирать самые уебищные языки, а потом жаловаться на то, как в них все плохо и нельзя сделать хорошо?
Попробуйте еще на XSLT что-нибудь такое слабать, а потом удивляться, почему так плохо. Тот кто язык придумал вложил просто очень много ума и усилий в то, чтобы сделать программирование удобным, поэтому хомячки теперь наслаждаются и изобретают заплатки поверху своих мегаудобных инструментов.
возвращаемся к ассемблерным флагам?
это только представьте, какой спагетти-код будет. и, в отличие от спагетти, не столь легкоусвояемый.
пы.сы. пойду пожру.
Жаль в пыхе массивы некрасиво описываются.
В гцц не помню, но вроде 256 и есть. Ненамного больше для генератора, совсем не отличимо от 128 для кода, который пишут руками.
да и в каждом таком еще по 3-4 вложенных elseif.
Так я о чем и пишу... Человеку насрать на эти ограничения с высокой колокольни. Ему что 256, что 128, что всего лишь 8. Разницы он не заметит.
те ещё суки!
Сколько?
еда - туда >
а происходит следующее: в дебаггере шагает, заходит в try блок, выходит, не заходя в finally, и пропадает бесследно. у него в этот момент пошатнулись каноны мира, он чуть в магию не поверил.
оказалось проще: там внутри создавался сокет, который вечно слушал... программа просто зависала )
Один раз там потом похожая херня оказалась - http коннект без таймаута ждал 2 дня, потом отваливался.
А второй раз был гейзенбаг и вроде как finally дейстивтельно не отрабатывало, но это было давно, под 1.4 . Тогда так и осталось неясным, то ли сервер душил каким-то хером тред, то баг в JIT.
http://i.imgur.com/BtjZedW.jpg
ALERGYX помогает нашему телу выработать собственные «блокирующие антитела», которые НАВСЕГДА ИСКЛЮЧАТ ВОЗМОЖНОСТЬ ПОВТОРНОГО ВОЗНИКНОВЕНИЯ АЛЛЕРГИИ.
Официальный сайт: http://alergyx.bxox.info