А шо сам чатгпт говорит о нормальности AS?

Использование ключевого слова AS для псевдонимов таблиц и столбцов в SQL запросах является общей практикой и абсолютно нормальным. Псевдонимы делают SQL-запросы более читаемыми и понятными, и они полезны, когда в запросе используются длинные или сложные имена таблиц и столбцов.

ну вот

Использование лишних ключевых слов as выдаёт новичка, который не привык работать с очень большой кодовой базой на sql и pl/pgsql или запросы, сформированные всякими тулзами. AS обычно опускается (как и INNER), чтобы при чтении запросов глаза меньше цеплялись за них. При этом само по себе использование псевдонимов является обязательным в коде (который требуется поддерживать) там где нужно явно ссылаться на таблицу или где имя столбца не определено явно (по имени выводимой колонки или в заголовке cte). На правах личного мнения. Скорее всего, есть проекты, в которых принято писать более многословно (особенно если пишет команда для которой база - только хранилище), но мне их не понять

Стикер

"И всё таки она существует". Читаемость кода. Обзывать её чисто маркетингом, наверное, черезчур. Иногда такой спагетти код люди выдают, что без поллитры не разберёшься. Лично я тоже аккуратно расставляю AS и чего тут может выдавать новичка - не ясно. Но с какого-то момента разговоры о "правильном" оформлении кода действительно превращаются в халивар. Мне даже удобно, когда у коллег какой-то другой стиль, сразу узнаёшь почерк, не глядя в историю. Как у радистов 😁

> "И всё таки она существует". Читаемость кода. Неужели? А доказательства этого утверждения у Вас есть? ;) Кроме шуток, проблема в том, что даже у исследователей в области software engineering даже её приемлемого определения нет (а не то что каких-то средств её измерения). Есть даже исследования, демонстрирующие, что "students learn to rate code against what they had been told were community norms of a quantity called readability". Какое отношение это "quantity" имеет к чему-то реальному и полезному, науке на данный момент неизвестно (да, я серьёзно!). > Но с какого-то момента разговоры о "правильном" оформлении кода действительно превращаются в халивар. Такие разговоры из него и состоят почти целиком, IMNSHO. ;) > Мне даже удобно, когда у коллег какой-то другой стиль, А мне нравится, когда у кода в проекте одинаковый стиль...

Правила оформления кода в каждом проекте нужны, в первую очередь, для ускорения командной работы. Тупо быстрее читать код, который оформлен одинаково. Всё остальное второстепенно, хотя профессиональные разработчики стараются придерживаться единого стиля в пределах проекта тупо чтобы потом не было за этот код стыдно. Сейчас в большинстве широко распространённых языков уже форматирование выполняется автоматическими средствами (IDE, либо входит в утилиту сборки). Для SQL с этим проблема: я не видел отдельной утилиты, которая бы полностью корректно (читабельно) форматировала очень длинные запросы, не срываясь в заполнение строчки до максимальной заданной ширины. Что касается процитированного отрывка текста - я с ним не совсем согласен. Есть объективные когнитивные ограничения (например, число объектов, которые человек способен быстро воспринять на одном уровне), а также ограничение средств отображения (например - размер экрана) и если их не учитывать, человеку становится достаточно сложно читать код. При чем если размер экрана меняется со временем (поэтому сейчас правила, запрещающие использовать более 80 символов в строке (где-то попадалась даже меньшая цифра) сейчас выглядят архаично), но вот когнитивные ограничения - практически нет, и если конкретный человек может натренироваться на восприятие большего куска информации за раз, нельзя ожидать того же самого от команды. Спор "писать AS/INNER или не писать" действительно не имеет смысла, но вот наличие правил в рамках одного проекта (не важно каких конкретно) - важны. В первую очередь из-за вышеописанного (чтобы кто-то не начал писать нечитаемые однострочники), но и чтобы за работу не было стыдно. Можете считать это профессиональным обычаем.

Для опознания кода коллег уже давно существует команда blame/annotate в системах контроля версий. Понятно, что какие-то элементы "почерка" остаются (не всё возможно регламентировать правилами оформления). Но когда команда большая или когда из других проектов периодически кто-то шлёт пулл-реквесты, то на этот "почерк" не обращаешь внимание

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

По мне - глупо для маркетинга хвастаться читаемостью внутреннего кода, если клиенты всё равно его не видят (если на проду идёт уже готовый продукт (сервис/программа)). Так же как и с рекламой сигарет. Читаемость кода только упрощает работу с ним, больше всего командную и расширяемую.

Да при чём тут хвастаться... Понимать бы его. И побыстрее. И правильно. Вот и все нехитрые требования. Это навык минимальной культуры программирования. Как навык гигиены. Работать бок о бок с неряхой или получать от коллеги код, в котором 10 соединений таблиц в одну строку... И то и то не смертельно же?

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

Искренне завидую, что Вам удалось. У нас коллектив поболе двух. Есть, конечно правила кодировпния в части именования, обработки ошибок, работы с транзакциями и всякое такое. Но договориться за стиль - не вышло. Начались те самые халивары и было бы из-за чего.

Ну чисто технически, на SQL и хранилищах вообще у нас четыре человека. Но все в этом чате видели мой уровень... И так, между прочим, мой уровень хотя бы позволяет правильно промты составлять. Так что скорее они просто поняли, что проще будет с меня считывать, чем спорить.

Возможно вы на скользком пути к авторитаризму. Будьте бдительны.

*убедительны

> Тупо быстрее читать код, который оформлен одинаково. Мне тоже так кажется. > Всё остальное второстепенно Мой посыл был в том, что нам это просто неизвестно (но т.к. "программисты должны быть смелыми", (не)знание ничтоже сумняшеся заменяется на набор догматов, с "обоснованиями" вроде "так лучше потому что мы так сказали", "иначе пишут только новички", "чтобы потом не было за этот код стыдно", и т.д. и т.п.). ;) > уже форматирование выполняется автоматическими средствами Только вот разных вариантов форматирования вагон почти в каждом из них (что намекает нам на что-то, нет?). > Для SQL с этим проблема Кстати, да. Может, уже и есть что-то, но я давно не смотрел. > я с ним не совсем согласен Этот отрывок — грубо говоря, резюме всех "замечательных" исследований в этой области от её основания и до 2021 года, вот в чём беда. :( > Есть объективные когнитивные ограничения Безусловно, они есть. Но каковы они конкретно и какая у них вариабельность — совсем другой вопрос. > (например, число объектов, которые человек способен быстро воспринять на одном уровне) Какой человек? И да, именно это ограничение точно как-то связано с "читаемостью"? ;) > но вот когнитивные ограничения - практически нет Как хорошо, что все мы — копии друг друга, и программистом может стать любой идиот человек, правда? ;) Кроме шуток, у нас тут какая-то субпопуляция, и вполне возможно, что в ней значения [неведомых, но] существенных для профессиональной деятельности показателей/ограничений существенно отличаются от общечеловеческих. > нельзя ожидать того же самого от команды. Может, если, например... хирург не может научиться держать в руках скальпель, в "команде" ему не место? Ну, как вариант? ;) > Спор "писать AS/INNER или не писать" действительно не имеет смысла Да кто его знает, опять-таки... ;) > Можете считать это профессиональным обычаем. Вот в том-то и дело, что всё это — не более чем обычай (и программисты через 100 лет, вполне возможно, будут хохотать над этими нашими суевериями и заявлять что-то вроде "Как можно было быть настолько тупыми, чтобы верить во всю эту чушь?!"). Что более печально — примерно таким вот образом, например (раз уж меня понесло в эту сторону выше), профессионалы в области медицины (у них тоже были "обычаи" и "правдоподобные резоны") свели в могилу за предыдущие 3 века несколько миллионов людей (и да, вот это — как раз оценки современных исследователей).

Приходилось (более того, я так часто поступаю именно с SQL-запросами — ну невыносимо же читать неправильно оформленный код, а правильно почему-то оформляю один только я ;) ). > используя Ваши же аргументы Это не мои аргументы. ;) Конкретно, "понятие о читаемости кода сильно индивидуально" <> "это чистый маркетинг".

Никто не говорил, что "маркетинг" чем-то таким хвастается. Посыл был в том, что само понятие "читаемость кода" на сейчас мало отличается от "маркетинга".