Внедрение функции стандартов кодирования Oracle - PullRequest
Новая
       25

Внедрение функции стандартов кодирования Oracle

2 голосов
/ 30 октября 2009

Хорошо, я зашел в какой-то тупик.

В моем проекте с открытым исходным кодом, браузере базы данных Oracle на базе .NET, я реализовал несколько инструментов рефакторинга. Все идет нормально. Единственной функцией, которую я действительно надеялся реализовать, было большое «Глобальное переформатирование», которое сделало бы стандарты кода (скрипты, функции, процедуры, пакеты, представления и т. Д.) Совместимыми. (Меня всегда огорчало отсутствие приличных инструментов рефакторинга SQL, и я хотел с этим что-то сделать.)

К сожалению, я обнаруживаю, к большому огорчению, что, похоже, не существует какого-либо одного широко используемого или даже "общепринятого" стандарта для PL-SQL. Такого рода помехи в моих планах реализации.

Мой поиск был довольно исчерпывающим. Я нашел много противоречивых документов, тем и статей, и мнения довольно разные. (Запятая, между прочим, кажется, вызывает немало споров.)

Итак, я столкнулся с парой вариантов:

  • Добавьте функцию, которая позволяет пользователю настраивать стандарт, а затем переформатировать код в соответствии с этим стандартом.

-ИЛИ-

  • Добавьте функцию, которая позволяет пользователю настраивать стандарт и просто генерировать список нарушений, как это делает StyleCop, оставляя SQL нетронутым.

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

В любом сценарии у меня все еще нет стандарта. То, что я должен знать от вас, ребята, является своего рода опросом, но вроде нет. Если вы собираетесь использовать инструмент такого типа, какие части вашего кода SQL вы бы хотели, чтобы он предупреждал вас или исправлял?

Опять же, я просто в растерянности из-за отсутствия единого стандарта. И, учитывая, что Oracle ничего официально не публикует, я думаю, что это то, на что сообщество может рассчитывать. Кроме того, учитывая то, как голосование работает на SO, голосование поможет установить популярность данного «рефакторинга».

P.S. Движок анализирует SQL в дереве выражений, чтобы он мог надежно анализировать SQL и переформатировать его. Там должно быть совсем немного, что мы можем сделать, чтобы исправить формат SQL. Но я думаю, что для первого релиза, layout является главной задачей. Хотя стоит отметить, что эта штука уже имеет рефакторинг для преобразования ключевых слов в верхний регистр и идентификаторы в нижний регистр.

Ответы [ 4 ]

1 голос
/ 18 апреля 2010

Мне нравится "стандарт" Тома Кайта (в его книгах). Это означает, что все в нижнем регистре. Самый легкий для глаз.

1 голос
/ 24 ноября 2009

PL / SQL является производным от Ады, однако руководство по стилю Ады почти так же отвратительно, как и большинство «старых школьников», предпочитающих БД. (Тот, где вы должны думать, что их замок заглавных букв застрял довольно плохо)

Придерживайтесь того, что вы уже знаете из .Net, что означает разумных идентификаторов, без шифрования / сжатия половины базы данных в 30 символов.
Вы можете использовать словарь и разделить части идентификатора на верблюжьих или подчеркнутых и проверить, являются ли они реальными словами. Вроде как то, что делает FxCop. Может быть немного раздражает, хотя. Поскольку средняя база данных Oracle имеет самые жестокие и непоследовательные правила именования, которые устарели даже 30 лет назад. Поэтому я не думаю, что вы достигнете цели получения чистых идентификаторов везде в ваших проектах (или ваших пользователях)

Поскольку PL / SQL нечувствителен к регистру, а столбцы предпочтительнее локальных переменных с одинаковыми именами, вам придется сделать еще больше компромиссов. Вы можете взять часть руководства по стилю для других производных паскаля (Ada основана на Modula, которая основана на Pascal), например Delphi , которые чувствуются немного ближе к дому для PL / SQL (я использую смесь .Net & Delphi). Особенно «aPrefix» для параметров может быть спасением, потому что вы не столкнетесь с именами столбцов таким образом: 

subtype TName is SomeTable.Name%type;
subtype TId   is SomeTable.Id%type;

function Test(aName in TName) return TId is
  result TId;
begin
  SELECT t.Id
  INTO   result
  FROM   SomeTable t
  WHERE  t.Name = aName;

  return result;
exception
  when No_Data_Found then
    return null;
end;

Без префикса oracle всегда будет выбирать столбец «Имя», а не параметр «Имя». (Это довольно раздражает, так как столбцы могут быть определены с псевдонимом ...)

Я настроил свой PL / SQL Devloper таким образом, чтобы все ключевые слова были написаны строчными буквами, однако я использовал те, которые используются в простом SQL, в верхнем регистре (SELECT, WHERE и т. Д.) В результате SQL-коды торчат из кода, но не весь мой код должен быть подвергнут жестокому обращению со всеми верхними ключевыми словами. (В любом случае они подсвечиваются, так что там с верхним фетишем? ;-))

Когда ваш инструмент способен идентифицировать простые SQL и дать некоторую визуальную подсказку, даже ключевые слова SQL не должны иметь другой регистр.

Кстати, я бы с удовольствием посмотрел на это. Можете ли вы опубликовать URL, или все еще "под прикрытием"? Ура, Роберт

1 голос
/ 02 ноября 2009

TOAD имеет «симпатичный принтер» и использует массу опций, чтобы дать пользователю возможность узнать, что сделано. (Но это стало настолько сложным, что я до сих пор не могу получить желаемые результаты.)

Для меня некоторые варианты выглядят ужасно, но, похоже, некоторым они нравятся. Разумное значение по умолчанию должно быть приемлемым в течение 80% времени, но так как это проблема религиозных войн, я уверен, что вы можете потратить совершенно неразумное количество времени на довольно маленькие результаты. Я бы посоветовал написать некоторые вещи, чтобы справиться с упомянутым вами 10-летним sp, и добавить что-то вроде <pre> тега, который красавчик-принтер оставляет в покое.

0 голосов
/ 24 ноября 2009

Если все, что вы делаете, это переставляете пробелы, чтобы код выглядел последовательно чистым, тогда нет риска изменить результаты SQL.

Однако, как разработчик Oracle / PLSQL в течение последних 8 лет, я почти гарантирую, что не буду использовать ваш инструмент независимо от того, сколько вариантов вы ему предоставите. Массовое переформатирование кода в принципе звучит великолепно, но тогда вы полностью разрушили его возможность контроля версий между ревизиями до и после переформатирования.

...