ржака не лучшая вещь, с коей стоило бы иметь дело, но вещь по-своему интересная - под линем для него прям всё есть: чертовски удобный vscode (впрочем, часть публики уютненько сидят в vim - не осуждаю, пч часть сорцев нужно ладить на месте и тамо только консоль). у компиля ржаки много идиотских предупреждений, но благо эта крень легко лечится, влепив в main.rs.. Код (Text): #![allow(non_camel_case_types)] #![allow(non_snake_case)] #![allow(dead_code)] #![allow(unused)] #![allow(unused_variables)] #![allow(non_upper_case_globals)] #![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 --- кстати, переходим в хип
Независимо от её рабочести, её просто не пропустят в ядро, пока она не будет соответствовать соглашениям о стиле. В компаниях аналогично: доработку просто завернут на ревью и скажут привести код в порядок.