Лучший способ избавиться от венгерской нотации?
Допустим, вы унаследовали кодовую базу C#, которая использует один класс с 200 статическими методами для обеспечения основных функций (таких как поиск в базе данных). Из многих кошмаров в этом классе есть обильное использование венгерской нотации (плохой вид).
Реорганизуете ли вы имена переменных для удаления венгерской нотации или оставите их в покое?
Если бы вы решили изменить все переменные, чтобы убрать венгерскую нотацию, каким был бы ваш метод?
19 ответов
Просто оставь это в покое. Есть лучшее использование вашего времени.
Рефакторинг - я считаю, что венгерская запись в таком масштабе действительно мешает естественной читабельности кода, и это упражнение является хорошим способом ознакомления с тем, что там.
Однако, если есть другие члены команды, которые знают кодовую базу, вам потребуется консенсус по рефакторингу, и если какая-либо из переменных будет представлена вне одного проекта, вам придется оставить их в покое.
Щелкните правой кнопкой мыши на имени переменной, Refactor -> Rename.
Есть надстройки VS, которые делают это также, но встроенный метод работает хорошо для меня.
Не забывайте, что есть два вида венгерской нотации.
Оригинальный Charles Simonyi HN, позже известный как венгерский в App, а позднее мерзость, названная System Hungarian после некоторой чепухи (это технический термин), полностью неверно истолковал оригинальную статью Симони.
К сожалению, система HN была распространена Petzold и другими, чтобы стать более доминирующим абортом, который по праву признан сегодня.
Прочитайте отличную статью Джоэла о намерениях оригинальной Службы венгерской нотации и извинитесь за то, что было потеряно в спешке
Если у вас есть приложение на венгерском языке, вы, вероятно, захотите сохранить его после прочтения как оригинальной статьи Чарльза Симони, так и статьи Джоэла.
Если вы попали в дымящуюся кучу System Hungarian?
Все ставки сделаны!
Уф! (сказал, держа нос) (-:
Что бы я сделал? Предполагая, что я просто должен поддерживать код, а не переписывать его каким-либо существенным образом? Оставь это в покое. И когда я добавляю код, переходите к существующему стилю, то есть используйте эту уродливую венгерскую нотацию (настолько грязную, насколько мне кажется).
Но, эй, если у тебя действительно есть тяга к рефакторингу, просто делай понемногу. Каждый раз, когда вы работаете над этим, тратите десять минут на переименование переменных. Немного прибираюсь. Через несколько месяцев вы можете обнаружить, что он чистый как свисток....
Раньше я использовал его религиозно еще в дни VB6, но прекратил работу, когда вышел VB.NET, потому что так сказано в новых рекомендациях VB. Другие разработчики не сделали. Итак, у нас есть много старого кода с ним. Когда я выполняю обслуживание кода, я удаляю обозначение из функций / методов / суб, к которым я прикасаюсь. Я не убрал бы все сразу, если у вас нет действительно хороших модульных тестов для всего и вы можете запустить их, чтобы доказать, что ничего не сломано.
Сколько вы собираетесь сломать, делая это? Это важный вопрос, который нужно задать себе. Если есть много других частей кода, которые используют эту библиотеку, то вы можете просто создавать работу для людей (возможно, для вас), выполнив упражнение по переименованию.
Я бы включил это в список вещей, которые нужно сделать при рефакторинге. По крайней мере, тогда все ожидают, что вы сломаете библиотеку (временно).
Тем не менее, я полностью разочарован плохо названными методами и переменными, так что я могу общаться.
Если вам повезло и вы хотите, чтобы венгерский язык ушел, выделите используемые венгерские префиксы и попробуйте выполнить поиск и замену в файле, чтобы заменить их ничем, а затем выполните очистку и перестройку. Если количество ошибок невелико, просто исправьте это. Если количество ошибок велико, вернитесь назад и разбейте его сначала на логические (по доменам) классы, а затем переименуйте по отдельности (поможет IDE)
Я бы не стал делать из этого проект. Я бы использовал инструменты рефакторинга в VS (на самом деле, я бы использовал Resharper, но работа VS просто отлично) и исправил бы все переменные в любом методе, который мне нужно было изменить. Или, если бы мне пришлось вносить более масштабные изменения, я бы рефакторировал имена переменных в любом методе, который мне был необходим для понимания.
Я бы сказал, что большая проблема в том, что у вас есть один класс с 200(!) Методами!
Если это сильно зависит от / сильно измененного класса, возможно, стоит сделать рефакторинг, чтобы сделать его более удобным для использования.
В этом Resharper абсолютно необходим (вы можете использовать встроенный рефакторинг, но Resharper намного лучше).
Начните находить группу связанных методов, а затем преобразуйте их в хороший маленький сплоченный класс. Обновите, чтобы соответствовать вашим последним стандартам кода.
Скомпилируйте и запустите ваш набор тестов.
Есть энергия для большего? Извлеките другой класс.
Изношены - нет проблем; вернись и сделай еще немного завтра. Всего за несколько дней ты покоришь зверя.
Я согласен с тем, что лучший способ отказаться от венгерской нотации - это реорганизовать код по мере его изменения. Самым большим преимуществом такого рефакторинга является то, что вы должны писать модульные тесты вокруг кода, который вы модифицируете, чтобы у вас была сеть безопасности вместо того, чтобы скрестить пальцы и надеяться, что вы не сломаете существующую функциональность. После того, как у вас есть эти модульные тесты, вы можете сменить код на свое усмотрение.
Я согласен с @Booji - делайте это вручную, на рутинной основе, когда вы уже посещаете код по какой-либо другой веской причине. Тогда вы получите самые распространенные из них, и кто заботится об остальном.
Я думал о том, чтобы задать аналогичный вопрос, только в моем случае код, вызывающий оскорбление, - мой собственный. У меня есть очень старая привычка использовать "плохой вид" венгерского из моих дней FoxPro (который имел слабую типизацию и необычную ограниченность) - привычка, которую я только недавно бросил.
Это сложно - это означает, что нужно принять несовместимый стиль в вашей кодовой базе. Это было только неделю назад, когда я наконец сказал "винт" и начал имя параметра без буквы "p". Когнитивный диссонанс, который я первоначально почувствовал, сменился чувством свободы. Мир не пришел к концу.
Если у вас есть законная необходимость удалить и изменить его, я бы использовал либо встроенные инструменты рефакторинга, либо что-то вроде Resharper.
Тем не менее, я бы согласился с Крисом Конвеем в определенной точке зрения и спросил бы вас, ПОЧЕМУ, да, это раздражает, но в то же время, в большинстве случаев, метод "если ничего не сломано, то не исправить это" действительно лучший путь!
Я решил эту проблему, меняя одну переменную за раз, когда сталкиваюсь с ними, а затем выполняю более радикальные изменения, когда вы возвращаетесь, чтобы сделать более глубокие изменения. Если вы чем-то похожи на меня, то другая номенклатура ваших переменных на некоторое время сведет вас с ума от летучей мыши, но вы постепенно к этому привыкнете. Ключ в том, чтобы постепенно избавляться от него, пока у вас не будет все, где оно должно быть.
В качестве альтернативы, вы можете полностью исключить свои переменные и просто вернуть каждую функцию 42.
Измените его только тогда, когда вы его используете напрямую. И убедитесь, что у вас есть готовый испытательный стенд, чтобы убедиться, что он все еще работает.
Если вы собираетесь нарушать код только ради рефакторинга, я бы серьезно подумал о том, чтобы оставить меня одного, особенно, если вы собираетесь влиять на других людей в вашей команде, которые могут зависеть от этого кода.
Если ваша команда в порядке с этим рефакторингом и вкладывает ваше время в это (что может сэкономить время в будущем, если это означает, что код более читабелен / удобен в обслуживании), используйте Visual Studio (или любую IDE, которую вы используете), чтобы помочь вам рефакторинг кода.
Однако, если такие большие перемены не являются риском для вашей команды / руководителя, я бы предложил несколько неортодоксальный подход на полпути. Вместо того, чтобы выполнять весь процесс рефакторинга за один раз, почему бы не рефакторинг разделов кода (точнее, функций), к которым нужно обращаться при обычном обслуживании? Со временем этот медленный рефакторинг приведёт код в более чистое состояние, и в этот момент вы можете завершить процесс рефакторинга с окончательной проверкой.
Мне кажется, что большая проблема в том, что класс God Object состоит из 200 методов. Я бы предположил, что рефакторинг только для того, чтобы убрать венгерскую нотацию, сам по себе является малоценной и рискованной деятельностью. Если в этом классе нет обильного набора автоматических модульных тестов, чтобы придать вам уверенность в вашем рефакторинге, я думаю, вы должны оставить его в покое и по-настоящему в покое.
Я полагаю, что такой набор тестов маловероятен, потому что разработчик, следуя методам TDD, (надеюсь), естественно, вообще избежал бы создания объекта God - было бы очень сложно написать всесторонние тесты.
Однако устранение объекта бога и получение базы для юнит-тестирования имеет большую ценность. Я бы посоветовал поискать возможности для реорганизации самого класса - возможно, когда появятся подходящие бизнес-требования / изменения, которые потребуют изменения в этом коде (и, следовательно, мы надеемся, что будут куплены и оплачены некоторые системные и регрессионные тесты). Возможно, вы не сможете оправдать усилия по рефакторингу всего этого за один раз, но вы можете сделать это по частям, как только появится возможность, и протестировать изменения. Таким образом, вы можете постепенно преобразовывать код спагетти в более чистую кодовую базу с помощью комплексных модульных тестов, постепенно.
И вы можете ликвидировать венгерский, как вы идете, если хотите.
Я фактически делаю то же самое здесь для расширения приложения. Мой подход состоял в том, чтобы использовать сопоставления VIM для поиска определенных венгерских префиксов нотации, а затем удалять их и исправлять заглавные буквы в зависимости от ситуации.
Примеры (идет в vimrc):
"" Hungarian notation conversion helpers
"" get rid of str prefixes and fix caps e.g. strName -> name
map ,bs /\Wstr[A-Z]^Ml3x~
map ,bi /\Wint[A-Z]^Ml3x~
"" little more complex to clean up m_p type class variables
map ,bm /\Wm_p\?[A-Z]^M:.s/\(\W\)m_p\?/\1_/^M/\W_[A-Z]^Mll~
map ,bp /\Wp[A-Z]^Mlx~
Используйте этот инструмент java для удаления HN:
Или просто используйте "replace"/"replace all" на регулярное выражение, как показано ниже, чтобы заменить "c_strX" на "x":
Я люблю венгерскую нотацию. Не понимаю, почему вы хотели бы избавиться от этого.