Форматирование если Операторы

Вы можете поместить свои маршруты в план:

bp = Blueprint('burritos', __name__,
                        template_folder='templates')

@bp.route("/")
def index_page():
  return "This is a website about burritos"

@bp.route("/about")
def about_page():
  return "This is a website about burritos"

Затем вы регистрируете проект приложением с использованием префикса:

app = Flask(__name__)
app.register_blueprint(bp, url_prefix='/abc/123')
8
задан 6 revs, 2 users 100% 17 January 2014 в 19:45
поделиться

39 ответов

Я желаю, чтобы IDE осуществил бы это поведение. Когда Вы правильно указали, там не "правильное" поведение. Непротиворечивость более важна..., это мог быть любой стиль.

0
ответ дан 5 December 2019 в 04:27
поделиться

Из опций, если, я пошел бы с

if (x) {
  print "x is true";    
}

просто на основании фигурных скобок, являющихся привычкой ввести.

Реалистично, тем не менее, как программист главным-образом-Perl, я, более вероятно, буду использовать

print "x is true" if x;

(Который всегда сбивает меня с толку, когда я работаю на языке, который не поддерживает постфиксные условные выражения.)

0
ответ дан 5 December 2019 в 04:27
поделиться

Любое форматирование этого типа прекрасно. Люди будут спорить с Вами в синяках по этому, потому что это - что-то легкое для понимания. Людям нравится говорить о вещах, которые они понимают вместо того, чтобы иметь дело с большими проблемами, такими как хороший дизайн и решить тяжелые проблемы с новыми алгоритмами. Я склонен не предпочитать скобки для простых острот. Однако я также рад считать его со скобками. Если существует конкретное руководство по стилю для данного проекта, я предпочитаю следовать за этим. Я верю в непротиворечивость по некоторому субъективному идеалу правильности.

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

0
ответ дан 5 December 2019 в 04:27
поделиться

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


if (x)
    x = x + 1;
    printf("%d\n", x);

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


#define FREE(ptr) {free(ptr); ptr = NULL;}

if (x)
    FREE(x);
else
    ...

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

Таким образом, существуют возможные проблемы с тем способом форматировать, но они являются, по моему скромному мнению, не фатальными. Это заканчивается, чтобы быть вопросом вкуса.

0
ответ дан 5 December 2019 в 04:27
поделиться

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

0
ответ дан 5 December 2019 в 04:27
поделиться

Я предпочитаю следующее... я думаю, что это выглядит более чистым.

if(x)
{
    code;
}
else
{
     other code;
}
0
ответ дан 5 December 2019 в 04:27
поделиться

Я чувствую себя подобно забаллотированный до сих пор, но я буду ручаться за один из:

if (expr) {
   funcA();
}
else {
   funcB();
}

Или, стенография в ограниченных случаях для удобочитаемости:

if (expr) funcA();
else funcB();

Мне краткий формат хорош, когда Вы хотите, чтобы он читал как английская грамматика. Если код не будет выглядеть достаточно читаемым, то я вспыхну строки:

if (expr)
   funcA();
else
   funcB();

С внимательным рассмотрением я не помещаю вложенные условные выражения в if/else блоки для предотвращения неоднозначности кодера/компилятора. Если это больше сложно, чем это, я использую фигурные скобки на обоих if и else блоки.

0
ответ дан 5 December 2019 в 04:27
поделиться

One liners are just that... one liners and should remain like this :

if (param == null || parameterDoesNotValidateForMethod) throw new InvalidArgumentExeption("Parameter null or invalid");

I like this style for argument checking for example,it is compact and usually reads easily. I used to put braces with indented code all the time but found that in many trivial cases it just wasted spaces on the monitor. Dropping the braces for some cases allowed me to get into the meat of methods faster and made the overall presentation easier on the eyes. If however it gets more involved then I treat it like everything else and I go all out with braces like so :

if (something)
{
    for(blablabla)
    {
    }
}else if
{
 //one liner or bunch of other code all get the braces
}else
{
  //... well you get the point
}

This being said... I despise braces on the same line like so :

if(someCondition) { doSimpleStuff; }

of worst

if(somethingElse){
  //then do something
}

It is more compact but I find it harder to keep track of the braces.

Overall it's more a question of personal taste so long as one does not adopt some really strange way to indent and brace...

    if(someStuff)
        {
  //do something
        }
0
ответ дан 5 December 2019 в 04:27
поделиться

Я думаю, что я больше не такой, как я думал; Я еще не заметил этого.

Я поклонник

if (x)
{ foo(); }

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

Это также больше точка останова -дружелюбнее, чем однострочные if. Он также чувствует себя более комфортно в моем мире фигурных скобок на новой строке:

if (x)
{ foo(); }
else
{
   bar();
   baz();
}

Редактировать : похоже, я неправильно прочитал исходный вопрос, поэтому этот ответ не по теме. Однако мне все еще любопытно получить какой-нибудь ответ.

0
ответ дан 5 December 2019 в 04:27
поделиться
Другие вопросы по тегам:

Похожие вопросы: