- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
зачем ставить скобку на новой строке ? это некрасиво :)
во-первых если кода много внутри процедуры/ф-ии то скобки открывающая и закрывающая окажутся на одной вертикальной линии что в целом улучашает визуальное восприятие блоков кода.
а во-вторых чтобы объявление ф-ии/метода не прилипали сразу к его содержимому..
имхо вот это все плюсы такого подхода) а вообще, как сказал BrokenBrake дело вкуса!
У меня другой вопрос - сколько должно смениться поколений интернет-программеров, чтобы они наконец просекли фишку и стали ставить открывающую скобку на новой строке? В оффлайн-языках это окончательно стало стандартом лет 15 назад. А в сети - до сих пор корячатся... :-/
Задумался - смешно но: всегда ставлю фигурные скобки отдельной строкой (действительно удобнее читать потом) - КРОМЕ одного случая - в конструкциях типа if / else - ВСЕГДА в строке сразу за условием...
Не знаю почему - но так уж привык... :)
Насчет скобочки:
http://java.sun.com/docs/codeconv/html/CodeConventions.doc6.html#430
if (condition) {
statements;
}
if (condition) {
statements;
} else {
statements;
}
if (condition) {
statements;
} else if (condition) {
statements;
} else {
statements;
}
http://java.sun.com/docs/codeconv/html/CodeConventions.doc5.html#2991
* No space between a method name and the parenthesis "(" starting its parameter list
* Open brace "{" appears at the end of the same line as the declaration statement
* Closing brace "}" starts a line by itself indented to match its corresponding opening statement, except when it is a null statement the "}" should appear immediately after the "{"
class Sample extends Object {
int ivar1;
int ivar2;
Sample(int i, int j) {
ivar1 = i;
ivar2 = j;
}
int emptyMethod() {}
...
}
Для пхп справедливы все те же правила, хотя бы на примере этого проекта.
А во, нашел что-то http://framework.zend.com/manual/en/coding-standard.html
И меня очень раздражают деятели, которые считают, что они самые умные и будут ставить скобки как им угодно. А потом нормальные люди глаза об их код ломают.
Плохо не знать и говорить
http://habrahabr.ru/blogs/php/38214/
Плохо не знать и говорить
http://habrahabr.ru/blogs/php/38214/
Я поправил еще до того, как вы прокомментировали. 😂 Более того, если же код конвеншнс существуют, и вы знаете об их существовании, то почему не следуете им?
Очень-очень самокритично
Задело за живое? Правда она такая, режет всегда. :o
во-первых если кода много внутри процедуры/ф-ии то скобки открывающая и закрывающая окажутся на одной вертикальной линии что в целом улучашает визуальное восприятие блоков кода.
Ну на вкус и цвет - кто к чему привык. Имхо, такое написание только путает.
а во-вторых чтобы объявление ф-ии/метода не прилипали сразу к его содержимому..
В содержимом за объявлением чаще идет описание необходимых переменных ;)
вообще-то это классический стиль. на западе ему даже авторов придумали - типа керниган и ричи так писали свою книгу по си, потому пример не катит.
аллергия к ооп после процедурного программирования мне лично понятна. сам с трудом переходил после процедурного паскаля (да там тоже есть объекты, но тогда я его еще не использовал) в ооп.
после процедурного подхода где как бы и так все получалось трудно привыкать к ооп - сразу лезешь думать в обратную сторону, с мыслями как это решить с парочкой функций. к сожалению хороших примеров сразу так и не найдешь, но постепенно то тут то там перейдешь на ооп.
в пхп, где сразу с чистого листа можно написать что-то работающее, вообще по началу было такое ощущение мол вот она месть ооп-шникам, последний процедурный остров :) но постепенно все равно напишешь свой класс для доступа к базам данных, потом даже узнаешь, что такие классы называют синглтонами (ну так у меня получилось - сначала написал, потом прочитал про всю эту паттернизацию), и что на эту тему придумали кучу названий для шаблонов и т.д.
ну и с новым ооп-подходом в последнем пхп - похоже и тут ооп возьмет верх. ничего личного против ооп, но просто глупо когда пишут целый объект ради одной функции, или класс с кучей статических функций - чем хуже/лучше инклуда файла с кучей функций. имхо, часто объекты ради объектов - мол так принято и т.д.
ну и во многом виноваты книги - там бывают такие примеры на ооп, когда сначала автор ставит себе задачу, которую поставь немного по-другому и все решается темии же функциями. так нет же начинается - абстрактный класс, интерфейс на интерфейсе, кучи вспомогательных классов и т.д. ну и шаблоны вам туда и т.д. и все это с нашими классическими объяснениями про "масштабируемость, упорядоченность, повторное использование кода" и прочие святые фразы...
имхо, на ооп писать надо, но без такого "завзяття" и веры в чудо ооп как это происходит сейчас. а то будут у нас бегать толпы мыслящих паттернами прогеров, всякий процесс норовящие описать с умл и чумовыми диаграммами классов, а вот как дело доходит до банальной задачи, то начинается...
вполне удобно в немаленьких проектах с подключаемыми библиотеками, плагинами, модулями. читабельно и более понятно. бывает изменяешь какой-нибудь большой проект на функциях, там сотни файлов и приходится искать нужную функцию, перерывая все подряд.
В оффлайн-языках это окончательно стало стандартом лет 15 назад.
Потому что эффективность оффлайн-программистов в буржунии измеряется непустыми строками кода ;) Предлагаю прекратить оффтопный холивар про скобки и заняться делом, т.е. холиваром про ООП. Хотите поговорить о скобках - велкам в отдельный топик.
Например, распространенный скрипт подключаемый ко многим сайтам: sape.php
Как тут уже сказали, это не лучший пример ООП. Тем не менее, даже в таком виде он позволяет делать небольшие трюки.
1. Наследуемся от их класса, переопределяем raise_error(), делаем отправку уведомления об ошибке по мылу, или по аське, или запись в лог, или еще что угодно. "Родной" код при этом не меняется, мы можем его обновлять. Это наследование.
2. Другие методы тоже можно переопределять, как именно - вопрос фантазии. Если бы декомпозиция класса была выполнена более аккуратно, вариантов было бы больше. Например, можно сделать, чтоб ссылки брались не из медленного файла, а из какого-нибудь быстрого кэша. Поскольку информация о способе хранения и извлечения данных спрятана за интерфейсом, клиентский код от наших экспериментов не пострадает. Это инкапсуляция.
3. Можно, например, написать адаптер, приводящий вызовы нескольких разных бирж к единому интерфейсу, использовать какой-нибудь порождающий шаблон, чтоб изолировать код, который решает, какая биржа лучше подходит на этой странице (т.е. будет создавать экземпляр нужного класса), и далее во всем клиентском коде отображать ссылки, вообще не имея понятия, откуда они взялись. Это полиморфизм.
Тут можно поспорить, что на функциях можно сделать то же самое.
Во-первых, пример не самый удачный - когда интерфейс по сути состоит из единственного метода, действительно выигрыш не велик. Но это не значит, что ООП плохо, просто этот конкретный класс спроектирован в стиле "минимализм" :)
Во-вторых, даже на этом примере прекрасно видна важная прикладная причина удобства ООП: понятный способ хранения служебных данных, используемых несколькими методами. В функциональном стиле пришлось бы либо засорять глобальную область видимости (жди проблем, например при многократном вызове), либо - таскать между вызовами какую-то структуру, что усложняет интерфейс, требует доп. описания в доках и т.д.
Ну и наконец самый простой, но очень важный аргумент. Сейчас ООП - это не только стандарт технологический, но и стандарт мышления большинства специалистов. Они видят мир в терминах классов и методов. Если ты видишь мир как-то иначе, будет довольно сложно общаться с коллегами и использовать результаты их труда. Это не хорошо и не плохо, просто на сегодняшний день это так. Наверное, потом будет как-то еще.
P.S. Кстати, могу еще рассказать, почему многим пыхарям сложно въехать в ООП. Дело в том, что большинство примеров, удачно иллюстрирующих основные принципы, не слишком применимы в вебе, в силу специфики среды (которая в большинстве случаев - однопоточная, синхронная, и где объекты не существуют на протяжении долгого времени). В вебе приходится иметь дело с абстракциями другого рода, и это сбивает с толку. Я бы, кстати, рекомендовал веб-программистам, желающим въехать в ООП, тренироваться в области JavaScript. Хотя там реализация ООП довольно нетривиальная, реальные практические преимущества подхода, мне кажется, там понять легче.
Потому что функции все-таки жрут в случае пхп раза в 2-3 меньше памяти в целом и все-таки быстрее чем классы.
Хотелось бы посмотреть бенчмарки, желательно с абсолютными величинами. А то по вашим словам может сложиться впечатление, что проект, выполненный в процедурном стиле, только за счет стиля работает втрое быстрее :)