я попробовал почитать одну страницу: мне очень понравился этот опыт! действительно читаешь с бОльшим удовольствием, чем всеми другими доступными мне способами.
Единственное, что мне за это короткое время помешало, так это точность перевода фраз: например
вообще то я думал, что Critical это самый высший приоритет :)
Насчет сомнений в фиче — я с вами согласен, ошибки в тулинге достаточно опасны и последствия могут быть печальными. Что еще тут сказать, верифицировать корректность IDE-тулинга еще не научились, значит будем просто чинить :)
Интересно, мне казалось, что на сам рефакторинг можно написать обычные программные тесты. Поэтому меня сильно озадачила такая ошибка.
Можно пояснить, почему этот рефакторинг нужно тестировать через IDE?
Если вы серъезно считаете, что для новых фич языка программирования сложности C# можно сделать что-то типа «Add to user dictionary», то очень глубоко заблуждаетесь.
вот за это я и люблю хабр, что на одно «глубокое заблуждение» у меня станет меньше :). осовободится место для других.
Вообще то мой вопрос звучал так, можно ли предложить пользователю workaround для того, что бы как то «подавить» проблемы неправильной подсветки кода (для c# 6). Я уверен, что если пофантазировать, можно найти варианты. Может быть они будут не практичны, а может и да.
Интересно, ведь решарпер может знать, что компилятор таки скомпилировал этот код и наверняка, можно получить результаты парсинга. Эта информация не может помочь подумать о каком либо решении проблемы подсветки?
Переходное состояние языка, когда некоторые конструкции существуют в неутвержденном виде — крайне редкая и непродолжительная вещь. Если уж человек скачивает бета-версию попробовать, обычно он готов к тому, что что-то может не работать. Так что проблема сама по себе во многом надумана.
Негативное впечатление очень легко заработать и потом трудно исправить. И вместо того, что бы я всему окружению рассказывал бы, какой решарпер крутой и уже поддерживает c# 6, я буду вынужден говорить, что девятка еще глюковата, давайте подождем (хотя объективно для продашена c# 6 и не нужен сейчас).
Или на внутреннем семинаре о фичах c# 6 все будут спрашивать, а почему там что то красненькое такое, а я буду отвечать глюковат релиз 9-ого решарпера.
Так как я запускаю превью студии, то проблемы студии будут игнорироваться, а проблемы релизной версии решарпера нет.
Не описывает ничего, кроме новых ключевых слов — за бортом оказываются операторы, интерполяция строк, новая семантика первичных конструкторов, инициализаторы свойств, инициализаторы словарей, в общем всё остальное.
Тут поднимается вопрос, можно ли реализовать «add to user's dictionary» не только для ключевых слов, но и для других языковых конструкций. Если нельзя — то и говорить не о чем. А вот если можно, то почему бы нет?
Тут вопрос технический. Интересно бы узнать мнение от разработчиков решарпера.
Не решает ничего, кроме некорректной подсветки в тексте — тот же nameof будет подсвечен как ключевое слово, но среда разработки по-прежнему не знает, какое выражение допустимо в скобках и что с ним делать в случае рефакторинга.
Так я и говорю только о подсветке и не прошу рефакторинга.
Переносит ответственность с разработчиков среды и инструментов к ней на конечного пользователя, что в корне неверно.
Согласен. Только эти слова я бы переадресовал бы разработчикам решарпера.
Ок. Давайте рассмотрим ситуацию: сейчас подсветка синтаксиса работает не корректно.
Я вижу два варианта:
1. Ничего не делать, т.е. продолжать подсвечивать корректный синтаксис как ошибка. В этом случае, разработчик быстро перестанет считаться с подсветкой вообще.
2. Добавить возможность что то типа «Add to to user dictionary», что бы разработчик мог бы добавить неподдерживаемые слова в свой словарь с уровнем «предупреждение». В этом случае, разработчик может и дальше доверять подсветке синтаксиса и видеть те конструкции, которые пока не поддерживаюся.
Мне кажется, что второй вариант все-таки меньшее из зол.
Проблема в ожиданиях разработчика: вот пока решарпер не был релизным, я спокойней относился к «полуподдежке».
Но в релизной версии я ожидаю или полную поддержку (плюс/минус баги) или явное описание того, что не поддерживается.
Зачем писать поддержку и тратить время того, что через месяц выбросят?
например, что бы Ваши пользователи были еще более довольны, чем сейчас :)
Т.е. вы говорите, что проблема еще хуже: не только в решарпере, но и в других продуктах разработчиков раздражает неправильная подсветка синтаксиса?
В этом случае мне кажется хорошо бы поискать какое то общее решение (позволять пользователю что то типа «add to user dictionary»), иначе вся эта подсветка ситнтаксиса ничего не стоит.
Кстати, что там за проблема с относительным путем к другому .ps1 файлу? было бы полезно понять в чем проблема и какие есть подходы к ее решению. Даже пример из поста содержит абсолютный путь, что не всегда хорошо.
получается, что одна заметка содержит всю инорфмацию о человеке, включая серьезное количество фоток?
и проекты так же структурированы? один проект — одна заметка? или один проект — один блокнот?
интересно структрура на уровне notebooks.
правильно ли я понимаю, что есть например блокнот «Люди», а нем блокнот для каждого человека? и вся информация о человеке сваливается в этот блокнот в виде последовательного листа заметок (без дополнительной иерархии)?
ССЗБ. Вы продолжаете писать неправильный код, потому что сейчас лениво сделать DI хотя бы в виде ServiceLocator-а, умеющего создавать графы объектов для тех классов, которые про DI не знают.
Извините, но вы делаете слишком много предположений, и не все из них соответствуют действительности.
Итого, согласимся на:
1. Писать статические поля — плохо.
2. Хорошо бы использовать DI или хотя бы ServiceLocator.
3. Не надо лениться и продолжать писать неправильный код.
Но те люди, которые все-таки игнорируют такие замечательные правила и хотят проверять, что поле какого-то определенного типа должно быть статическим, могут воспользоваться тем правилом анализа кода, которое обсуждалось в этом посте.
Кстати, чисто, что бы улучшить мир, поделитесь примером или описанием "ServiceLocator-а, умеющего создавать графы объектов для тех классов, которые про DI не знают".
Единственное, что мне за это короткое время помешало, так это точность перевода фраз: например .
Кстати, paypal планируется поддержать?
просто не было теста, по причине того, что сама фича еще не очень зарелизина?
Интересно, мне казалось, что на сам рефакторинг можно написать обычные программные тесты. Поэтому меня сильно озадачила такая ошибка.
Можно пояснить, почему этот рефакторинг нужно тестировать через IDE?
вот за это я и люблю хабр, что на одно «глубокое заблуждение» у меня станет меньше :). осовободится место для других.
Вообще то мой вопрос звучал так, можно ли предложить пользователю workaround для того, что бы как то «подавить» проблемы неправильной подсветки кода (для c# 6). Я уверен, что если пофантазировать, можно найти варианты. Может быть они будут не практичны, а может и да.
Интересно, ведь решарпер может знать, что компилятор таки скомпилировал этот код и наверняка, можно получить результаты парсинга. Эта информация не может помочь подумать о каком либо решении проблемы подсветки?
Даже ваши люди пометили этот «маленький» баг как критический.
Любое сомнение в правильности кода генерации, на мой взгляд, убивает этот фичер сразу и надолго.
я так могу представить, что «релиз» нужен для денег, а поддержка из превью для обката новых возможностей решарпера.
Негативное впечатление очень легко заработать и потом трудно исправить. И вместо того, что бы я всему окружению рассказывал бы, какой решарпер крутой и уже поддерживает c# 6, я буду вынужден говорить, что девятка еще глюковата, давайте подождем (хотя объективно для продашена c# 6 и не нужен сейчас).
Или на внутреннем семинаре о фичах c# 6 все будут спрашивать, а почему там что то красненькое такое, а я буду отвечать глюковат релиз 9-ого решарпера.
Так как я запускаю превью студии, то проблемы студии будут игнорироваться, а проблемы релизной версии решарпера нет.
Тут поднимается вопрос, можно ли реализовать «add to user's dictionary» не только для ключевых слов, но и для других языковых конструкций. Если нельзя — то и говорить не о чем. А вот если можно, то почему бы нет?
Тут вопрос технический. Интересно бы узнать мнение от разработчиков решарпера.
Так я и говорю только о подсветке и не прошу рефакторинга.
Согласен. Только эти слова я бы переадресовал бы разработчикам решарпера.
Я вижу два варианта:
1. Ничего не делать, т.е. продолжать подсвечивать корректный синтаксис как ошибка. В этом случае, разработчик быстро перестанет считаться с подсветкой вообще.
2. Добавить возможность что то типа «Add to to user dictionary», что бы разработчик мог бы добавить неподдерживаемые слова в свой словарь с уровнем «предупреждение». В этом случае, разработчик может и дальше доверять подсветке синтаксиса и видеть те конструкции, которые пока не поддерживаюся.
Мне кажется, что второй вариант все-таки меньшее из зол.
Но в релизной версии я ожидаю или полную поддержку (плюс/минус баги) или явное описание того, что не поддерживается.
например, что бы Ваши пользователи были еще более довольны, чем сейчас :)
В этом случае мне кажется хорошо бы поискать какое то общее решение (позволять пользователю что то типа «add to user dictionary»), иначе вся эта подсветка ситнтаксиса ничего не стоит.
Я наверно попутал с какой-нибудь или чем таким же.
Кстати, что там за проблема с относительным путем к другому .ps1 файлу? было бы полезно понять в чем проблема и какие есть подходы к ее решению. Даже пример из поста содержит абсолютный путь, что не всегда хорошо.
и проекты так же структурированы? один проект — одна заметка? или один проект — один блокнот?
правильно ли я понимаю, что есть например блокнот «Люди», а нем блокнот для каждого человека? и вся информация о человеке сваливается в этот блокнот в виде последовательного листа заметок (без дополнительной иерархии)?
Извините, но вы делаете слишком много предположений, и не все из них соответствуют действительности.
Итого, согласимся на:
1. Писать статические поля — плохо.
2. Хорошо бы использовать DI или хотя бы ServiceLocator.
3. Не надо лениться и продолжать писать неправильный код.
Но те люди, которые все-таки игнорируют такие замечательные правила и хотят проверять, что поле какого-то определенного типа должно быть статическим, могут воспользоваться тем правилом анализа кода, которое обсуждалось в этом посте.
Кстати, чисто, что бы улучшить мир, поделитесь примером или описанием "ServiceLocator-а, умеющего создавать графы объектов для тех классов, которые про DI не знают".