Comments 9
впрочем, я бы оставил такой вариант:
onReady = (function(ie){
var d = document;
return ie ? function(c){
var n = d.firstChild;
(function(){
try{
c(n.doScroll('left'))
}catch(e){
setTimeout(arguments.callee, 10)
}
})();
} :
/webkit|safari|khtml/i.test(navigator.userAgent) ? function(c){
(function(){
/loaded|complete/.test(d.readyState) ? c() : setTimeout(arguments.callee, 10)
})();
} :
function(c){
d.addEventListener("DOMContentLoaded", c, false);
}
})(/*@cc_on 1@*/);
onReady = (function(ie){
var d = document;
return ie ? function(c){
var n = d.firstChild;
(function(){
try{
c(n.doScroll('left'))
}catch(e){
setTimeout(arguments.callee, 10)
}
})();
} :
/webkit|safari|khtml/i.test(navigator.userAgent) ? function(c){
(function(){
/loaded|complete/.test(d.readyState) ? c() : setTimeout(arguments.callee, 10)
})();
} :
function(c){
d.addEventListener("DOMContentLoaded", c, false);
}
})(/*@cc_on 1@*/);
Насчет самого метода — ок.
Однако, смотря на одну из предыдущих тем, хочется сказать,
что подобное применение тернарного оператора ничуть не способствует читабельности кода, наоборот.
Однако, смотря на одну из предыдущих тем, хочется сказать,
что подобное применение тернарного оператора ничуть не способствует читабельности кода, наоборот.
«читабельность» понятие субъективное ;) Да, с первого взгляда весь «путь» не просмотреть если глаз привык к «простым» структурам, когда начинаешь сталкиваться с вышеприведенными конструкциями чаще, то и «читабельность» их изменится.
Существует такое понятие, как "стиль" кода ;)
То, что можно научиться разбирать и чертовски запутанные идиотские конструкции в любом из языков, сомнения не вызывает, опыт есть. Не говорю ж, что "ничерта не понятно" ;).
Однако это не аргумент — надо упрощают жизнь, а не усложнять.
Например, можно использовать только while/switch, не пользуясь for/do/if, не в том же собака зарыта.
Здесь тернарный оператор совсем не к месту: читаемость усложняется, ни скорость выполнения кода, ни его понимания не увеличивается. Плюсов-то нет.
То, что можно научиться разбирать и чертовски запутанные идиотские конструкции в любом из языков, сомнения не вызывает, опыт есть. Не говорю ж, что "ничерта не понятно" ;).
Однако это не аргумент — надо упрощают жизнь, а не усложнять.
Например, можно использовать только while/switch, не пользуясь for/do/if, не в том же собака зарыта.
Здесь тернарный оператор совсем не к месту: читаемость усложняется, ни скорость выполнения кода, ни его понимания не увеличивается. Плюсов-то нет.
В этой теме можно спорить бесконечно... да, есть понятие «стиль» кода, но он определяется соглашением группы программистов. Понимаете? Приняла группа — изволь следовать, если состоишь в этой группе. Если же ты сам себе кузнец то и крутиться можешь как угодно ;) Шучу конечно, но... не могу я понять эти заявления «читабельность усложняется»! Для кого усложняется? Для вас? Или для всех? Мне, например, что так легко прочитать, что иначе и еще найдется n-цать человек которые и не обратят внимание на «читабельность», а будут смотреть на само решение. А «к месту» или «не к месту» это уже автор решает, ибо у каждого свой «стиль» ;) Вот я могу 99% дать за то, что в вашем написании кода есть элемент который, допустим, я или не приемлю вообще или не пользуюсь.
Словом не нужно смотреть на крошки, просто ешьте хлеб.
Словом не нужно смотреть на крошки, просто ешьте хлеб.
я бы, вклиниваясь в диалог, с вами поспорил.
по поводу вашего комментария
а) крошки надо стирать со стола, причины, думаю, объяснять не надо ;)
б) множество людей приемлет любой вариант, а другое множество не четко структурированный код будет изучать дольше; если первому множеству не важно, может стоит потратить минуту ради второго?
мое же мнение - демонстрируя код, надо описывать алгоритм программы, пользуясь каноническими if/for/while/etc в нужных местах, это ведь демонстрация
а конечная реализация все равно будет зависеть от разработчика и будет скорее всего сильно ужата до нечитабельности (убраны лишние пробелы/скобки)
по поводу вашего комментария
а) крошки надо стирать со стола, причины, думаю, объяснять не надо ;)
б) множество людей приемлет любой вариант, а другое множество не четко структурированный код будет изучать дольше; если первому множеству не важно, может стоит потратить минуту ради второго?
мое же мнение - демонстрируя код, надо описывать алгоритм программы, пользуясь каноническими if/for/while/etc в нужных местах, это ведь демонстрация
а конечная реализация все равно будет зависеть от разработчика и будет скорее всего сильно ужата до нечитабельности (убраны лишние пробелы/скобки)
тьфу, не обратил внимания на дату
однако, почитав ваши посты, считаю комментарий очень уместным
когда вы пишете код, это ваш код и ваше дело, как он выглядит
когда же вы выкладываете код для всеобщего ознакомления, стоит все-таки делать его максимально понятным и разложенным по полочкам
однако, почитав ваши посты, считаю комментарий очень уместным
когда вы пишете код, это ваш код и ваше дело, как он выглядит
когда же вы выкладываете код для всеобщего ознакомления, стоит все-таки делать его максимально понятным и разложенным по полочкам
Блин, так не хочу спорить, тем более, что это вызывает значительное количество негатива в мою сторону. Я не теоретик, а практик, который и читал код за многими и читали за мною и понял одну вещь — для начинающего (малоопытного и т.д.) как не расписывай, все равно будет «трудночитаемо», а профессионал смотрит не на оформление, а на идею. В вышеприведенном примере эта идея в паре строчек, а все остальное — это очевидные и общеприменимые вещи (разве что оформляют их по-разному).
идея хороша, спасибо, подумаю над использованием
пока что просто по таймауту проверяю наличие body
пока что просто по таймауту проверяю наличие body
Sign up to leave a comment.
Еще одна реализация DOM onReady