| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > JavaScript: для новичков > Важные моменты в программировании на JavaScript |
| Автор: Aliance 6.6.2005, 22:12 | ||||||||||||
| Думаю, необходимо создать такую тему, где бы описывалось, что нужно знать и помнить человеку, программирующему на JavaScript. Итак, прежде всего это контейнер, в котором все чудо и происходит. Лучше всего писать полностью, так:
Аттрибут type указывает на то, что это сценарий JavaScript (как MIME-тип) Необязательный аттрибут language сообщает веб-браузеру, на каком языке написан сценарий. Это нужно для тех случаев, когда браузеры, не понимающие указанный язык, пропускают этот контейнер. Значения:
Далее, часто возникает ситуация, когда необходимо динамически добавить тег <script>. Обычно дилетанты делают это так:
Но это не есть корректно, т.к. интерпритатор JS, встречая закрывающий тег <script> - прекращает работу сценария, остальное выводится как код HTML. Соответственно правельно будет так:
Далее, стоит комментаровать свои сценарии и делать удобочиваемыми:
можно и нужно записать так:
Не стоит забывать о точкая с запятой в конце каждого оператора (или операции). Вообще, интерпритатор ставит их автоматом, но если вы будете их сами ставить - это облегчит вам жизнь, сделает ваш сценарий более привлекательным и поможет избежать от ошибок. Еще одна интересная история случается, когда в качестве, скажем, индефикатора функции использовать глобальный метод или в качестве имени переменно - зарезервированное слово = то возникает ошибка времени исполнения. У меня такое случалось с таким кодом:
Т.к. do - глобальный метод. Писалось о необходимости в наличии while (do/while - цикл) Итак, постим сюда свои наблюдения и находки, изощрености и прочее. |
| Автор: Opik 6.6.2005, 23:42 | ||||
Не помню, когда именно возникает. Вроде при несовпадении типов, например:
решение:
|
| Автор: Aliance 6.6.2005, 23:52 | ||||
может так:
Но естественно, что результат будет не таким как ожидалось. Описал тут: http://forum.vingrad.ru/index.php?showtopic=54409&view=findpost&p=432827 |
| Автор: Opik 6.6.2005, 23:54 |
| Aliance да, я знаю. а чем плохо, что переменные становятся глобальными? а разница toNumber или parseInt, второе как то мне больше нравится. |
| Автор: Aliance 6.6.2005, 23:55 | ||||
она есть, я приводил примеры. Сам с таким столкнуля =)
Это не плохо. Скорее обычные меры предосторожности. Ведь глобальную переменную создавать нужно только специально. Иначе можно забыть про это и навредить себе 8)) |
| Автор: Opik 6.6.2005, 23:59 |
| Aliance ок, учту. (про глобальные переменные.). Однако parseInt - аналог intval в PHP. Она поступает полностью аналогично. Я выбрал её не случайно. |
| Автор: Sardar 7.6.2005, 01:34 | ||||
Если функция вызовет сама себя рекурсивно или где в других функцих используються те же имена(часто итератор i) то появляються трудно находимые глюки Помимо обьявления локальных переменных в функциях (var peremennaja), не стоит забывать что JS это обьектно - (*) язык (звёздочку понимайте как хотите лишь бы вам думать не мешало
Естественно код становиться короче и проще, ведь код в каждом обьекте будет описывать всё необходимое для работы только с этим "типом" обьекта. Полезно не пользоваться старыми способами адресаций типа: document.all или просто document.что_либо. Во первых это ведёт к не переносимому на новые платформы коду. Во вторых коллекции содержат элементы не только по идентификатору, но и по имени, в результате получаем коллизии имён/ИД. Нет стандартного действия в такой ситуации, браузер может выдать список всех элементов с таким именем/ИД или просто первый встречный элемент. Вывод: задаём уникальные идентификаторы(а это не всегда нужно На счёт идентификаторов третий совет: елси вы генерите скриптом кучу кода(допустим меню), то не задавайте вашим субэлементам идентификаторы типа ("префикс_"+счёчик). Гораздо проще положить все элементы в дополнительный контейнер(например div) и работать с элементами через W3C DOM. Другими словами задайте правильную логичную структуру тому что вы генерите и это сыграет вам на руку. |
| Автор: Dave 28.7.2005, 12:15 | ||||||
то есть в ф-ии когда пишем var variable_name то переменная локальная а если без var то глобальная, я правильно понял ? а как поступить с итератором i в ф-ии чтобы он был локальным? написать предварительно var i =0; ? ...кажется нашел, в ф-ии в цикле можно так написать
|
| Автор: Гость_12345 7.12.2005, 15:14 | ||
| Приёмы в написании кодов JS. Для сокращения длинных записей и улучшения читаемости:
|
| Автор: Гость_12345 7.12.2005, 15:15 | ||
|
| Автор: Sardar 7.12.2005, 17:00 | ||
Не согласен, d менее читаемо чем document, наработано опытом 2) а зачем eval то? 4) одна из самых плохих привычек - опускание кавычек. Такой код не читаем стандартными парсерами, это кстати одна из причин создания XHTML. Совет вем: не опускайте кавычки и не сокращайте логичное и ясное false до !1 5) DOM придумывался как стандартный интерфейс к деревьям документов. Имена методов долзны запоминаться как они есть, т.к. помимо JS есть и другие языки, где W3C DOM актино используеться и имена те же самые. document.getElementById сразу ставит все точки над i, d.ID вводи в заблуждение выигрывая несколько символов в коде... не на том экономишь 7) люблю так писать, но большинство народу не любят такую запись, т.к. менее читаема. Согласен с ними, но по прежнему пишу кратко 9) можно и так alert([12,23,aaa,xxx].join(' ')); с пробелом, кстати технически этот код не обязательно тeрбует больше ресурсов чем просто со строками, в своём Trilobite Scripting Language (скриптовое окружение для eZ80) выбрал стратегию экономить на памяти, с массивом код по идее должен отрабатывать быстрей. Не знаю как реализованно в JS браузера. 10) и зачем эти пару символов экономить, нужно думать над алгоритмом, писать эффективно. Сэкономленные пара байт не заметны для пользователя, даже если он на самом убогом модеме, за то ты сам будешь долго материться если придёться переделывать такой код года через полтора |
| Автор: Ciber SLasH 7.12.2005, 17:34 |
| Полностью согласен с Sardar. 2Гость_12345: Твой код иногда сложновато разобрать, приходится повторно смотреть, что же это за d.<что-то>. Конечно я согласен с: "Если писать только для себя скрипты и разработать определённые правила (типа: d - это document; d.ID - это document.getElementById), то конечно можно писать как можно меньший код, опуская точки с запятой, придумывать ещё какие-то сокращения, бороться за байты в документе... Но если твой код прийдётся смотреть другим людям, то у них явно возникнут проблемы с пониманием твоего кода." |
| Автор: Гость_12345 13.12.2005, 17:43 |
| Sardar: я перечислил выработанные для себя правила, например, знаю, что в своём коде не буду занимать имена d, v, hid, d.ID и некоторые другие под другие переменные. Некоторая надстройка над языком, принятая 1 раз и помогающая не отвлекаться на длинные имена и длинные выражения с длинными именами. У других - другие условности. Когда читаешь чужой код и есть желание разобраться, приходится учитывать. 2) а зачем eval то? Чтобы 1 раз написать вверху кодов, а потом знать, что в каждом обработчике приводится объект event к имени "е". Обработчиков много, и тогда несущественные формальности мешают читать суть. alert([12,23,aaa,xxx].join(' ')); не хочу ради краткости, при отладке. 5) DOM придумывался... document.getElementById), ... Другие языки будут с этими проблемами разбираться сами, а здесь она решается так. > нужно думать над алгоритмом, писать эффективно согласен, а эти приёмы мне помогают читать алгоритм в коде. 4) одна из самых плохих привычек - опускание кавычек. Такой код не читаем стандартными парсерами... пока не использую парсеры и не планирую использовать их, не собираюсь утруждать себя следованию стандартам, написанным не для живого HTML. Так же, как var имя_переменной=...; в функциях. Когда задача перерастёт установленные рамки, это будет заметно по задаче, тогда и переучимся. Пока этого нет, не надо засотрять текст несущественным. Сравните: мы произносим слова так, чтобы это было понятно собеседнику, а не так, как написали бы то же самое в книге, чтобы удовлетворить всем. На этом пути начал Перл, но он же и рухнул под массой условностей - $i="$j$k";print$i; Ничего - взяли лучшее и пошли дальше. Ciber SLasH У меня тоже возникают проблемы, когда экран засорён длинными выражениями с малым содержанием, какого размера экран бы ни был. |
| Автор: Sardar 14.12.2005, 00:50 | ||
| Гость_12345 - явно минималист Интересно что сам таким был, пока не столкнулся с коллективной разработкой. Не под каким либо давлением, а "по собственному разумению" врдруг приходишь к тому что писать нужно ясно и не забывать о коментариях, которые порой больше чем сам код В любом случае я не советую другим пользоваться твоми приёмами, больше проблем.
Код что в eval можно сразу вписать в функцию, всё равно меняться не будет, лишняя потеря в производительности. |
| Автор: Гость_12345 14.12.2005, 13:41 |
| > Код что в eval можно сразу вписать в функцию Когда речь о производительности, а не о наглядности, то другое дело. И d.ID придётся развернуть. О комментариях не забываю, до коллективной работы не доходил. : ) |
| Автор: Innuendo 6.1.2006, 01:43 |
| а вот я часто себя ловил на document.write('text') когда в text были аппострофы.. не понимал где ошибка |
| Автор: Ciber SLasH 26.2.2006, 06:59 |
| 2Innuendo: Ну это не апостроф, а одинарная кавычка, а апостроф имеет код & 096; Кстати, если встречается одинарная кавычка или другие спец. символы, которые портят целостность данных, то эти спец. символы можно экранировать подстановкой перед спец.сим. обратного слэша \. Т.е. будет так: \' А ещё можно обрамить строку, в которой встречается одинарная кавычка, в двойные кавычки: "Д'Артаньян" или 'Д\'Артаньян'. |
| Автор: iamyri 26.3.2006, 09:48 |
| Надо сразу привыкать помещать скрипты в отдельные файлы и закрывать их от роботов. |
| Автор: Vigoroso 5.8.2006, 22:43 |
| что за роботы |
| Автор: Sardar 5.8.2006, 23:07 |
| Поисковые боты, что бы скрипты не индексировали, хотя в этом ничего плохого нет, да и сами боты фильтруют всё кроме основного текста. |
| Автор: skyboy 29.8.2006, 11:14 |
| при создании таблицы методом DOM если создавать: table -> tbody -> tr -> td то всё нормально. А если при создании упустить tbody, то в IE(только в нём) таблица будет 1х1 пиксел размером, а содержимое никак не захочет отобрадаться. |
| Автор: Sardar 29.8.2006, 11:55 |
| skyboy, таблицы вообще тяжёлая вещь в браузерах, потому имеют свой API от W3C (смотрим DOM HTML). Строки лучше вставлять через insertRow, ячейки в строках через insertCell. |
| Автор: skyboy 29.8.2006, 13:40 |
| Sardar, единообразие - хорошая штука |
| Автор: Sardar 29.8.2006, 13:43 |
| innerHTML не переносят, не лечиться, согласно стандарту. Также <table>...</table> вставляемый в innerHTML любого блочного элемента убивает таблицу, лечиться оборачиванием в любой блочный элемент, например <div><table>....</table></div>. Вроде всё |
| Автор: cruelangel 12.9.2007, 22:35 |
| мда... гость - большой любитель спагетти |
| Автор: evilice 21.1.2010, 11:51 |
| сокращать код, конечно, надо! Но делайте это с умом и комментируйте! Так же исользуйте js-библиотеки (prototypeJS, jQuery...) - это упрастит процесс разработки не только Вам, но и другим разработчикам, которым, возможно, придётся разбираться в Вашем коде. + ко всему эти библиотеки прекрасно работают с DOM и AJAX и Вам не придётся изобретать велосипед! На примере prototypeJS: document.getElementById("element") можно заменить на $("element") а document.getElementById("element").value на $("element").value или ещё проще V("element") По поводу if(temp =! 1) Старайтесь не сравнивать разные типы данных! (1 - Integer, false - boolean). Можно, ошибочно, подумать, что temp может принимать значения 2, 3, -100... |
| Автор: popov654 15.8.2011, 17:41 | ||
Мда, тяжёлый случай |
| Автор: webguru 27.2.2018, 20:18 |
| Вот нашел классный материал о объектах и свойстве prototype. http://webdiz.com.ua/glava5-obiekty-v-javascript/rasshirenie-obektov-svoystvo-prototype/ |