У меня есть опыт защиты Windows-приложений при помощи цифровых подписей сборок (ассиметричного шифрования). Однако даже этот способ не спасал от декомпиляции и переподписывания. Вобщем, вывод такой, что надежной защиты кода для .NET-сборок нет. Единственный вариант — это вынести существенную часть функциональности приложения на подконтрольные вам веб-сервисы, которые заодно будут проверять лицензионность (по IP или номеру лицензии), вести черные списки. Понятно, что это подходит не для всех заказчиков.
«Взлом» NET-кода при помощи Reflector — дело относительно простое, если код не обфусцирован. Есть, конечно, деобфускаторы, но в любом случае это добавляет значительную порцию геморроя. Рекомендую в советы разработчикам добавить: «Не забывайте обфусцировать свои приложения».
Полные мудаки те кто так говорит, не попробовав. А новый синтаксис никто не изобретает — это всё тот же C#. Если есть доводы «против» — обосновывай, а иначе — это безосновательные понты, точнее — попытка выдать мнение большинства за свое личное.
Ощущения понятны. У меня тоже такое поначалу было.
Но как я уже писал — через несколько дней использования русских символов это проходит. Кто не верит — попробуйте :)
Кто-нибудь еще понимает — почему (кроме снобизма) код по ссылке так бесил вольфа? Впрочем, я не знаток JS, и возможно, специфика языка не позволяет писать по-русски?
По-моему — хороший код — это неглючащий и легко модифицируемый код. Остальное не так уж важно.
Многое зависит еще и от архитектуры решения. Если выделены слои объектной модели и слоя доступа к хранилищу — проблем не будет. Если такого разделения нет и предполагается что объектная модель сама собой вытекает из схемы таблиц — проблемы обязательно будут. Но их причиной будут не столько русскоязычные идентификаторы, сколько неграмотная слипшаяся архитектура.
Кстати, мне в работе все чаще попадаются базы (SQL), в которых таблицы и столбцы названы по-русски. Сам я в SQL не силен, использую EntityFramework — проблем с русскими названиями ни разу не было.
Хорошо когда есть альтернатива, когда вы можете по своим убеждениям или привычкам выбирать наиболее удобный для себя способ работы. До dotNET возможности создавать объектную модель на русском не было, теперь вот появилась. Некоторые из тех кто ее попробует — станут ее использовать по возможности всегда, остальные — будут работать «традиционно», и это не означает что кто-то из них прав или не прав.
В конечном счете успех проекта зависит не от языка идентификаторов и даже не от языка программирования, а от более глобальных вещей.
Ну и плюс — есть еще процессы, идущие независимо от наших привычек. Например — кириллические домены. Хотим мы или нет — бизнес сделает свое время, и скоро ссылки типа www.поликлиника123.рф будут восприниматься нами нормально, как бы презрительно мы сейчас не плевались.
Да, это известно.
Однако это не означает, что всегда и везде нам нужно общаться только на международном. Если проект отечественный (как, например, Хабр) — можно общаться и по-русски :)
Если между заказчиком и программистами у вас отдел аналитиков — тогда, может, и незачем. А если с постановщик задачи — сисадмин из поликлиники и отдела аналитиков у вас нет — тогда программистам будет легко обсуждать с сисадмином их «хотелки» и ваши «могульки» при помощи одних терминов.
Кстати, как правило, программисты не жаждут сильно разбираться в предметной области и терминологии заказчика.
Большая часть кода в VisualStudio пишется при помощи IntelliSense и сниппетов. Таким образом, достаточно один раз аккуратно вбить названия — и потом выбирать их из выпадающих списков.
Да, конечно, что угодно может привести к глюкам. Но самые жесткие глюки (имеющие далеко идущие последствия) обычно кроются в неправильной архитектуре, или в том что разработчик неточно понял желания заказчика, или в том что кто-то из команды программистов непрально понял объектную модель. И это — важнее чем мелкие проблемы из-за раскладки. Обозначая проблему — давайте обозначать и ее важность на фоне других проблем, давайте учитывать приоритеты.
Разве идея описания предметной области языком, близким к языку заказчика — не важнее мелких проблем из-за невнимательности разработчика или стоимости слегка раздолбанной клавиатуры?
Я уже писал, что это дело привычки. Сперва кажется ужасом — через несколько дней всё отлично. Таким же ужасом покажется любой новый язык программирования, но стоит немного попрограммировать на нем — и он начинает казаться естественным. Проверено на опыте.
Видимо, вопрос в приоритетах — что ценнее: клавиатура или легкочитаемый код. Из 17 лет программирования 14 лет я тоже программировал исключительно по-английски. Однако лично я готов пожертвовать клавиатурой ради понятного кода.
Про подчеркивания и разные среды: при написании статьи я имел в виду исключительно VisualStudio, dotNET и C#. Еще я использую Resharper — русские идентификаторы он за ошибки не считает :)
Про удобство поиска — понятно. То есть вы НЕ ПРОТИВ русских названий, это лишь дело привычки. Кстати, если бы вы называли все файлы по-русски — искать их по первым буквам было бы также просто :)
За три года использования русских идентификаторов у меня был лишь один такой случай (с буквой «c»). Решить проблему оказалось несложно, и больше такое не повторялось.
Эту проблему можно и с ног на голову перевернуть: а вдруг кто-то в английском идентификаторе по невнимательности вместо английских «C» и «O» напишет русские? Для примера: угадайте — где три русских буквы в этом названии: ОbjectCоlleсtionProvider ???
Но как я уже писал — через несколько дней использования русских символов это проходит. Кто не верит — попробуйте :)
По-моему — хороший код — это неглючащий и легко модифицируемый код. Остальное не так уж важно.
Кстати, мне в работе все чаще попадаются базы (SQL), в которых таблицы и столбцы названы по-русски. Сам я в SQL не силен, использую EntityFramework — проблем с русскими названиями ни разу не было.
Хорошо когда есть альтернатива, когда вы можете по своим убеждениям или привычкам выбирать наиболее удобный для себя способ работы. До dotNET возможности создавать объектную модель на русском не было, теперь вот появилась. Некоторые из тех кто ее попробует — станут ее использовать по возможности всегда, остальные — будут работать «традиционно», и это не означает что кто-то из них прав или не прав.
В конечном счете успех проекта зависит не от языка идентификаторов и даже не от языка программирования, а от более глобальных вещей.
Ну и плюс — есть еще процессы, идущие независимо от наших привычек. Например — кириллические домены. Хотим мы или нет — бизнес сделает свое время, и скоро ссылки типа www.поликлиника123.рф будут восприниматься нами нормально, как бы презрительно мы сейчас не плевались.
Однако это не означает, что всегда и везде нам нужно общаться только на международном. Если проект отечественный (как, например, Хабр) — можно общаться и по-русски :)
Кстати, как правило, программисты не жаждут сильно разбираться в предметной области и терминологии заказчика.
А вот если вам закажут автоматизировать местную поликлинику или детсад — возможность создания русской объектной модели может очень пригодиться.
Да, конечно, что угодно может привести к глюкам. Но самые жесткие глюки (имеющие далеко идущие последствия) обычно кроются в неправильной архитектуре, или в том что разработчик неточно понял желания заказчика, или в том что кто-то из команды программистов непрально понял объектную модель. И это — важнее чем мелкие проблемы из-за раскладки. Обозначая проблему — давайте обозначать и ее важность на фоне других проблем, давайте учитывать приоритеты.
Разве идея описания предметной области языком, близким к языку заказчика — не важнее мелких проблем из-за невнимательности разработчика или стоимости слегка раздолбанной клавиатуры?
Я уже писал, что это дело привычки. Сперва кажется ужасом — через несколько дней всё отлично. Таким же ужасом покажется любой новый язык программирования, но стоит немного попрограммировать на нем — и он начинает казаться естественным. Проверено на опыте.
Про подчеркивания и разные среды: при написании статьи я имел в виду исключительно VisualStudio, dotNET и C#. Еще я использую Resharper — русские идентификаторы он за ошибки не считает :)
Эту проблему можно и с ног на голову перевернуть: а вдруг кто-то в английском идентификаторе по невнимательности вместо английских «C» и «O» напишет русские? Для примера: угадайте — где три русских буквы в этом названии: ОbjectCоlleсtionProvider ???