Однако на Хабре регулярно проскакивают посты про «во, что я придумал, как код писать надо», а там это уже есть ) Так что имхо польза неоценима — и как справочник в том числе.
Я у вас насчитал 14 начертаний шрифтов, отличающихся размером, цветом, стилем. А если учесть баннеры, то и того больше будет. Имхо это можно улучшить и стоит улучшить.
Побродив по сайту, легко понять, что разработка уйдет на аутсорс, и хорошо, если на нее выделят 2-5 миллионов физическому исполнителю (примерная стоимость работ, точно сказать затруднительно). Остальные деньги пойдут на оплату услуг откат-менеджмента.
Тем, что вы пользуетесь наследованием для реализации функционала. В данном случае этот метод не так чтобы плох, потому что функционал сессии логически относится к объекту LightPage, но в случае уже существующего проекта переписывать все страницы, чтобы унаследовать их от LightPage, будет не самой хорошей идеей.
За этот код скажите отдельно спасибо тому, кто не понимает разницы между M, V и C в MVC модели. Дотнет тут не при чем.
Ну а если вам кажется, что «этот их» c# слишком синтаксически мусорный, возьмите Boo (Бу), и используйте его. Boo — почти что питон по синтаксису, и по красоте кода не сильно от руби оторвался.
words = @/ /.Split(«Some long string») # пользуюсь регэкспом прямо в языке
for word in words:
print word
Существует такая вещь, как публичный контракт на библиотеку. Думаю, что он в основном решает эту проблему. То, что код с именованными параметрами становится куда читабельнее, чем без них, перевешивает указанный вами недостаток, но это мое имхо.
Я пишу на с#, и за последние полгода я не помню, чтобы пришлось переименовать параметры public или protected метода в сборке, поставленной на продакшн или в stable-ветке.
Кроме того, в .net достаточно хорошо работает версионирование сборок.
Когда я писал на с и с++, да еще и участвовал в build-team, со сменой интерфейса приходиломь помудохаться, да ) Но с .net этих трудностей не наблюдается. Пока )
>>не прокатывает — во-первых только «некоторые».
идеален только Б-г :)
>>во-вторых — вы всегда запускаете программу во время разработки — вы увидите ошибки, если они есть.
Есть ощущение, что вы не видели программы таких размеров, что пройти по всем веткам становится крайне затруднительно. Unit-test'инг никто не отменял, но все-таки.
>>в третьих — постоянное приведение типов в c# никак не спасает от каста не того объекта не к тому типу. вы пишете программы без кастов? хха!
Пишу. Посчитал специально. За последние написанные ~6000 строк не пользовался ни разу
>>в четвёртых — пишите юнит тесты. ваш код станет лучше.
здесь категорически согласен и не спорю, портя вам удовольствие от пятницы, уж извините :)
Я думаю, что такая ситуация пойдет во благо и заставит людей внимательнее относиться к именованию параметров. Ну и потом, это все отлавливается на этапе compile-time, т.е. до еще до запуска первичных unit-test'ов.
Насколько мне известно, их можно подзаряжать из любого состояния без негативных последствий типа потери емкости или износа рабочего тела; далее, они могут быть сделаны достаточно произвольной формы и толщины, а так же они в настоящий момент самые дешевые по соотношению емкость/стоимость.
>>представлением вызовов методов или бинарных операций в виде дерева
Сложновато завернули. Давайте напишем это как: компилятор строит AST для участка программы и сохраняет его в метаданных, которые потом можно разобрать. Кстати, такое было возможно и в .net 3 (Linq2XXX был построен как раз на нем), только сильно урезано.
>> Новое в generic
Очень сложно пояснили; это называется ковариантностью относительно параметризующих типов. В предыдущем фреймворке она была только для System.Array; теперь и для generic'ов можно указать, нужна она или нет.
По-моему, M$ четко оговорили, в каком случае стоит использовать WebForms, а не лезть за ASP.NET MVC. Так что может и не стоит стремиться к полному переходу? ) Берите от обеих технологий лучшее
Однако на Хабре регулярно проскакивают посты про «во, что я придумал, как код писать надо», а там это уже есть ) Так что имхо польза неоценима — и как справочник в том числе.
webmate.com.ru/ebooks/book410.html
Ну а если вам кажется, что «этот их» c# слишком синтаксически мусорный, возьмите Boo (Бу), и используйте его. Boo — почти что питон по синтаксису, и по красоте кода не сильно от руби оторвался.
words = @/ /.Split(«Some long string») # пользуюсь регэкспом прямо в языке
for word in words:
print word
По поводу ide — я на ревью, например, пользуюсь блокнотом и иже с ним, а не IDE, поэтому и указал, что имхо.
Спасибо за беседу.
Существует такая вещь, как публичный контракт на библиотеку. Думаю, что он в основном решает эту проблему. То, что код с именованными параметрами становится куда читабельнее, чем без них, перевешивает указанный вами недостаток, но это мое имхо.
Я пишу на с#, и за последние полгода я не помню, чтобы пришлось переименовать параметры public или protected метода в сборке, поставленной на продакшн или в stable-ветке.
Кроме того, в .net достаточно хорошо работает версионирование сборок.
Когда я писал на с и с++, да еще и участвовал в build-team, со сменой интерфейса приходиломь помудохаться, да ) Но с .net этих трудностей не наблюдается. Пока )
Какой-то вы неправильный код видели, наверное.
идеален только Б-г :)
>>во-вторых — вы всегда запускаете программу во время разработки — вы увидите ошибки, если они есть.
Есть ощущение, что вы не видели программы таких размеров, что пройти по всем веткам становится крайне затруднительно. Unit-test'инг никто не отменял, но все-таки.
>>в третьих — постоянное приведение типов в c# никак не спасает от каста не того объекта не к тому типу. вы пишете программы без кастов? хха!
Пишу. Посчитал специально. За последние написанные ~6000 строк не пользовался ни разу
>>в четвёртых — пишите юнит тесты. ваш код станет лучше.
здесь категорически согласен и не спорю, портя вам удовольствие от пятницы, уж извините :)
Я думаю, что такая ситуация пойдет во благо и заставит людей внимательнее относиться к именованию параметров. Ну и потом, это все отлавливается на этапе compile-time, т.е. до еще до запуска первичных unit-test'ов.
Вот с dynamic будет сложнее )
Насколько мне известно, их можно подзаряжать из любого состояния без негативных последствий типа потери емкости или износа рабочего тела; далее, они могут быть сделаны достаточно произвольной формы и толщины, а так же они в настоящий момент самые дешевые по соотношению емкость/стоимость.
А я — наоборот :)
>>представлением вызовов методов или бинарных операций в виде дерева
Сложновато завернули. Давайте напишем это как: компилятор строит AST для участка программы и сохраняет его в метаданных, которые потом можно разобрать. Кстати, такое было возможно и в .net 3 (Linq2XXX был построен как раз на нем), только сильно урезано.
>> Новое в generic
Очень сложно пояснили; это называется ковариантностью относительно параметризующих типов. В предыдущем фреймворке она была только для System.Array; теперь и для generic'ов можно указать, нужна она или нет.
Очень громкие заявления для человека, который сам признал, что с asp.net знаком «абы как», вы не находите?