Пока готовился к сертификации 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. Договоренность об оформлении кода. Я думаю, если протестовать никто не будет, то можно вместе договориться о том, в каком виде отображать код. Подсветка, названия переменных, и прочее.
Не всем надо, но многие, смотря на хороший красивый код, будут немного приучаться :)
Мое личное мнение.
Ну и со вторым - 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. Договоренность об оформлении кода. Я думаю, если протестовать никто не будет, то можно вместе договориться о том, в каком виде отображать код. Подсветка, названия переменных, и прочее.
Не всем надо, но многие, смотря на хороший красивый код, будут немного приучаться :)