Библиотеки для STM32 Опции

[juvf]

Где можно подчерпнуть библиотеку для процессора stm32L030?

Раньше библиотеки можно было скачать с сайта st.com
сейчас их там нет. например библиотека stm32f10x standard peripheral library была тут, сейчас там "SORRY, PAGE NOT FOUND". Что то поменялось у ST? Теперь библиотек нет? Или они их в куб убрали?

[Kabdim]

Извиняюсь, если мои посты вызвали ощущение холивара, его там нет.
Мой поинт в том что пользы от унификации для большинства команд и проектов больше чем от кастомизации. Т.е. если взять популярный codestyle можно во-первых не набивать свои шишки на неочевидных вещах, во-вторых читать сторонний код в этом codestyle как свой/вносить правки не перестраивая свой мозг лишний раз. А различных крупных codestyle'ов много, можно выбрать то что ближе.
Крупные проекты очевидно являются исключением, т.к. их крупность позволяет авторам таких проектов создать тонко настроенные инструменты под свои задачи. И при этом затраты на разработку и переучивание программистов будут ниже чем польза.

[Forger]

И при этом затраты на разработку и переучивание программистов будут ниже чем польза.

Затраты на переучивание? Не смешите ))) Если программер не умеет читать чужой код, то его бесполезно переучивать

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

[Kabdim]

Затраты на переучивание? Не смешите ))) Если программер не умеет читать чужой код, то его бесполезно переучивать

Выходит codestyle вообще не нужен?

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

Не понял, вы другими словами повторил то что я сказал, но при этом возразили.

[Forger]

Выходит codestyle вообще не нужен?

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

Код

quitonlastwindowclosed

Не понял, вы другими словами повторил то что я сказал, но при этом возразили.

Повторюсь: "крайне затратно вынуждать опытного программиста писать и отлаживать свой код в стиле чужого кривого кода".
Под словом "кривой" я подразумеваю код, реализованный в "кривом" стиле, который выдуман "с потолка", в стиле "изобретаем велосипед".

[Kabdim]

Нужен, если он создан под максимальное кол-во народу, а не под уникальных мега-ботанов

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

Повторюсь: "крайне затратно вынуждать опытного программиста писать и отлаживать свой код в стиле чужого кривого кода".
Под словом "кривой" я подразумеваю код, реализованный в "кривом" стиле, который выдуман "с потолка", в стиле "изобретаем велосипед".

Чем публичней и распространенней стандарт тем меньше он кривой? И наоборот чем уже сфера пользователей тем он как минимум шероховатый.

[Forger]

Чем публичней и распространенней стандарт тем меньше он кривой? И наоборот чем уже сфера пользователей тем он как минимум шероховатый.

Все так, это - эволюция (извиняюсь за громкое слово).
Кривой стиль и соответственно говно-код не способны эволюционировать нормально.

Но нужно отличать коммерциолизированный стандарт (скажем, гугльстайл) и обычный - "бесплатный", который можно почерпнуть из книжек.
Бесплатный эволюционирует эффективнее, он гибче и потому жизнеспособнее, нежели платный ()

Но это все же пустая дискуссия, все одно каждый останется при своем мнении и при своем стиле

[zltigo]

Но это все же пустая дискуссия, все одно каждый останется при своем мнении и при своем стиле

Ну отчего же "останется". Лично у меня за годы стиль менялся под влияним писанного и читанного. При этом догмы в общем нет. Есть обшие тяготения, например, имена функций все явно больше маленькими буквами без разделителей, если это не группа функций. Переменные напротив все с подчеркиваними, поскольку очень люблю структуры, а для структур разделители явяются естественными. Соответственно и просто переменные смотрятся на таком фоне гармоничнее с подчеркиваниями. Заглавные буквы когда то использовал в именах струкур, но перестал за в общем то ненадобностью. Константы и константные выражения, само собой заглавными. Макросы когда то давно тоже именовал заглавными, но перестал за ненадобностью.
Не терплю органически "венгерского" стиля именования. В остальном в общем всеяден. Только трепертно отношусь к фоматировнию - любой чужой исходник с которым предстоит работать перегоняется для начала в удобный для себя формат.

[Forger]

При этом догмы в общем нет. Есть обшие тяготения, например, имена функций все явно больше маленькими буквами без разделителей, если это не группа функций. Переменные напротив все с подчеркиваними, поскольку очень люблю структуры, а для структур разделители явяются естественными. Соответственно и просто переменные смотрятся на таком фоне гармоничнее с подчеркиваниями. Заглавные буквы когда то использовал в именах струкур, но перестал за в общем то ненадобностью. Константы и константные выражения, само собой заглавными. Макросы когда то давно тоже именовал заглавными, но перестал за ненадобностью.

А я в свое время отказался от такого кол-ва правил и упростил все до минимума, как в книжке Мартина "Чистый код" - не люблю кучу лишних правил, их тогда приходится всегда держать в голове.
А особенно это напрягает при переписывании кода - скажем, структура переросла в класс, глобальная переменная стала локальной, поле класса стало локальной переменной, константа перестала быть таковой и наоборот.
Короче, прошел через это, поплевался и удалил кучу лишних правил. После этого все стало значительно проще.
Читаемость кода не пострадала, а даже наоборот - считаю лишним "кодировать" в названии объекта его принадлежность к определенной "рассе", другие нынче времена
Насчет макросов тут я не буду спорить, скорее всего сам уйду на именование макросов, как обычных методов классов (функций), т. к. любой макрос может стать функцией и наоборот.
А вот замены "магических" чисел сознательно делаю большими буквами, пока что мне кажется, что это улучшает читаемость кода.
Впрочем, время покажет ))) Я тоже "эволюционирую" )))

Не терплю органически "венгерского" стиля именования. В остальном в общем всеяден.

Аналогично! До тошнотиков не выношу, когда в название переменной с какого-то перепугу вносят ее "рассовую" принадлежность
Абсолютно убежден, что оооочень значительно ухудшает читаемость кода - приходится при изменении типа этой переменной ВЕЗДЕ менять ее название - "мартышкин" труд, иначе не назовешь ))

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

Абсолютно солидарен! Чистым кодом пользоваться гораздо приятнее )))

[jcxz]

скажем, структура переросла в класс,

Это как это?
В чём по Вашему отличие между структурой и классом?