ColdFusion: действительно ли безопасно не учесть ключевое слово переменных в CFC?

Особенно в CFCs, надлежащий обзор важен. Дополнительное 'многословие' стоит ясности. Имеющие переменные выскальзывают из своего объема отступа, вызовет серьезные проблемы и очень трудно диагностировать.

Многословие является не всегда плохой вещью. Мы называем наши функции и методы описательными способами как getAuthenticatedUser (), а не gau (). Столбцы базы данных и таблицы лучше всего оставляют описательными как EmployeePayroll, а не empprl. Таким образом быть кратким могло бы быть 'легче', когда Ваша кратковременная память полна деталей проекта, но быть описательными шоу, Ваше намерение и полезно в течение этапа технического обслуживания приложения после Вашей кратковременной памяти, было заполнено другим материалом.

Я скажу Да. Это явно необходимо? Нет. Можно ли сойти с рук не выполнение его?Конечно. Вы напрашиваетесь на неприятности? Абсолютно. Если у Вас есть следующая внутренняя часть cffunction:

<cfset foo = "bar" />

Это не поместит ту переменную в функциональный локальный объем var, она поместит его в объем ГЛОБАЛЬНЫХ ПЕРЕМЕННЫХ CFC, означая, что это доступно каждому методу этого CFC. Существуют времена, когда можно хотеть сделать это, но большую часть времени Вы попросили бы состояние состязания.

Когда любая переменная читается сервером, если та переменная не является explicity, объявленным как часть объема (ЗАПРОС., СЕССИЯ., и т.д.) затем ColdFusion выполнит ScopeCheck () для определения, в каком объеме переменная находится. Мало того, что это помещает ненужные издержки в Ваш сервер приложений, они также представляют способность к угону, посредством чего Ваша переменная находится в одном объеме, но ScopeCheck () нашел переменную того же имени выше в порядке приоритета.

Всегда, всегда, ВСЕГДА, определяют объем всех переменных. Неважно, как тривиальный. Даже вещи как имена запроса и индексы цикличного выполнения. Сохраните себя и тех, которые приезжают позади Вас от боли.

Короткий ответ на Ваш вопрос - то, что не, Вы, вероятно, не столкнетесь с проблемой, пытающейся сделать это. Вне контекста UDF (даже все еще в CFC), неограниченный по объему оператор набора подразумевает объем переменных.

Кроме того, в CFC, объем Переменных доступен всем своим функциям; это - вид глобальной области видимости в этом, CFC - подобный "этому" объему, кроме объема переменных сродни "частным" переменным, тогда как этот объем сродни общедоступным переменным.

Для тестирования этого создайте test.cfc:

<cfcomponent>
    <cfset foo = "bar" />
    <cffunction name="dumpit" output="true">
        <cfdump var="#variables#" label="cfc variables scope">
        <cfdump var="#this#" label="cfc this scope">
    </cffunction>
</cfcomponent>

и страница для тестирования его, test.cfm:

<cfset createObject("component", "test").dumpit() />

И результаты будут:

Теперь, для рассмотрения другой проблемы я вижу в примере кода...

В CF все Определяемые пользователем Функции имеют специальный объем без имени, обычно называемый объемом "var". Если Вы делаете следующую внутреннюю часть UDF:

<cfset foo = "bar" />

Затем Вы говорите CF помещать ту переменную в объем var.

Для соединения вещей немного можно столкнуться с проблемами (изменение значений переменных, когда Вы не ожидали их к), когда Вы не используете объем var в своем встроенном UDFs.

Таким образом, эмпирическое правило к всегда, Всегда, ВСЕГДА, ВСЕГДА объем var Ваши функциональные внутренние переменные (включая имена запроса). Существует инструмент, названный varScoper, который поможет Вам в нахождении переменных, которые должны быть ограничены по объему var. В последний раз я проверил, что это не было прекрасно, но это - определенно запуск.

Однако это - плохая идея сослаться (отображают/используют) переменные без объема (очевидно, за исключением ограниченных по объему var переменных, поскольку Вы не можете указать объем для чтения из) в CFCs или даже на стандартных страницах CFM. С CF7 было 9 объемов, которые были проверены в определенном порядке, когда Вы читаете переменную, не указывая объем, сначала соответствуете победам. С CF8 могло быть больше объемов в том списке, я не проверил. Когда Вы делаете это, Вы рискуете получать значение от одного объема, когда Вы ожидаете это от другого; который является кошмаром для отладки... Я уверяю Вас.;)

Так короче говоря: допущение объема переменной (на наборе) не является ужасной идеей (хотя я обычно указываю его так или иначе); но выведение объема переменной (на чтении) напрашивается на неприятности.

Не явно обзор в объеме переменных может работать, но это не хорошая идея, и честно единственной причиной не к является вне лени IMO. Если Вы явно определяете объем всего, что 1) Вы избегаете, чтобы потенциал вышел и 2) это делает код легче считать, потому что нет никакого вопроса, которые определяют объем вещей, находятся в.

Мне это не делает код более подробным (и конечно весьма обязательно подробный) - это на самом деле легче считать, избегает беспорядка и избегает странных побочных эффектов, которые могут неожиданно возникнуть, если Вы явно не определяете объем.

Вот очень хорошая ссылка объема CFC от Raymond Camden. Лично, я предпочитаю делать 'сам' хеш для предотвращения всего беспорядка (заметьте, что я не использую объем 'переменных' в функциях):

<cfcomponent>
  <cfset variables.self = structNew()>
  <cfscript>
    structInsert(variables.self, <key>, <value>);
    ...
  </cfscript>

  <cffunction name="foo">
    self.<key> = <value>
    <cfreturn self.<key> />
  </cffunction>

  ...

Лучшие практики в стороне, я полагаю, что это могло также зависеть от того, как Ваша попытка получить доступ к Вашему cfc's у меня не было проблем при пропуске их при создании объектов и доступе к ним от coldfusion. Однако я думаю, что это могло бы быть необходимо при доступе и/или отображении их удаленно через actionscript в гибком проводе/флэш-памяти.

После чтения Ваших ответов вот то, что я думаю:

Да, это безопасно. В целом это не необходимо или полезно явно указать объем переменных. Это просто добавляет помеху к уже подробному языку.

Предоставленный, существует одно незначительное исключение, как Soldarnal указал, где квалификация ограниченной по объему переменными переменной требуется. Это - то, если у Вас есть функциональная локальная переменная с тем же именем. (Но Вы, вероятно, не должны делать этого так или иначе.)

Простой ответ на Ваш вопрос: "нет, Это не необходимо"

Однако я думаю, что лучшие практики предложили бы, чтобы Вы действительно, на самом деле, использовали переменные indentifier при доступе к тем переменным. По-моему, любой, кто наталкивается на Ваш код в будущем и смотрит посреди функции, будет немедленно знать обзор переменной, не имея необходимость сканировать вершину функции локальные функции.

На самом деле я добавляю немного дополнительного многословия к своему CFC UDFs путем создания одной локальной структуры:

<cfset var, локальный = structNew ()/>

Затем я поместил весь свой локальный Вар в ту структуру и ссылаюсь на них тот путь, таким образом, мой код будет выглядеть примерно так:

<cfset local.foo = variables.bar + 10/>