Как стать автором
Обновить

Комментарии 32

if <>                      # начало блока 1
    if <>                      # начало блока 2
        ... команды .... 2
    elif <>
        ... команды .... 2
    elif 1:                    # вместо "else" 2
        ... команды .... 2
    elif 0: pass               # конец блока 2
elif <>
    ... команды .... 1
elif 1:                    # вместо "else" 1
    ... команды .... 1
elif 0: pass               # конец блока 1

if <>                      # начало блока 1
    if <>                      # начало блока 2
        ... команды .... 2
    elif <>
        ... команды .... 2
elif 1:                    # вместо "else" 2
    ... команды .... 2
elif 0: pass               # конец блока 2
elif <>
    ... команды .... 1
elif 1:                    # вместо "else" 1
    ... команды .... 1
elif 0: pass               # конец блока 1
В этом случае легко заметить (в т.ч. автоформаттером), что очередной «elif» после «elif 0: pass», а не начинается с «if»

Не увидел, а что делать в блоками with?

и, пожалуйста, уберите сокращения ПГ и т.п.
Да, от этого катастрофически уменьшается читаемость текста.
Жесть какая-то. Писать дополнительные continue в конце цикла for только потому что разработчики языка сами себе злобные буратины, и теперь ПГ-ту приходится использовать в ПГ-ме костыли.
Просто голосуйте рублем и не пишите на этом убогом языке, благо других языков ПГ-вания хватает.

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

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

Это не проблема языка. Это проблема конкретного кода и конкретных рук, которые пишут так, что без дополнительных подписей не помнят про что же их код. Можно было, например, вынести внутренности в методы с внятным названием.
Трёхэкраный цикл на С/C++/Lua/Java/Rust/итыды тоже будет "непонятен без лишних подписей, что за убогий язык". Особенно если спрятать весь заголовок цикла, как это сделал автор.


Современные IDE отлично подсвечивают конец блока кода.

А не проблема языка, когда семантика кода противоречит его внешнему виду? Я думаю, многие ошибутся, увидев в большом файле код такого вида


...
some_code
if (x==0) 
    cout << "Error";
    some_function(x);
someother_code
...

Это тоже жертва копипасты, но другого типа

> И сложно вспомнить, что значит каждый уровень отступов.

просто не надо в таком стиле писать :) Можно спорить о «Чистом коде» Мартина, но там явно указано: любая функция должна умещаться на одном экране — так мозгу проще охватить и понять что происходит.

Это высказывание во времена 29" 4к мониторов, боюсь, уже не актуально.

Я про другое. Самый ценный ресурс программиста — мозг. Если функция на 294+ строк — мозг ломается. Автор пишет «вспомнить уровень отступов» — это про слом мозга, не про монитор.
Функция/метод должа описывать одну логическую единицу алгоритма, с уровнем вложенности не более 3. Пайтон с его отсупами форсит это правило — если замечаешь что пишешь в правой части экрана — пора уменьшать вложенность.
Ниже правильно сказали, что код автора — скорее сишный, переложенный на пайтон. И автору трудно в пайтоне, язык ему поворачивает голову в правильное направление: парень, ты делаешь что-то не так.
Другое дело — как парень решает проблему… Хорошо что статья вышла, есть шанс понять красоту в простоте.

Только к ширине мониторов, а всё наращивание в первую голову идёт именно в ширину, чай не 4*3 же давно уже. Ну и проблема что проще работать с тем, что охватывается одним взглядом, а если не влезает — то разбито на влезающее по логически шагам/разделам, остаётся вне зависимости от габаритов монитора.


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

В Python программные блоки основаны ТОЛЬКО(!) на отступах. Из-за этого:

уменьшается «читабильность» ПГ (см.ниже),

читаемость только увеличивается

невозможно полноценное автоформатирование исходного текста,

— black вам в помощь

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

— не стоит нажимать случайно кнопочки

Проще поставить нормальную IDE и не… себе голову.

Очень многие советуют поставить хорошую IDE и т.о. решить проблему. Но! Как я и писал в статье, в процессе разработки программы очень часто приходится изменять уровни программных блоков перенося отдельные участки команд на разные другие уровни отступов.

Ни одна IDE не сможет определить правильно или нет ты «захватил» блок отступов при таком перемещении, т.к. только программист знает зачем он это делает, зачем он увеличивает или уменьшает уровни отступов участка программы.

Alt+arrow up отлично справляются с задачей выделения логических блоков во всех IntelliJ ide

Простите, но примеры, в которых Вы показываете как-же-это-плохо, вызывают боль. Это сишный код, перегнанный напрямую в питон. Да ещё и с транслитом в переменных.
Из-за этого и объём кода вырастает, и разбираться в нём сложнее.


Например, возьмем кусок исходного кода:

переписывается в:


def do_work_on_line(tb0, i: int, line: str):
     """ Extract REGP, DAT and NNMT from the line, store to item """
     tek_str = line.rstrip('\n')             #Уберем \n на концах строки
     tek_spisok = tek_str.split('\t')        #Разбивка строк в список

     REGP = tek_spisok[0]
     DATA = tek_spisok[1]
     NNMT = tek_spisok[2]

     tb0.setItem(i, 0, QtWidgets.QTableWidgetItem(REGP))
     tb0.setItem(i, 1, QtWidgets.QTableWidgetItem(DATA))
     tb0.setItem(i, 2, QtWidgets.QTableWidgetItem(NNMT))

# working with file
with open(imya_file,'r',encoding='utf-8') as f:
      for i, line in enumerate(f):
            do_work_on_line(tb0, i, line)

Можно ещё сократить без потери смысла, как объединив rstrip и split


REGP, DATA, NNMT = line.rstrip('\n').split('\t')[:3]

так и собрав назначение полей в подцикл по range(3), либо по списку именованных индексов. Можно разбить на два метода, из которых первый выберет информацию, второй внесёт в поля — так будет ещё лучше.
И вот уже логические конструкции выделены и одноуровневы. И проблема "пробелы мешают" исчезла сама собой.

Даже, пожалуй. много телодвижений. Весь код дожимается до


with open(imya_file,'r',encoding='utf-8') as f:
    for index, line in enumerate(f):
        for i, entry in enumerate(line.rstrip('\n').split('\t')[:3]):
            tb0.setItem(index, i, QtWidgets.QTableWidgetItem(entry))       

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


Зато, заметьте, никаких вопросов из какого блока какая строка.

Для ясности, возьмем крайний случай:
Если в тексте исходников питона убрать все отступы (т.е. ВСЕ строки кода будут с начала строки), какая-н. IDE сможет восстановить работоспособную программу на Python?
Боюсь, что нет.

При оформлении же программы способом, как в статье, программа будет полностью восстановлена.

Если необратимо портить код — то можно необратимо испортить код любого языка. Уберите все фигурные кавычки сложного кода на С++ и расскажите как легко его восстановить.


Предложенный "способ" — это попытка из питона сделать C++ для тех, кто желает писать именно на C++. Зачем заставлять писать на языке тех, кто на нём писать не желает? Кроме неудобства, они ещё и коряво писать будут и неэффективно.


Upd. Я могу понять неудобство с отступами, могу понять тех, кто не пользуется IDE. Но предложенное "решение" не решает ничего.

Вспомнился старинный анекдот: программист-фортранщик на любом языке пишет на фортране.

Ответ: «Только несущественные недостатки. Т.е. по большому счету — нет.»

Такие как GIL и однопоточность.
Но отступы, которые решаются использованием IDE, хоть того же PyCharm Community Edition, важнее, да...

По крайней мере я ни где решения такого полноценного автоформатирования для Python не смог найти.

Как выше уже упомянули — black. Всё больше проектов переходят на него, потихоньку становится де-факто стандартом. И никаких проблем с автоформатированием нет, всё отлично форматируется и без описанных здесь уродств.

Если в тексте исходников питона убрать все отступы (т.е. ВСЕ строки кода будут с начала строки), black восстановит работоспособную программу на Python?
Боюсь, что нет.

При оформлении же программы способом, как в статье, программа будет полностью восстановлена.
А это точно является проблемой? По-моему вы её сами себе придумали.

Вас кто-то заставляет убирать все отступы? Выше уже ответили симметрично:


Уберите все фигурные кавычки сложного кода на С++ и расскажите как легко его восстановить.

Дочитал до ПГ-ния. Кровь из глаз затмила текст, простите.

from __future__ import braces

not a chance :)

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

Публикации

Истории