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

ржака не лучшая вещь, с коей стоило бы иметь дело, но вещь по-своему интересная - под линем для него прям всё есть: чертовски удобный 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 ---

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

 

HoShiMin, любой код можно обозвать дерьмом и подвести крепкую базу для обоснования такой точки зрения, но житуХА далека от сказок. Вот возьмём тот же линь - тут список недавних контрибьютеров..

https://www.linaro.org/blog/linaro-...ost-active-linux-kernel-contributors-in-2022/
это к вопросу о заменимости

 

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

 

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

--- Сообщение объединено, 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 может "хорошо написанный нерабочий код" писать в неограниченных кол-вах?

 

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

 

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

 

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