Пока готовился к сертификации MS по .net 2.0 пришлось многое изучить. И вот что заметил - разные части фреймворка писали абсолютно разные люди и команды. Это, конечно, понятно. Но порой удивлялся названиям классов :)
Ничем они не плохи. И от RSDN. И даже от SubMain. Просто иметь их под рукой на хабре проще. Да и немного приятнее, что они общие. Наши :)
Мое личное мнение.
Смысл в том, чтобы смотреть на код примеров, которые иногда проскакивают на хабре, и видеть там хороший код.
Примеры, как известно, для того, чтобы учиться, а учиться, как известно, лучше хорошему.
Да, еще. Обязательно нужно писать модификатор доступа.
И любая объявленная переменная или поле должны иметь значение
private List _names = null;
int x = 0;
Понятно, что все знают (или почти все), какое там будет значение по умолчанию, однако, с таким дополнением легче читать код.
Молодец, что собрал всю информацию вместе.
Мои комментарии и дополнения :)
1. Приватные поля - начинать имена с подчеркивания и маленькой буквы.
2. Скобки - я за то, чтобы ставить их всегда. А то иногда одну строчку после условия особо умные комментируют и начинается магия :) - if распространяется на следующую.
3. Про именование контролов - всеми руками за вариант dmx. Точно такой же практикой пользуемся.
А насчет наглядности - после двух-трех дней пользования сокращениями, поймете, что все-таки, они лучше. Нежели сто раз в день видеть TextBox, Literal, ObjectDataSource.
4. Про оформление классов - сначала пишутся все приватные и защищенные поля, позже идут свойства, далее - методы - сначала приватные, потом защищенные и наконец общие.
Обычно, если более одного метода, свойства, поля - мы объединяем в регионы.
Пока ничего больше в голову не приходит...
Хотелось бы получить ответы на 2 вопроса. Желательно, аргументированные.
1. Отличие коллекций первого фреймворка от второго и выше
2. В чем различие между XML Web Services с использованием ASMX и .NET Remoting с использованием SOAP?
1. Попробовал. Вы тоже молодец, что попробовали. :)
== Не работает, однако отлично работает Equals. Не надо так быстро сдаваться, проблемы лучше решать :)
2. Представил. Вы делаете UI, ваш коллега - обработчик. Есть общая спецификация(документация), там указано, что и как и почему
3. Мне тоже очень приятно беседовать с небезразличными.
На самом деле не хочу убеждать никого, в споре нет победивших. Тем более, лучше, когда есть много точек зрения. Лишь конструктивно критикую :)
Я думаю, что достаточно использовать правила MS для .NET . Если есть желание все это оформить, то могу заняться.
На готдотнете вроде бы есть уже. На RSDN точно. Там впервые прочитал, теперь пользуюемся на работе стандартными MS с дополнениями и улучшениями.
1. public ImageFormat(Guid guid)
2. Если будет в коде метод
bool IsImageFormatAllowed(ImageFormat imageFormat)
{
return (imageFormat == ImageFormat.Gif)||(imageFormat == ImageFormat.Jpeg)
}
* This source code was highlighted with Source Code Highlighter.
то код будет более читаемым, нежели с использованием DynamicImageFormat.
Извините за оффтоп, но у меня почему-то не получается вставить ни одной ссылки в комментарий.
1. Возможно. ImageFormat.Png.Guid
2,3. Создается базовый класс(что-то вроде ImageHandlerBase), в трех обработчиках лишь перегружается один-два метода.
4. Спасибо, действительно не знал про это :)
5. Договоренность об оформлении кода. Я думаю, если протестовать никто не будет, то можно вместе договориться о том, в каком виде отображать код. Подсветка, названия переменных, и прочее.
Не всем надо, но многие, смотря на хороший красивый код, будут немного приучаться :)
Очень помогают решать самые разнообразные проблемы и задачи. Кроссворды, поиск неполадок, переговоры... Мозг знает много разных фактов, а уже составить нужную их комбинацию для него намного проще. Если у него есть все факты, которые необходимы для умозаключения, то он сделает его. Но если будет чего-то не хватать, то, ммм, будет труднее.
Сразу же оговорюсь, что занимаюсь корпоративными Web-разработками на .net. Соответственно, для нашей компании важным является стабильность, производительность и хорошая поддерживаемость кода. Если болеет сотрудник, который разработал контрол, то его вполне может доработать любой другой. Я это к тому, что буду комментировать с этой точки зрения.
1. По-моему, стоит все-таки пользоваться классом ImageFormat, несмотря на Ваше возражение. Лишний класс лишь вносит путаницу в код, который позже придется поддерживать.
2 и 3. Из моего опыта могу сказать, что этот механизм, который Вы предложили в данном примере, не лучший. Удобнее все-таки делать несколько Handler-ов. Один отвечает за фотографии, которые тянет из БД (к примеру), второй за капчи, которые генерятся, третий - за круговые диаграммы, данные для которых тоже берутся из БД.
Все это довольно различающиеся механизмы, которые, если их обобщить, вносят опять же путаницу.
4. Интересно, зачем использовать MemoryStream, если можно
Bitmap bitmap = ...
bitmap.Save(Response.OutputStream, ImageFormat.Gif);
5. Пора вводить Code Conventions для .NET блога :)
Мое личное мнение.
Ну и со вторым - LoanTableAdapter lta = new LoanTableAdapter();
Button - btn.
ImageButton - тоже btn(потому как наследник Button).
Примеры, как известно, для того, чтобы учиться, а учиться, как известно, лучше хорошему.
И любая объявленная переменная или поле должны иметь значение
private List _names = null;
int x = 0;
Понятно, что все знают (или почти все), какое там будет значение по умолчанию, однако, с таким дополнением легче читать код.
Мои комментарии и дополнения :)
1. Приватные поля - начинать имена с подчеркивания и маленькой буквы.
2. Скобки - я за то, чтобы ставить их всегда. А то иногда одну строчку после условия особо умные комментируют и начинается магия :) - if распространяется на следующую.
3. Про именование контролов - всеми руками за вариант dmx. Точно такой же практикой пользуемся.
А насчет наглядности - после двух-трех дней пользования сокращениями, поймете, что все-таки, они лучше. Нежели сто раз в день видеть TextBox, Literal, ObjectDataSource.
4. Про оформление классов - сначала пишутся все приватные и защищенные поля, позже идут свойства, далее - методы - сначала приватные, потом защищенные и наконец общие.
Обычно, если более одного метода, свойства, поля - мы объединяем в регионы.
Пока ничего больше в голову не приходит...
1. Отличие коллекций первого фреймворка от второго и выше
2. В чем различие между XML Web Services с использованием ASMX и .NET Remoting с использованием SOAP?
== Не работает, однако отлично работает Equals. Не надо так быстро сдаваться, проблемы лучше решать :)
2. Представил. Вы делаете UI, ваш коллега - обработчик. Есть общая спецификация(документация), там указано, что и как и почему
3. Мне тоже очень приятно беседовать с небезразличными.
На самом деле не хочу убеждать никого, в споре нет победивших. Тем более, лучше, когда есть много точек зрения. Лишь конструктивно критикую :)
На готдотнете вроде бы есть уже. На RSDN точно. Там впервые прочитал, теперь пользуюемся на работе стандартными MS с дополнениями и улучшениями.
2. Если будет в коде метод
bool IsImageFormatAllowed(ImageFormat imageFormat)
{
return (imageFormat == ImageFormat.Gif)||(imageFormat == ImageFormat.Jpeg)
}
* This source code was highlighted with Source Code Highlighter.
то код будет более читаемым, нежели с использованием DynamicImageFormat.
Извините за оффтоп, но у меня почему-то не получается вставить ни одной ссылки в комментарий.
2,3. Создается базовый класс(что-то вроде ImageHandlerBase), в трех обработчиках лишь перегружается один-два метода.
4. Спасибо, действительно не знал про это :)
5. Договоренность об оформлении кода. Я думаю, если протестовать никто не будет, то можно вместе договориться о том, в каком виде отображать код. Подсветка, названия переменных, и прочее.
Не всем надо, но многие, смотря на хороший красивый код, будут немного приучаться :)
1. По-моему, стоит все-таки пользоваться классом ImageFormat, несмотря на Ваше возражение. Лишний класс лишь вносит путаницу в код, который позже придется поддерживать.
2 и 3. Из моего опыта могу сказать, что этот механизм, который Вы предложили в данном примере, не лучший. Удобнее все-таки делать несколько Handler-ов. Один отвечает за фотографии, которые тянет из БД (к примеру), второй за капчи, которые генерятся, третий - за круговые диаграммы, данные для которых тоже берутся из БД.
Все это довольно различающиеся механизмы, которые, если их обобщить, вносят опять же путаницу.
4. Интересно, зачем использовать MemoryStream, если можно
Bitmap bitmap = ...
bitmap.Save(Response.OutputStream, ImageFormat.Gif);
5. Пора вводить Code Conventions для .NET блога :)