Вы используете 'это' перед переменными экземпляра?
Технически, да, вроде.
Но вам придется рекурсивно искать все instance_variables каждого объекта. И , как указывает Кэри , объект может быть назначен более чем одной переменной одновременно.
Не делай этого.
Причина, по которой я искал это поведение, заключалась в том, чтобы использовать имя переменной, но также в качестве позиции в сетке данных. Таким образом, если бы имелась двумерная сетка, имена переменных были бы похожи на «AA», «AB», «BC» и т. Д. Он знал его имя, он также знал бы его положение.
blockquote>То, что вы описываете, - это антишаблон «действие на расстоянии» , где изменения в одной части программы изменяют другую часть программы без очевидной связи. Это нарушает инкапсуляцию; Хорошая инкапсуляция позволяет вам понять отдельную часть системы, просто взглянув на ее входы и выходы. Нарушение инкапсуляции означает, что для понимания одной части системы вы должны понимать каждую часть системы, что приводит к кошмару обслуживания. Современные языки и практики стремятся как можно больше избегать этого.
Например, имя переменной никогда не должно иметь значения для поведения программы. Вы должны быть в состоянии безопасно выполнить рефакторинг Rename Variable , чтобы назвать переменную в соответствии с тем, что имеет смысл для пользователя объекта. В вашем примере это изменило бы поведение программы, нарушающей принцип наименьшего удивления .
Вместо этого у вас будет объект, представляющий вашу Грид, и это будет управлять отношениями между Узлами в Грид. Вместо того, чтобы обгонять отдельные узлы, вы обойдете сетку.
Или каждый Узел может знать, кто их соседние Узлы. Примером этого может служить традиционная структура Tree , Graph или Linked List . Преимущество здесь в том, что нет фиксированной позиции, и структура данных может расти или уменьшаться в любом направлении. Любой Узел может быть обойден, и он знает свое положение в структуре.
17 ответов
Нет. Я считаю это визуальным шумом. Я думаю, что эта переменная является опорой для плохих стилей именования. В моем типе я должен иметь возможность управлять именами полей, свойств и методов.
Нет абсолютно никаких веских оснований называть ваше вспомогательное поле «myfield», параметр для конструктора как «myField» и свойство для быть " Если вам нужно сделать это, то я утверждаю, что ваш тип слишком велик и, вероятно, не следует принципу единой ответственности . И скажем, вы есть. Зачем держать это. после того, как вы на самом деле позвоните. Рефакторинг это.
Если вам нужно сделать это, то я утверждаю, что ваш тип слишком велик и, вероятно, не следует принципу единой ответственности . И скажем, вы есть. Зачем держать это. после того, как вы на самом деле позвоните. Рефакторинг это.Я много делаю просто потому, что это вызывает всплывающее окно автозаполнения.
Если ваше имя переменной экземпляра совпадает с аргументом метода - это больше не «просто причина для разъяснения». Если вы не сделаете предварительную работу - это может привести к дефектам.
Я думаю, это то, что имел в виду Бен С. - но просто хотел подчеркнуть - что это уже не вопрос передовой практики.
Я часто делаю - увеличивает ясность. Я не думаю, что это добавляет беспорядок - потому что наш мозг быстро читает мимо него, но регистрирует, что это переменная экземпляра
Только когда требуется различать параметры, как в установщике или конструкторе. Я считаю его использование в ненужных случаях «кодовым мусором», аналогичным чарджанку Эдварда Туфте . Шум вместо сигнала.
Да. Я приобрел эту привычку, когда Intellisense в Visual Studio не был таким умным, как в наши дни.
Я не нахожу это отвлекающим, я полагаю, потому что я пишу много на Python и привык видеть себя везде.
Как правило, да. Коммуникационная сфера является важным аспектом читабельности. Он отличает его от локальных переменных, статических методов и т. Д. Он также сообщает, что определение «рядом».
О, и я делаю это только для открытых методов / свойств. Они, как правило, пишутся с большой буквы, поэтому все выглядит правильно. Внутренний вид выглядит как внешний вид (myInstance.Thing). Частные объекты часто бывают строчными и поэтому для них это менее привлекательная идея.
Конечно, это не является строго необходимым, и некоторые люди предпочитают это более кратко. Но он дает подсказки мне и другим разработчикам, которые могут посмотреть на код.
Да, если я увижу это. Я уверен, что это местный, и мне не нужно смотреть дальше. Если это не префикс с этим. (или, может быть, '_') Я должен проверить, объявлено ли оно локально или в предке, или это параметр, или ...
Все эти проверки занимают немного больше времени во время отладки ...
Да, для меня это добавляет немного ясности к коду, в текущей процедуре или классе ?
Мы используем ReSharper, который очень хорошо справляется со всем этим. Большую часть времени мы удаляем «this», не сохраняя его в конструкторе, поскольку мы обычно используем параметры конструктора с тем же именем.
Нет, но потом я много пишу на VB;)
О единственном времени, когда я проверю это / Me - это когда я не помню точное имя члена или когда мне нужно выделить его с помощью параметра функции с тем же именем.
В любое время у меня есть параметр метода, имя которого идентично переменной экземпляра (редко), которую я использую, чтобы избежать путаницы.
Я думаю, что эта практика в большинстве случаев улучшает разборчивость, так что да.
Абсолютно. «this» исключает необходимость использования префиксов, таких как m_. Что еще более важно, это быстро повышает производительность моего кода, и вот почему:
Я действительно принял Microsoft Cops (FxCop, StyleCop). Они действительно помогли мне поймать вещи, о которых я обычно даже не думал. Например, если метод не ссылается на какие-либо переменные-члены, одно из предложений FxCop - пометить метод как статический, чтобы метод не обязательно назначался каждому экземпляру класса. Из MSDN :
Методы, которые не обращаются к экземпляру методы данных или экземпляра вызова могут быть помечен как статический (Общий в Visual Basic). После того, как вы отметите методы как статический, компилятор выдаст не виртуальные сайты вызова на эти члены. Излучение не виртуального вызова сайты будут препятствовать проверке во время выполнения для каждого вызова, который гарантирует, что текущий указатель объекта не нулевой. Это может привести к измеримым увеличение производительности для чувствительный к производительности код. В некоторых случаях, невозможность доступа к текущий экземпляр объекта представляет проблема правильности.
Префикс моих переменных-членов с помощью this. делает две вещи для меня. Во-первых, это удовлетворяет StyleCop. Во-вторых, и что более важно, это помогает мне быстро определить, нужно ли помечать метод как статический.
Конечно, запуск FxCop скажет мне, если мне нужно пометить метод как статический. Однако, используя «это». помогает мне тратить больше времени на написание нового кода и меньше времени на устранение нарушений FxCop.
В C # я абсолютно верю. Основные причины:
Делать это или нет - стилистический вопрос. Несмотря на все продолжающиеся боевые действия, я не верю, что есть объективно лучший подход.
Мой инструмент анализа исходного кода ( StyleCop ) по умолчанию требует
этого.в перед обращениями к экземпляру. Мое первое замечание подразумевает, что мне не следует особо заботиться о том, всегда ли я делаю или всегда не делаю, и потому что настройка StyleCop по умолчанию для всегда требую этого, я выбираю путь наименьшего сопротивления / наибольшей последовательности и следую настройкам по умолчанию .
Я следую этой философии в большинстве стилистических вопросов. Я большой поклонник , а не изменения параметров форматирования по умолчанию в среде IDE с автоматическим форматированием. Это просто усложняет жизнь каждого из-за того, что на самом деле не так важно.
Я использую только this. префикс в конструкторах или установщиках, главным образом в случае, когда переданные параметры имеют то же имя, что и соответствующие переменные-члены.
Нет! Я, конечно, вижу, что это может быть полезно, но ничто из того, над чем я работаю, не является достаточно сложным, чтобы нуждаться в другом уровне разъяснения.