Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 30
return [function (c, d) {var a;if(a = c[d][0] || c[d][b]) {f[d] = a;e.push(d);}}, function (a) {a = a.replace(/i``/ig, «i`»);return a.replace(/(©z)(?=[ieyj])/ig, "$2");}];
Зачем вы берете на себя функции минификатора? Вы думаете, что он справится хуже?
Зачем вы пишете комменты какбэ в JsDoc, но на самом деле нет?
Вы не слышали, что код надо иногда сопровождать — фиксить баги, расширять, оптимизировать, портировать, понятие читабельного кода вам не знакомо?
да уж, чего стоит именование переменных. Может это просто слегка деобфусцированный код?
И Вам, доброго времени.
Спасибо за ваше мнение.
Постараюсь ответить по порядку.
1) Логику стараюсь упростить до минимума, только чтобы не перегружать код, и если что-то останется для минимизатора, пусть Crockford или Closure трудятся.
2) Мой шаблон для Far Manager гораздо старше JsDoc, а переписывать лень, так и оставил, не знаю, до этого всем все было понятно, или я ошибаюсь?
3) Насчет читабельности, описание логики алгоритма, храню отдельно, опять-таки, чтобы не перегружать код. Но там нет ничего, что стоило бы внимания, хотя здесь вы наверное правы, у меня привычки астматика (еще с masm 2).
В зависимости от значения параметров.
Собираю таблицу преобразования символов, по ней RegExp, ну и функцию обработки.
Позже прокомментирую код, обещаю;)
Спасибо за ваше мнение.
Постараюсь ответить по порядку.
1) Логику стараюсь упростить до минимума, только чтобы не перегружать код, и если что-то останется для минимизатора, пусть Crockford или Closure трудятся.
2) Мой шаблон для Far Manager гораздо старше JsDoc, а переписывать лень, так и оставил, не знаю, до этого всем все было понятно, или я ошибаюсь?
3) Насчет читабельности, описание логики алгоритма, храню отдельно, опять-таки, чтобы не перегружать код. Но там нет ничего, что стоило бы внимания, хотя здесь вы наверное правы, у меня привычки астматика (еще с masm 2).
В зависимости от значения параметров.
Собираю таблицу преобразования символов, по ней RegExp, ну и функцию обработки.
Позже прокомментирую код, обещаю;)
1) Простите, ничего не понял. Как связаны сложность кода и то, что он у вас написан так, будто вы его уже прогнали через минификатор. И при чем тут Дуглас Крокфорд?
2) Все понятно, только из JsDoc можно сгенерить отдельную страничку с документацией и он поддерживается в некоторых IDE, а это ваше неизвестно что существует только в виде шаблона для Far.
3) Тащить привычки из одного языка в другой надо осмотрительно:) В любом случае, необязательно комментировать каждую строчку, чтобы код был читабелен. Для начала было бы неплохо, если бы на каждой строке была только одна операция и функции и переменные носили осмысленные имена, а не a, b, c, d.
2) Все понятно, только из JsDoc можно сгенерить отдельную страничку с документацией и он поддерживается в некоторых IDE, а это ваше неизвестно что существует только в виде шаблона для Far.
3) Тащить привычки из одного языка в другой надо осмотрительно:) В любом случае, необязательно комментировать каждую строчку, чтобы код был читабелен. Для начала было бы неплохо, если бы на каждой строке была только одна операция и функции и переменные носили осмысленные имена, а не a, b, c, d.
1) Все уже используют свои минификаторы на проектах, включая нормальные сурсы библиотек в сборку — это, как минимум, помогает в отладке. Ну и приятно, когда код библиотеки можно просто прочесть, не продираясь через лес оптимизаций
2) JSDoc — промышленный стандарт, если хотите, чтобы простынка была именно библиотекой, и везде работало автодополнение.
Ну и для библиотеки js хороший тон быть в bower/npm — один package.json скажет больше, чем вот эта шапка комментов.
3) Логику алогритма можно понять, если следить за неймингом и логикой. И писать по какому-нибудь кодстайлу.
+) JS прекрасно работает с UTF-8, нет? Зачем \u?
+) Зачем кому-то тащить ненужный ему македонский? Плюс это усложняет текущий код. Если взять в пример какой-нибудь numeral, вполне можно выделить таблицы локализации в отдельный файл. (что приведет к большей поддерживаемости и возможности заюзать, например, по выбору ГОСТ или ISO)
2) JSDoc — промышленный стандарт, если хотите, чтобы простынка была именно библиотекой, и везде работало автодополнение.
Ну и для библиотеки js хороший тон быть в bower/npm — один package.json скажет больше, чем вот эта шапка комментов.
3) Логику алогритма можно понять, если следить за неймингом и логикой. И писать по какому-нибудь кодстайлу.
+) JS прекрасно работает с UTF-8, нет? Зачем \u?
+) Зачем кому-то тащить ненужный ему македонский? Плюс это усложняет текущий код. Если взять в пример какой-нибудь numeral, вполне можно выделить таблицы локализации в отдельный файл. (что приведет к большей поддерживаемости и возможности заюзать, например, по выбору ГОСТ или ISO)
Спасибо
+) Чтоб хранить в базе данных весь код.
+)
Если взять в пример какой-нибудь numeral, вполне можно выделить таблицы локализации в отдельный файл. (что приведет к большей поддерживаемости и возможности заюзать, например, по выбору ГОСТ или ISO)
Удалите и не используйте македонский (поддержка стандарта) и код это не затронет, таблица кодов в одной переменной используйте хоть с другого сервера и кстати код уже поддерживает выбору ГОСТ и ISO
+)
Если взять в пример какой-нибудь numeral, вполне можно выделить таблицы локализации в отдельный файл. (что приведет к большей поддерживаемости и возможности заюзать, например, по выбору ГОСТ или ISO)
Удалите и не используйте македонский (поддержка стандарта) и код это не затронет, таблица кодов в одной переменной используйте хоть с другого сервера и кстати код уже поддерживает выбору ГОСТ и ISO
Ну вот, например, чтобы это было норм статьей, можно было бы сравнить с уже существующими и инфраструктурно встраиваемыми решениями (которые, кстати, покрыты тестами, но не указывают, какую оф.версию транслита они реализуют)
www.npmjs.com/package/transliterate
www.npmjs.com/packages/translit-ru-ua
www.npmjs.com/package/translitit-engine
и еще www.npmjs.com/search?q=translit
www.npmjs.com/package/transliterate
www.npmjs.com/packages/translit-ru-ua
www.npmjs.com/package/translitit-engine
и еще www.npmjs.com/search?q=translit
Страница кода — это не публикация. Чтобы превратить это в статью должна быть тема (уже есть: транслит), описание задачи, которую решаем, какое-то исследование и решение. Код можно положить на GitHub и дать ссылку на него. Если мы говорим о JavaScript, то сейчас, де-факто, код следует оформлять в виде npm-пакета.
А как же bower?
Спасибо
Насчет оформления исправлюсь.
Задача и была написать оптимизированный по времени и размеру код для транслитерации по стандарту.
Можно положить и на Git но я предполагал что код и его оптимизация и есть тема обсуждения.
Насчет NPM, я не использовал в функции сторонний код поэтому так и оставил, код под ECMA 3,
а если писать под 'нод' или что то еще можно было бы использовать 'Object.keys' и тому подобное я же старался придерживаться ECMA, да и еще, а как быть Googl и mozilla SDK.
Задача и была написать оптимизированный по времени и размеру код для транслитерации по стандарту.
Можно положить и на Git но я предполагал что код и его оптимизация и есть тема обсуждения.
Насчет NPM, я не использовал в функции сторонний код поэтому так и оставил, код под ECMA 3,
а если писать под 'нод' или что то еще можно было бы использовать 'Object.keys' и тому подобное я же старался придерживаться ECMA, да и еще, а как быть Googl и mozilla SDK.
код и его оптимизация и есть тема обсужденияНе совсем. Намного лучше было бы, если бы статья представляла целостное повествование, от идеи до реализации, с элементами кода. В духе «здесь я использовал такое решение JS», «здесь пригодилась такая фишка Unicode» и так далее. Обсуждение строится уже на этом повествовании. В конце можно дать ссылку на репозиторий. Кстати, репозиторий необходим не для выпендрёжа, а для коллаборации: чтобы другие могли воспользоваться тем, что вы достигли, либо прислать вам дополнения.
оставил, код под ECMA 3Это нормально и адекватно в условиях совместимости, и это не противоречит созданию пакета. Пакет нужен не для того, чтобы заточиться под конкретную платформу (ноду, в данном случае), а чтобы формализовать ваши наработки в виде некоторого юнита, у которого будут описаны версия, описание, лицензия, точка входа, что с ним можно сделать, зависимости (если есть). npm, кстати, позиционируется, как пакетный менеджер для всего. И он не прибит гвоздями к ноде, в нём есть поле
engines, которое позволяет указать на каких движках пакет работает или не работает. Пакет можно потом преобразовать для браузера.Кстати, я вчера поискал в npm registry пакет для транслита и не нашёл: два очень старых, неподдерживаемых пакета. Так что ваша работа может оказаться очень полезной, если доведёте до ума.
Спасибо
1) Ну тогда, стоит начать сначала, JavaScript считаю наименее мной изученным языком, да и себя не позиционирую как программиста скорей как сисадмина, но просмотрев избранное своего браузера оказалось, что по MASM, C++, C#, JS, VBS, VB, Linux, железу и т.д. и т.п больше всего ссылок на Хабрахабр.
Почитав хабр и учитывая свои возможности, решил быть хоть чем то полезным, это и была задача.
2) C npm столкнулся только в Node и то для изучения чужого кода. Придется почитать.
Ощущение как у школьника, но буду стараться.
Спасибо, за советы это уже похоже на дискуссию.
Почитав хабр и учитывая свои возможности, решил быть хоть чем то полезным, это и была задача.
2) C npm столкнулся только в Node и то для изучения чужого кода. Придется почитать.
Ощущение как у школьника, но буду стараться.
Спасибо, за советы это уже похоже на дискуссию.
Начните отсюда:
docs.npmjs.com/files/package.json
Если возьмётесь, могу помочь с оформлением пакета и возникающими вопросами (вопросы сюда в лс).
docs.npmjs.com/files/package.json
Если возьмётесь, могу помочь с оформлением пакета и возникающими вопросами (вопросы сюда в лс).
Спасибо
== > Начните отсюда:
Как раз сейчас пытаюсь осмыслить.
== > (вопросы сюда в лс)
Я так понимаю
package.json:
{
«name»: «translit»,
«version»: «0.0.4»,
«description»: «Forward and reverse transliteration according to ISO 9 or ISO 9: 1995 or GOST 7.79-2000 system of A and B»,
«main»: «translit.js»,
«scripts»: {
«test»: "??? — пока не понимаю что туда"
},
«author»: «xguest <xguest@list.ru>»,
«license»: «GPL»
}
Как раз сейчас пытаюсь осмыслить.
== > (вопросы сюда в лс)
Я так понимаю
package.json:
{
«name»: «translit»,
«version»: «0.0.4»,
«description»: «Forward and reverse transliteration according to ISO 9 or ISO 9: 1995 or GOST 7.79-2000 system of A and B»,
«main»: «translit.js»,
«scripts»: {
«test»: "??? — пока не понимаю что туда"
},
«author»: «xguest <xguest@list.ru>»,
«license»: «GPL»
}
Сам использую такой вариант, нашёл где-то в интернете
var toTranslit = function (text) {
return text.replace(/([а-яё])|([\s_-])|([^a-z\d])/gi,
function (all, ch, space, words, i) {
if (space || words) {
return space ? '-' : '';
}
var code = ch.charCodeAt(0),
index = code == 1025 || code == 1105 ? 0 :
code > 1071 ? code - 1071 : code - 1039,
t = ['yo', 'a', 'b', 'v', 'g', 'd', 'e', 'zh',
'z', 'i', 'y', 'k', 'l', 'm', 'n', 'o', 'p',
'r', 's', 't', 'u', 'f', 'h', 'c', 'ch', 'sh',
'shch', '', 'y', '', 'e', 'yu', 'ya'
];
return t[index];
});
};
Спасибо за ваше внимание.
На 20 февраля 2015 23:24 проголосовало 17 человек из них 7 нравиться и 10 не нравиться, в избранное добавили 17.
Насчет замечаний, все конечно в тему, и постараюсь исправить но:
Не хватает комментариев — я не претендовал на обучающий материал — допишу.
Оптимизация, не есть минимизация.
Все остальное есть дело вкуса.
k12th
1) Код потому и простой, что оптимизирован руками. Дуглас Крокфорд и Closure ни причем. Имя Дугласа Крокфорда — упомянул как автора первого минимизатора, с которым столкнулся: github.com/douglascrockford/JSMin.git.
2) JSDoc наверное интересная вещь, но я не переписывал шаблоны так как не хватало описания стандарта. А насчет страницы с документацией, у меня все мои наработки лежат в отдельном MDB и мне все равно, что из него делать: .js; .html или что-то еще. «JSDoc… в некоторых IDE» — Не пользуюсь, мне в фаре комфортней, но это дело вкуса я не осуждаю. Тоже самое насчет привычек.
3) Оптимизация, не есть минимизация.
В этой функции используется максимум 10 ECMA 3 функций, штук 5-6 переменных, не использует сторонних инструкций и функций тем более из NodeJS, а как быть Googl и mozilla SDK. И ещё, что вы подразумеваете под «если бы на каждой строке была только одна операция»
В этой функции используется максимум 10 ECMA функций, штук 5-6 переменных, синтаксис соответствует ECMA 3 и не использует NodeJS, а как быть Googl и mozilla SDK,. И ещё,
что вы подразумеваете под «если бы на каждой строке была только одна операция»
Например тот фрагмент кода который вы привели:
return [ // Возвращаем массив функций
function (c, d) { // c — таблица, d — символ (создаем таблицу и RegExp)
var a; // Создаем временную переменную для хранения символа
if(a = c[d][0] || c[d][b]) { // Если символ есть
f[d] = a; // Добавляем символ в объект преобразования
e.push(d); // Добавляем в массив RegExp
}
}, function (a) { // a — строка (функция пост-обработки)
a = a.replace(/i``/ig, «i`»); // для старославянского и болгарского
return a.replace(/(©z)(?=[ieyj])/ig, "$2"); // правило использования символа «c»
}];
кстати оптимизатор переписал бы последнюю функцию как минимум так,
return a.replace(/i``/ig, «i`»).replace(/(©z)(?=[ieyj])/ig, "$2");
а я пропустил.
Вы предполагали эти комментарии?
P.S. Если есть ссылка на описание стандарта JsDoc, бросьте в меня пожалуйста.
На 20 февраля 2015 23:24 проголосовало 17 человек из них 7 нравиться и 10 не нравиться, в избранное добавили 17.
Насчет замечаний, все конечно в тему, и постараюсь исправить но:
Не хватает комментариев — я не претендовал на обучающий материал — допишу.
Оптимизация, не есть минимизация.
Все остальное есть дело вкуса.
k12th
1) Код потому и простой, что оптимизирован руками. Дуглас Крокфорд и Closure ни причем. Имя Дугласа Крокфорда — упомянул как автора первого минимизатора, с которым столкнулся: github.com/douglascrockford/JSMin.git.
2) JSDoc наверное интересная вещь, но я не переписывал шаблоны так как не хватало описания стандарта. А насчет страницы с документацией, у меня все мои наработки лежат в отдельном MDB и мне все равно, что из него делать: .js; .html или что-то еще. «JSDoc… в некоторых IDE» — Не пользуюсь, мне в фаре комфортней, но это дело вкуса я не осуждаю. Тоже самое насчет привычек.
3) Оптимизация, не есть минимизация.
В этой функции используется максимум 10 ECMA 3 функций, штук 5-6 переменных, не использует сторонних инструкций и функций тем более из NodeJS, а как быть Googl и mozilla SDK. И ещё, что вы подразумеваете под «если бы на каждой строке была только одна операция»
В этой функции используется максимум 10 ECMA функций, штук 5-6 переменных, синтаксис соответствует ECMA 3 и не использует NodeJS, а как быть Googl и mozilla SDK,. И ещё,
что вы подразумеваете под «если бы на каждой строке была только одна операция»
Например тот фрагмент кода который вы привели:
return [ // Возвращаем массив функций
function (c, d) { // c — таблица, d — символ (создаем таблицу и RegExp)
var a; // Создаем временную переменную для хранения символа
if(a = c[d][0] || c[d][b]) { // Если символ есть
f[d] = a; // Добавляем символ в объект преобразования
e.push(d); // Добавляем в массив RegExp
}
}, function (a) { // a — строка (функция пост-обработки)
a = a.replace(/i``/ig, «i`»); // для старославянского и болгарского
return a.replace(/(©z)(?=[ieyj])/ig, "$2"); // правило использования символа «c»
}];
кстати оптимизатор переписал бы последнюю функцию как минимум так,
return a.replace(/i``/ig, «i`»).replace(/(©z)(?=[ieyj])/ig, "$2");
а я пропустил.
Вы предполагали эти комментарии?
P.S. Если есть ссылка на описание стандарта JsDoc, бросьте в меня пожалуйста.
проголосовало 17 человек из них 7 нравиться и 10 не нравиться
Потому что все содержимое топика — неподдерживаемый, сложный код,
Код потому и простой
Код не простой, он короткий. И сложный. Даже я со своего опыта не сразу в нем разобрался. А простой код — когда глянешь одним глазком и сразу всё понятно.
Все остальное есть дело вкуса.
Не дело вкуса, а правила хорошего тона. Или пердеть на всю комнату и дурно с такого хихикать — тоже дело вкуса?
Не пользуюсь, мне в фаре комфортней, но это дело вкуса я не осуждаю.
Тогда зачем выкладывали? Вам комфортнее — пользуйтесь. Выкладываете — приведите к общему стандарту.
Оптимизация, не есть минимизация
Не подменяйте понятия, ничего общего с оптимизацией ваш код не имеет. Минимизация — да. Оптимизация — даже близко нет.
В этой функции используется максимум 10 ECMA 3 функций, штук 5-6 переменных
И что? Можно вообще не использовать функции и использовать только четыре переменные, чтобы создать квадратическую сложность алгоритма. Но у вас дело даже не в алгоритме
new RegExp(e.join("|")
Вы весь код запускаете при каждом вызове функции. Более того, прям в коде создаете регулярку. Зачем? Все пред-созданные регулярки браузер компилит заранее и потом просто переиспользует.
var a; // Создаем временную переменную для хранения символа
e.push(d); // Добавляем в массив RegExp
Почему a — символ, e — массив, а d — регексп? Что за извращенная логика? Или вы в первом классе и сдаете знание алфавита? Вам надо не комментировать код, а написать его так, чтобы вопросов не возникало.
что вы подразумеваете под «если бы на каждой строке была только одна операция»
А то, что код не пишется в одну строчку. Тот код для машины, а не для человека:
return [function (c, d) {var a;if(a = c[d][0] || c[d][b]) {f[d] = a;e.push(d);}}, function (a) {a = a.replace(/i``/ig, «i`»);return a.replace(/(©z)(?=[ieyj])/ig, "$2");}];
Мне пришлось пропустить ваш код через jsbeautifier.org/, чтобы хоть как-то его читать.
Подумайте над всем сказанным и перед тем как снова выставлять такое — приведите его в порядок, а не вываливайте кашу.
Спасибо
Меня на такой, комментарий не хватило бы.
Постараюсь, сначала аргументировать ваши замечания, а потом займусь кодом.
1) Насчет проголосовавших, я хотел сказать, что не зависимо от голосования, кто то посчитал его для себя полезным.
2) О простоте кода — это уже философия, считаю в лесу проще заблудится, чем в трех деревьях. Сложный? чем — повторным использованием переменных, отсутствием лишних
проверок, но согласен кое что в коде проработать можно. Мой папа тоже всегда упоминал о своем возрасте и опыте, а когда мне исполнилось примерно столько же, понял, что тогда нужно было согласится независимо от того прав он был или нет. Говорят, это наживное, возможно кому-то и лога отладчика хватает и я им завидую.
3) Насчет вкусов вы по моему передёрнули, или не поняли я имел ввиду, что говорю о функции, а не о том где ее использовать.
4) Насчет, зачем выкладывал, искал более простой вариант, наверное хотел выслушать чье то мнение, я уже пообещал прокомментировать. Может укажите стандарт?
5) Об оптимизации и минимизации, для этого и писал искал более оптимальный вариант, о чем и написано в шапке.
6) ==> Но у вас дело даже не в алгоритме \n RegExp(e.join("|")
А что вас здесь смущает, преобразовать массив в строку с разделителем "|", что в свою очередь для RegExp является символом или. Кстати вы писали почему не выровнены имена переменных по алфавиту, и как раз про 'e' она там внешняя, и при совмещении двух рядов с учетом видимости и алфавита она вышла буквой 'e'.
7) ==> Все пред-созданные регулярки браузер компилит заранее и потом просто переиспользует.
Насколько я помню добиться увеличения скорости можно кэшируя большие данные, мой же код имея в ГОСТ восемь полей и 14 вариантов таблиц не кэширует ничего просто проверяет направление и создает таблицу и RegExp. И это как раз то что хотелось оптимизировать но там только одна проверка, сомневаюсь но думаю что заранее создавать все регулярки уже будет накладно.
8) ==> Почему a — символ,…
а — потому что это единственная локальная переменная в этой функции.
все остальные переменные для нее внешние.
9) ==> А то, что код не пишется в одну строчку.
Тут мой косяк, уже сказал исправлюсь, эти функции пощипал не интересными, и свернул но в принципе то там ни чего и нет.
Еще раз спасибо.
Постараюсь, сначала аргументировать ваши замечания, а потом займусь кодом.
1) Насчет проголосовавших, я хотел сказать, что не зависимо от голосования, кто то посчитал его для себя полезным.
2) О простоте кода — это уже философия, считаю в лесу проще заблудится, чем в трех деревьях. Сложный? чем — повторным использованием переменных, отсутствием лишних
проверок, но согласен кое что в коде проработать можно. Мой папа тоже всегда упоминал о своем возрасте и опыте, а когда мне исполнилось примерно столько же, понял, что тогда нужно было согласится независимо от того прав он был или нет. Говорят, это наживное, возможно кому-то и лога отладчика хватает и я им завидую.
3) Насчет вкусов вы по моему передёрнули, или не поняли я имел ввиду, что говорю о функции, а не о том где ее использовать.
4) Насчет, зачем выкладывал, искал более простой вариант, наверное хотел выслушать чье то мнение, я уже пообещал прокомментировать. Может укажите стандарт?
5) Об оптимизации и минимизации, для этого и писал искал более оптимальный вариант, о чем и написано в шапке.
6) ==> Но у вас дело даже не в алгоритме \n RegExp(e.join("|")
А что вас здесь смущает, преобразовать массив в строку с разделителем "|", что в свою очередь для RegExp является символом или. Кстати вы писали почему не выровнены имена переменных по алфавиту, и как раз про 'e' она там внешняя, и при совмещении двух рядов с учетом видимости и алфавита она вышла буквой 'e'.
7) ==> Все пред-созданные регулярки браузер компилит заранее и потом просто переиспользует.
Насколько я помню добиться увеличения скорости можно кэшируя большие данные, мой же код имея в ГОСТ восемь полей и 14 вариантов таблиц не кэширует ничего просто проверяет направление и создает таблицу и RegExp. И это как раз то что хотелось оптимизировать но там только одна проверка, сомневаюсь но думаю что заранее создавать все регулярки уже будет накладно.
8) ==> Почему a — символ,…
а — потому что это единственная локальная переменная в этой функции.
все остальные переменные для нее внешние.
9) ==> А то, что код не пишется в одну строчку.
Тут мой косяк, уже сказал исправлюсь, эти функции пощипал не интересными, и свернул но в принципе то там ни чего и нет.
Еще раз спасибо.
Прокомментирую пункт 8.
Абстрактно.
Сравните код:
Понятно что-нибудь?
Какой понятнее?
«Пишите код так, как будто читать его будет сексуальный маньяк с садистскими наклонностями, и он знает адрес где вы живёте.» (с)
Абстрактно.
Сравните код:
Раз
var a = /(#[0-9a-f]{6})|(#[0-9a-f]{3})|(rgba?\((\d{1,3})\,\s*(\d{1,3})\,\s*(\d{1,3})(\,\s*([0-9\.]{1,4}))?\))|(rgba?\((\d{1,3})\%?\,\s*(\d{1,3})\%?\,\s*(\d{1,3})\%?(\,\s*([0-9\.]{1,4}))?\))/;
var b = c.match(a);
for(var d = 0; d < e; d++){
z[f][v] = b[d];
}
Понятно что-нибудь?
Два
тут не стоило использовать регулярки, конечно
var distanceRegexp = /(#[0-9a-f]{6})|(#[0-9a-f]{3})|(rgba?\((\d{1,3})\,\s*(\d{1,3})\,\s*(\d{1,3})(\,\s*([0-9\.]{1,4}))?\))|(rgba?\((\d{1,3})\%?\,\s*(\d{1,3})\%?\,\s*(\d{1,3})\%?(\,\s*([0-9\.]{1,4}))?\))/;
var matches = value.match( distanceRegexp );
for(var i = 0; i < count; i++){
result[index0][index1] = matches[i];
}
тут не стоило использовать регулярки, конечно
Какой понятнее?
«Пишите код так, как будто читать его будет сексуальный маньяк с садистскими наклонностями, и он знает адрес где вы живёте.» (с)
Спасибо
Согласен с вами.
Не привязывал переменные логически к названию, чтоб не терять возможности повторного использования.
К именованию переменных у меня БЫЛО два подхода.
Не привязывал переменные логически к названию, чтоб не терять возможности повторного использования.
К именованию переменных у меня БЫЛО два подхода.
- При изучения чужого кода и отладке собственного — использую маркеры из "$", "_" и буквы верхнего регистра.
var $A="Marker'$A'";
var _A="Marker'_A'";
var _$A="Marker'_$A'";
- При оптимизации кода — минимальное имя переменной и отсутствие логической привязки названия к значению для временных %TMP% переменных, и их логическая последовательность
Иногда всё же стоит жертвовать повторным использованием в пользу читаемости кода. Ну если вам так критично — попробуйте написать что-нибудь, чтобы такой код:
Превращался в такой:
И читаемо, и переменные повторно используются.
var first = 0;
// ...
var second = 'abc'; // reuse first
alert(second);
Превращался в такой:
var first = 0;
// ...
first = 'abc';
alert(first);
И читаемо, и переменные повторно используются.
P.S.
Если не секрет, зачем всё сообщение писать в спойлере?
Спасибо
В спойлере, чтоб не захламлять топик, и ответы были за вопросами.
Keyten
Если не секрет, зачем всё сообщение писать в спойлере?
В спойлере, чтоб не захламлять топик, и ответы были за вопросами.
var first = 0; // Предположим, что эта переменная действительно 'first'
// со значением типа Number
// ... // здесь что-то происходит возможно, что с 'first'
first = 'abc'; // Меняем тип переменной, и она уже не может быть 'first' скорее 'tmp'
// Это и есть разрыв логической привязки.
alert(first); // Я бы сразу написал alert('abc');
// Не удачный пример, я бы выбрал, что то об обмене значений переменных, и описал бы классический стек.
//
// В моем понимании оптимизация это разумное соотношение размера кода к количеству
// выполненных операций для получения определенной цели. Я стараюсь не использовать
// переменных, которые использоваться однократно, проще интегрировать эти значения в код.
// После того как понимаешь что все переменные на своих местах, начинаю разбираться, а все
// ли переменные и операции мне нужны - это как упростить уравнение, если упрощать нечего,
// начинаю сортировать переменные в порядке использования, а последним шагом сокращаю имена
// переменных и функций.
//
// Постарался полно ответить на ваши вопросы.
k12th Спасибо, С JSDoc пока разбираюсь.
Прокомментировал код, как смог.
Прошу сильно не пинать, это моя первая публикация, и я стараюсь.
Хочу переименовать переменные.
Не привязывал их логически к названию, чтоб не терять возможности повторного использования.
У меня вопрос, а если вы в середине кода понимаете, что переменная больше не нужна, разве ее нельзя использовать повторно?
Прокомментировал код, как смог.
Прошу сильно не пинать, это моя первая публикация, и я стараюсь.
Хочу переименовать переменные.
Не привязывал их логически к названию, чтоб не терять возможности повторного использования.
У меня вопрос, а если вы в середине кода понимаете, что переменная больше не нужна, разве ее нельзя использовать повторно?
Я не уверен, что даже в ассемблере стоит повторно использовать переменные.
Во-первых, это сильно затрудняет понимание кода, а время человека стоит дороже, чем время компьютера, потраченное на выделение памяти. Во-вторых, это экономия на спичках — современные компиляторы/интерпретаторы сами неплохо оптимизируют, особенно если речь о таких высокоуровневых вещах, как JS.
Во-первых, это сильно затрудняет понимание кода, а время человека стоит дороже, чем время компьютера, потраченное на выделение памяти. Во-вторых, это экономия на спичках — современные компиляторы/интерпретаторы сами неплохо оптимизируют, особенно если речь о таких высокоуровневых вещах, как JS.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Translit для JavaScript и ГОСТ-7.79-2000