Согласен с вами — именно про это и говорю — ошибки надо стараться исправлять, без фанатизма. Но никак не в открытую на них забивать, да еще и гордиться этим (что уже является другой крайностью).
Ну и я говорил не про вас, а про людей, которые руководствуются принципом «всеравно пешу быстра, пра стондарты и грамматнасть можна ващще не думать» (согласитесь, такое читать не особо приятно? :) Вот по-моему то же самое и с кодом).
Так я говорил не про JS, а про Java :)
С JavaScript, увы, все не так радужно — возможно, есть стандарт кодирования ECMA, но если даже он есть — то его судя по всему мало кто придерживается.
в таком случае использовать для каждого языка какой-то особенный стиль (рекомендуемый для данного языка) будет очень не удобно.
Согласен, вполне возможно. Но лично я такой проблемы не вижу — пишу одновременно на Руби, Питоне, и PHP — и везде стараюсь соблюдать стандарты.
Иногда идет «поток мысли кода» и тут совсем не хочется думать о правильном оформлении оного.
Тут та же проблема, что и с грамотностью — есть ведь такая отмазка как «торопился и не думал об ошибках». :) Но грамотные люди пишут грамотно всегда, вне зависимости от того, торопятся они или нет.
Тут то же самое — писать код нужно всегда правильно и по принятому в языке/компании/проекте стандарту.
В целом — согласен, но по-моему есть еще вариант твердо прописать правила расстановки табов/пробелов в стандартах кодирования языка.
Например, для PHP есть стандарт Zend/PEAR, где регламентируется ставить 4 пробела вместо табов для отступов — но хорошо, если его придерживается хотя бы 10% разработчиков. Поэтому я для PHP отступы предпочитаю делать табами.
Другое дело — Ruby, где за стандарт принято делать отступы двумя пробелами (и, кстати, самого стандарта я не читал — но сразу это понял по исходникам множества библиотек). И код, который не следует этому правилу выглядит просто чужеродно — я даже подозреваю, что такие библиотеки использовать почти никто не будет. Или будут, но только после того, как переделают табы в пробелы :)
P.S. Кстати, есть аналогичная статья от Дмитрия Котерова (широко известного в узких кругах PHP и JavaScript-гуру).
Только хотел запостить ссылку, а вы меня опередили :)
Но у нас похоже мало кто такими тарифами пользуются — многие (и я в их числе) сидят на 3G от госпровайдера — 2 Мбит/сек., по 3 цента (~1 руб.) за мегабайт. А еще совсем недавно из альтернатив был только EDGE со скоростью 160 кбит/сек.
Вы жаву на десктопе кроме убогих программ для бесперебойников, видели?
Как минимум IDE — NetBeans, Eclipse, Aptana, RubyMine/IDEA, и еще с десяток. Игра «Майнкрафт», опять же :)
Я не придираюсь к словам, но Java на десктопе есть. Может, конечно, у нее своя ниша — но она есть.
Java никуда не денется еще очень долго. Слишком много на ней написано.
В принципе, так же как и COBOL — на нем ведь тоже очень многое написано. Тем не менее, сейчас не особо много желающих найдется писать новый софт на Коболе :)
Думаю, та же участь ждет и Java.
Оптимизация — по-моему, это, например, Substitute Algorithm у того же Фаулера.
Использование же «отработавших» переменных — это идиотизм, а не оптимизация (не в обиду будет сказано) :) Нужно не экономить на спичках, а решать реальные проблемы производительности с профайлером наголо — есть ведь замечательные инструменты вроде webgrind.
И оптимизировать отрефакторенный код не в пример легче и проще, чем код, который необдуманно следует всем вышеприведенным советам.
OK, давайте посмотрим Reference на сайте processing.js.
Что есть в processing.js / сравнение с LibCanvas:
1) Расширение стандартных прототипов / Прототипы расширяет MooTools
2) Подсчет framerate'а / LibCanvas.Utils.FpsMeter
3) 2D-примитивы — эллипсы, квадраты, треугольники / LibCanvas.Shapes.*
4) Кривые Безье / LibCanvas.Shapes.Path
5) Построение полигонов через vertex / LibCanvas.Shapes.Polygon
6) Ввод с клавиатуры и мыши / LibCanvas.Interfaces.MouseListener, LibCanvas.Core.Keyboard
7) Трансформации матриц / встроено в классы Shapes
8) Загрузка и отображение картинок / LibCanvas.Context2D.drawImage, LibCanvas.Utils.ImagePreloader
Это все, что есть в Processing.js.
Чего там нет, и что есть в LibCanvas (и это только начало): анимация спрайтов, отрисовка частей изображений (полезно для спрайтов), буферизации и кэширования спрайтов, поведений Linkable, Clickable, Draggable, Droppable, предварительной загрузки изображений.
Теперь, внимание, просьба и одновременно вопрос — покажите мне пожалуйста, в каком месте у processing.js реализован больший функционал?
> Если говорить про игру из поста, то авторы пока что не знают, что такое оптимизация.
Вы хоть скажите, где оптимизировать-то. В коде браузеров? Или автор статьи ответственен за то, что примеры, использующие по большей части экспериментальный компонент Canvas (вы, кстати, в курсе, что релиз HTML5 состоится только в течение 10 следующих лет?) тормозят в вашем браузере и на вашем компьютере?
Как всегда — эксперты на проводе, по делу абсолютно ничего — зато напускной важности — хоть отбавляй.
XP SP3, Opera 10.6, ноутбучный процессор Pentium Dual-Core T4400 — никаких лагов или тормозов не замечено.
Интересно получается — очень большой разброс по результатам скорости у Canvas — у кого-то очень сильно тормозит даже на сильных компьютерах, а у кого-то летает на средних.
Видимо, это можно объяснить только тем, что HTML5 все-таки еще драфт :)
Если пишете в своем стиле — то документируйте его, пожалуйста.
А то вдруг мне придется работать с вашим кодом. :)
Ну и я говорил не про вас, а про людей, которые руководствуются принципом «всеравно пешу быстра, пра стондарты и грамматнасть можна ващще не думать» (согласитесь, такое читать не особо приятно? :) Вот по-моему то же самое и с кодом).
С JavaScript, увы, все не так радужно — возможно, есть стандарт кодирования ECMA, но если даже он есть — то его судя по всему мало кто придерживается.
Согласен, вполне возможно. Но лично я такой проблемы не вижу — пишу одновременно на Руби, Питоне, и PHP — и везде стараюсь соблюдать стандарты.
Тут та же проблема, что и с грамотностью — есть ведь такая отмазка как «торопился и не думал об ошибках». :) Но грамотные люди пишут грамотно всегда, вне зависимости от того, торопятся они или нет.
Тут то же самое — писать код нужно всегда правильно и по принятому в языке/компании/проекте стандарту.
В Java, Python, и Ruby этой проблемы не существует — за игнорирование стандартов, как тут уже сказали, можно получить молотком по пальцам. :)
Например, для PHP есть стандарт Zend/PEAR, где регламентируется ставить 4 пробела вместо табов для отступов — но хорошо, если его придерживается хотя бы 10% разработчиков. Поэтому я для PHP отступы предпочитаю делать табами.
Другое дело — Ruby, где за стандарт принято делать отступы двумя пробелами (и, кстати, самого стандарта я не читал — но сразу это понял по исходникам множества библиотек). И код, который не следует этому правилу выглядит просто чужеродно — я даже подозреваю, что такие библиотеки использовать почти никто не будет. Или будут, но только после того, как переделают табы в пробелы :)
P.S. Кстати, есть аналогичная статья от Дмитрия Котерова (широко известного в узких кругах PHP и JavaScript-гуру).
Попробуйте opera:config#UserPrefs|DimSearchOpacity установить в 0
Рекомендую более легкий и простой MongoODM.
Но у нас похоже мало кто такими тарифами пользуются — многие (и я в их числе) сидят на 3G от госпровайдера — 2 Мбит/сек., по 3 цента (~1 руб.) за мегабайт. А еще совсем недавно из альтернатив был только EDGE со скоростью 160 кбит/сек.
Как минимум IDE — NetBeans, Eclipse, Aptana, RubyMine/IDEA, и еще с десяток. Игра «Майнкрафт», опять же :)
Я не придираюсь к словам, но Java на десктопе есть. Может, конечно, у нее своя ниша — но она есть.
Думаю, та же участь ждет и Java.
Использование же «отработавших» переменных — это идиотизм, а не оптимизация (не в обиду будет сказано) :) Нужно не экономить на спичках, а решать реальные проблемы производительности с профайлером наголо — есть ведь замечательные инструменты вроде webgrind.
И оптимизировать отрефакторенный код не в пример легче и проще, чем код, который необдуманно следует всем вышеприведенным советам.
В общем, «предварительная оптимизация — корень всего зла» © :)
Посмотрите фильм «Вечное сияние чистого разума» :)
Что есть в processing.js / сравнение с LibCanvas:
1) Расширение стандартных прототипов / Прототипы расширяет MooTools
2) Подсчет framerate'а / LibCanvas.Utils.FpsMeter
3) 2D-примитивы — эллипсы, квадраты, треугольники / LibCanvas.Shapes.*
4) Кривые Безье / LibCanvas.Shapes.Path
5) Построение полигонов через vertex / LibCanvas.Shapes.Polygon
6) Ввод с клавиатуры и мыши / LibCanvas.Interfaces.MouseListener, LibCanvas.Core.Keyboard
7) Трансформации матриц / встроено в классы Shapes
8) Загрузка и отображение картинок / LibCanvas.Context2D.drawImage, LibCanvas.Utils.ImagePreloader
Это все, что есть в Processing.js.
Чего там нет, и что есть в LibCanvas (и это только начало): анимация спрайтов, отрисовка частей изображений (полезно для спрайтов), буферизации и кэширования спрайтов, поведений Linkable, Clickable, Draggable, Droppable, предварительной загрузки изображений.
Теперь, внимание, просьба и одновременно вопрос — покажите мне пожалуйста, в каком месте у processing.js реализован больший функционал?
Опера 10.6, загрузка процессора — 50%, тормозит даже больше чем Канвасная версия.
Или вы хотели показать, что векторная графика лучше растровой? :)
Вы хоть скажите, где оптимизировать-то. В коде браузеров? Или автор статьи ответственен за то, что примеры, использующие по большей части экспериментальный компонент Canvas (вы, кстати, в курсе, что релиз HTML5 состоится только в течение 10 следующих лет?) тормозят в вашем браузере и на вашем компьютере?
Как всегда — эксперты на проводе, по делу абсолютно ничего — зато напускной важности — хоть отбавляй.
Я посмотрел код — лично меня что-то не впечатлило.
Интересно получается — очень большой разброс по результатам скорости у Canvas — у кого-то очень сильно тормозит даже на сильных компьютерах, а у кого-то летает на средних.
Видимо, это можно объяснить только тем, что HTML5 все-таки еще драфт :)