Есть ли хорошая причина использовать прописные буквы для ключевых слов SQL? [закрыто]
Вам нужно изменить свой код следующим образом:
/**
* @Route(
* "/drop/getCategory/",
* name="getCategory"
* )
* @Method("GET")
*/
public function getAllCategoryAction() {
$categorias = $this->getDoctrine()
->getRepository('AppBundle:Categoria')
->findAll();
$categorias = $this->get('serializer')->serialize($categorias, 'json');
$response = new Response($categorias);
$response->headers->set('Content-Type', 'application/json');
return $response;
}
Если служба serializer не включена, вы должны включить ее в app/config/config.yml:
framework:
# ...
serializer:
enabled: true
Для более сложных опций для сериализации вы можете установить JMSSerializerBundle
10 ответов
Это - просто вопрос стиля, вероятно, происходящего в дни, когда редакторы не сделали окраски кода.
я раньше предпочитал весь верхний регистр, но я теперь склоняюсь, все понижаются.
Одна из причин продолжения использовать капитализацию - (или кто-то еще) при просмотре кода в чем-то как блокнот это помогает читать. т.е. можно дифференцироваться легко между "ключевыми словами" и именами таблиц, SP, udf's и т.д.
Кроме соответствия для пользы соответствий, нет. Хотя это - очень субъективная тема, я предпочитаю использовать смешанный случай для всего SQL. SQL намного легче считать, и ничто не потеряно в современных IDE, где на ключевые слова все наносят цветную маркировку так или иначе.
Я нахожу это более читаемым. То же для того, чтобы иметь новую строку в течение начала каждого пункта и расположения с отступом между пунктами.
Попробуйте продукт форматирования (я использую Подсказку/SQL SQL, Осуществляют рефакторинг от Красного Логического элемента). Можно установить, как Вы хотите, чтобы капитализация работала, и Ваш код будет всегда последовательно форматироваться. Оставьте свой мизинец и позвольте компьютеру сделать работу для Вас.
Верхний регистр может обеспечить усиление в видимости ключевого слова, но можно компенсировать с выделением кода и добавлением отступа.
Мы используем нижний регистр, потому что редактор запросов и другие инструменты делают чудеса в редактировании t-кода-SQL, и мы не видим потребности подвергнуть пыткам мизинец.
Верхний регистр менее читаем. Схема всех слов формируется как поля; нет никаких подстрочных элементов или надстрочных элементов. Строчный FTW!
Обезьяна видит, обезьяна делают для меня. Сопоставление с образцом - если я делаю это способ, которым я видел сделанный, структура пунктов, выстраивается в линию мысленно более легко.
Примеры Gordon Bell не точно корректны; обычно, только ключевые слова выделяются, не весь запрос. Его второй пример был бы похож:
SELECT name, id, xtype, uid, info, status,
base_schema_ver, replinfo, parent_obj, crdate,
ftcatid, schema_ver, stats_schema_ver, type,
userstat, sysstat, indexdel, refdate, version,
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1
я нахожу настолько далеко легче читать, так как ключевые слова выделяются больше. Даже с подсветкой синтаксиса, я нахожу, что некапитализированный пример намного тяжелее читает.
В моей компании, мы идем немного дальше с нашим форматированием SQL.
SELECT name, id, xtype, uid, info, status,
base_schema_ver, replinfo, parent_obj, crdate,
ftcatid, schema_ver, stats_schema_ver, type,
userstat, sysstat, indexdel, refdate, version,
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
LEFT JOIN systhingies ON
sysobjects.col1=systhingies.col2
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1
ЛИЧНО, мне не НРАВИТСЯ МОЙ SQL, ВОПЯЩИЙ НА ME. IT НАПОМИНАЕТ МНЕ ОБ ОСНОВНЫХ ИЛИ КОБОЛЕ.
, Таким образом, я предпочитаю свой нижний регистр T-SQL с именами объектов базы данных MixedCase.
намного легче читать, и литералы и комментарии выделяются.