- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
String.prototype.toCamelCase = function () {
var symbols = [], ready = '';
for (var z = 0; z < this.length; z++) {
symbols[z] = this.charAt(z);
}
for (var i = 0; i < symbols.length; i++) {
if (symbols[i] == '-') {
symbols[i + 1] = symbols[i + 1].toUpperCase();
}
}
for (var q = 0; q < symbols.length; q++) {
ready = ready + symbols[q];
}
ready = ready.replace('-', '');
return ready;
};
Follow us!
Почему, если код без гуру-выебов - то сразу говно? неоптимизированный но понятный код- говно. код, оптимизированный для быстродействия, но нечитаемый - тоже говно. код, оптимизированный по потреблению памяти - опять же говно.
то есть неговнокод написать невозможно: какая нить сука да вякнет, что это неТРУЪ
Да, и ты забыл упомянуть про оптимизированный и читаемый код.
Где ты тут видишь говнокод?
А Lure Of Chaos был прав.
> Да у вас тоже не без говна.
о чем я и говорил: неговнокод написать невозможно
Ну это только у заядлых говнокодеров неполучается.
С чего вы взяли, что это правда?
Я раскрыл свои карты.
У меня конечно нет шансов тебя переубедить, ведь твоё мнение одобрил сам WebKill, программист погромист всех времён и народов.
не призываю писать код левой задней конечностью
нубокодом задача решается в один проход
?
ваш К.О.
Но даже ненавидимые мною экстеншен методы в .NET/CLR и то имеют более приятный синтаксис.
Меня в JS именно синтаксис вымораживает. Хотя и на нем можно писать, и даже привыкнуть -- сам пробовал
Я бы советовал или сделать нормаьный синтаксис для ООП или не поддерживать вовсе эту парадигму.
Ну согласитесь -- идиотизм, когда приватное свойсто пишется как "var m_strProperty", а публичное как "this.m_strProperty", когда объекты называются "function()" и значение "this" зависит от контекста...
Я понимаю что обратная совместимость и все дела, но язык действительно очень некрасивый.
там много всяких "но", ленюсь.
о некрасивости: вы еще duck-типизацию не видели.
В JS тоже типизация утиная -- статической-то типизации в JS нет.
Вообще языки без статической типизации это сакс. Если вам нужно написать больше одной страницы кода, то без статической типизации плохо.
Даже на горячо любимом мною питоне я бы не стал делать крупные проекты.
иногда как раз динамики не хватает. На той же яве приходится выкручиваться средствами рефлексии и динамической компиляции. Хвала, есть груви
На питоне кстати немало успешных крупных проектов
Потому что интерфейсов нет?
>>На той же яве приходится выкручиваться средствами рефлексии
Это, скорее всего, говорит не об очень хорошем дизайне.
Даже кастинг это плохо (со времен генериков) что уж говорить о рефлексии.
>>На питоне кстати немало успешных крупных проектов
Не спорю, один portage чего стоит) Из скриптовых языков питон наверное самый лучший с самой внятной идеологией.
Но я бы не осилил на нем крупный проект, наверное
Ага, "Дзэн Питона". Нехватка идеологии - частая причина сфейленных языков...
Это ирония? Посмотрите на PHP, в котором столько подходов к написанию программ -- сколько школьников приложилось к его использованию. В любом проекте есть восемь разных код-стайлов, немного ООП подхода, немного процедурного, и шесть велосипедов)
>Потому что интерфейсов нет?
нет, не поэтому. А потому, что (почитайте про утиную типизацию) из того, что классы одинаково определены, они еще не равны
при утиной типизации мы бы получили тоже 1
Представить интерфейс значит просто реализовать все методы, без указания "implements" (или ":").
Разве на сравнение это влияет?
вряд ли. Допустим, у коллеги была такая задача:
есть шаблон, абсолютно непредсказуемой формы (скажем, ртф), его нужно заполнить из пришедшего бина (поля могут соответствовать или нет), и выдать заполненный документ (дополнительно что бы был в пдф). Реализовать на яве.
здесь, поскольку свойства бина могут быть любыми, алгоритм должен в конечном итоге использовать рефлексию.
При использовании динамического языка (тот же груви или житон) задача упрощается в разы
В таком случае (боже, что я говорю!) там должен быть Map а не свойства бина) Это лучше, чем рефлексия.
наверное. Но синтаксис, в частности, использование табов в качестве оформителей блоков, меня отвернул от него раз и навсегда еще на этапе изучения
Так вот питон заставляет Вас их делать)
2) >>сел и сходу начал писать"
Дада, F4 в фаре -- и вперед. На PHP так часто пишут
>> Дада, F4 в фаре -- и вперед. На PHP так часто пишут
А что такого - весь пойнт питона в этом - сел и начал сходу писать. Во всей идеологии и структуре это прослеживается (утиная типизация, "динамические" объекты, минимум ключевых слови т.д.) На продумывание и возню с редакторами/синтаксисом/мэйкфайлами всякие с++ придуманы...
Поглядите на пайшарм, серьезно
В принципЕ, есть что-то схожее с явой -- она была сначала интерпретируемая и очень тормозная (особенно на машинах того времени), а сейчас скорость приближается к с++, но от статуса тормозной до сих пор никак не отмоется..
щито?
А вы не знали? о_О До появления HotSpot'а не было джиттинга в натив, ява интерпретировалось байткодину за байткодиной. Прбиавьте сюда процессоры времён середины 90-ых - много fun'а
(пока грузится апплет явы, можно действительно заварить пару чашек кофе ))
Я бы не стал называть этот процесс "интерпретацией".
Схема всегда была одна: код - > opcodes -> jvm.
Просто потом добавили JIT для скорости.
Но может быть я не владею терминологией, конечно
http://en.wikipedia.org/wiki/Interpreter_%28computing%29
И после этого ты не википедик??
Это ничего не говорящая схема, вопрос в том, как называть переходы от одного элемента к другому.
java-код -> opcodes -- это компиляция
opcodes -> jvm это интерпретация
В моно сначала тоже не было джиттера, и штука, которая запускала эксешник, называлась mint = mono interpreter.
Хм.
В таком случае запуск .com файла тоже интерпретация)
Так и есть, цПУ это интерпретатор машинных команд... Просто слово "интерпретация" имеет широкое и узкое значения... Узкое значение проявляется в противопставлении "машинный код" ("компилируенмый" язык) vs "байткод" ("интерпретируемый язык/VM"). А широкое значение когда вообще любой код интерпретируется цпу, в том числе машинный x86...
Я так понимаю...
> В таком случае запуск .com файла тоже интерпретация)
на >WinXP это в любых смыслах явная интерпретация)
2)причем тут xp?
какая разница -- работает процессов режиме real или "virtual 8086"?
В моём посте это значило "Отсутствие джиттинга", конец)
> причем тут xp?
ну так .com'ы во всех виндах после ХР эмулируются (т.е. интерпретируются) внутренней подсистемой недовиртуализации, винда хрен тебе даст прямиком в real лезть. Там инструкции именно что интерпретируются.
Или я ошибаюсь на этот счёт?
читать Basic Architecture и System Programming Guide.
У проца есть режимы работы: real, protected, V86 (виртуальный 8080), еще всякие SMI и 32e, но это к делу не относится.
Винда при загрузке переключает процессор в protected (это делает чуть ли не NTLDR).
Обратно в реал его не вернуть -- тока перезагрузкой, да и не надо это.
Что бы выполнять 16ти разрядный код нужно переключить процессор в режим V86, который для программы выглядит как реал (с некоторыми ограничениями на IN/OUT и другие инструкции, так же ошибки приводят к исключениям (понятие защиненного режима)).
Для этого винда запускает ntvdm.exe, про которого можно почитать у Руссиновича
Они и в хп под виртуальной машиной выполняются.
Инструкции в WinXP выполняются в V86 режиме процессора. Обращение к портам ввода вывода генерят прерывание ошибки недостаточного уровня IOPL для обращения к порту, в котором обработчик решает, как данное обращение к порту переслать реальному виндовому драйверу устройства.
:)))))
"Алиса, никогда не используй слова за то, что они длинные и красивые" (c)
Сопроцессор занимался плавающей точкой, и встроен в процессор со времен 486х.
Никакого специально "VM86 сопроцессора" не существует -- это тот же проц, просто переключенный в другой режим работы.
Википидорить научился?
Сам додумался, прикинь?
Вроде байткод интерпретируется.. А как ещё сказать?
http://en.wikipedia.org/wiki/Interpreter_%28computing%29
Прикинул.
Лять. Ну это вообще пиздец загнул.
Долбоёб. Это трансляция.
> Долбоёб. Это трансляция.
Компиляция и есть трансляция.
"Это яблоко." -- "Долбоёб, это фрукт!"
))))для чего лучше?
Устарет ты чувак.
Потом мне запретили юзать ворованный софт, я пожалел $20, и стал искать алтернативу. Пробовал notepad++, еще всякое -- все не то. В итоге поставил себе gvim, и понял что я дома)))
Все таки VI это прекрасно
А я в нотепаде++ до сих пор.
о, ужас! Вы из тех, кто вместо табов любит делать 4 пробела?
Табы лучше потому, что Вася может настроить редактор на ширину табов в 8 пробелов, а Маша -- на ширину табов в 2 пробела. В зависмости от их вкусов/мониторов/разрешения и зрения. Именно этим табы в тысячу раз лучше пробелов.
>>Да и скобки легче посчитать
В хорошей программе ничего считать не надо -- все и так видно. Если у Вас восемь уровней вложенности, или IF и ELSE разделяют 70 строк кода, или у Вас функция на 4 экрана -- Вам срочно нужно делать рефакторинг!
Если Вы видите "}" и не понимаете -- откуда она -- у Вас некрасивый код)
> Табы лучше потому, что Вася может настроить редактор на ширину табов в 8 пробелов, а Маша -- на ширину табов в 2 пробела. В зависмости от их вкусов/мониторов/разрешения и зрения.
Ага, и если исходник изначально отформатирован определённым образом, то у Маши он может отображаться вкривь и вкось.
Напр. если взять сишное:
у Пети отобразится нормально, а у Маши с её настроенными табами может всё поехать.
Именно этим пробелы в тысячу раз лучше табов (по крайней мере для си).
Да, намного легче визуально воспринимтаь, где начинается блок, а где кончается -- в отличие от каши в явовском гайдлайне.
на самом деле это вопрос код-стайла.
Я пишу на новой везде, кроме джавы (там так принято)
Ну коненчо, в чужий монастырь со своим уставом не лезут.
Однако реально скобка с новой строки выделяется среди прочего кода --и легче воспринимать что где (по крайней мере, мне -- неужели кто-то считает иначе?)
p.s. И рефакторить намного легче -- выделил весб блок и удалил/перенёс/закомментировал, а в яве нужно бороться вручную..
Рефакторить нужно в нормальном IDE. Например в idea есть хоткеи для выделения блока по первой скобке, и хоткей для комментария и вынеса в функцию)
Не нужно прсто изначально придумывать себе проблемы ) Не спорю, что костылей напридумано несчетное количество наверное..
А я всегда делаю так (и для сей тоже)
Это в определении функции.
Мой пример - по вызову. В си такое на каждом шагу (и вообще подобное форматирование). Например, взять CreateProcess. У неё дофига параметров - и правильный код должен каждый параметр прокомментировать. С табами всё превращается в кучу.
Вот напр. пример на MSDN:
Как с "правильно названными параметрами" определить, что NULL в седьмой аргументе говорит о том, что субпроцесс наследует список переменных окружения, а NULL в первом - что нужно игнорировать первый аргумент и использовать второй?
2, 4 это слишком много
Два - слишком мало. В моих косых глазах код начинает путаться.
Для хелловорлда можно и 2, но если имеется комманда, то нужно учитывать всех - т.е. юзать стандартное 4. Это не так много. В ядре линукса юзается 8 -- и даже оно не смотрится ужасно.
Хоть 2 хоть 16 -- табы можно настраивать, как угодно)
так что 2
> так что 2
В жабе принято иметь по два пробела?
Боюсь, закончится это баном и меня(
Это такой INT_MAX
этого не случится, ага