Сколько людей — столько мнений. :)
Мне удобнее именовать так. И особенно удачно в сочетании с некими префиксами, например, $countApples = 0 либо, если устанавливаем какой-то флаг, $boolAppleGood = false
И так далее.
Разумеется, я не истина в последней инстанции и мой стиль, возможно, — ущербен. Однако никто не жаловался до сих пор. :)
Я так думаю, стиль переменных зависит от соглашений по форматированию кода, принятого в текущем проекте команды.
Уточню. Даже если вы привыкли именовать переменные, допустим, $this_is_var, но стиль проекта $thisIsVar, то, как ни крути, вам придется принять общие условия.
И да, я придерживаюсь стиля №3, где это возможно.
Я лично склоняюсь к редакторам на основе вики-разметки. Например, textile или markdown.
Просто, удобно, понятно. Основные правила разметки запомнить легко. Особенно в textile.
Хорошая статья, полезная. Кратко и по существу.
Забавно: Pan Africa Market при максимальном приближении находится как раз посредине проезжей части. Небольшая ошибка в координатах? Или все-таки следует делать вычисления с учетом проекции Меркатора?
Они не злодеи. Ведь стили оформления для этого и существуют: для увеличения эфективности командной разработки.
Но, думаю, группа примет какой-то из указанных стилей, лишь с минорными дополнениями. И новичку в группе будет легко втянуться в общие стандарты.
P.s. Сам пользую GForge стиль.
О. Внимательнее присмотрелся: такое впечатление, что рывок у блока получается тогда, когда элемент H3 занимает положение padding-bottom предыдущего элемента P. У высота+паддинг равны 21 px, а padding-bottom предыдущего равен 20 px.
Разумеется, не претендую на правоту. Всего только версия.
Еще советую попробовать Komodo IDE, громоздкий чуть менее, чем Эклипс.
А так, конечно, поддерживаю тех, кто советует Eclipse PDT. Бесплатен, гибок, достаточное количество плагинов, развивается.
Быстро подправить — да.
Эффективность IDE в полной мере раскрывается как раз на громоздких вещах. И да, с не одним десятком классов.
Не вижу ничего зазорного в том, что среда разработки услужливо подскажет переменную в области видимости, автоматически завершит ввод функции PHP или функции, определенной вами и имеющей веселое camelCaseLike-название.
Как минимум, сэкономится время и вероятность механической опечатки уменьшится.
4FXO предполагают минимум 4 аппарата, если непосредственно в гейт. Однако упоминание астериска в сочетании с FXO-железкой позволяет предположить, что будет задействована АТС. В принципе, можно и без астериска :). Но не столь удобно.
По-моему, если «вбивать» эти самые «страшные вещи» без отрыва от земли, закрепляя практикой, то ничего страшного не будет. Особенно, если это все применяется пусть учебном цельном проекте. А не отдельными упражнениями-скриптиками. Тогда у ученика разовьется как бы комплексное видение. Без больших соблазнов «ой, а там легче применить jQuery и не мучаться, все-равно проект сложный».
И да, это мое мнение.
Мне удобнее именовать так. И особенно удачно в сочетании с некими префиксами, например, $countApples = 0 либо, если устанавливаем какой-то флаг, $boolAppleGood = false
И так далее.
Разумеется, я не истина в последней инстанции и мой стиль, возможно, — ущербен. Однако никто не жаловался до сих пор. :)
Уточню. Даже если вы привыкли именовать переменные, допустим, $this_is_var, но стиль проекта $thisIsVar, то, как ни крути, вам придется принять общие условия.
И да, я придерживаюсь стиля №3, где это возможно.
Просто, удобно, понятно. Основные правила разметки запомнить легко. Особенно в textile.
Забавно: Pan Africa Market при максимальном приближении находится как раз посредине проезжей части. Небольшая ошибка в координатах? Или все-таки следует делать вычисления с учетом проекции Меркатора?
Спасибо.
Но, думаю, группа примет какой-то из указанных стилей, лишь с минорными дополнениями. И новичку в группе будет легко втянуться в общие стандарты.
P.s. Сам пользую GForge стиль.
Считаю, что схема и иллюстрации в данной статье — уместны.
Разумеется, не претендую на правоту. Всего только версия.
Может, я неправ, но конфигурация компьютера (немного слабое железо) может влиять на скорость рендеринга?
Ничего личного, конечно.
А так, конечно, поддерживаю тех, кто советует Eclipse PDT. Бесплатен, гибок, достаточное количество плагинов, развивается.
Эффективность IDE в полной мере раскрывается как раз на громоздких вещах. И да, с не одним десятком классов.
Не вижу ничего зазорного в том, что среда разработки услужливо подскажет переменную в области видимости, автоматически завершит ввод функции PHP или функции, определенной вами и имеющей веселое camelCaseLike-название.
Как минимум, сэкономится время и вероятность механической опечатки уменьшится.
И да, это мое мнение.