Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 208
Спасибо, посмеялся, написано великолепно! Вспомнились свои ранние проекты где все кишило подобным. Особой значимостью пользовался пункт «Дублируйте функциональность», а «страшное» слово рефакторинг посылалось далеко-далеко.
Больше вложенных ifов =) чем больше вложенность тем больше + в карму ;)
… запрятанный где-то в глубине иерархии if-ов оператор goto (или break/continue в тех языках, где оператора goto почему-то нет) добавит вашему коду изюминку, а разбирающему его — массу интересных эмоций!
goto — это прошлый век. comefrom — наше всё!
#define true false
Вторая версия:
To Do
< — #define true false -->
< — go to ->
#define false true
Ну и к базе надо обращаться не сколь часто сколь сильно — фильтры на стороне сервера придумали трусы!
Трафик = крутость :)
To Do
< — #define true false -->
< — go to ->
#define false true
Ну и к базе надо обращаться не сколь часто сколь сильно — фильтры на стороне сервера придумали трусы!
Трафик = крутость :)
ну когда сложная логика строится в одном if — тоже не фонтан получается. в проекте, над которым сейчас работаю, есть ряд таких мест — даже трогать боюсь :)
Вообще-то это не так уж и плохо. В процессе разработки такое встречается частенько. Это часто бывает когда знаешь что условий будет несколько, но ещё не знаешь точно какие.
помню, смотрел исходник index.php форума phpBB
там было столько вложенных IF, что я иногда даже терялся
там было столько вложенных IF, что я иногда даже терялся
в #4 я бы добавил:
… В случае, если вы все же используете комментарии, по возможности следите за тем, чтобы они всегда отставали на 2-3 версии от комментируемого кода. Тому, кто будет разбирать ваш код, очень интересно будет проследить ретроспективу сделанных изменений. Возможно, он даже окажется поражен, насколько кардинально вам пришлось переработать ту или иную часть программы. Если вы вместе с кодом обновите и комментарии, как он узнает о вашем титаническом труде?
… В случае, если вы все же используете комментарии, по возможности следите за тем, чтобы они всегда отставали на 2-3 версии от комментируемого кода. Тому, кто будет разбирать ваш код, очень интересно будет проследить ретроспективу сделанных изменений. Возможно, он даже окажется поражен, насколько кардинально вам пришлось переработать ту или иную часть программы. Если вы вместе с кодом обновите и комментарии, как он узнает о вашем титаническом труде?
Чем вам try/catch не угодил? :)
отсутствием log.Write или [re]throw в блоке catch
если код по какой-то причине вылетает — нужно всего лишь обернуть его в try/catch. Это избавит вас от необходимости отладки, а пользователя — от лишних волнений по поводу странных сообщений об ошибках!
try
{
MainLoop()
}
catch
{
// Ничо небыло, небыло н-и-и-ч-его, всё работает как надо, вам показалось
// Бабуськи, бабуськи, бабуськи, *вуи-и-и-и-и-и*
}
{
MainLoop()
}
catch
{
// Ничо небыло, небыло н-и-и-ч-его, всё работает как надо, вам показалось
// Бабуськи, бабуськи, бабуськи, *вуи-и-и-и-и-и*
}
не хочу никого обидеть и упоминание языка связано только с тем, что используемое ПО написано на нем. Да и по вашему примеру похоже на C#. Есть у нас разработчики, которые делают так, которые, наверное, и думают как написано в комментариях кода. Вот только я как пользователь откомментировал бы так:
Ничо небыло, небыло н-и-и-ч-его, НИЧЕГО не работает как надо и вы теперь хрен разберетесь где у меня косяк… (из личного опыта)
Ничо небыло, небыло н-и-и-ч-его, НИЧЕГО не работает как надо и вы теперь хрен разберетесь где у меня косяк… (из личного опыта)
:) спасибо за идею, сам бы не догадался весь mainloop завернуть :)
Прекрасный вариант если вы будете информировать пользователя, что данные успешно записались в БД:
$query = «insert into table_name values(1,1,1)»;
try {
mysql_query($query, $MySQLlink);
} catch (Exception $e) {
//Какая-то ошибка
}
echo «Все успешно записалось!»;
Пользователь будет всегда уверен в вашем приложении и корректности его действий!
$query = «insert into table_name values(1,1,1)»;
try {
mysql_query($query, $MySQLlink);
} catch (Exception $e) {
//Какая-то ошибка
}
echo «Все успешно записалось!»;
Пользователь будет всегда уверен в вашем приложении и корректности его действий!
одно дело реагировать на ошибку, совсем другое — просто ее закрывать
Он не был оформлен в цикле, вызывающем рекурсивную функцию, скорее всего… Это просто недопустимо с точки зрения описанного выше подхода к проектированию.
Интересно, что бы было в блоке catch программы управления ядерным реактором какой-нибудть Терра-электростанции…
Боже. Вы вскрыли, что-то невероятно опасное :)
Плохо, когда программисты забывают о возможных проблемах любой строчки кода.
Плохо, когда программисты забывают о возможных проблемах любой строчки кода.
было очень приятно почитать. про убийство переменных — не могу согнать идиотскую улыбку до сих пор с лица
Спасибо!) Кое с чем приходилось сталкиваться =)
Теперь я знаю как получить в карму плюсик :)
Благо ни разу не встречал ни чего подобного (кроме отсутствия документирования нечитабельного кода), и если честно я не подозревал что некоторые моменты реально встречаются в жизни.
А ваш этот контрактер не студент случайно?
Я, поначалу, тоже допускал в своей практике глупости, но, буквально, за пару месяцев усиленной практики, избавился от всего (разве что не научился нормальные доки писать — чисто психологически не могу — напрягает, но стараюсь)
А ваш этот контрактер не студент случайно?
Я, поначалу, тоже допускал в своей практике глупости, но, буквально, за пару месяцев усиленной практики, избавился от всего (разве что не научился нормальные доки писать — чисто психологически не могу — напрягает, но стараюсь)
>> Я, поначалу, тоже допускал в своей практике глупости, но, буквально, за пару месяцев усиленной практики
ну так может быть его пара месяцев еще не прошла…
ну так может быть его пара месяцев еще не прошла…
везёт вам. лично встречал в production коде 10, 7, 4, 3, 2. И это ещё не предел.
Лично встречал в production коде все 10, до 8 в пределах одного проекта :)
а, так Donnie Garvich — это вы!
что, серьезно называют переменные именами героев фильма? не верю!..:)
Ну именами героев — такого есс-но не бывает, но не говорящие названия встречаются очень часто, вот например цитата из одной CMS, где я с этим встретился в последний раз:
Если как используются docstart, adm и edit еще можно что-то предположить — то остальные переменные… Так вот в данном случае уж лучше-бы они назывались именами героев фильмов :)global $c, $cl, $h, $u, $l, $docstart, $su, $s, $pth, $tx, $edit, $adm, $cf;
#2 — мне больше всего нравится, как пользователю. Жмешь на кнопку и не поймешь в чем дело.
По-моему в ХабраЮмор будет логичнее поместить. За топик спасибо :)
10 способов… я знаю как минимум 100 и активно их применяю!
#N Никогда, слышите, НИКОГДА не применяйте ООП в проекте. Использование функционального, а лучше вообще линейного подхода придаст Вашему коду особый шарм и привлекательность. Если же по тем или иным религиозным причинам, Вам всё таки пришлось пользоваться функциями, разносите их как можно дальше от того места, где они используются.
Оптимальным вариантом будет тот, в котором функция будет принимать как минимум двадцать разношёрстных аргументов и, в зависимости от их вида и состава возвращать совершенно непредсказуемый набор данных. В некоторых случаях можно даже чуть-чуть приправить это всё функцией rand() для придания особого вкуса и аромата.
Оптимальным вариантом будет тот, в котором функция будет принимать как минимум двадцать разношёрстных аргументов и, в зависимости от их вида и состава возвращать совершенно непредсказуемый набор данных. В некоторых случаях можно даже чуть-чуть приправить это всё функцией rand() для придания особого вкуса и аромата.
Сразу видно что ООП вы совсем не понимаете, наследовать надо ВСЁ!!! БД от конфигурации, шаблонизатор от БД, контроллер от шаблонизатора — вот тогда все это будет гибко и удобно, все под рукой! А самый первый класс конечно-же нужно от исключения наследовать, чтобы можно было сделать так:
throw $this; // Не ожидали?
Ну в рабочем проекте конечно было поскромнее :) Абстрактный контроллер наследуется от смарти, сам в себе методов контроллера не содержит, зато содержит методы работы с БД, ну и от него уже контроллеры страниц, с экранированием данных в конструкторе, когда их вызывалось несколько — то и данные несколько раз экранировались, на сложной странице массив пост был экранирован 14 раз, чтобы совсем безопасно было :)
А исключения там по-умному использовались:
А исключения там по-умному использовались:
try {
if(!isset($_POST['data'])) {
throw Exception;
}
$data = $_POST['data'];
} catch(Exception $e) {
$data = NULL;
}
Убили
всё, я не могу больше смеяться
руки трясутся )
руки трясутся )
Самое главное в нашем деле- забыть к чертовой матери про инкапсуляцию. Сделайте все поля public, а заодно наклепайте одноименных свойств объекту. Мы же свободу действий- человек должен иметь право творить с объектом все что он хочет!..
А еще делайте объекты, которые делают всё. Нет, вы не поняли. Вообще ВСЁ! Если описываете объект стол, то интерфейс «Собрать, Разобрать, ПоставитьНаСтол»- жадность. Пусть стол еще сам определяет поверхность на которой стоит, свойства грунта, плотность атмосферы, и силу ветра в соседней стране.
А еще делайте объекты, которые делают всё. Нет, вы не поняли. Вообще ВСЁ! Если описываете объект стол, то интерфейс «Собрать, Разобрать, ПоставитьНаСтол»- жадность. Пусть стол еще сам определяет поверхность на которой стоит, свойства грунта, плотность атмосферы, и силу ветра в соседней стране.
«Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.»
эммм, а вы вообще смотрели на эту «иконку»?
херню написал, какая иконка?! Смотрели левее ника автора, там какбе ссылка на оригинал.
Скажу в обвинение возмущающегося — каждый топик-перевод начинается с этого вот брызганья слюной по поводу того что дескать топик-перевод не похож на топик-перевод, и на каждый такой комментарий отвечают и про иконку, и про ссылку на авторский текст — но как-бы все равно в каждом следующем топике переводе появляется новый бэтмен, возмущающийся попранием авторского права. Доколе? Whyyouwannakillme? :)
Ну недоработка интерфейса — это-же не вина автора перевода. Можно понять людей которые не задумываясь обращаются к переводчику как к автору текста, как раз таки из-за недоработки интерфейса, они при этом никого не обвиняют, но когда человек готов перерыть пол-интернета в поисках оригинала, ради того только чтобы написать "%username% — ты казёл!", вместо того чтобы разглядеть повнимательнее сам топик — я этому не вижу оправданий :)
Ну безусловно, сколько-либо заметная надпись «перевод» решила-бы эту проблему.
Но тут в принципе мне, я так думаю, понятна позиция разработчиков, мне вот лично при прочтении топика в первую очередь интересен текст топика, и что уж скрывать, мне абсолютно наплевать кто его написал, но если уж текст покажется мне настолько интересным что я захочу найти другие статьи автора — то единственное место где я могу это сделать — та самая панелька с ником автора, датой и кнопками голосования, и у топиков-переводов там как раз таки находится ссылка на оригинал, ч.т.д. :) Ведь даже если топик — не перевод — не будешь-же громогласно объявлять в комментариях: «Автор, поди сюды, пости мне ссылки на остальные твои статьи! Быро!». То есть когда есть заинтересованность в авторстве статьи — есть только один способ его узнать.
Но тут в принципе мне, я так думаю, понятна позиция разработчиков, мне вот лично при прочтении топика в первую очередь интересен текст топика, и что уж скрывать, мне абсолютно наплевать кто его написал, но если уж текст покажется мне настолько интересным что я захочу найти другие статьи автора — то единственное место где я могу это сделать — та самая панелька с ником автора, датой и кнопками голосования, и у топиков-переводов там как раз таки находится ссылка на оригинал, ч.т.д. :) Ведь даже если топик — не перевод — не будешь-же громогласно объявлять в комментариях: «Автор, поди сюды, пости мне ссылки на остальные твои статьи! Быро!». То есть когда есть заинтересованность в авторстве статьи — есть только один способ его узнать.
вы вроде как давно на хабре, а о топиках переводах не знаете? иконка Z-Я означает что это топик перевод, в конце топика возле ника опубликовавшего есть ссылка на оригинал.
Прежде чем возмущаться, посмотрите на значок рядом с заголовком, а затем на строку под тегами.
#8 — достаточно спорный способ облажаться. Конечно в приведенном примере это вполне себе способ, но на практике бывает иначе, и если есть хитрый плагин который решает задачу, и пусть он дает еще 2-3 новые фичи, которые толком никому не нужны — лучше воспользоваться им и просто убрать эти 2-3 фичи, если уж совсем не нужны. Почему? Ну хотя бы потому-что изобретать велосипеды не хорошо. Да и потом, разве легче будет разобраться с куском доработанного кода для WYSIWYG? чем с более навороченным редактором или плагином таблиц для этого редактора?
ох… вспоминается:
#define true false // удачного дебага
или
#define true ((rand() % 2? true: false)
#define true false // удачного дебага
или
#define true ((rand() % 2? true: false)
О да. Спасибо автору, очень сильно улыбался. Но не оттого что смешно. А потому что 1:1 описан софт, с которым я работаю по долгу службы. Нет, правда. Такое ощущение, что «афтар» действительно держал ваш списочек под руками.
От себя могу добавить еще кое что:
1) Используйте новые технологии! На дворе 21 век! Какое нафиг MFC и Дельфи! Тащите в проект как можно больше всего нового и интересного! Пусть часть страниц будет генерироваться в jQuery, часть прямо в коде библиотек, часть в БД (а чего она простаивает большую часть времени, столько же денег на сервер потратили). Все будут восхищаться тем, какой крутой ваш проект и как в нем органично сочетается все новое. Разумеется вы гуру, поэтому будете применять даже то, о чем прочитали лишь сегодня на хабре. Продакшн просто создан для обкатки всего нового!
2) COM объекты это просто рай! Их должно быть побольше! Нужно установить соединение? COM объект! Нужно сообщить об ошибке? COM объект! Нужно обработать миллион записей из базы? Ну, вы поняли… Да, обработчики тоже должны быть COM объектами и лежать в базе в виде dll. Ну и что, что четырехъядерный сервер будет ложиться при пяти клиентах. Зато вы поддержите технический прогресс! А переносимость тут вообще непричем. Я и слова-то такого не знаю.
3) Контроль версий? Вы о чем? Настоящие индейцы пишут программу одним махом и никогда не делают ни форков, ни резервных копий дерева. Бранч для слабаков!
4) Побольше велосипедов! Новые технологии это конечно здорово, но вы же знаете что у них есть фундаментальный недостаток — его писали не вы (ну да, это уже копипаст)! В общем не унывайте. Если вам нужен архиватор, нет ничего лучше чем написать его самому. Скриптинг тоже хорошо. Но для полноты ощущений надо сделать свой собственный ЯП! Ну вы же знаете, что если вы хотите сделать что-то хорошо, надо сделать это самому. Так что, смелее товарищи! Топчите батоны пачками. Аминь.
От себя могу добавить еще кое что:
1) Используйте новые технологии! На дворе 21 век! Какое нафиг MFC и Дельфи! Тащите в проект как можно больше всего нового и интересного! Пусть часть страниц будет генерироваться в jQuery, часть прямо в коде библиотек, часть в БД (а чего она простаивает большую часть времени, столько же денег на сервер потратили). Все будут восхищаться тем, какой крутой ваш проект и как в нем органично сочетается все новое. Разумеется вы гуру, поэтому будете применять даже то, о чем прочитали лишь сегодня на хабре. Продакшн просто создан для обкатки всего нового!
2) COM объекты это просто рай! Их должно быть побольше! Нужно установить соединение? COM объект! Нужно сообщить об ошибке? COM объект! Нужно обработать миллион записей из базы? Ну, вы поняли… Да, обработчики тоже должны быть COM объектами и лежать в базе в виде dll. Ну и что, что четырехъядерный сервер будет ложиться при пяти клиентах. Зато вы поддержите технический прогресс! А переносимость тут вообще непричем. Я и слова-то такого не знаю.
3) Контроль версий? Вы о чем? Настоящие индейцы пишут программу одним махом и никогда не делают ни форков, ни резервных копий дерева. Бранч для слабаков!
4) Побольше велосипедов! Новые технологии это конечно здорово, но вы же знаете что у них есть фундаментальный недостаток — его писали не вы (ну да, это уже копипаст)! В общем не унывайте. Если вам нужен архиватор, нет ничего лучше чем написать его самому. Скриптинг тоже хорошо. Но для полноты ощущений надо сделать свой собственный ЯП! Ну вы же знаете, что если вы хотите сделать что-то хорошо, надо сделать это самому. Так что, смелее товарищи! Топчите батоны пачками. Аминь.
Можно контакты Вашего контрактора узнать, чтоб если что, то сразу к профи? )))
1. Критерии WHERE для SQL запросов лучше всего забивать в значение полей формы.
2. Глобальные переменные наиболее гибки и универсальны, какой смысл использовать локальные?
3. Зачем усложнять логику приложения, если многие вещи, такие как удаление пользователя, вполне реализуемы Smarty-плагином?
4. Нужно четко следовать соглашениям, по понеденьникам называть функции через_подчеркивание, по вторникам в camelCase, по средам можнослитно, в четверг функции писать грех, обходитесь без них.
5. К коммитам нужно писать комментарии, вариант some changes наиболее универсален.
2. Глобальные переменные наиболее гибки и универсальны, какой смысл использовать локальные?
3. Зачем усложнять логику приложения, если многие вещи, такие как удаление пользователя, вполне реализуемы Smarty-плагином?
4. Нужно четко следовать соглашениям, по понеденьникам называть функции через_подчеркивание, по вторникам в camelCase, по средам можнослитно, в четверг функции писать грех, обходитесь без них.
5. К коммитам нужно писать комментарии, вариант some changes наиболее универсален.
И не забывайте про обфускацию :)
Есть такая классическая книжка С.Макконнелла — «Совершенный Код». У данного фундаментального труда есть одно неоспоримое преимущество: увесистым томиком очень удобно бить разработчиков, которые следуют указанным в топике советам.
Нанесенные телесные повреждения, обычно, способствуют улучшению ситуации с кодом. ^_^
Нанесенные телесные повреждения, обычно, способствуют улучшению ситуации с кодом. ^_^
10 заповедей говнокода.
в индусском коде популярны такие конструкции:
if (someExpression)
{
// code
}
else
{
// точно такой же code
}
Дайте картинку из топика покрупнее
хотел попросить тоже самое.
Это покромсаная Airplane safety brochure from Fight Club
Посчитал, что будет уместна к такой теме :)
Посчитал, что будет уместна к такой теме :)
даааа… ни кому не пожелаешь встретиться с таким произведением искусства
до сих пор помню, как копаясь в каком то билинге нашли шикарнейшую конструкцию:
запрос к базе Select 1 from user; // да да да, именно 1 едеиничка!
далее все это принимаем в массив
затем еще раз проходим по массиву и делаем users=user+элемент массива (который единичка)
в общем страшно =)
запрос к базе Select 1 from user; // да да да, именно 1 едеиничка!
далее все это принимаем в массив
затем еще раз проходим по массиву и делаем users=user+элемент массива (который единичка)
в общем страшно =)
хочется добавить пару пунктов.
1. разнести функционал который может выполнять один класс на 2-3 класса, с перекрёстными ссылками друг на друга
2. использовать по больше интерфейсов, причем каждый интерфейс пусть реализовывается только одним классом — это очень удобно отлаживать, нажимаешь на «показать реализацию», а IDE тебя в интерфейс бросает
3. использовать магические числа почаще. типа так: executeSomething(-12);
4. инкапсуляция это не для нас. методы нельзя вызывать простым someObject.executeSomething(), это будет слишком просто. метод надо вызывать так:
someObject.executeSomething(anotherObject.getSomeSettings(object3.staticField)). Таким образом мы убъём сразу трех зайцев — разработчика, администратора и саппорт.
5. в ссобщениях пользователю обязательно должны присутсвовать слова «инициализация», «дескриптор», «процессор».
6. очень важно чтобы в вашей программе был хотябы один цикл на 1000 строчек, пара модулей с 3-5 классами которые модифицируют приватные поля дружественных классов и по больше методов на 100-200 строк.
7. к каждому методу и классу неплохо было бы дописать коментарии вот такого вида
// конструктор [для конструкторов]
// получение серверного времени [ для метода getServerTime() ]
// менеджер печати [для класса PrintManager]
и на последок совет: пишите побольше своего кода. много, очень много кода. фреймворки придумали враги.
1. разнести функционал который может выполнять один класс на 2-3 класса, с перекрёстными ссылками друг на друга
2. использовать по больше интерфейсов, причем каждый интерфейс пусть реализовывается только одним классом — это очень удобно отлаживать, нажимаешь на «показать реализацию», а IDE тебя в интерфейс бросает
3. использовать магические числа почаще. типа так: executeSomething(-12);
4. инкапсуляция это не для нас. методы нельзя вызывать простым someObject.executeSomething(), это будет слишком просто. метод надо вызывать так:
someObject.executeSomething(anotherObject.getSomeSettings(object3.staticField)). Таким образом мы убъём сразу трех зайцев — разработчика, администратора и саппорт.
5. в ссобщениях пользователю обязательно должны присутсвовать слова «инициализация», «дескриптор», «процессор».
6. очень важно чтобы в вашей программе был хотябы один цикл на 1000 строчек, пара модулей с 3-5 классами которые модифицируют приватные поля дружественных классов и по больше методов на 100-200 строк.
7. к каждому методу и классу неплохо было бы дописать коментарии вот такого вида
// конструктор [для конструкторов]
// получение серверного времени [ для метода getServerTime() ]
// менеджер печати [для класса PrintManager]
и на последок совет: пишите побольше своего кода. много, очень много кода. фреймворки придумали враги.
Накипело?
нажимаешь на «показать реализацию», а IDE тебя в интерфейс бросает
какая-то у вас странная IDE. не то что бы я работал с большим количеством IDE, но eclipse же показывает нормально и объявление, и реализацию
какая-то у вас странная IDE. не то что бы я работал с большим количеством IDE, но eclipse же показывает нормально и объявление, и реализацию
Спасибо, посмеялся :).
7 пункт, каюсь ибо грешен. Вечная моя проблема стараться закоментировать заголовки всех методов
/**
* Get Product Id by SKU
*
* @param string $productSku sku of product
* @return array[product id, store_id], or null if product not found or condition not equal
*/
private function getProductIdBySku($productSku)
/**
* Get Product Id by SKU
*
* @param string $productSku sku of product
* @return array[product id, store_id], or null if product not found or condition not equal
*/
private function getProductIdBySku($productSku)
Почему не упомянут адский замес html и php кода на одной странице?
Автор пропустил много интересного.
Автор пропустил много интересного.
Понравился стиль написания =) Приятно было читать.
А вообще всегда надо контролировать процесс… это реалии.
А вообще всегда надо контролировать процесс… это реалии.
Идеальная инструкция. Завтра же заменю предыдущую :)
Представляю какая веселуха будет, после хорошенького внедрения функционального программирования в бизнес-проекты, с жесточайшими рекурсиями и веселыми лямбдами.
Думаю статью стоит дополнить реальными примерами.
govnokod.ru/
govnokod.ru/
Придумайте свой формат хранения данных. Забейте на всякие там XML, JSON и прочую хрень — ну зачем оно Вам? Напишите свой парсер. Ничего не документируйте — Ваш формат ведь простой и понятный!
Едко, но актуально :)
Старайтесь минимизировать количество файлов. Кому нужны огрызки по сто строк? Запихните весь проект в один файл. Идущий за вами будет счастливо поражён и позовёт друзей посмотреть на «смотрите, жмём PageDown, и 20 секунд оно скролится»
К девятому пункту могу добавить совет не закрывать соединение сразу же после получения данных — ведь довольно скоро снова нужно будет обратиться к базе.
А пустые catch'и — дааа, это верх мастерства просто.
Magento видели? — хватить ныть! =)
Омайгадебл :)).
Извините, Вам сюда ;))
а, то есть все остальные советы нормальные, да?
а ведь люди на полном серьезе пишут такие каменты…
Почитайте заголовок…
> Не пытайтесь сохранить информацию о пользователе, вроде «isAdmin», присвоив значение какой-то переменной и используя ее на протяжении всего текущего запроса. Соединяйтесь с базой данных каждый раз, когда вам нужно что-либо узнать о пользователе.
Если доходить до крайностей, то и это и обратное вредно. Если программп полагается для определения прав пользователя только на переменную isAdmin на клиенте, то может найтись тот, кто возьмёт какой-нибудь ArtMoney и пороавит её. Если постоянно хранить все данные в уме, то к концу сеанса можеть стяться что представление программы об объекте неадекватно реальности. В общем надо по ситуации смотреть и во всём знать меру. Перефразируя Эйнштейна, можно сказать что следует делать компоненты на столько незваисимыми на сколько это возможно, но не больше.
Если доходить до крайностей, то и это и обратное вредно. Если программп полагается для определения прав пользователя только на переменную isAdmin на клиенте, то может найтись тот, кто возьмёт какой-нибудь ArtMoney и пороавит её. Если постоянно хранить все данные в уме, то к концу сеанса можеть стяться что представление программы об объекте неадекватно реальности. В общем надо по ситуации смотреть и во всём знать меру. Перефразируя Эйнштейна, можно сказать что следует делать компоненты на столько незваисимыми на сколько это возможно, но не больше.
> +1 в карму, если вы сможете найти плагин, который не делает то, что вам нужно, но предлагает 15 МБ + возможностей, которые вам не нужны, однако которые нельзя убрать. +2 в карму, если документация для этого плагина написана на языке, который вы не знаете.
+3 в карму если Вы работаете программистом не зная английского, +4 в карму если Вы найдёте плагин, для которого нет документации ни на английском ни на русском.
+3 в карму если Вы работаете программистом не зная английского, +4 в карму если Вы найдёте плагин, для которого нет документации ни на английском ни на русском.
+4 в карму — это сила :) Остается только скорбеть о том что PHP не поддерживает локализованное именование переменных, функций и т.п., а-ля:
$суньхуньвчай = new Выньсампей();
> Очевидно, если разбить данные на страницы — все будет прекрасно работать и производительности всегда будет отличной.
С разбивкой на страницы тоже надо меру знать. Лично меня очень задалбывает когда табличка из 100 не слишком больших записей разбивается, скажем, на 5 страниц в гонке за скоростью отдельных запросов не стоит забывать о юзабилити (а я частенько это встречал). Если речь идёт о бизнес-приложении, то в идеале, мне кажется, чтобы при pagination на одну страницу по дефолту выдавалось столько записей, сколько поместится на одной странице при печати, и практически обязательно у пользователя должен быть выбор (например меня всегда напрягало отсутствие в некоторых популярных форумных движках возможности отобразить всю ветку целиком, без pagination).
С разбивкой на страницы тоже надо меру знать. Лично меня очень задалбывает когда табличка из 100 не слишком больших записей разбивается, скажем, на 5 страниц в гонке за скоростью отдельных запросов не стоит забывать о юзабилити (а я частенько это встречал). Если речь идёт о бизнес-приложении, то в идеале, мне кажется, чтобы при pagination на одну страницу по дефолту выдавалось столько записей, сколько поместится на одной странице при печати, и практически обязательно у пользователя должен быть выбор (например меня всегда напрягало отсутствие в некоторых популярных форумных движках возможности отобразить всю ветку целиком, без pagination).
Слишком сложно.
Есть универсальный рецепт «многослойный говнокод»:
1. Сначала пишем побыстрее лишь хоть как-то работало.
2. Никогда не трогаем написанное в первом пункте лишь бы не сломалось.
3. Применяем первые два пункта всегда и везде в проекте.
Результат будет даже круче, чем у автора оригинала.
Есть универсальный рецепт «многослойный говнокод»:
1. Сначала пишем побыстрее лишь хоть как-то работало.
2. Никогда не трогаем написанное в первом пункте лишь бы не сломалось.
3. Применяем первые два пункта всегда и везде в проекте.
Результат будет даже круче, чем у автора оригинала.
Это уже придумано и называется Rapid application development :)
«как писать нечитаемый код (гарантированная работа на всю жизнь ;-)»
www.nestor.minsk.by/sr/2006/02/sr60201.html
www.nestor.minsk.by/sr/2006/02/sr60201.html
— Зачем платить Пете если Вася сделает в три раза дешевле.
…
Петя дорабатывает, нарабатывает, матерится…
PS Ситуация до боли знакомая. Причем мало знающий без опытный заказчик всегда выберет дешевый вариант. Поэтому людям которые хорошо владеют профессией зачастую попадаются такого рода проекты, так как к ним приходят уже на второй раз.
…
Петя дорабатывает, нарабатывает, матерится…
PS Ситуация до боли знакомая. Причем мало знающий без опытный заказчик всегда выберет дешевый вариант. Поэтому людям которые хорошо владеют профессией зачастую попадаются такого рода проекты, так как к ним приходят уже на второй раз.
Эх, радуйтесь что код вообще читаем и разбираем, пусть и с бутылкой. Мне как-то достался почти мегабайт исходников кода, который иначе как бредом я назвать не могу. После трех дней мучительного ковыряния в IDE и с тетрадкой, в которой я кратенько записывал что там творилось, я просто с заказчика вытряс старые требования и переписал его напрочь.
Облажался тот, кому досталось это все разгребать за человеком, который срубил бабки и исчез
Всем известное высказывание Кнута как бы намекает, что #6 это больше вопрос корректного тестирования, нежели производительности.
Не нравится повествования статей таким типом. Типа — уйдем от противного.
Наверное, мне не хватает таблички «Сарказм».
Наверное, мне не хватает таблички «Сарказм».
Остера в детстве не читали, наверно… Это ж классика =)
Читал-не читал, какая разница? Просто говорю, что лично мне не нравятся такие статьи. Просто не интересно учить. Типа подъёбывают. Не люблю подъёбы.
черт, про меня на хабре пишут)
pastebin.ru/312604
Больше for for for!
Больше for for for!
Не выйдет нормальных разработчиков из тех, кому плевать на систему которую они создают и еще больше плевать на необходимость понять зачем, для чего и кому она собственно нужна.
Хороший программист никогда не ставит комментариев в коде, что писалось с трудом, должно пониматься с трудом ©
Хороший программист из каждого класса делает Синглтон.
А если вы флешер, обязательно разносите весь ваш код по кадрам, что бы заказчик понял, как много работы вы проделали.
Спасибо, возьмем на вооружение :)
Обязательно выполняйте SQL запросы прямо в HTML-шаблоне — это прибавит вашей работе монументальности.
Добавьте к третьему пункту:
ОБЯЗАТЕЛЬНО используйте разные имена для переменных пришедших из GET и POST запросов.
ОБЯЗАТЕЛЬНО используйте разные имена для переменных пришедших из GET и POST запросов.
Пишите все имена с маленькой буквы, особенно имена классов, а потом создавайте переменные с таким же именем: user user = new user(); Только представьте сколько времени можно сэкономить забыв про клавишу Shift, а потом потратить его на дублирование функциональности!
Простите что поднял тему, но все-таки… добавлю пару пунктов заказчиков, из которых и вытекает подобное «нытье»… :)
3. Вы заплатили 150$ за сайт, требуйте документацию кода, исходники дизайна, хостинг и техническое сопровождение ресурса минимум на 5 лет.
2. Никогда не обращайтесь к профессионалам, есть ведь Вася Пупкин, который сделает все за 150$;
1. Обращайтесь к профи «все в одном», ведь если один человек делает сайт, значит он лучше всех будет понимать что от него требуется, дизайн, верстка, программирование, и еще только он один сможет вывести Вас на топовые места в поисковиках.
0. Индусы — делают все дешевле, чем Вася Пупкин, поэтому надо еще торговаться, ведь Вы можете нанять их.
Сумбурно, но тему вы поняли…
3. Вы заплатили 150$ за сайт, требуйте документацию кода, исходники дизайна, хостинг и техническое сопровождение ресурса минимум на 5 лет.
2. Никогда не обращайтесь к профессионалам, есть ведь Вася Пупкин, который сделает все за 150$;
1. Обращайтесь к профи «все в одном», ведь если один человек делает сайт, значит он лучше всех будет понимать что от него требуется, дизайн, верстка, программирование, и еще только он один сможет вывести Вас на топовые места в поисковиках.
0. Индусы — делают все дешевле, чем Вася Пупкин, поэтому надо еще торговаться, ведь Вы можете нанять их.
Сумбурно, но тему вы поняли…
) Да уж, Vertex, +1. :)
Насчет 7 пункта можно поспорить. Я, бывает, оставляю «мертвый» код. Или 10 раз переспрашиваю прежде, чем удалить. Бывали красавцы, которые сначала заявляют, что та или иная функция больше не нужна, а через пару недель резко передумывали ) Очень весело потом сидеть с git cherry-pick и ковыряться в логе коммитов…
Насчет 7 пункта можно поспорить. Я, бывает, оставляю «мертвый» код. Или 10 раз переспрашиваю прежде, чем удалить. Бывали красавцы, которые сначала заявляют, что та или иная функция больше не нужна, а через пару недель резко передумывали ) Очень весело потом сидеть с git cherry-pick и ковыряться в логе коммитов…
Каждая функция или метод непременно должны иметь как минимум три точки выхода:
— первый return пусть возвращает boolean
— второй — integer
— третий — структуру.
Не забываем про Exception'ы!
И, чтобы разработчики использующие и поддерживающие этот код окончательно погрузились в транс и нашли путь к просвещению, функция должна возвращать сообщение об ошибках во всех этих четырёх форматах… Например: false, -1, {code: 2345, msg: «Shit happens!»}, (предложите ещё три способа), etc…
***
И помните, каждая функция может определить, что ей сейчас делать путём тонкого исследования call stack'a!
— первый return пусть возвращает boolean
— второй — integer
— третий — структуру.
Не забываем про Exception'ы!
И, чтобы разработчики использующие и поддерживающие этот код окончательно погрузились в транс и нашли путь к просвещению, функция должна возвращать сообщение об ошибках во всех этих четырёх форматах… Например: false, -1, {code: 2345, msg: «Shit happens!»}, (предложите ещё три способа), etc…
***
И помните, каждая функция может определить, что ей сейчас делать путём тонкого исследования call stack'a!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 способов облажаться в программировании