1) 4 пробела замест одного таба.
2) function<тут должен быть перевод строки и отступы (в 4 пробела каждый) до буквы f>{
3) if<циклы, условия, свитчи, тут должен быть один пробел>(
4) xxx (...)<циклы, условия, свитчи, пробел без перевода строки>{
5) $reason1<выравнивание пробелами, так же и для ассоциативного массива>= $reason
6) максимальная длина строки 80 символов, критическая 120. Если ты влез в 80, то молодец, если вылез за 80 -- ты хоть и какашка, но вот тебе поблажка. Ну а если вылез за 120, то ты дрыщ позорный и макаронный монстр ))
Есть отступы (табуляция, в PSR она делается пробелами), а есть выравнивание, оно всегда делается пробелами.
И не надо путать эти два понятия.
Отступы всегда от левого края строки, а выравнивания могут идти только в центре строки.
Смирись.
Я тоже смирился.
Уже даже привык.
Нет, уже даже других гоняю ))
Еще можно поговорить по оформлению алгоритмов.
Делать как можно меньше "ступенек".
И еще было дело мы тут недавно обсуждали где-то, что делать несколько ретурнов из ф-ции с разных глубин вложенных условий это некошерно.
В таком куске кода нужно пораскинуть мозгами и развернуть эти макароны в идеале в односложную одноуровневую последовательность действий.
И "опускать руки" только в том случае, если улучшить уже невозможно.
Если определено, что ф-ция возвращает массив, то она всегда должна возвращать массив.
Не нашлось что вернуть? Ну так возвращай пустой массив.
Так же, ты используешь *_once для единоразового подключения файлов.
Но, это хрень. Нет, оно конечно свое дело делает.
Но, нужно использовать хранилище инстансов, которое инкапсулирует в себе все эти инклюды и проверки.
Ну я написал простейший пример в своем предыдущем сообщении.
Потому что тупой пых смотрит только в одну область видимости.
А писать на каждый чих эти богомерзкие global внутри каждого скопа (ф-ции) -- себя не уважать.
Принцип "глобализации переменных" быстро пронюхали -- любая статика (ф-ция или статический метод) всегда глобальны.
Но выбирается именно статический метод, т.к. у классов/объектов есть изкоробочный бонус -- сохранение внутреннего состояния.
Писать про передачу аргументов в конструируемые экземпляры объектов мне влом.
Так же влом сейчас писать про рефлексию и способы передачи там аргументов по ссылке.
Оно тебе и жирновато будет сразу.
Даже если вы знаете что значение полностью безопастно (сами его генерируете, а не берёте от пользователя), то всёравно лучше вынести его из запроса, такое разделение более правильное
Выносят всегда вот почему.
Даже сама фраза "подготовленный запрос" уже намекает, что запрос подготавливается.
Что значит подготавливается?
Он валидируется синтаксически (только в контексте SQL без учета данных, которых еще и нет).
Так же, в некоторых БД текст запроса даже отправляется на сервер чтобы пройти валидацию там, причем не только синтаксическую, но и на наличие таблиц, полей и прочего.
База может (и скорее всего сделает это) заранее просчитать наилучший вариант обработки запроса.
Тут можно положиться на саму базу, а можно указать ей (и структурно и синтаксически) какие индексы конкретно использовать или в каком порядке выполнять вычисления.
На любом из этапов валидации (подготовки) запроса может что-то пойти не так, и мы сразу узнаем об этом, т.к. процесс будет прерван.
Действительно, зачем пытаться лопатить миллионную таблицу, если в запросе синтаксическая или иная ошибка?
Успешно подготовленный запрос, если это делалось прямо на клиенте (в драйвере), вместе с подставленными данными (эскейпинг которых проходит в драйвере(?)) отправляется наконец в базу для выполнения.
А если подготовка проходила уже в базе, то успешно подготовленный запрос лежит в памяти базы и ждет от нас данные для подстановки.
Т.е. мы отправляем только данные (эскейпинг которых проходит в драйвере(?)) для подстановки.
И тут наконец сам запрос и выполняется.
И во время выполнения уже точно никаких ошибок не возникнет.
И мы можем быть уверены что получим результат.
Даже если мы получим ноль строк -- это результат на основании условий запроса.
Ну да, для инсертов или апдейтов конечно может произойти ошибка во время выполнения.
Например попытка дублировать уникальный ключ. И все такое.
Но это уже мелочи.
Дословно с выносом мозга: обрезает пробелы у строки, которая присваивается (или переопределяет) в качестве значения массива по ключу colorbag из неопределенной константы value, преобразованной автоматически в строку с значением value.
Велком ту пых!!! (Добавление)
.
Народ, пофиксите человеку скриптик.
Только не забудьте почистить от XSS!
1) отпадает смысл входного формата ака дробь (мб только хотели видеть как решающий бут с дробями работать, но, это не известно).
Кстати, это в моем примере дроби как дроби.
А в условии задачи сразу деление, т.е. сразу флоаты.
В любом случае я решил задачу пропорционального распределения случайностей (таблица или кастом генератор).
Но, домножение флоатов до целого числа, где множитель зависит от максимальной заполненности разрядов одного из флоатов, ИМХО, приведет сразу к тому, что мы упремся в PHP_INT_MAX.
Вот и приплыли -- при малой точности выпадают варианты, а при большой упираемся в ограничения.
Ну да -- давай gmp_* прикрутим ))
2) работа с отрезком челых чисел, где размер отрезка равен их сумме, противоречит условию пропорций поставленному в задаче.
И вносит двойную неточность:
а) сумма безосновательно болтающихся "на хвосте абстрактного коня в вакууме" чисел.
б) рандом который может надолго залипнуть в некотором сегменте отрезка.
Пока я тот пост писал, мой пукан превратился в головешку, а под ним стул поплавился.
Со стула потек жидкий пластик и залил ковер.
Вот не знаю что теперь делать.
Не обращать так сильно внимание на тупые вопросы работодателей?
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 10281
