15 возможностей ReSharper-а для навигации и редактирования

Инструменты – средство усиления вашего таланта. Чем они лучше и чем лучше вы ими владеете, тем больше вы сможете сделать.
Энди Хант и Дейв Томас «Программист-прагматик. Путь от подмастерья к мастеру»

DISCLAIMER: это не заказная и совершенно не проплаченная статья (JetBrains, я ни на что не намекаюJ). Здесь представлены лишь возможности популярного расширения для Visual Studio (а иногда и аналогичные возможности самой студии), которые я лично использую в повседневной деятельности.

Инструменты не являются панацеей от кривых рук и сами по себе не сделают из заурядного специалиста аццкого сатану, способного рвать любую задачу, как известные четвероногий друг тряпку. Они не решают сами ваши задачи, а лишь помогают снять с плеч некоторые рутинные вещи и дают возможность сосредоточиться на главном, не задумываясь о таких мирских вещах, как добавление нужных директив using, проблемах форматирования или навигации по коду. Многие инструменты (в особенности ReSharper) могут помочь в решении и других, не мене важных задач, таких как поиск ошибок в коде, следование стандартам кодирования, запуск юнит-тестов и многих других. И хотя все эти возможности являются мегафичами сами по себе, но сегодня речь в основном пойдет о возможностях навигации и поиска.

Формат описания следующий: названия фичи, а затем в скобках горячие клавиши для схемы Visual Studio, а затем для схемы IDEA.

Например: Go To Type (Ctrl + T, Ctrl + N).

Альтернативная проверка предусловий в Code Contracts

При попытке использования библиотеки Code Contracts в реальном проекте может возникнуть небольшая сложность: хотя сам класс Contract с методами проверки предусловий и постусловий, располагается в mscorlib начиная с 4-й версии .NET Framework, но без установки самой библиотеки Code Contracts, они не попадают в результирующую сборку.

Это может вызвать определенные сложности в крупных распределенных командах, поскольку для нормального использования контрактов всем разработчикам придется установить дополнительное расширение. А поскольку у ключевых людей проекта может не быть четкой уверенности в том, а нужно ли вообще нам это добро, то такой переход может быть затруднительным.

Однако Code Contracts поддерживает дополнительный «режим совместимости», который позволяет «жестко зашить» проверки предусловий в результирующий код, так что они будут видны всем, не зависимо от того, установлены контракты на машине разработчика или нет.

Brainbench: Bench Games has started!

Сайт Brainbench.com, который занимается on-line сертификацией, с сегодняшнего дня запустил Bench Games, что для простых смертных означает возможность сдать на халяву любые тесты (а их там чего-то порядка 600). Да, это не распространяется на бумажные версии сертификатов, так что если захотите свою гениальность получить в персистентном виде, то дать им денег все равно придется.

Я прекрасно осознаю ограниченность любых формальных методов оценки специалистов, но, согласитесь, иногда померяться чем-нибудь очень даже интересно. Насколько я помню, в последний раз подобное мероприятие проводилось сайтом brainbench.com где-то лет 5 назад, после этого, они периодически делали часть своих экзаменов бесплатными (что тоже хорошо), но сейчас можно попробовать свои силы даже в том, что «не знал», «знал, да забыл», или «вообще что-это-за-хрень, но мне все равно интересно».

В общем, let the game begins.

З.Ы. Старовало это добро сегодня и длиться будет до 9-го марта.

UPDATE: я хз, как дать прямую ссылку на все тесты, похоже, чтобы по ней перейти нужно вначале залогиниться на brainbench-е. В общем, вот ссылка на все тесты. Если не получится зайти по ссылке, то логинимся, и потом сюда: Skills Center > Test Center > All Tests.

Наследование интерфейсов и контракты

В библиотеке Code Contracts, которая любезно предоставляет возможности контрактного программирования на платформе .NET, для задания предусловий и постусловий используются вызовы статических методов класса Contract. С одной стороны – это хорошо, поскольку альтернативная реализация на основе атрибутов была бы слишком ограниченной. С другой стороны – это добавляет определенные сложности, когда дело касается контрактов интерфейсов или абстрактных методов, которые, по своей природе, не содержат никакого кода, а значит и вызывать методы просто не откуда.

Решается эта с помощью двух атрибутов: ContractClassAttribute, который вешается на интерфейс или абстрактный класс, и ContractClassForAttribute – который вешается на сам контракт.

Принцип замещения Лисков и контракты

Идея этой заметки навеяна статьей Александра Бындю “Дополнение к LSP” и может рассматриваться, как развернутый комментарий к статье Александра.

Итак, вопрос следующий, предположим, один из членов команды пытается реализовать интерфейс IList of T в классе DoubleList of T таким образом, чтобы при добавлении элемента с помощью метода Add, добавлялся бы не один, а два одинаковых элемента. Поскольку класс List of T всегда добавляет только один элемент, то можно считать, что данное поведение нарушает принцип замещения Лисков (LSP – Liskov Substitution Principle).

Повторное использование знаний

Уже не первый раз натыкаюсь на обсуждения вопросов о том, кто и как изучает новые технологии и о том, как справится с тем огромном потоком «нововведений», которые ежегодно появляются в индустрии ПО. Однажды я уже отвечал на этот вопрос на кывт-е, и после очередного вопроса решил оформить эти мысли более структурированным образом.

Если оглядеться вокруг, то может сложиться впечатление, что отрасль разработки ПО шагает такими громадными шагами, что угнаться за ней нет никакой возможности. И если рассматривать всю отрасль в целом, то действительно это так и есть. Как-то сразу вспоминается старина Брукс со своим «Мифическим человеко-месяцем», когда он в заключении к своей книге пишет о том, как изменилась индустрия ПО в середине 90-х по сравнению с 50-ми годами. В те далекие годы (да, 90-е тоже уже далеки, так что уж говорить за эпоху зарождения индустрии сорока годами ранее) можно было прочитать все журналы (!),компьютерной тематики, которые выходили в свет. Сейчас же ежемесячно появляется десятки книг только по одной из популярных технологий, а количество статей просто не поддается счету.

Attached свойства для ограничения текстового ввода

WPF – это уже далеко не новая технология на рынке, но относительно новая для меня. И, как это часто бывает при изучении чего-то нового, появляется желание/необходимость в изобретении велосипедов с квадратными колесами и литыми дисками для решения некоторых типовых задач.

Одной из таких задач является ограничение ввода пользователем определенных данных. Например, мы хотим, чтобы в некоторое текстовое поле можно было вводить только целочисленные значения, а в другое – дату в определенном формате, а в третье – только числа с плавающей запятой. Конечно, окончательная валидация подобных значений все равно будет происходить во вью-моделях, но подобные ограничения на ввод делают пользовательский интерфейс более дружественным.

В Windows Forms эта задача решалась довольно легко, а когда в распоряжении был тот же TextBox от DevExpress со встроенной возможностью ограничения ввода с помощью регулярных выражений, то все было вообще просто. Примеров решения этой же задачи в WPF довольно много, большинство из которых сводится к одному из двух вариантов: использование наследника класса TextBox или добавление attached property с нужными ограничениями.