Это - плохая практика для использования временных переменных, чтобы не вводить?
Я не использовал его лично, но , SwingUnit выглядит довольно хорошим. Можно использовать его с jUnit, и это не основано "на местоположении компонентов" (т.е. координаты X и Y).
единственная вещь можно иметь отношение к разработчику NetBeans GUI, определенные уникальные имена для компонентов.
8 ответов
Этот пример прекрасен, поскольку вы используете его в функциях / методах.
Переменная будет сброшена сразу после завершения метода / функции - так что утечки памяти не так много или что-то в этом роде.
Также, сделав это, вы "вроде" реализовали DRY - не повторяйтесь.
Зачем писать так много $ this-> currentDatabase , когда вы можете написать $ db . А что, если вам нужно изменить $ this-> currentDatabase на другие значения?
Actually, you're not trying to avoid typing (otherwise, you'd use a completion mechanism in your editor), but you're just making your function more readable (by using "abbreviations") which is a good thing.
Drawbacks will show up when you start doing this to avoid typing (and sacrifice readability)
Это зависит от того, какой контракт на $ this-> currentDatabase. Может ли он измениться в любой момент после вызова любого метода? Если он изменится, вы должны продолжать использовать объект, который вы использовали при первом вызове базы данных, или вы должны всегда использовать текущее значение? Это диктует, если вы должны всегда использовать $ this-> currentDatabase, или если вы должны всегда сохранять его в переменной перед использованием.
Так что, строго говоря, это не вообще вопрос стиля.
Но, если предположить, что член никогда не изменяется во время таких вызовов функций, как этот, это не имеет значения. Я бы сказал, что хранить его в переменной немного лучше, так как его легче читать и он позволяет избежать доступа к члену объекта при каждой операции. Компилятор может оптимизировать его, если он хорош,
Кажется, я помню, что Стив МакКоннелл не рекомендует использовать временные переменные в «Завершенном коде». Рискуя совершить ересь, я вынужден не согласиться. Я предпочитаю введенную дополнительную удобочитаемость. Я также обнаружил, что добавляю их для помощи в пошаговой отладке, но не вижу причин для их удаления.
ссылка: http://css-discuss.incutio.com/?page=ScreenreaderVisibility
display: none: не будет не видел и не слышал. *
видимость: скрытый: не будет ни виден, ни слышен. *
text-indent: 9999: не будет виден, но будет слышен.
- Большая часть программы чтения с экрана не будет «говорить» display: none и visibility : скрытый ,
Если вы сделаете это осторожно, ничего страшного. Пока вы используете только несколько из этих переменных в небольшом объеме кода и внутри небольших функций, я думаю, что это нормально.
Если у вас много этих переменных и они плохо названы, например, i, j, l и f, в одной и той же функции, понятность вашего кода пострадает. Если это так, я бы предпочел ввести немного больше, чем иметь непонятный код. Это одна из причин, по которой в хорошей среде IDE есть автоматическое завершение кода.
Нет, я думаю, это нормально. Часто производительность, если не так критична, как чистый читаемый код.
Кроме того, вы жертвуете памятью небольшим выделением в стеке для более быстрых вызовов методов, избегая лишних разыменований.
В общем:
- И $ db, и $ this-> currentDatabase указывают на один и тот же объект.
- Небольшое пространство, выделенное для $ db, освобождается (или может использоваться для сборки мусора. ) когда функция завершается
, поэтому я бы сказал: нет, это неплохая практика.