Я мыслил именно в этом направлении, когда сам эту задачку решал :) Но всё равно можно запутаться, если не знать что аргументы становятся локальными переменными ф-ции.
У меня долгое время на при виде таких задач всплывала в голове фраза «Не надо писать странный код», но потом я понял для себя две вещи:
Частенько нам приходится работать с чужим, не всегда годным, кодом, и чем круче скилл «компилирования кода в голове» тем проще проходит этот процесс
Такие вопросы могут показать опыт человека, ибо если человек при виде странного кода сходу говорит, что тут не так и как это исправить — скорее всего он когда-то уже так напоролся и не поленился разобраться в вопросе
раз уж мы говорим об оптимизации стоит убрать, ибо оно ничем не оправдано.
А здесь я бы на вашем месте использовал бы case. Конечно в данном примере это не даст большого выигрыша, но привычка плохая… Ибо на месте массива, может оказаться ёмкий по времени метод, который будет вызываться несколько раз вместо одного.
...
elseif ($this->gif[$this->pnt + 1] == "\xFF") {
...
} elseif ($this->gif[$this->pnt + 1] == "\x01") {
...
/**
А можно так
*/
switch ( $this->gif[$this->pnt + 1] ) {
case "\xFF":
...
case "\x01":
...
}
А вообще, раз уж вы представляте код комьюнити, стоит оформить его, как для комьюнити. Я конечно не говорю о композере, но пхпдоки и человечное форматирование кода, были бы очень кстати, тем более в любой современной IDE, это делается нажатием одного хоткея ;)
Мне в CI нравится работа с БД и роутер и как по мне — для мелких проектов фреймворк вполне годный.
Для всяких крупных и нестандартных штук наверное всё таки лучше Symfony, но я к нему пока не привык.
А полностью писать свой код наверное всётаки не стоит :)
Разработчикам всегда приходится выходить за рамки существующих решений — это не значит что существующие решения не нужно использовать.
Мы же не будем конструировать новый велосипед если нам понадобится прикрутить к нему фонарик :)
Вопрос только в том, что бы правильно выбирать велосипед.
Думаю статья всё же окажется интересна тем, кто ничего об этом не знает, но хочет иметь начальное представление. Да наверное для тех, кто собаку съел в операционных системах она покажется скучной, но, как говорят в моём любимом паблике, это моя первая — не судите строго :)
Но ссылку добавлю — вопросы годные.
Анализаторы использую редко и ИМХО — это плохая практика. Код ревью может быть так же эффективно и при этом приносит пользу всем участникам :)
раз уж мы говорим об оптимизации стоит убрать, ибо оно ничем не оправдано.
А здесь я бы на вашем месте использовал бы case. Конечно в данном примере это не даст большого выигрыша, но привычка плохая… Ибо на месте массива, может оказаться ёмкий по времени метод, который будет вызываться несколько раз вместо одного.
А вообще, раз уж вы представляте код комьюнити, стоит оформить его, как для комьюнити. Я конечно не говорю о композере, но пхпдоки и человечное форматирование кода, были бы очень кстати, тем более в любой современной IDE, это делается нажатием одного хоткея ;)
Для всяких крупных и нестандартных штук наверное всё таки лучше Symfony, но я к нему пока не привык.
А полностью писать свой код наверное всётаки не стоит :)
Разработчикам всегда приходится выходить за рамки существующих решений — это не значит что существующие решения не нужно использовать.
Мы же не будем конструировать новый велосипед если нам понадобится прикрутить к нему фонарик :)
Вопрос только в том, что бы правильно выбирать велосипед.