Годнота на ржаку. :)

ржака не лучшая вещь, с коей стоило бы иметь дело, но вещь по-своему интересная - под линем для него прям всё есть: чертовски удобный vscode (впрочем, часть публики уютненько сидят в vim - не осуждаю, пч часть сорцев нужно ладить на месте и тамо только консоль). у компиля ржаки много идиотских предупреждений, но благо эта крень легко лечится, влепив в main.rs..

Код (Text):

1. #![allow(non_camel_case_types)]
2. #![allow(non_snake_case)]
3. #![allow(dead_code)]
4. #![allow(unused)]
5. #![allow(unused_variables)]
6. #![allow(non_upper_case_globals)]
7. #![allow(while_true)]

--------
много годных онлайн док, одна эта онлайн книжка вполне может ответить на кучу вопросов
ну, и описание как настроить vim.

 

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

От себя рекомендую ставить в проектах на расте #![warn(clippy::pedantic)], а в си и плюсах /W4 в msvc и -Wpedantic -Wall в gcc и сразу писать с учётом строгих требований.
В будущем это сильно упростит жизнь.

 

HoShiMin, если бы программирование строилось сугубо по стандартам, то ржаки по-определению не было бы а то, о чём ты говоришь - это лишь набор локальных договорённостей в группе разрабов, кои не всегда соблюдаются + формат названий и переменных можно переделывать в (полу)авто-режиме. в конце-концов всем нужен рабочий код

 

Если не включать линтер для стиля - точно не будут соблюдаться и начнётся разброд и шатание.
Когда пишешь один в вакууме - без проблем, можно писать как угодно, но когда пишешь библиотеку в паблик или когда делаешь проект, в котором предполагается участие других людей - нужно соблюдать стандарты, потому что твой код будут читать люди, привыкшие к общепринятому стилю.
Кому-то общепринятый стиль может не нравиться, но это работает, как с законами: "Закон суров, но это закон".
Единственное допустимое исключение - когда ты портируешь код с другого языка, в котором принято другое соглашение: например, для обёрток над WinAPI, в котором функции в UpperCamelCase, а типы в SCREAM_CASE.
Если у языка нет стандартного стиля, как в си с плюсами, команда договаривается о стиле сама, иногда даже настраивают clang-format, и на код-ревью шлёпают линейкой по рукам, если кто-то от него отступает.
Но в большинстве современных языков есть стандартный стиль, который принят или сообществом, или разработчиками самого языка, и нет причин ему не следовать.

 

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

 

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

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

Например, были две функции: SomeFunc и someFunc, пришёл рандомный чел, который этот код видит впервые, и переименовал первую функцию в someFunc, чтобы было по правилам - в итоге проект сломан об колено из-за нарушения ODR.

А на следующий день разработчик приходит на работу, делает git pull, открывает код, который он писал вчера, и ничего не понимает: там ВСЁ не так, всё не в его стиле - это уже не его код: он не знает, как теперь называются его же собственные функции и типы.

Ты уверен, что это так работает?

А ещё немножко про экономическую целесообразность: вместо того, чтобы обязать всех сотрудников писать по соглашению, мы нанимаем дополнительных людей, которые должны рефакторить код других сотрудников.
То есть, на одного-двух разработчиков мы наймём бойца, который будет вникать в кодовую базу и… править за ними имена, скобочки и отступы? Итого у нас штат на ровном месте скакнул в полтора раза.
«Отличный план, надёжный, как швейцарский нож, если я правильно понял.»

 

HoShiMin, Вопрос Тебе сугубо Практический: есть два прогера - один графоманит прям загляденье, но кодес ни черта не работает; другой выдаёт на гора грязненькие тексты, однако, бАлин - ОНО работает == как прикажешь такое разруливать???

 

А ты часто видел такие случаи?
Я вот что-то ни разу такого не встречал. Вообще никогда, хотя сурсов повидал немало.
Зато когда код написан как курица лапой, и при этом ожидаемо работает плохо - сколько угодно.

И в твоём примере нет противоречий: в команде задан стиль, изволь ему следовать.
Человек может встать в позу: «А я не буду!» - что ж, незаменимых людей нет.
Мне приходилось править баги и допиливать плохо написанный, но техничный код. Во всех случаях этот код проще переписать с нуля, чем рефакторить до читабельного состояния.
Если автор уйдёт из компании - ты получишь чёрный ящик, в котором никто не понимает ни строчки.
Это всегда потеря времени - а значит, потеря денег.

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

 

HoShiMin, чистописание оставь для секретарш, а прогер в 1ую чреду должен понимать саму тему и инструментарий этой темы == не понимаешь тему, не поймёшь и сорцы касательно неё; понимаешь - сразу будешь знать, что искать в сорцах и как их лучше читать.

 

Вот я - живой пример, когда знание темы СОВСЕМ не помогает понимать плохой код.

--- Сообщение объединено, 30 дек 2023 ---

Ну и в конце концов, плохой код - это просто неуважение к своим коллегам

 

Вот возьмём тот же линь: строгое следование стилю. Пишешь не как положено - патч в ядро не принимают.
А перед влитием ещё и тщательно рассматривают.
Каким бы ты ни был незаменимым гуру, тебя просто завернут, если ты написал нечитаемую простыню.

 

если эта простыня рабочая, то либо сам потихоньку перепишешь / либо найдётся публика, коя эту работу сделает / либо выкидываешь в в отдельную репу и кому надо, тому надо впрочем, в линь ядре тоже всегда шняшки хватало даже по стандартам

--- Сообщение объединено, 30 дек 2023 ---

кстати, переходим в хип

 

Независимо от её рабочести, её просто не пропустят в ядро, пока она не будет соответствовать соглашениям о стиле.
В компаниях аналогично: доработку просто завернут на ревью и скажут привести код в порядок.

 

https://wasm.in/threads/zabavnye-novosti-0j-ti.32771/page-40#post-440539

 

репост https://wasm.in/threads/otobrazheni...jaemaja-v-dll-pamjat.35010/page-2#post-440814

 

A GPT может "хорошо написанный нерабочий код" писать в неограниченных кол-вах?

 

Он даже плохо написанный нерабочий пишет с трудом

 

В нашем мире киберпанка сам Убивец вполне может сойти за нейронку.

 

вечерние мысли про ЖПТ и мир будушего

 

Понравилось, как он щёлкает пальцами и говорит, что GPT по щелчку генерирует змейку.
Хорошо, змейку по щелчку он генерировать умеет, а когда я спрашиваю Copilot'а что-то, приближенное к реальности, он бодро начинает писать код с несуществующими функциями, выдавая абсолютно синтаксически корректный код, но совершенно бессмысленный.
Видимо, это подразумевалось под тезисом о том, что нейронки пишут код уровня миддла.

Хорошо, пройдёт десять лет и GPT научится действительно придумывать рабочий код, а не воспроизводить по выученному шаблону. А как верифицировать написанное?
Сто строк в змейке мы можем пробежать глазами, а что делать, если мы его попросили написать банковский сервис на пару миллионов строк, и он его действительно написал?
Мы получили чёрный ящик, который неизвестно как тестировать, в котором никто не знает ни строчки, как не знает и логики, по которой GPT его писал.
А давайте попросим GPT объяснить. И он объяснит: а где гарантия, что то, что он ответил, действительно соответствует тому, что он делал пять минут назад?

Ладно, пропускаем - действительно, кого это волнует, клиент же говорит "а пофиг, софт работает, мне больше ничего не надо".
И вот софт работал и внезапно сломался. Мы говорим: "GPT, а твой код падает" (а мы даже не знаем, где и почему) - здесь блогер снова щёлкает пальцами и предлагает сгенерировать новый вариант с учётом правок.
А нам не надо новый вариант, нам надо исправить один конкретный баг. Надо снова убедиться, что его правки не затронули весь остальной функционал (тесты, видимо, тоже предлагается писать с помощью GPT).

Дальше он говорит, что ИИ уже подвинул творческие специальности.
Художников? Да, он может нарисовать миллион вариантов одной картинки, но художественная ценность таких работ нулевая (и мы ещё не говорим про хтонь с пальцами, но её пофиксят).
Актёров озвучки? Ну, разве как говорилку. Интонации и тембр у каждого человека уникальны, людей не заменить и здесь - банки голосов надо у кого-то брать.
Музыкантов? На ютубе полно треков, сгенеренных нейросетями, только их что-то никто не слушает.

Зато GPT неплохо справляется с рутинной работой.
Тот же Copilot неплохо угадывает, когда надо сделать что-то по шаблону, что-то переименовать или создать какие-то последовательности. Как чуть более умное дополнение для интеллисенса, не более.
Для художников - как инструмент для генерации заготовок или аналог фотостоков.
В озвучке - например, когда надо "воскресить" чей-то голос или озвучить малобюджетный проект (например, как недавнюю мемную игру про Русов против Ящеров).
Всё это просто инструменты, наравне со всем уже имеющимся у людей инструментарием, но не самостоятельные творцы.

--- Сообщение объединено, 16 янв 2024 ---

Ну и немного рандомного бреда. Вот что будет, если попросить Copilot'а сделать деревянную вешалку с металлическим крючком: