Пара слов об именовании переменных и методов

[OZR]

person.has_publications()
True

Мне почему-то не нравится этот вариант. Хочется видеть person.isHasPublication(). Я не нэйтив инглиш. Но почему-то ожидаю получить true именно в варианте is has… А в варианте has словно утверждение. Да, публикации есть.

Может кто встречал какую-либо базовую грамматику английского для программистов как раз на подобные связки, для написания грамотного кода? А то я же как-то пишу… Не хочется, чтобы меня потом материли только потому что я не native, а кривое подобие google транcлейт, которое всё понимает, но разговаривает на уровне собаки :)

[sunnyfox]

is has — это кровавые слезы из глаз, два глагола подряд. has_publications — нормально, утверждение "имеет публикации" может быть как истиной, так и ложью, если вернет True — значит имеет, если False — значит нет. Глагол is применим к определениям, например, post.is_published().
Базовая грамматика — она базовая не только для прораммистов, а для всех, могу посоветовать просто пройти базовый курс на любом из ресурсов по обучению английскому :)

[vgbege]

present perfect continuous в пассивном залоге — вот это кровавые слезы. четыре глагола подряд! :)

[sunnyfox]

Ну так-то да, мое утверждение насчет глаголов подряд требует уточнения :) Какие и когда можно в цепочку строить, а какие нельзя.

[erdbeeranke]

I haven't been noticing four verbs in a row here

[vgbege]

so they haven't been being noticed?

[erdbeeranke]

no way that noticed could be something else than an adjective here

[vgbege]

cmon! past participle is still a form of a verb, not an adjective.

[erdbeeranke]

but yeah but no but yeah but no

[vgbege]

I know, right? *wink*

[DorianPeregrim]

Использовать is с глаголом в прошедшей форме тоже не самый лучший выбор, хоть и интуитивно понятнее. Но все же. is_active(), is_empty(), но published().

[sunnyfox]

Это не глагол в прошедшей форме, это страдательное причастие Participle II ^_^ Можно расценивать слово published как свойство, прилагательное, определение, так же как active или empty.

[DorianPeregrim]

И правда, бес попутал, спасибо за поправку. :)

[vgbege]

так это и есть базовая грамматика, conditional sentences.
if the cup is empty, refill it.
if the person has publications, show them on the screen.

проверки на действия, происходящие прямо сейчас — present continuous.
if the car is moving, keep eyes open.

ну и так далее, просто нагуглите подходящую статью по conditional sentences.

[wretwe]

Спасибо за статью! Немного дополню вашу, в большинстве случаев справедливую, критику линтерами Python, которые помогут избежать сего:

Привязка названия переменной к типу, хранящихся в ней данных — это чаще всего плохая идея, особенно, когда вы работаете с динамическими языками

mypy

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

vulture

Для оформления докстрингов используйте pydocstyle

[sebres]

Не r, не res, не resp и уж точно не req, а именно response. res, r, resp (про req и вовсе молчу) — это все переменные, содержание которых можно понять, только взглянув на их объявление, а зачем прыгать к объявлению, когда можно изначально дать подходящее название?

1. Если для понимания что скрывается под res, r, resp (или даже req) нужно прыгать к объявлению, то скорее всего там совершенно другие проблемы (ну например слишком длинная функция или метод, или код "обфусцирован" по самое не хочу).
2. В py-2.x dict.keys() возвращает list, а в 3.x — dict_keys, что теперь делать — срочно переименовать все переменные? А 4.x придет?
3. Ну то вообще такое в duck typing языке, например тот метод класса сможет работать с входящим MySmartDict, возвращающим для keys() шибко мудреный мутирующий итератор ShibkoMudreniyMutableIterator… Назовем её — shmmi?
4. Last but not least — самая главная ошибка в таком наименовании — если вообще нужна смысловая нагрузка, то берите ее из бизнес-логики а не из языковой модели, т.к. иначе:
   
   • оно либо избыточно (в смысле знания о том чем является переменная в логике языка как программистской сущности)
   • либо неверно, ибо завтра туда передадут что-нибудь другое (всё меняется);
   • ну и недостаточно одновременно (ибо не несет в себе знания бизнес логики приложения).

Как правило программист читает код (в смысле языковых конструкций) на ура, но если при этом ни черта не понимает кто тут с кем и кого ест, то оно отсюда как раз, т. е. по причине что переменные "не говорят" про бизнес логику, а повторяют типизацию или всем известные сущности.
Т.е. объяснять программисту что Reqest возвращает response (или request находу мутирующий в response), вместо например чего мы вообще туда лезем, или что оттуда берем, совершенно излишне. Кроме того, совсем не поможет разобраться в (бизнес) логике программы.

const errorCode = errorText.substr(5)
А еще лучше прибегнуть к более декларативному подходу и избавиться от комментария вообще:
const errorCode = errorText.replace('net::', '')

Ну да, исправляли коммент, и переписали код… А ничего что оно не совсем то:

 errorText='how::it-works-if net::is not at begin?';
-errorText.substr(5)               ==> "it-works-if net::is not at begin?"
+errorText.replace('net::', '')    ==> "how::it-works-if is not at begin?"

[likid_ri]

Об этом я предупредил сразу:

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

Ну и последний пример описывает конкретный кейс, где ошибка приходит в конкретном формате. Для каждого отдельного кейса нужно писать наиболее подходящее решение.