Кстати, был когда-то негативом, смог исправиться. Путь — просто перестал говорить нет и всё что начинается с не… Мышление стало меняться то же. Сам себя перепрограммировал :)
Ограничение этой статьи в том что нужно о замыканиях ещё где-нибудь почитать (можно по имеющимся в статье ссылкам), с нуля фиг разберешься. Приведенные примеры скорее описывают тонкости, а не сами замыкания.
По противоречиям всё просто :)
а) Наследования, как такового нет, т.е. нельзя определить объект и как в C++ сказать class B: public A{...}. Есть прототипы, через которые можно сделать «почти» то же самое, об этом и писал :)
b) Я писал о пример — в примере выше конструктора не было, а далее я привел пример именно с конструктором
хотел написать ответ, уже закончил и увидел ваш комментарий :) добавить нечего :)
я много дискуссий вел со сторонниками комментариев, автодокументирования, в коде и все примеры сводились к выше приведенному, ну кроме уж совсем смешных, например: // конец цикла for
и тем не менее, справедливости ради, я скажу, что комментарии я пишу, там где используется хак или «костыль». Сразу же создаю баг на себя с меткой рефакторинг и даю ссылку в коде на него иногда включаю комментарий из бага
Спасибо! Вы правы, я it-директор :) и всё же нахожу время программировать в своё удовольствие на JavaScript + jQuery — делаю прототипы для проектов которыми управляю.
Программировал бы на рубине :), но как-то проектов не попадалось :)
> делите сложный код на много методов, другое?
я не смогу написать лучше чем лучшие в своих книгах уже написал Мартин Фаулер «Рефакторинг. Улучшение существующего кода» ISBN 5-8459-0579-6, ISBN 0-321-12742-0 и после рекомендую, его же, «Архитектура корпоративных программных приложений, Patterns of Enterprise Application Architecture» ISBN 5-8459-0579-6, ISBN 0-321-12742-0
> можно ли пример посмотреть?
там есть примеры, но если вам интересно присылайте код, попробую порекомендовать, что-нибудь
> каким образом вы комментируете сложные/«не красивые» участки кода?
комментирую я только хаки или те места которые нет времени делать красиво и приходиться делать подпорки (костыли)
выглядит это как ссылка на багтрекер, где описан баг специально созданный под этот случай (в момент написания костыля или хака). Иногда я включаю формулировку бага в комментарий со ссылкой.
таким образом я получаю задание переписать этот участок кода и комментарий с описание что я собираюсь сделать и зачем + место где я могу обсудить проблемное место с другими членами команды
Во-первых, нужно понять почему он бегает. Возможны варианты: жмут сроки; он не понимает что вы делаете; у него есть для вас «своя» задача.
1. Я говорю одним предложением о том чем занимаюсь сейчас, максимально понятно и без терминологии. Т.е. о результате моих действий и когда он этот результат получит.
2 Если у него «своя-очень-срочная-задача». Тогда у менеджера есть выбор или прервать выполнение вами текущей задачи или не мешать :)
3. В любом случае предлагайте варианты с описание результатов и сроков, когда они будут.
Любой менеджер, кроме клинических случаев, не будет делать хуже проекту, важно доверять своему менеджеру, т.к. он знает о проекте и его развитии гараздо больше.
Я надеюсь на их либерализм :) конг-фу конечно имеет отношение к боевым искусствам и всё же… Люблю сравнивать совершенство навыков в чем бы то ни было с конг-фу.
Не я один такой. В первую очередь, потому что восхищаюсь конг-фу не только как боевым искусством, сколько как искусством вообще.
нет не думал, но в первый момент, когда прочитал Ваш коммент, показалось что описался. Воображение нарисовало другой head-line: К! и! нг-фу поддержки проектов
кстати, также кот есть у Шрёдингера, им тяжело встретиться, и легко подружиться :)
интересно, есть ещё животные у великих?
Кстати, был когда-то негативом, смог исправиться. Путь — просто перестал говорить нет и всё что начинается с не… Мышление стало меняться то же. Сам себя перепрограммировал :)
рекомендую прочитать статью: «The power of NO» почему-то не сомневаюсь что она доставит Вам удовольствие %)
все языки являются надстройками для создания байт кода :)
Илья Кантор молодец, респект и уважуха :)
имел честь с ним работать, профи!
Ограничение этой статьи в том что нужно о замыканиях ещё где-нибудь почитать (можно по имеющимся в статье ссылкам), с нуля фиг разберешься. Приведенные примеры скорее описывают тонкости, а не сами замыкания.
По противоречиям всё просто :)
а) Наследования, как такового нет, т.е. нельзя определить объект и как в C++ сказать class B: public A{...}. Есть прототипы, через которые можно сделать «почти» то же самое, об этом и писал :)
b) Я писал о пример — в примере выше конструктора не было, а далее я привел пример именно с конструктором
1. Я не отрицал, а наоборот подчеркивал (4ртый абзац и далее)
2. можно говорить о наследовании прототипов, а не классов. Я это то же писал
3. буду рад увидеть ваш вариант и убрать свой :) О недостатках и достоинствах я не писал вообще, только о разнице :)
у Вас комментарий в стиле «The power of NO» получился %)
я много дискуссий вел со сторонниками комментариев, автодокументирования, в коде и все примеры сводились к выше приведенному, ну кроме уж совсем смешных, например: // конец цикла for
и тем не менее, справедливости ради, я скажу, что комментарии я пишу, там где используется хак или «костыль». Сразу же создаю баг на себя с меткой рефакторинг и даю ссылку в коде на него иногда включаю комментарий из бага
Программировал бы на рубине :), но как-то проектов не попадалось :)
> делите сложный код на много методов, другое?
я не смогу написать лучше чем лучшие в своих книгах уже написал Мартин Фаулер «Рефакторинг. Улучшение существующего кода» ISBN 5-8459-0579-6, ISBN 0-321-12742-0 и после рекомендую, его же, «Архитектура корпоративных программных приложений, Patterns of Enterprise Application Architecture» ISBN 5-8459-0579-6, ISBN 0-321-12742-0
> можно ли пример посмотреть?
там есть примеры, но если вам интересно присылайте код, попробую порекомендовать, что-нибудь
> каким образом вы комментируете сложные/«не красивые» участки кода?
комментирую я только хаки или те места которые нет времени делать красиво и приходиться делать подпорки (костыли)
выглядит это как ссылка на багтрекер, где описан баг специально созданный под этот случай (в момент написания костыля или хака). Иногда я включаю формулировку бага в комментарий со ссылкой.
таким образом я получаю задание переписать этот участок кода и комментарий с описание что я собираюсь сделать и зачем + место где я могу обсудить проблемное место с другими членами команды
Когда бегает :) я рассказвываю ему правду :)
Во-первых, нужно понять почему он бегает. Возможны варианты: жмут сроки; он не понимает что вы делаете; у него есть для вас «своя» задача.
1. Я говорю одним предложением о том чем занимаюсь сейчас, максимально понятно и без терминологии. Т.е. о результате моих действий и когда он этот результат получит.
2 Если у него «своя-очень-срочная-задача». Тогда у менеджера есть выбор или прервать выполнение вами текущей задачи или не мешать :)
3. В любом случае предлагайте варианты с описание результатов и сроков, когда они будут.
Любой менеджер, кроме клинических случаев, не будет делать хуже проекту, важно доверять своему менеджеру, т.к. он знает о проекте и его развитии гараздо больше.
надеюсь я ответил :)
и Спасибо :)
Не я один такой. В первую очередь, потому что восхищаюсь конг-фу не только как боевым искусством, сколько как искусством вообще.