Как выбрать программиста для сайта?

боюсь, что нотисы правильно обрабатывает подавляющее меньшинство прогеров :(

прогер плохо владеет английским

код писали два прогера или один копипастил :)

потенциальные скл-инъекции:

Один, скопипастил из готовАго

Коммент писался, скорей всего, для себя.

можно ли места кода под sql инъекции использовать для снижения стоимости программирования? Я плачу хорошие деньги, на выходе получаю не качественный код. Ведь насколько я понимаю, такие вещи должны быть написаны правильно в базовом варианте кода.

Или программер может сказать, что убрать такие вещи стоит еще столько то денег?

В моем понимании пусть дает скидку, и я на эту скидку должен нанять другого, которые исправит эти косяки, если существующий не может это делать по ходу работы.

Такая логика имеет право на жизнь?

---------- Добавлено 14.05.2016 в 10:36 ----------

Я так понимаю, что эти моменты должны закрываться программистом сразу. Если он этого не делает, значит он просто на это забивает.

Или, если он этого не знает, значит у него просто ультра низкая квалификация. Так?

Backuper, не бывает "плохого" кода, бывает рабочий и не рабочий, уязвимый и малоуязвимый. А если новый программист не понимает что написал старый - то это плохой новый программист.

у меня малоуязвимый или уязвимый?

Допустим, задача Одна.

1 прогер, накодырит 100 строчек.

2 прогер, вложится в 10 строчек.

Оба кода рабочие, но у 1 прогера "плохой" код)

Как то так...

а если кодер кроме 10 строк вкорячил фреймворк на 50 мб + еще десяток популярных библиотек, классов и прочих функций? ))) хотя таких можно считать очень плохими прогерами, согласен, но на их фоне тогда первый прогер с 100 строками будет молодец.

у вас обрывок кода в вакууме. анализировать нужно весь скрипт (cms) в целом, потому что если в указанном куске что-то не экранировано - это не значит, что оно в соседнем куске кода небыло экранировано.

1) Вам выше справедливо указали на отсутствие корректных проверок на валидность входных данных.

2) Моё замечание сходу: в этом коде почему то всё свалено, как я понял, в кучу - и создание контроллера, и обработка запроса, и предметная логика: расчет площади и цены и т.д.

Если первый пункт можно легко поправить, то второй пункт практичеки неисправим в будущем.

А это что?

preg_match("/Необходимая площадь или кол-во паллето мест:<\/strong>(.*?)<br/si", $product_desc, $matches);

Смешивание представления с логикой да еще в куче разношерстного кода? А если эту надпись потребуется в будущем изменить? В логику лезть?

ЗЫ

Что касается выбора программиста, то для меня на первом месте стояло бы - подробное и качественное документирование всего и вся.

foxi, я привел как пример, без "если" и других подводных камней.

А если кодыр, туда еще что то "вковырял" то таким, нужно вообще руки отрывать)

Документирование необходимо как правило только при описании api и других торчащих наружу мест.

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

Нет, не так. Может быть масса причин почему там не видим экранирования. Раз уж я и обрвтил внимание на отсутствие экранирование, то сейчас могу точно так же предположить почему оно там нафиг не нужно.

Ведь переменная в параметр попадает через запрос в функцию , а не через $_GET. И может там функция наследует уже предварительную обработку входных данных и производится экранирование в нужном виде именно там.

Т.е. как сказали выше, надо смотреть код. А пока сиди и гадай на кофейной гуще :)

Исправить конкретную ошибку - да, будет легче. А проанализировать код на предмет ошибок - может запросто оказаться дороже, чем само написание кода.