Никогда, о nevermore

[egorius]

На сайте Фейерштейна (никогда не знаешь, как его правильно написать, а тем более — произнести) выложены несколько «стандартов кодирования» для PL/SQL. Интересно, думаю, надо посмотреть. Читаю:

Never issue a RETURN statement inside a loop. Your module should have one point of exit.

Ну почему, объясните! Нет, просто never и всё тут. По-моему, это всё из серии «никогда не используйте GOTO» — почему, уже никто не помнит, но все знают, что не положено.

Ещё и ещё раз убеждаюсь в том, что вместо тонны категоричных формулировок куда полезнее сформулировать несколько основополагающих правил и показать, как они работают на практике. Sapienti sat, а остальным всё равно не поможет.

Что, собственно, я и пытался проделать на работе на своём семинаре про качественные программы: у каждого свой способ чинить мотоцикл... Было уже две серии, видимо будет ещё. Кое-что можно и нужно улучшить, но в целом вроде получилось.

Comments

[hardsign.livejournal.com]

А где бы ознакомиться_с?

[egorius.livejournal.com]

В печатном виде пока_не, но как только_то.
Могу даже пригласить_на, если выдержишь 2 × 4 часа нравоучений :)

[hardsign.livejournal.com]

приглашай, на...

[d-byzero.livejournal.com]

(занудно): но это же вообще общее правило "хорошего тона" кодирования на любом языке -- из модуля (процедуры/функции) должен быть один выход.

Почему? Ну, потому что вдруг придет голову дописать что-нибудь общее, что должно выполняться перед выходом из модуля в любом случае? Ну и окажется, что, если есть дострочные выходы, то им это дописывание будет недоступно, просто потому, что о них забыли.

[d-byzero.livejournal.com]

читабелность, опять же. Можно, взглянув на модуль, определить, сколько у него точек выхода, если она не одна?

[egorius.livejournal.com]

Да-да, а GOTO нельзя использовать, поскольку это приводит к неструктурированному и запутанному коду.

Давай на примере. Вот так:

int get_something() {
  if (...) { // отбросим эти тривиальные случаи
    return 0;
  }

  . . .
  . . .
  . . .
  return (...);
}

Или вот так:

int get_something() {
  int something;

  if (!...) {
    . . .
    . . .
    . . .
    something = (...);
  } else {
    something = 0;
  }
  return something;
}

По-моему, вопрос спорный и лежит в плоскости личных пристрастий, а не читабельности.

[d-byzero.livejournal.com]

ну я сам использую иногда вар 1. но представляю, откуда растут ноги у требования варианта 2.

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

Как я понимаю, вар 1. очень трудно описать в стандарте. Ну не скажешь же "все дострочные выходы из модуля должны встречаться не более чем в превых X строках определения". А если вообще ничего не сказать, то, значит, можно дострочно выходить из любого места из любого if'а любой степени вложенности. И будет совершенно нечитаемо и несопровождаемо. С Goto, кстати, аналогичная фигня.

> По-моему, вопрос спорный и лежит в плоскости личных пристрастий
Проблема в том, что категориями личных пристрастий стандарт оперировать не может :-)

[egorius.livejournal.com]

Проблема в том, что понятие качества вообще не является объективным :)
Поэтому для любого набора правил можно написать программу, им удовлетворяющую, но такую, что без слёз на неё смотреть будет невозможно.
А поэтому без апелляции к здравому смыслу всё равно не обойтись. Что и хорошо :)

[konung2000.livejournal.com]

Кстати насчет Фейерштейна... Запустил он один проектец plsqlchallenge.com. Идея в том, чтобы раз в день отвечать на один вопрос по PL/SQL. В зависиомости уровня сложности и затраченного времени, тебе выставляются баллы. Есть два вида рейтинга - пожизненный и раз в картал. Так вот скоро начинается новый квартал - вливайтесь. А то с Арстела опознал я только одного человека и себя :)

[-pk-sly.livejournal.com]

Мне мольше нравятся вот такие эмпирические правила типа "пишите понятно" :)

[egorius.livejournal.com]

Я бы считал это не столько правилом, сколько указанием на то, к чему надо стремиться.
Если, применяя какое-то менее эмпирическое правило, ты получаешь более понятную программу, то ты на правильном пути. А если не получаешь — то ну его, надо искать что-то другое.