собачники против кинофобов
- Автор темы grigori
- Дата начала
Redjik, извените, а более простой вариант не рассматривался?
PHP:
class Filesystem{
public function __call( $m, $args ){
if(in_array( $m, array('mkdir', /* просто перечислить методы с 104 по 1590 строку */ ) )){
set_error_handler(function($errno, $errstr){
//throw Exception::factory($errstr,$errno);
echo $errno.' '.$errstr; // тестил ))
});
$result = call_user_func_array($m,$args);
restore_error_handler();
return $result;
}
}
}
Redjik
Джедай-мастер
Из-за невнятного теста ошибки - на любую ошибку получаем
Код:
root@ubuntu:/tmp# php -r "var_dump(filemtime('/tmp/teste'));"
PHP Warning: filemtime(): stat failed for /tmp/teste in Command line code on line 1поэтому я открывал поток и делал fstat, 90 процентов ошибок вылезут уже при открытии потока
Redjik
Джедай-мастер
Отлично, а главное конструктивно все обьяснил.
Все? Больше не чешется, ЧСВ то? Так ты не стесняйся - чеши сильнее, у нас же не хабр - тут можно!
блин, так и тянет прокомментировать в тему ))) но без политики: есть другой опыт, решают не стандарты кодинга, решает проработка бизнес-логики и архитектура, стабильность есть когда ей уделяют внимание, а разные стили скобок уживаются отлично
Вурдалак
Продвинутый новичок
Мой опыт говорит об обратном, если человек не в состоянии принять соглашения по коду и пишет по-своему, то не случится и чудес в понимании более высокоуровневых вопросов. В программировании очень важны скрупулезность и педантичность.
Дьявол в мелочах. Сегодня ты назвал переменную не совсем правильно, отражающую суть не очень точно, или даже с ошибкой, завтра эта переменная с именем попала в public API, послезавтра ты будешь объяснять клиентам, что название не совсем корректное, потом будешь менять API, поддерживать BC. Название переменной — это ни разу не архитектурный вопрос, тут нужно проявить достаточную скрупулезность, чтобы дать коллеге понять, что он пишет херню и пусть это поправит.
Дьявол в чёртовых мелочах. Сегодня ты пишешь $userRepository->getUserByName() throw new UserNotFound, а завтра — с return null. Это же не Java, сам язык не будет следить за соблюдением контрактов во многих случаях. Нужно быть педантичным, чтобы в yet another time нажать на reject в code review, даже если тут говорят, что задача очень критичная и вот уже скоро deadline.
Дьявол в этих ваших мелочах. Сегодня ты юзаешь новомодный foo()['bar'], а завтра вообще не заботишься об API своего класса, потому что можно написать getMess()['anything']. Нужно сразу бить по зубам.
Дьявол в мелочах. Сегодня ты назвал переменную не совсем правильно, отражающую суть не очень точно, или даже с ошибкой, завтра эта переменная с именем попала в public API, послезавтра ты будешь объяснять клиентам, что название не совсем корректное, потом будешь менять API, поддерживать BC. Название переменной — это ни разу не архитектурный вопрос, тут нужно проявить достаточную скрупулезность, чтобы дать коллеге понять, что он пишет херню и пусть это поправит.
Дьявол в чёртовых мелочах. Сегодня ты пишешь $userRepository->getUserByName() throw new UserNotFound, а завтра — с return null. Это же не Java, сам язык не будет следить за соблюдением контрактов во многих случаях. Нужно быть педантичным, чтобы в yet another time нажать на reject в code review, даже если тут говорят, что задача очень критичная и вот уже скоро deadline.
Дьявол в этих ваших мелочах. Сегодня ты юзаешь новомодный foo()['bar'], а завтра вообще не заботишься об API своего класса, потому что можно написать getMess()['anything']. Нужно сразу бить по зубам.
Последнее редактирование:
Я с вами абсолютно согласен. (С) Легко давать в зубы на форуме.
Будете очень долго искать сотрудников с такими понтами: и грамотность, и скурпулезность, и переменные чтоб называл по-твоему, и хотел сделать лучше, а по факту возьмете живого обычного человека. Один из 30 join напишет, и его берете. Пару раз "в зубы" - всем пока и спасибо за рыбу, а вы просрали все полимеры.
У меня паренек один, отличный математик и алгоритмист из пригорода, писал "пожайлусто", и переменные называл так же. Уволить его за это? Да щаз!
В реальности проекты живут на коде с разными стилями фигурных скобок, с костылями и переменными на транслите. Влияние стиля кодинга на успех проекта не стоит преувеличивать.
Будете очень долго искать сотрудников с такими понтами: и грамотность, и скурпулезность, и переменные чтоб называл по-твоему, и хотел сделать лучше, а по факту возьмете живого обычного человека. Один из 30 join напишет, и его берете. Пару раз "в зубы" - всем пока и спасибо за рыбу, а вы просрали все полимеры.
У меня паренек один, отличный математик и алгоритмист из пригорода, писал "пожайлусто", и переменные называл так же. Уволить его за это? Да щаз!
В реальности проекты живут на коде с разными стилями фигурных скобок, с костылями и переменными на транслите. Влияние стиля кодинга на успех проекта не стоит преувеличивать.
Последнее редактирование: