Поговорим о мелочах
02.06.2003
|
IT |
Я понимаю, что программирование в .NET итак существенно снижает объём набиваемого кода за счёт всяких атрибутов и обширной библиотеки, сводя технические детали реализации многих вещей практически к минимуму. Но, тем не менее, хотелось бы большего... точнее ещё меньшего.
Оставим в покое теже атрибуты и библиотеки и давайте поговорим о мелочах, которые хоть немного могут снизить объём кода и повысить его читабельность (быстродействие и размер откомпилированной программы пока не в счёт).
К чему это я? Надоело постоянно писать:
Как такую проверку сделать короче?
Или вот ещё пример. Такой код в MFC проходит на ура и даёт эксепшин в C#
В результате приходится писать вот такого уродца:
К счастью это можно заменить на
И получится даже короче
Что касается читабельности, то, в частности, я практически полностью перешёл от конкатенации строк к Format, т.е. вместо
пишем
Хоть немножко и длиннее, но гораздо читабельнее, да и всегда можно формат без проблем подправить.
Кроме всего прочего в ближайшее время у меня намечается тотальный переход с ArrayList на наследников CollectionBase и т.п. Всё что нужно сделать — это написать такой класс:
Времени чтобы это скопипейстить нужно не много, но зато потом можно сохранить кучу нервных клеток. К тому же, если кто не в курсе, большинство контролов, которые работают с источниками данных типа DataSet, вполне запросто могут отображать информацию из IList, если у элемента списка отображаемые поля объявлены как public properties. Единственная проблема, если список пустой, то такой контрол не может получить тип элемента. При использовании типизированных коллекций данная проблема решается, т.к. в данном случае берётся возвращаемый индексером тип. Т.е. в большинстве случаев, там где не нужно отображать сложные связи поддерживаемые датасетом необходимость в его использовании и связанный с этим оверхед отпадает.
В принципе, хотелось бы побеседовать на эту тему, узнать кто какие трики использует в повседневной работе, которые могли бы хоть как-то облегчить трудовые будни советских учёных
Оставим в покое теже атрибуты и библиотеки и давайте поговорим о мелочах, которые хоть немного могут снизить объём кода и повысить его читабельность (быстродействие и размер откомпилированной программы пока не в счёт).
К чему это я? Надоело постоянно писать:
void foo(string s)
{
if (s != null && s.Length != 0)
{
...
}
}
Как такую проверку сделать короче?
Или вот ещё пример. Такой код в MFC проходит на ура и даёт эксепшин в C#
string s1 = "123";
string s2 = "12";
if (s2.Substring(0, s1.Length) == s1)
{
}
В результате приходится писать вот такого уродца:
string s1 = "123";
string s2 = "12";
if (s1.Length <= s2.Length && s2.Substring(0, s1.Length) == s1)
{
}
К счастью это можно заменить на
string s1 = "123";
string s2 = "12";
if (s2.IndexOf(s1) == 0)
{
}
И получится даже короче
Что касается читабельности, то, в частности, я практически полностью перешёл от конкатенации строк к Format, т.е. вместо
int i1 = 10;
int i2 = 20;
string s = "Bla-bla " + i1 + " of " + i2;
пишем
int i1 = 10;
int i2 = 20;
string s = string.Format("Bla-bla {0} of {1}", i1, i2);
Хоть немножко и длиннее, но гораздо читабельнее, да и всегда можно формат без проблем подправить.
Кроме всего прочего в ближайшее время у меня намечается тотальный переход с ArrayList на наследников CollectionBase и т.п. Всё что нужно сделать — это написать такой класс:
using System;
using System.Collections;
public class MyTypeCollection : CollectionBase
{
public MyType this[int index]
{
get { return (MyType)List[index]; }
set { List[index] = value; }
}
public int Add(MyType value)
{
return List.Add(value);
}
public int IndexOf(MyType value)
{
return List.IndexOf(value);
}
public void Insert(int index, MyType value)
{
List.Insert(index, value);
}
public void Remove(MyType value)
{
List.Remove(value);
}
}
Времени чтобы это скопипейстить нужно не много, но зато потом можно сохранить кучу нервных клеток. К тому же, если кто не в курсе, большинство контролов, которые работают с источниками данных типа DataSet, вполне запросто могут отображать информацию из IList, если у элемента списка отображаемые поля объявлены как public properties. Единственная проблема, если список пустой, то такой контрол не может получить тип элемента. При использовании типизированных коллекций данная проблема решается, т.к. в данном случае берётся возвращаемый индексером тип. Т.е. в большинстве случаев, там где не нужно отображать сложные связи поддерживаемые датасетом необходимость в его использовании и связанный с этим оверхед отпадает.
В принципе, хотелось бы побеседовать на эту тему, узнать кто какие трики использует в повседневной работе, которые могли бы хоть как-то облегчить трудовые будни советских учёных
02.06.2003 104 комментария |
IT>К чему это я? Надоело постоянно писать:
IT>
IT>Как такую проверку сделать короче?
У меня есть класс Utils со статическими методами, в частности я пишу
Который для строки делает то, что ты написал. Соответственно JIT обычно это инлайнит. Есть версии и для коллекций и т.п.
IT>Что касается читабельности, то, в частности, я практически полностью перешёл от конкатенации строк к Format
IT>
Единственное, что мне не нравится в таких форматах (и иже с ними Console.Write и т.п.), это позиционность параметров. Мне бы в идеале хотелось иметь такое:
Можно это сделать?
IT>Кроме всего прочего в ближайшее время у меня намечается тотальный переход с ArrayList на наследников CollectionBase и т.п. Всё что нужно сделать — это написать такой класс:
IT>
Это правильно, еще бы дженерики и счастье вот оно
IT>Времени чтобы это скопипейстить нужно не много
Визарда написать, что-ли?
IT>В принципе, хотелось бы побеседовать на эту тему, узнать кто какие трики использует в повседневной работе, которые могли бы хоть как-то облегчить трудовые будни советских учёных
Надо подумать, так с ходу не скажу...
O>Единственное, что мне не нравится в таких форматах (и иже с ними Console.Write и т.п.), это позиционность параметров. Мне бы в идеале хотелось иметь такое:
O>
O>Можно это сделать?
А что делать вот с такими вещами? (дублировать полные имена?):
O>Единственное, что мне не нравится в таких форматах (и иже с ними Console.Write и т.п.), это позиционность параметров. Мне бы в идеале хотелось иметь такое:
O>
O>Можно это сделать?
DG>А что делать вот с такими вещами? (дублировать полные имена?):
DG>
Да, что-то не подумал Но можно и позиционный вариант оставить, хотя тогда как отличать {1} в таком случае:
Это первый параметр или константа?
Так что, видать не обойтись без позиционности...
IT>>Кроме всего прочего в ближайшее время у меня намечается тотальный переход с ArrayList на наследников CollectionBase и т.п. Всё что нужно сделать — это написать такой класс:
IT>>
O>Это правильно, еще бы дженерики и счастье вот оно
IT>>Времени чтобы это скопипейстить нужно не много
O>Визарда написать, что-ли?
Написано уже всё.
ArrayList Builder
CollectionBase Builder
DictionaryBase Builder
Stack Builder
IT>>Времени чтобы это скопипейстить нужно не много
O>Визарда написать, что-ли?
ОГ>Написано уже всё.
Я имел ввиду аддин к студии, чтобы сразу New Collection... и новый файл в правильном неймспейсе в нужном месте и появился, со всеми пирогами
O>Я имел ввиду аддин к студии, чтобы сразу New Collection... и новый файл в правильном неймспейсе в нужном месте и появился, со всеми пирогами
Попробуй QuickCode .NET by Development Expertise.
На первый взгляд то, что нужно.
И как раз с Collection пример есть...
O>Здравствуйте, Олег Гашев, Вы писали:
IT>>>Времени чтобы это скопипейстить нужно не много
O>>Визарда написать, что-ли?
ОГ>>Написано уже всё.
O>Я имел ввиду аддин к студии, чтобы сразу New Collection... и новый файл в правильном неймспейсе в нужном месте и появился, со всеми пирогами
Типа такого: http://www.rsdn.ru/File/15309/CollectionAddin.zip ?
O>Я имел ввиду аддин к студии, чтобы сразу New Collection... и новый файл в правильном неймспейсе в нужном месте и появился, со всеми пирогами
Накодировал вчера. Остался вопрос добавление генерируемого файла в проект.
O>Я имел ввиду аддин к студии, чтобы сразу New Collection... и новый файл в правильном неймспейсе в нужном месте и появился, со всеми пирогами
ОГ>Накодировал вчера. Остался вопрос добавление генерируемого файла в проект.
Угу, спасибо, посмотрю попозже сегодня, я тут над другим бьюсь, а именно встраиванием человеческим в студию...
O>Угу, спасибо, посмотрю попозже сегодня, я тут над другим бьюсь, а именно встраиванием человеческим в студию...
Ты делаешь его как Add-ins или New Item? Я тут накапал статью на C# Corner Basics of Extending Your Working Environment in Visual Studio о создании Wizard. О Add-ins можешь почитать Tutorial: Creating Visual Studio Add-Ins.
O>Угу, спасибо, посмотрю попозже сегодня, я тут над другим бьюсь, а именно встраиванием человеческим в студию...
ОГ>Ты делаешь его как Add-ins или New Item?
Сделал как Add-in, сейчас в меню (context menu on project)/Add/ добавляется пункт Code from Template, там дальше выпадающий список имеющихся шаблонов, из шаблона читается список переменных, пока просто отображается в property grid, сейчас после нажатия Ok буду делать генерацию файла с результатом шаблона. Потом добавлю встраивание в Code Editor, чтобы результат шаблона можно было просто в код вставлять, где нужно. Думаю, завтра первая версия будет готова А то уже скоро спать пора, см.ориджин.
ОГ>Написано уже всё.
Ага, ещё 20 лет назад.
ОГ>ArrayList Builder
ОГ>CollectionBase Builder
ОГ>DictionaryBase Builder
ОГ>Stack Builder
В примерах в MSDN к этим классам есть ещё рантайм проверка на соответствие типам. Она, конечно, не всегда нужна, на с какой-нибудь галочкой её можно было бы пришпандорить. А ещё лучше сделать вариаент для DEBUG версии только.
ОГ>Написано уже всё.
IT>Ага, ещё 20 лет назад.
И чего мы здесь тусуемся?
IT>В примерах в MSDN к этим классам есть ещё рантайм проверка на соответствие типам. Она, конечно, не всегда нужна, на с какой-нибудь галочкой её можно было бы пришпандорить. А ещё лучше сделать вариаент для DEBUG версии только.
Давно хотел поизучать DTE, надо поковыряться. Быстрого результата не обещаю, но потыкаюсь. Еще предложения будут?
O>У меня есть класс Utils со статическими методами, в частности я пишу
O>
Тогда туда же
Который бы не кидался исключениями, а возвращал бы 0, если 'o' не int.
O>Единственное, что мне не нравится в таких форматах (и иже с ними Console.Write и т.п.), это позиционность параметров. Мне бы в идеале хотелось иметь такое:
O>
O>Можно это сделать?
Сомневаюсь, для этого нужно переписывать эти функции.
O>Это правильно, еще бы дженерики и счастье вот оно
Ждёмс, всего лишь годик остался
IT>>Времени чтобы это скопипейстить нужно не много
O>Визарда написать, что-ли?
Давай, такой что бы встаивался в студию и генерировал исходник.
IT>
IT>Который бы не кидался исключениями, а возвращал бы 0, если 'o' не int.
Вот не очень нравятся мне такие затычки, хотя иногда полезно. Мы тут как-то с leper ругались на эту тему
Если что не так — фиг найдёшь где проблема. Хотя бы должен быть переключатель, типа бросать исключение или нет... Например, в конфигурации приложения.
O>Единственное, что мне не нравится в таких форматах (и иже с ними Console.Write и т.п.), это позиционность параметров. Мне бы в идеале хотелось иметь такое:
O>
O>Можно это сделать?
IT>Сомневаюсь, для этого нужно переписывать эти функции.
Да понятно, что своё писать, вопрос можно ли вообще такое сделать...
O>Можно это сделать?
IT>Сомневаюсь, для этого нужно переписывать эти функции.
O>Да понятно, что своё писать, вопрос можно ли вообще такое сделать...
Нельзя. Как ты узнаешь в функции имя переменной, особенно локальной?
O>>Единственное, что мне не нравится в таких форматах (и иже с ними Console.Write и т.п.), это позиционность параметров. Мне бы в идеале хотелось иметь такое:
O>>
O>>Можно это сделать?
IT>Сомневаюсь, для этого нужно переписывать эти функции.
Угу, а зоадно и CLR.
IT>>Сомневаюсь, для этого нужно переписывать эти функции.
L>Угу, а зоадно и CLR.
Да-да, и его тоже
IT>Тогда туда же
IT>
IT>Который бы не кидался исключениями, а возвращал бы 0, если 'o' не int.
Идем дальше,
M>
Тогда уж стоит написать десяток перегрузок для double, decimal, float, short и т.п. Пусть распознаётся, это же тоже в каком-то смысле int.
P.S. Хотя, по-моему, лучше забить. Подозрительные какие-то улучшения. Привычки вредные могут появиться.
O>У меня есть класс Utils со статическими методами, в частности я пишу
O>
O>Который для строки делает то, что ты написал. Соответственно JIT обычно это инлайнит. Есть версии и для коллекций и т.п.
Вот такие вещи я жутко не люблю в чужом коде. В смысле когда в одну либу (класс) безо всякой структуризации валят кучу разнородной функциональности. Ты то конечно прекрасно помнишь что у тебя в этом Utils, а вот другому человеку читать такой код сплошное мучение.
AVK>Здравствуйте, orangy, Вы писали:
O>>У меня есть класс Utils со статическими методами, в частности я пишу
O>>
O>>Который для строки делает то, что ты написал. Соответственно JIT обычно это инлайнит. Есть версии и для коллекций и т.п.
AVK>Вот такие вещи я жутко не люблю в чужом коде. В смысле когда в одну либу (класс) безо всякой структуризации валят кучу разнородной функциональности. Ты то конечно прекрасно помнишь что у тебя в этом Utils, а вот другому человеку читать такой код сплошное мучение.
У меня такие функции лежат в классах с названиями:
StringHlp, CollectionHlp, MathHlp и т.д., т.е. имя вспомогательно класса созвучно имени стандартного класса
DG>У меня такие функции лежат в классах с названиями:
DG>StringHlp, CollectionHlp, MathHlp и т.д., т.е. имя вспомогательно класса созвучно имени стандартного класса
Ну так о том и речь что нужно не лениться и делать несколько классов, а не пихать все в один.
O>У меня есть класс Utils со статическими методами, в частности я пишу
O>
O>Который для строки делает то, что ты написал. Соответственно JIT обычно это инлайнит. Есть версии и для коллекций и т.п.
AVK>Вот такие вещи я жутко не люблю в чужом коде. В смысле когда в одну либу (класс) безо всякой структуризации валят кучу разнородной функциональности. Ты то конечно прекрасно помнишь что у тебя в этом Utils, а вот другому человеку читать такой код сплошное мучение.
Если их таких много, то конечно делить нужно, а если их всего 5-6 методов в маленьком проекте? К тому же doc спасёт отца русского рефакторинга
O>Если их таких много, то конечно делить нужно, а если их всего 5-6 методов в маленьком проекте?
Лучше все же не полагаться на маленькость проекта, чревато. Бывало напишешь примитивную утилиту, а через полгода в этой утилите в десять раз больше кода. Так что я для всего кода, который не погибнет через неделю стараусь подходить со взрослым подходом.
O>К тому же doc спасёт отца русского рефакторинга
Ничего он не спасает, если честно.
IT>
IT>Что касается читабельности, то, в частности, я практически полностью перешёл от конкатенации строк к Format,
Поддерживаю
DG>
О! Вот о чём я и говорю. Должно же быть что-то подобное, но разве найдёшь, а если и найдёшь, то упомнишь всё среди тысяч фукций и пропертей. Это вам не какой-нибудь crtl из трёх сотен функций
Что-нибудь ещё свеженького в запасе чего не было в C++?
Я новичёк, поэтому слабо понимаю зачем в C# использовать вообще CollectionBase ? (и иже с ним ArrayList, CollectionBase, DictionaryBase , Stack)
EL>Я новичёк, поэтому слабо понимаю зачем в C# использовать вообще CollectionBase ? (и иже с ним ArrayList, CollectionBase, DictionaryBase , Stack)
А в чем ты набор объектов хранишь?
AVK>Здравствуйте, ExtraLamer, Вы писали:
EL>>Я новичёк, поэтому слабо понимаю зачем в C# использовать вообще CollectionBase ? (и иже с ним ArrayList, CollectionBase, DictionaryBase , Stack)
AVK>А в чем ты набор объектов хранишь?
в простом массиве.
AVK>>А в чем ты набор объектов хранишь?
EL>в простом массиве.
А как поиск в нём делаешь и новые записи добавляешь/удаляешь?
Поиск в массивах есть (System.Array is IList == true)
AVK>>А в чем ты набор объектов хранишь?
EL>в простом массиве.
Обычный массив имеет заранее определенный размер. Когда размер массива необходимо изменять, или нет данных о кол-ве элементов массива, применяют динамические массивы. Динамические массивы реализованы, например, в ArrayList.
> Оставим в покое теже атрибуты и библиотеки и давайте поговорим о мелочах, которые хоть немного могут снизить объём кода и повысить его читабельность (быстродействие и размер откомпилированной программы пока не в счёт).
>
> К чему это я? Надоело постоянно писать:
>
>
> Как такую проверку сделать короче?
>
Можно поставить eXtensible C# и писать:
TK>Можно поставить eXtensible C# и писать:
И что будет? Исключение?
>
> TK>Можно поставить eXtensible C# и писать:
>
> И что будет? Исключение?
Как минимум ассерт
TK>Можно поставить eXtensible C# и писать:
TK>
Это чего ж — через CBO? Мда, хороший пример стрельбы из пушки по воробьям.
TK>>Можно поставить eXtensible C# и писать:
AVK>Это чего ж — через CBO? Мда, хороший пример стрельбы из пушки по воробьям.
Сходил-бы по ссылке что-ли?
TK>Сходил-бы по ссылке что-ли?
Ах, это компилер. Еще веселее. Ты тут про перцев из mono писал, так эти перцы ничем тех перцев в этом плане не лучше.
TK>>Сходил-бы по ссылке что-ли?
AVK>Ах, это компилер. Еще веселее. Ты тут про перцев из mono писал, так эти перцы ничем тех перцев в этом плане не лучше.
по крайней мере эти перцы уже поддерживают VS.NET 2003, да и не строят громадных планов...
AVK>Ах, это компилер. Еще веселее. Ты тут про перцев из mono писал, так эти перцы ничем тех перцев в этом плане не лучше.
TK>по крайней мере эти перцы уже поддерживают VS.NET 2003, да и не строят громадных планов...
Все таки ИМХО самопальный компилятор это не та штука, которую можно смело использовать. Куча подобных компилеров для джавы так и не получила успеха.
AVK>Здравствуйте, TK, Вы писали:
AVK>>Ах, это компилер. Еще веселее. Ты тут про перцев из mono писал, так эти перцы ничем тех перцев в этом плане не лучше.
TK>>по крайней мере эти перцы уже поддерживают VS.NET 2003, да и не строят громадных планов...
AVK>Все таки ИМХО самопальный компилятор это не та штука, которую можно смело использовать. Куча подобных компилеров для джавы так и не получила успеха.
Более того. Я пытался юзать этот XC# на реальном проекте... Не прокатило. Что-то где-то он не так компилил и многое стало просто падать. Причем это стало происходить сразу, без добавления каких-либо XC# ограничений, на обычном проекте. Видать, написание хорошего компилятора не такая уж и простая задача, как они себе вообразили.
TK>Сходил-бы по ссылке что-ли?
Дальше home-page-а не уходит... Сайт падает
зы
А, вообще, имеет смысл генерировать часть кода в runtime?
Вот тот же пример с множественным наследованием развивать стоит?
DG>Вот тот же пример с множественным наследованием развивать стоит?
Иногда такое может очень пригодится. Средство очень мощное. Знаешь ведь, что RegularExpressions компилируются в IL (есть такая опция)?
Можно при помощи "генерации в runtime" оптимизировать механизм Class Factory.
Например, сейчас Activator.CreateInstance использует Reflection для вызова конструктора. Оптимизиованный алгоритм мог бы под каждый класс создавать "на лету" реализацию какого-нибудь IClassFactory. И хранить такие IClassFactory в хеш-таблице.
Сейчас-то механизм ClassFactory при создании большого количества объектов будет подтормаживать. А с такой оптимизацией вполне прокатит.
Ещё прикольно можно делать на лету потомка какого-нибудь класса, реализующего некий интерфейс. Например, наш класс "текстуально" подходит под интерфейс ISomeInterface, то есть содержит все необходимые методы. Можно на лету строить его потомка-враппер, который будет реализовать интерфейс ISomeInterface.
Чёрт его знает, где оно реально больше всего пригодится. Возможно, в скриптовых заморочках. Например, автоматически подключать методы типа Button2_Click к событиям и т.п.
IT>Я понимаю, что программирование в .NET итак существенно снижает объём набиваемого кода за счёт всяких атрибутов и обширной библиотеки, сводя технические детали реализации многих вещей практически к минимуму. Но, тем не менее, хотелось бы большего... точнее ещё меньшего.
Чего это тебя пробило?
IT>К чему это я? Надоело постоянно писать:
IT>
IT>Как такую проверку сделать короче?
Да, тоже достает изрядно. Правда в дотнетовской либе как правило null вместо строки нигде не фигурирует. Решения могу предложить три:
1) Если это поле, или свойство, подвязанное на поле то при объявлении явно писать string _StrField = "";
2) Написать класс хелпер — StringHelper.IsEmpty(str)
3) Извратный — s + "" != "". Сам понимаешь что в плане перфоманса не ахти, но зато просто.
IT>Или вот ещё пример. Такой код в MFC проходит на ура и даёт эксепшин в C#
IT>
А еще оно жутко тормозит при этом. ИМХО бага. И есть у меня такое страшное подозрение что в 1.0 работало нормально.
IT>И получится даже короче
Ну это если действительно подстроку не нужно.
IT>Хоть немножко и длиннее, но гораздо читабельнее, да и всегда можно формат без проблем подправить.
ИМХО зависит от задачки. Иногда конкатенация примитивна, там и + прокатит. Да и в плане перфоманса Format не лучший вариант.
IT>Времени чтобы это скопипейстить нужно не много, но зато потом можно сохранить кучу нервных клеток.
В SharpDevelop есть визард. Правда не очень мне нравится. Можно написать свой — благо не долго.
IT>При использовании типизированных коллекций данная проблема решается, т.к. в данном случае берётся возвращаемый индексером тип. Т.е. в большинстве случаев, там где не нужно отображать сложные связи поддерживаемые датасетом необходимость в его использовании и связанный с этим оверхед отпадает.
Ровно такая же ситуация с отображением коллекций в PropertyGrid. Совершенно понятно что нетипизированные коллекции идут лесом.
IT>В принципе, хотелось бы побеседовать на эту тему, узнать кто какие трики использует в повседневной работе, которые могли бы хоть как-то облегчить трудовые будни советских учёных
Что касаемо типизированный холлекций, то есть у меня мечта в такой тулзе:
На xml пишется шаблон некоего кода — фактически это CodeDOM, но с возможностью недоопределять его элементы и привязывать неопределенность к определенному значению.
Далее есть гуевая тулза, которая показывает на экране список шаблонов, и дает ввести недоопределенные в шаблоне значения.
Ну и наконец результатом работы этой тулзы является сгенеренный код на выбранном языке
Было бы совсем прелестно, если бы эта тулза генеренный и правленный код могла проанализировать и вернуть обратно к шаблону, с выделением параметров и правленых кусков, т.е. этакий two way tool.
Я в курсе что есть всякие тугезы, но имхо для данной конкретной задачи эти решения черезчур тяжеловесны.
AVK>Что касаемо типизированный холлекций, то есть у меня мечта в такой тулзе:
AVK>На xml пишется шаблон некоего кода — фактически это CodeDOM, но с возможностью недоопределять его элементы и привязывать неопределенность к определенному значению.
AVK>Далее есть гуевая тулза, которая показывает на экране список шаблонов, и дает ввести недоопределенные в шаблоне значения.
AVK>Ну и наконец результатом работы этой тулзы является сгенеренный код на выбранном языке
AVK>Было бы совсем прелестно, если бы эта тулза генеренный и правленный код могла проанализировать и вернуть обратно к шаблону, с выделением параметров и правленых кусков, т.е. этакий two way tool.
AVK>Я в курсе что есть всякие тугезы, но имхо для данной конкретной задачи эти решения черезчур тяжеловесны.
Полностью согласен.ТОлько я добавил бы не только коллекцииЮ, но и другие шаблоны для генерации...
В>Полностью согласен.ТОлько я добавил бы не только коллекцииЮ, но и другие шаблоны для генерации...
Ну саио собой. Я к тому что эти шаблоны можно писать ручками под себя. Мне к примеру после генераторов тех же типизированных коллекций бывает приходится дописывать руками еще шаблонный код.
AVK>Здравствуйте, Ведмедь, Вы писали:
AVK>Ну саио собой. Я к тому что эти шаблоны можно писать ручками под себя. Мне к примеру после генераторов тех же типизированных коллекций бывает приходится дописывать руками еще шаблонный код.
А то надо получить 20-30 классов, одинаково работающис с БД и их коллекция, тут и начинается....
AVK>Чего это тебя пробило?
Да вот всякие гнусные мысли в голову лезут после очередного code review
IT>>К чему это я? Надоело постоянно писать:
AVK>Да, тоже достает изрядно. Правда в дотнетовской либе как правило null вместо строки нигде не фигурирует.
Нулевые строки получаются элементарно из датасета или из бизнес-объектов. Если захочешь немного трафик пооптимизировать, то ты сам их нулями забъёшь. Как известно, для строк нулевой длинны soap-форматер вставляет в xml пустой тэг, для null он этот тэг вообще выбрасывает.
AVK>Решения могу предложить три:
AVK>1) Если это поле, или свойство, подвязанное на поле то при объявлении явно писать string _StrField = "";
Тогда уж лучше _StrField = string.Empty. Как никак экономия памяти Хотя нормальный компилятор эту подстановку сам должен сделать.
AVK>2) Написать класс хелпер — StringHelper.IsEmpty(str)
AVK>3) Извратный — s + "" != "". Сам понимаешь что в плане перфоманса не ахти, но зато просто.
Понятно
IT>>if (s2.Substring(0, s1.Length) == s1)
AVK>А еще оно жутко тормозит при этом. ИМХО бага. И есть у меня такое страшное подозрение что в 1.0 работало нормально.
Не работало. Я как-то перетаскивал код с MFC, так жутко изматерился...
AVK>ИМХО зависит от задачки. Иногда конкатенация примитивна, там и + прокатит. Да и в плане перфоманса Format не лучший вариант.
Интересно на сколько сильно тормозит Format?
IT>Нулевые строки получаются элементарно из датасета
Поправочка — не из датасета, а из DataReader. Да, это действительно неприятность — строки возвращаются почему то ввиде null, а не DBNull
IT>или из бизнес-объектов.
А вот это уже косяк, который надо править.
IT>Если захочешь немного трафик пооптимизировать, то ты сам их нулями забъёшь. Как известно, для строк нулевой длинны soap-форматер вставляет в xml пустой тэг, для null он этот тэг вообще выбрасывает.
Если ты пользуешь soap-форматтер, то о какой экономии трафика может идти речь? На крайняк пожми все зипом — все эти пустые теги уйдут в ноль.
IT>Тогда уж лучше _StrField = string.Empty.
Согласен.
IT>Как никак экономия памяти
Да дело то даже не в экономии, а в том что плодить строковые константы по коду не есть гуд. А экономии тут никакой — все строковые константы интернированы, т.е. "" и String.Empty это физически один и тот же экземпляр.
AVK>ИМХО зависит от задачки. Иногда конкатенация примитивна, там и + прокатит. Да и в плане перфоманса Format не лучший вариант.
IT>Интересно на сколько сильно тормозит Format?
Дык померь.
IT>>Если захочешь немного трафик пооптимизировать, то ты сам их нулями забъёшь. Как известно, для строк нулевой длинны soap-форматер вставляет в xml пустой тэг, для null он этот тэг вообще выбрасывает.
AVK>Если ты пользуешь soap-форматтер, то о какой экономии трафика может идти речь?
Да о простой, раза в 2-3 если у меня две трети полей в таблице допускают NULL и если мне надо закачать больше сотни таких записей.
IT>>Интересно на сколько сильно тормозит Format?
AVK>Дык померь.
Дык лень.
IT>Я понимаю, что программирование в .NET итак существенно снижает объём набиваемого кода за счёт всяких атрибутов и обширной библиотеки, сводя технические детали реализации многих вещей практически к минимуму. Но, тем не менее, хотелось бы большего... точнее ещё меньшего.
Вот так начинаеться прогресс. В начале писали. Потом стало лень. Стали писать что бы потом писать меньше. Написали. Теперь пишем меньше. Стало ещё больше лень. Стали писать что бы потом... И так до бесконечности. По этому поводу анекдот:
IT>В принципе, хотелось бы побеседовать на эту тему, узнать кто какие трики использует в повседневной работе, которые могли бы хоть как-то облегчить трудовые будни советских учёных
Я вот сейчас скажу такое, что вы меня сразу закидаете и помидорами и может ещё чем потяжелее. Если серьёзно, то сегодняшние технологии повторного использования кода на мой взгляд находяться на зачаточном уровне развития, но уже прошли саму стадию зачатия. Я бы сказал что в таких средах обитания как жаба и дотнет повторное использование кода реализованно лучше всего, но все равно я без копи паста работать пока не могу. Взять те же коллекции. Как они у меня получаются. Берёшь готовую. Копи пастиш и изменяешь типы. Так что долго нам ещё лентяями не быть.
Точно как ты и говоришь, "быстродействие и размер откомпилированной программы не в счёт":
Сам так пишу, когда влом наводить полировку.
IT>Что касается читабельности, то, в частности, я практически полностью перешёл от конкатенации строк к Format, т.е. вместо
IT>
IT>пишем
IT>
IT>Хоть немножко и длиннее, но гораздо читабельнее, да и всегда можно формат без проблем подправить.
Не согласен. В первом случае сразу видишь, что i1 идёт в начале, а i2 в конце. А с использованием Format ошибиться уже легче.
IT>Кроме всего прочего в ближайшее время у меня намечается тотальный переход с ArrayList на наследников CollectionBase и т.п.
Имеет смысл только для внешних интерфейсов. Внутри, в приватных полях уходить от ArrayList'а смысла нет.
IT>Времени чтобы это скопипейстить нужно не много, но зато потом можно сохранить кучу нервных клеток.
Можно и не копипаствоать, а мелкую утилитку сделать.
Давным-давно на MSDN была статья о хитроумном способе кодогенерации. AVK, например, повсюду стремится исполльзовать CodeDom. А там предлагали кое-что намного проще и прикольнее.
Для кодогенерации можно использовать ASP/ASP.NET синтаксис (см. пример ниже).
В будующей версии .NET наследование от CollectionBase и написание custom collection будет не нужно, пойдут шаблоны типа ArrayList<MyType>.
Этой же темы касается генерация ValueType-коллекций. CollectionBase для них использовать нецелесообразно. Но проблему боксинга обойти можно, т.е. ValueTypeCollectionBase можно написать и работать будет так же быстро, как и на шаблонах.
M>Для кодогенерации можно использовать ASP/ASP.NET синтаксис (см. пример ниже).
Дык проще Wizard написать, он в студию встроится (по типу "Add New Class").
WF>Дык проще Wizard написать, он в студию встроится (по типу "Add New Class").
Это не взаимоисключающие вещи. ASP.NET-синтаксис удобен для написания "шаблонов-заготовок". А вызывать ASP.NET-скрипты из любого приложения, даже без IIS очень просто.
P.S. Правда, только на Win2000+. Но студия на меньшее и не становится.
M>Это не взаимоисключающие вещи. ASP.NET-синтаксис удобен для написания "шаблонов-заготовок". А вызывать ASP.NET-скрипты из любого приложения, даже без IIS очень просто.
M>P.S. Правда, только на Win2000+. Но студия на меньшее и не становится.
Я просто не понимаю, зачем ASP.NET, если можно стандартный формат шаблонов студии использовать. Вот, например, те же яйца, вид сбоку:
+ если нужно, можно добавить пару .html+js страничек для ввода дополнительных параметров. Я тут уже предлагал некий набросок Визарда для генерации типизированной коллекции.
И ничего прикручивать не надо — все необходимое уже есть. Шаблон кода + JS/Html для ввода и обработки данных.
Я про такие яйца и не знал. Спасибо за подсказку.
>
> Я про такие яйца и не знал. Спасибо за подсказку.
>
Записать не забудь
WF>>Я просто не понимаю, зачем ASP.NET, если можно стандартный формат шаблонов студии использовать. Вот, например, те же яйца, вид сбоку:
M>Я про такие яйца и не знал. Спасибо за подсказку.
Вот, похоже, про эти Визарды (я методом тыка изучал ):
ms-help://MS.MSDNQTR.2003APR.1033/vccore/html/_CORE_Overview_of_Creating_a_Custom_AppWizard.htm
или
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_CORE_Overview_of_Creating_a_Custom_AppWizard.asp?frame=true
M>Для кодогенерации можно использовать ASP/ASP.NET синтаксис (см. пример ниже).
Уж лучше тогда XSLT
AVK>Уж лучше тогда XSLT
Удобство ASP в том, что код текстуально понятен. На XSLT чёрт ногу сломит, тогда и правда начинаешь подумывать о CodeDom.
Кстати, раз уж речь пошла о XSLT. Был тут спор, как хранить импорты WinAPI и как их преобразовывать в текст. Сделал я примерный вариант, из XML-описания типов и функций создаётся прямо в IE текст на C#, даже сразу с цветным форматированием. По-простому, но примерчик работоспособный.
M>Удобство ASP в том, что код текстуально понятен. На XSLT чёрт ногу сломит, тогда и правда начинаешь подумывать о CodeDom.
Ну уж не знаю. Я на XSLT генерирую довольно сложный код на Си++ — ноги мои пока целы (не знал, что черти такие хлюпики!).
А>Ну уж не знаю. Я на XSLT генерирую довольно сложный код на Си++ — ноги мои пока целы (не знал, что черти такие хлюпики!).
Дядьку, та ви — монстр
Тут, конечно, практика поможет. Но самопонятность ASP-синтаксиса всё-таки тоже аргумент неплохой.
AVK>Уж лучше тогда XSLT
M>Удобство ASP в том, что код текстуально понятен. На XSLT чёрт ногу сломит
Ну это кому как.
AVK>Ну это кому как.
И кому же как? Пример шаблона для генератора Collection-ов я приводил. Неужели на XSLT можно сделать это понятнее?
Предложи, а то я сильно задолбался, когда на XSLT код генерировал
M>Предложи, а то я сильно задолбался, когда на XSLT код генерировал
Вопрос привычки. Когда много попишешь на xslt то он кажется не менее понятным и удобным.
AVK>Вопрос привычки. Когда много попишешь на xslt то он кажется не менее понятным и удобным.
Не кажется (поcле 10 месяцев плотной работы с xslt).
IT>>Что касается читабельности, то, в частности, я практически полностью перешёл от конкатенации строк к Format, т.е. вместо
IT>>
IT>>
IT>>Хоть немножко и длиннее, но гораздо читабельнее, да и всегда можно формат без проблем подправить.
M>Не согласен. В первом случае сразу видишь, что i1 идёт в начале, а i2 в конце. А с использованием Format ошибиться уже легче.
Ну это ты просто никогда трёхэтажный html ручками не генерирвал, а то бы ты так не считал
IT>>Кроме всего прочего в ближайшее время у меня намечается тотальный переход с ArrayList на наследников CollectionBase и т.п.
M>Имеет смысл только для внешних интерфейсов. Внутри, в приватных полях уходить от ArrayList'а смысла нет.
А почему? Неужели приятнее каждый раз кастить всё в рукопашную?
IT>>Времени чтобы это скопипейстить нужно не много, но зато потом можно сохранить кучу нервных клеток.
M>Можно и не копипаствоать, а мелкую утилитку сделать.
Кто бы сделал
M>Давным-давно на MSDN была статья о хитроумном способе кодогенерации. AVK, например, повсюду стремится исполльзовать CodeDom. А там предлагали кое-что намного проще и прикольнее.
M>Для кодогенерации можно использовать ASP/ASP.NET синтаксис (см. пример ниже).
Можно использовать даже синтаксис формата:
M>В будующей версии .NET наследование от CollectionBase и написание custom collection будет не нужно, пойдут шаблоны типа ArrayList<MyType>.
Да это как раз понятно, но это будет только через год.
M>Этой же темы касается генерация ValueType-коллекций. CollectionBase для них использовать нецелесообразно. Но проблему боксинга обойти можно, т.е. ValueTypeCollectionBase можно написать и работать будет так же быстро, как и на шаблонах.
Для меня вообще является большим вопросот необходимость использования структур, если предполагается их использование в коллекциях. Эти вещи введены для оптимизации, следовательно их и нужно для этого использовать, а не придумывать себе лишние проблемы.
IT>Да это как раз понятно, но это будет только через год.
Мужики, а откуда вы срок взяли, что будет через год?
IT>>Да это как раз понятно, но это будет только через год.
AVK>Мужики, а откуда вы срок взяли, что будет через год?
Да где-то пробегало, что Framework 2.0 будет выпущен вместе со следующей версией студии. Там же будет и новый SQL с поддержкой .NET.
Есс! Есс, есс, есс!
>
> IT>Да это как раз понятно, но это будет только через год.
>
> Мужики, а откуда вы срок взяли, что будет через год?
>
Типа на воде гадаем
Вообще проект (.NET 2.0) называется Whidbey — можно по этому слову искать в google.
Так-же можно ориентироваться на даты вахода Yukon (IHMO .NET 2.0 и новый SQL выйдут одновременно).
На сайте MS написано, что на октябрьском PDC должны представить бету юкона (ну и от .NET 2.0 тоже никуда не отвертятся)...
Бету юкона до релиза будут доводить примерно полгода т.е. октябрь + 6 месяцев будет март — апрель 2004 вот собственно и год
IT>Можно использовать даже синтаксис формата:
IT>
IT>
Рулез! Только всё-таки здесь я бы настоял на именованном варианте, а то запутаешься в лет Да и имена пользователю надо какие-то понятные показывать, а то "введите параметры с нулевого по третий"
ЗЫ: New project/addin...
O> Рулез! Только всё-таки здесь я бы настоял на именованном варианте, а то запутаешься в лет Да и имена пользователю надо какие-то понятные показывать, а то "введите параметры с нулевого по третий"
Вариант с CodeDOM все таки получше, так как не привязан к конкретному языку.
AVK>Вариант с CodeDOM все таки получше, так как не привязан к конкретному языку.
В чём-то лучше, в чём-то хуже. Удобнее всё-таки текстуально написать, со вставками типа {0} или <%=MyType%>. Конечно, для VB придётся заново переписывать.
O> Рулез! Только всё-таки здесь я бы настоял на именованном варианте, а то запутаешься в лет Да и имена пользователю надо какие-то понятные показывать, а то "введите параметры с нулевого по третий"
AVK>Вариант с CodeDOM все таки получше, так как не привязан к конкретному языку.
Изобрази мне в кодедом do {...} while (...) так, чтобы генерация C# кода была именно такой... И еще много-много чего делается в нем через технические отверстия. Если хочешь получить внятный сырец на C# — лучше на нём и писать.
AVK>Вариант с CodeDOM все таки получше, так как не привязан к конкретному языку.
O>Изобрази мне в кодедом do {...} while (...) так, чтобы генерация C# кода была именно такой...
В данном конкретном случае без этого можно прожить.
O>И еще много-много чего делается в нем через технические отверстия.
Ой, да ладно тебе. Ты меня в свое время напугал, я думал действительно все не просто. А на практике оказалось что практически всегда CodeDOM хватает. Вот только, собака, любит он скобки втыкать где не надо.
AVK>Вариант с CodeDOM все таки получше, так как не привязан к конкретному языку.
O>Изобрази мне в кодедом do {...} while (...) так, чтобы генерация C# кода была именно такой...
AVK>В данном конкретном случае без этого можно прожить.
Отмазался
O>И еще много-много чего делается в нем через технические отверстия.
AVK>Ой, да ладно тебе. Ты меня в свое время напугал...
"Страшный Orangy грозно прячет CodeDOM от программистов"
Может задачи у нас разные были?
IT>
O> Рулез! Только всё-таки здесь я бы настоял на именованном варианте, а то запутаешься в лет Да и имена пользователю надо какие-то понятные показывать, а то "введите параметры с нулевого по третий"
Хм, а чем же тогда плох синтаксис ASP.NET? По-моему удобней и понятней для людей. Там же ещё и процедурность можно в сложных случаях влепить.
А прикрутить его к студии вполне реально. Дело в том, что ASP.NET-скрипты элементарно могут работать без IIS, в любом удобном процессе. Пример отработки ASP.NET-скрипта в консоли был больше года назад на gotdotnet.com
M>Хм, а чем же тогда плох синтаксис ASP.NET? По-моему удобней и понятней для людей. Там же ещё и процедурность можно в сложных случаях влепить.
Да ничем. Просто я не знаю как это сделать, а ковыряться мне с этим /пока/ не хочется... Тут бы с DTE разобраться, уж больно корявая...
А кодогенераторы и форматы шаблонов можно хоть плагинами второго уровня делать
M>>В будующей версии .NET наследование от CollectionBase и написание custom collection будет не нужно, пойдут шаблоны типа ArrayList<MyType>.
IT>Да это как раз понятно, но это будет только через год.
Через год не факт что они будет.
Говорят, что может быть ближе к новому году будет .Net Framework 2.0. Но generics туда вроде как еще не будут включать.
>
> Кроме всего прочего в ближайшее время у меня намечается тотальный переход с ArrayList на наследников CollectionBase и т.п. Всё что нужно сделать — это написать такой класс:
>
CodeSmith? http://www.ericjsmith.net/codesmith/download.aspx
TK>CodeSmith? http://www.ericjsmith.net/codesmith/download.aspx
Пробовал?
>
> TK>CodeSmith? http://www.ericjsmith.net/codesmith/download.aspx
>
> Пробовал?
Пробовал. Достаточно простая и эффективная утилитка...
Чем-то похоже на ASP.NET, только генерится исходник.
TK>Пробовал. Достаточно простая и эффективная утилитка...
TK>Чем-то похоже на ASP.NET, только генерится исходник.
В реальной жизни часто пользуешься?
>
> TK>Пробовал. Достаточно простая и эффективная утилитка...
> TK>Чем-то похоже на ASP.NET, только генерится исходник.
>
> В реальной жизни часто пользуешься?
Думал на тебя посмотреть
TK>Думал на тебя посмотреть
Сейчас мы её поковырям
TK>>Думал на тебя посмотреть
IT>Сейчас мы её поковырям
Прикольная штука, думаю, мы с ней подружимся Жалко только исходник не создаёт.
> Кроме всего прочего в ближайшее время у меня намечается тотальный переход с ArrayList на наследников CollectionBase и т.п. Всё что нужно сделать — это написать такой класс:
>
TK>CodeSmith? http://www.ericjsmith.net/codesmith/download.aspx
Похожее здесь
Пользуюсь довольно часто — удобно.
IT>Кроме всего прочего в ближайшее время у меня намечается тотальный переход с ArrayList на наследников CollectionBase и т.п.
Так, ну пока есть такая ерунда...
Есть файл шаблона примерно вот такого вида:
Есть также файл списка шаблонов примерно такого вида:
При загрузке solution в контекстном меню Add... появляется дополнительный пункт Code Template, где в подменю перечислены подключенные темплейты. При выборе шаблона, вываливается property grid для переменных, после чего создается новый файл и добавляется в проект. Все тупо и незатейливо, переменные вида $varName$ заменяются простым String.Replace по-порядку. Оно кому-нибудь надо?
O>Все тупо и незатейливо, переменные вида $varName$ заменяются простым String.Replace по-порядку. Оно кому-нибудь надо?
Надо, мне парочку отгрузите пожалуйста.
O>Все тупо и незатейливо, переменные вида $varName$ заменяются простым String.Replace по-порядку. Оно кому-нибудь надо?
IT>Надо, мне парочку отгрузите пожалуйста.
Ух ты, видать придётся доводить до ума Ну ладно, сейчас сетупь соберу, если заработает — отгружу в виде тех-превью
Хм, попробовал, оно упало, щаз часик повожусь еще, если не получится — завтра... Ты пока CodeSmith посмотри, может оно тебе лучше будет?
O>Ух ты, видать придётся доводить до ума Ну ладно, сейчас сетупь соберу, если заработает — отгружу в виде тех-превью
O>Хм, попробовал, оно упало, щаз часик повожусь еще, если не получится — завтра... Ты пока CodeSmith посмотри, может оно тебе лучше будет?
Я уже сто раз собирался именно такой визард написать, но теперь дождусь твоего ... если, конечно, ты всё еще собираешься его дописать.
O>Ух ты, видать придётся доводить до ума Ну ладно, сейчас сетупь соберу, если заработает — отгружу в виде тех-превью
O>Хм, попробовал, оно упало, щаз часик повожусь еще, если не получится — завтра... Ты пока CodeSmith посмотри, может оно тебе лучше будет?
A>Я уже сто раз собирался именно такой визард написать, но теперь дождусь твоего ... если, конечно, ты всё еще собираешься его дописать.
В свободной от остальной ненужной работы время
"В будующей версии .NET наследование от CollectionBase и написание custom collection будет не нужно, пойдут шаблоны типа ArrayList<MyType>." Может и не надо тогда переходить на Collection, может код вообще тогда практически не прийдётся(?) править через год.
Смотри по ситуации. Без фанатизма
Ни какого фанатизма! просто не охота сначала на Collection перейти потом на ArrayList. Бег по кругу получается
IT>В принципе, хотелось бы побеседовать на эту тему, узнать кто какие трики использует в повседневной работе, которые могли бы хоть как-то облегчить трудовые будни советских учёных
Вот еще трик, как визуально прибиндить НЕтипизированную коллекцию или же одиночный экземпляр к форме или же гриду.
Т.е. есть задача — экземпляры абсолютно произвольных классов я хочу отображать на форме, при этом иметь возможность визуально биндится к св-вам этих классов. Далее, как раз тут я весьма просто решил избежать создания типизированных коллекций, потому что... да потому что если единственной задачей написания типизированных коллекций является их правильное распознавание дизайнером, то это не очень убедительный аргумент. Другие аргументы (их много) принимаются...
В общем, вот он адаптер:
Пользоваться им легко. Бросаю компонент на форму, задаю ему имя целевого типа, визуально биндю поля типа к контролам на форме или к колонкам грида (любого грида, от родного дотнетного до любого платного). Затем в конструкторе формы я наполняю List св-во компонента нужными данными, или же подаю сразу лист (в простейшем случае — массив).
Тут мы получаем интересный эффект. Экземпляры листа не обязаны быть того же или унаследованного типа, главное, чтобы они содержали указанные в биндинге одноименные св-ва (это баг или фича?)
Далее, тут еще стоит благородная задача сделать GUI Editor для св-ва TargetType. Но это гораздо более сложная задача, чем может показаться вначале, ибо полноценный едитор должен давать возможность указывать сборки и автоматически подключать их к проекту и т.д. и т.п.
Учитывая, что во 2-м фреймворке уже есть велосипед типа описанного (правда, скорее танк, чем велосипед), я более глубоко развивать эту тему не стал, тем более, что и приведенные 33 строки кода вполне решают мои повседневные нужды визуального биндинга.
[...]
я бы #define сделал нормальным как в ц
а не этот изврат с условной компиляцией...
чтобы можно было нормальные макросы писать.
O>я бы #define сделал нормальным как в ц
O>а не этот изврат с условной компиляцией...
O>чтобы можно было нормальные макросы писать.
Ребята из Редмонда специально убирали из языка всё, что несёт в себе потенциальные проблемы.