Formatter Plus кажеться ...

Да. Чем их меньше тем лучше.
А так же:
- отсутсвие явных коммитов и роллбеков
- код SQL зашитый в клиента ,вместо использования пакаджей
- неиспользование типов типа xxx%TYPE
- отсутствие схемы обработки ошибок
- отсутвие комментариев для последующих поддерживателей кода
- отсутвие предметно-ориентированного интерфейса в пакаджах
- код, приводящий к неиспользованию индексов

Вообще надо определиться с целями, а уж потом идут метрики как критерии их достижения. А цели примерно таковы:
- корректность кода;
- эффективность кода;
- простота в понимании;
- простота во внесении изменений (с обеспечением первых 3-х целей );

А дельше уж сам смотри как ты будешь этого достигать.

SELECT id FROM some_table WHERE id+1 = 123;

id - PK for some_table. Индекс по id не будет использован.

А про предметно-ориентированный интерфейс - названия методов и их логика должны отражать предметную область ,а не детали реализации.

Типа не IncreaseFirstField, а DepositSomeMoney

А также весьма полезно использовать private методы в пакаджах (те, что не были объявлены в спецификации)

PS:
Мне лично симпатичен подход Long-term lazyness - что в вольном переводе означает "Лучше день потерять, потом за час долететь"