На днях коллега рассказал одну задачу, которая заключается в том чтобы реализовать событие так, чтобы при возникновении исключения в одном обработчике, все равно были вызваны остальные обработчики.
6 сентября 2014 г.
29 августа 2014 г.
Частая ошибка №10: Накопление предупреждений компилятора. Перевод.
Оглавление
Это относится не только к C#, но в C# это особенно актуально, по сути вы лишаетесь части преимуществ строгой проверки типов, предлагаемых компилятором C#.
Предупреждения генерируются по какой-то причине. В то время как ошибки компилятора указывают на дефект в вашем коде, многие предупреждения делают тоже самое. Разница между ними в том, что в случае предупреждения, компилятор не имеет проблем с инструкциями в вашем коде. Тем не менее, он находит ваш код подозрительным, и существует вероятность что ваш код не совсем точно отражает ваши намерения.
Это относится не только к C#, но в C# это особенно актуально, по сути вы лишаетесь части преимуществ строгой проверки типов, предлагаемых компилятором C#.
Предупреждения генерируются по какой-то причине. В то время как ошибки компилятора указывают на дефект в вашем коде, многие предупреждения делают тоже самое. Разница между ними в том, что в случае предупреждения, компилятор не имеет проблем с инструкциями в вашем коде. Тем не менее, он находит ваш код подозрительным, и существует вероятность что ваш код не совсем точно отражает ваши намерения.
Частая ошибка №9: Избегание исключений. Перевод.
Оглавление
C# продолжает следить за безопасностью типов и во время выполнения. Это позволяет вам точнее и быстрее выявлять ошибки, по сравнению с языками типа C++, где ошибка приведения типа может привести к произвольному значению в полях объекта. Тем не менее, программисты могут "разбрасываться" такой замечательной возможностью C#. Они попадают в эту ловушку потому что C# предоставляет два различных пути для приведения: один из них бросает исключение, а другой - нет. Некоторые избегают варианта с исключениями, полагая что не имея блока try/catch они экономят немного кодирования.
C# продолжает следить за безопасностью типов и во время выполнения. Это позволяет вам точнее и быстрее выявлять ошибки, по сравнению с языками типа C++, где ошибка приведения типа может привести к произвольному значению в полях объекта. Тем не менее, программисты могут "разбрасываться" такой замечательной возможностью C#. Они попадают в эту ловушку потому что C# предоставляет два различных пути для приведения: один из них бросает исключение, а другой - нет. Некоторые избегают варианта с исключениями, полагая что не имея блока try/catch они экономят немного кодирования.
Частая ошибка №8: Пренебрежение очисткой ресурсов. Перевод.
Оглавление
Среда CLR использует сборщик мусора, так что вам не надо явно освобождать память, занятую под любой объект. Фактически, вы и не можете. Нет, подобного C++, оператора delete или функции free() как в C. Но это не означает что вы можете просто забыть обо всех объектах, после того как закончили использовать их. Многие типы объектов включают в себя некоторые другие типы системных ресурсов (например файл на диске, подключение к БД, сетевое соединение и т.п.). Оставляя такие ресурсы открытыми вы можете быстро истощить общее количество системных ресурсов, снизить производительность и в конце концов привести программу к ошибке.
Среда CLR использует сборщик мусора, так что вам не надо явно освобождать память, занятую под любой объект. Фактически, вы и не можете. Нет, подобного C++, оператора delete или функции free() как в C. Но это не означает что вы можете просто забыть обо всех объектах, после того как закончили использовать их. Многие типы объектов включают в себя некоторые другие типы системных ресурсов (например файл на диске, подключение к БД, сетевое соединение и т.п.). Оставляя такие ресурсы открытыми вы можете быстро истощить общее количество системных ресурсов, снизить производительность и в конце концов привести программу к ошибке.
28 августа 2014 г.
Частая ошибка №7: Использование неверного типа коллекции для поставленной задачи. Перевод.
Оглавление
C# предоставляет большое разнообразие объектов-коллекций, приведем неполных их список:
Array, ArrayList, BitArray, BitVector32, Dictionary<K,V>, HashTable, HybridDictionary, List<T>, NameValueCollection, OrderedDictionary, Queue, Queue<T>, SortedList, Stack, Stack<T>, StringCollection, StringDictionary.
C# предоставляет большое разнообразие объектов-коллекций, приведем неполных их список:
Array, ArrayList, BitArray, BitVector32, Dictionary<K,V>, HashTable, HybridDictionary, List<T>, NameValueCollection, OrderedDictionary, Queue, Queue<T>, SortedList, Stack, Stack<T>, StringCollection, StringDictionary.
25 августа 2014 г.
Частая ошибка №6: Путаница из-за методов расширения. Перевод.
Оглавление
Ранее я упомянул что выражения LINQ работают с любыми объектами, реализующими IEnumerable.
Ранее я упомянул что выражения LINQ работают с любыми объектами, реализующими IEnumerable.
20 августа 2014 г.
Частая ошибка №5: Непонимание объектов, лежащих в основе выражения LINQ. Перевод.
Оглавление
LINQ отлично подходит для абстрагирования задач работы с коллекциями, будь-то объекты в памяти, таблицы базы данных или XML-документы. В идеальном мире вам не нужно было бы знать какие объекты лежат в основе. Но ошибка здесь - думать что мы живем в идеальном мире. Фактически одно и тоже выражение LINQ может вернуть различные результаты при выполнении на абсолютно одинаковых данных, если эти данные были в различных форматах.
LINQ отлично подходит для абстрагирования задач работы с коллекциями, будь-то объекты в памяти, таблицы базы данных или XML-документы. В идеальном мире вам не нужно было бы знать какие объекты лежат в основе. Но ошибка здесь - думать что мы живем в идеальном мире. Фактически одно и тоже выражение LINQ может вернуть различные результаты при выполнении на абсолютно одинаковых данных, если эти данные были в различных форматах.
15 августа 2014 г.
Частая ошибка №4: Использование итеративных (вместо декларативных) выражений для работы с коллекциями. Перевод.
Оглавление
Добавление языка интегрированных запросов (LINQ) в C# 3.0 навсегда изменило способ работы с коллекциями. С тех пор, если вы используете итеративные выражения для работы с коллекциями, то вы не используете LINQ там, где, скорее всего, должны были бы.
Добавление языка интегрированных запросов (LINQ) в C# 3.0 навсегда изменило способ работы с коллекциями. С тех пор, если вы используете итеративные выражения для работы с коллекциями, то вы не используете LINQ там, где, скорее всего, должны были бы.
11 августа 2014 г.
Частая ошибка №3: Использование неподходящих или неопределенных методов сравнения строк. Перевод.
Существует множество различных способов сравнивать строки в C#.
Хотя многие программисты используют оператор == для сравнения строк, на самом деле это один из наименее желательных методов для этого, в первую очередь потому что он не позволяет явным образом в коде указать какой тип сравнения необходим.
Хотя многие программисты используют оператор == для сравнения строк, на самом деле это один из наименее желательных методов для этого, в первую очередь потому что он не позволяет явным образом в коде указать какой тип сравнения необходим.
7 августа 2014 г.
Частая ошибка №2: Неправильное понимание значений по умолчанию для неинициализированных переменных. Перевод.
Оглавление
В C#, типы значений не могут быть null. По определению типы значений имеют значение, и даже неинициализированные переменные типов значений должны иметь значение. Это называется значением по умолчанию для этого типа. Это приводит к последующему, обычно неожиданному, результату проверки инициализации переменной:
В C#, типы значений не могут быть null. По определению типы значений имеют значение, и даже неинициализированные переменные типов значений должны иметь значение. Это называется значением по умолчанию для этого типа. Это приводит к последующему, обычно неожиданному, результату проверки инициализации переменной:
Подписаться на:
Сообщения (Atom)