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

[juvf]

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

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

[arhiv6]

SPL тут лежит. Но STM вместо SPL теперь HAL продвигает. Где его скачать отдельно - не знаю, но он есть в составе CUBE (+ pdf с документацией). + для этой серии МК есть сниппеты кода.

Сообщение отредактировал arhiv6 - Mar 3 2017, 03:28

[Эдди]

Нет их. Пользуйтесь сниппетами. Я сам отказался уже для F0-серии от глюкавого opencm3 и пользуюсь только регистрами.
Вообще не вижу смысла на таких дохлых МК еще и калокубом пользоваться... Любителям калокуба нужно что-то жирное, с мегабайтом флеша и как минимум 96МГц.

[juvf]

SPL тут лежит.

Спасибо. Но это для stm32F0**. А для stm32L0**?

Я сам отказался уже для F0-серии от глюкавого opencm3 и пользуюсь только регистрами.

можно и регистрами напрямую... но нужен как минимум stm32l03***.h, ну и стартап не помешает.

[MoskWin32]

А для stm32L0**?

STM32CubeL0 gathers together, in a single package, all the generic embedded software
components required to develop an application on STM32L0 microcontrollers.

http://www.st.com/content/st_com/en/produc...tm32cubel0.html
В самом низу на странице ссылка на библиотеку

[arhiv6]

Спасибо. Но это для stm32F0**. А для stm32L0**?

Ой, просмотрел. Для L0 есть HAL, есть сниппеты. А вот SPL для них на глаза ни разу не попадался.

[demiurg_spb]

Я сам отказался уже для F0-серии от глюкавого opencm3

Чем не угодил libopencm3?
И почему бы не пофиксить багу и отправить патч?

[PheeL]

Кстати, просветите насчёт сниппетов, пожалуйста. Насколько я понял ST отказалась и от них тоже, заменив на HAL Low Level Drivers. Это макро-обёртки над регистрами периферии которыми пользуется верхний уровень самого HAL, но если для каких-то драйверов он избыточен и не применяется, то позволяется напрямую пользоваться этими макросами. Причём, поскольку это тоже относительно новое веяние, то например для F4 серии их я не заметил, хотя в HAL для других линеек они присутствуют.

Сообщение отредактировал PheeL - Mar 3 2017, 13:54

[jcxz]

можно и регистрами напрямую... но нужен как минимум stm32l03***.h, ну и стартап не помешает.

Самостоятельное написание stm32l03***.h с описаниями регистров периферии занимает времени меньше чем Вы тут потратили на написание постов и поиски "библиотек".

[Utyff]

можно и регистрами напрямую... но нужен как минимум stm32l03***.h, ну и стартап не помешает.

Снипеты это и есть небоходимые sytem* и startup* файлы с макросами. И примеры/шаблоны их применения.
Похоже ST отказалась от SPL для L0 и F0 серий и сделала снипеты.
http://www.st.com/en/embedded-software/stm...roductId=LN1898

Сообщение отредактировал Utyff - Mar 3 2017, 15:22

[scifi]

Снипеты это и есть небоходимые sytem* и startup* файлы с макросами.

Интересно, чем так страшен стартап? Вот, к примеру, мой:

CODE

#include "stm32f0xx.h"
#include <string.h>

extern char __etext, __data_start__, __data_end__, __bss_start__, __bss_end__;
extern int main();

static void
trap(void)
{
for (;;) ;
}

static void (*vectab[])(void) __attribute((used, section(".vectab"))) =
{
trap, // NMI
trap, // HardFault
// [UART_IRQN + 16 - 2] = uart_handler,
// [TIM2_IRQn + 16 - 2] = tim2_handler,
};

void __attribute((used, noreturn))
Reset_Handler(void)
{
// copy-init variables
memcpy(&__data_start__, &__etext, &__data_end__ - &__data_start__);
// zero-init variables
memset(&__bss_start__, 0, &__bss_end__ - &__bss_start__);

(void)main();
for (;;) ;
}

[Эдди]

Чем не угодил libopencm3?

Когда после очередного обновления у меня ничего не собралось из-за того, что разрабы охрененно порезали API, мое терпение лопнуло!
Я решил, что только nolib может спасти ситуацию. А наиболее употребимые штуки можно в макросы или static inline запихнуть.

Заголовочные файлы я взял в тех же сниппетах (можно из SPL их выдрать, или же из opencm3 — это уже на любителя).
Стартап в виде ассемблерного файла мне показался диким бредом, и я взял стартап у opencm3.

Ну и все, можно у меня на гитхабе глянуть, что получилось.

[scifi]

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

Для тех, кто в танке, они честно признаются заранее: "The API of the library is NOT yet considered stable! Please do not rely on it, yet! Changes to function names, macro names etc. can happen at any time without prior notice!"
Или вы любите ходить по граблям из любви к искусству?

[Эдди]

Ну, я раньше на это не обратил внимания.
Иначе, если бы сразу перешел на регистры, а не метался между всякой дрянью (сначала даже SPL пробовал, но буквально на одном проекте понял, что то говно), намного меньше времени бы потерял!

[juvf]

Самостоятельное написание stm32l03***.h с описаниями регистров периферии занимает времени меньше чем Вы тут потратили на написание постов и поиски "библиотек".

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

[Genadi Zawidowsk...]

страшен стартап? Вот, к примеру, мой

стек забыли

[scifi]

стек забыли

Код

SECTIONS
{
    .text :
    {
        __vtab_start__ = .;
        LONG(__StackTop)
        LONG(Reset_Handler | 1)
        KEEP(*(.vectab))
        *(.text*)

[Genadi Zawidowsk...]

"огласите весь список, ппожалуйста!" ©
Похожий шок я испытал, когда разбирался с тексасовским проектом, где адреса периферии назначались в линк-скрипте (а каждое устройство жило в своей секции). Это же надо так запутать...

[dxp]

Интересно, чем так страшен стартап?

+1.

Вот, к примеру, мой:
<...>

Или вот.

[Эдди]

Или вот.

Спасибо за ссылочку! Форкнул на всякий случай.

[jcxz]

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

А что в этом неправильного? Это основная задача линкера - распределять адресное пространство.
Точно так же можно в icf-файле IAR определить адресные пространства периферии.

[zltigo]

А что в этом неправильного? Это основная задача линкера - распределять адресное пространство.
Точно так же можно в icf-файле IAR определить адресные пространства периферии.

Неправильно, что то, что можно и НУЖНО делать преносимыми средствами языка, делается непереносимыми средствами инструмента. Появляется нахренненужная привязка и инструменту. Точнее, конечно, "нужная", но только тексасу пытающемуся таким образом подсадить недалеких потребителей и на свои инструменты, и свои контролеры. Такая же фигня в общем и у IAR - хидеры ваяют со своими "расширениями" с той же целью.

[pitt]

Неправильно, что то, что можно и НУЖНО делать преносимыми средствами языка, делается непереносимыми средствами инструмента. Появляется нахренненужная привязка и инструменту. Точнее, конечно, "нужная", но только тексасу пытающемуся таким образом подсадить недалеких потребителей и на свои инструменты, и свои контролеры. Такая же фигня в общем и у IAR - хидеры ваяют со своими "расширениями" с той же целью.

Agreed 100%

[SSerge]

Agreed 100%

Так-то оно так, да вот беда - в С не предусмотрено стандартных средств для назначения объектам реальных адресов.
Впрочем для процессоров где периферия отображается в общее с памятью адресное пространство (типа ARM или MSP430) эти средства не особо нужны, можно обойтись указателями на регистры периферии.

[Шаманъ]

Что-то я не понял про привязку. У меня таблица векторов выглядит так:

Код

__attribute__ ((section(".isr_vectors"))) void (* const __vectors[])(void) =
{      
    &_estack,           /* The initial stack pointer */
    Reset_Handler,              /* Reset Handler */
    NMI_Handler,                /* NMI Handler */
    HardFault_Handler,          /* Hard Fault Handler */
   .........................

В скрипте линкера прописывается куда положить какую секцию и собственно все.

[Genadi Zawidowsk...]

А есть люди, кто этот массив частично описывают в программе, частично собирают в скрипте линкера. Вот я глядя в исходник и ошибся, считая сто там ошибка (неполная таблица).

[jcxz]

Что-то я не понял про привязку. У меня таблица векторов выглядит так:
В скрипте линкера прописывается куда положить какую секцию и собственно все.

Разговор был про назначение адресов памяти регистрам периферии.
Кто-то делает это в си-шных хидерах, кто-то - через линкер. Принципиальной разницы нет. Имхо.

А есть люди, кто этот массив частично описывают в программе, частично собирают в скрипте линкера. Вот я глядя в исходник и ошибся, считая сто там ошибка (неполная таблица).

Скорее такие люди просто надёргали кусков отовсюду, не разбираясь и не понимая.

[Шаманъ]

Скорее такие люди просто надёргали кусков отовсюду, не разбираясь и не понимая.

Ну зачем же так сразу - некоторый смысл может быть если применяется загрузчик.

[jcxz]

Ну зачем же так сразу - некоторый смысл может быть если применяется загрузчик.

И какой смысл? И при чём тут загрузчик?

[Шаманъ]

И какой смысл? И при чём тут загрузчик?

Ну проявите фантазию

[yanvasiij]

Для этого же проца не нашел в свое время SPL. Пришлось сделать HAL. Немного не привычно, но не страшно, разобраться можно.

[Эдди]

не нашел в свое время SPL. Пришлось сделать HAL.

Ничего себе, это ж просто деление на нуль!
Ладно еще, когда народ по своей абдуринской привычке эти монструозные библиотеки на F4 или F7 пихает, но на F0 это просто жесть!
Неужто сложно прочесть тоненький RM?

[yanvasiij]

Это избитая холиварная тема, спорить на которую можно долго и нудно, самое главное бесполезно. Вы не обессудьте, что я выскажусь и на этом закончу, не вступая далее в полемику.
Смысл такой: что spl, что hal, что opencm3 дают очевидные, на мой взгляд, преимущества:
1) не нужно тратить время на написание драйверов с нуля, при том что когда пишешь драйвера с нуля точно также допускаешь ошибки (выше по теме Вы можете это наблюдать). От чтения RM это конечно не освобождает, без этого никак. Там есть ошибки - не страшно, они отлавливаются на раз-два, было бы терпение и потом многократно используются.
2) hal, opencm3, и даже spl в отличии от самописных библиотек поддерживаются разработчиками и сообществом. Они развиваются и их функционал расширяется, ошибки внутри устраняются. Самописную же либу, поддерживает только один разработчик.
3) Тот же hal тянет за собой массу дополнительных библиотек (стек tcp, файловую систему, стек usb и прочее). Вы скажете, что это можно поднять самому скачав отдельно? Но зачем делать работу второй раз и тратить на нее время? Не проще ли разобраться в том, что уже сделано?
4) Переносимость между сериями и проектами. Код написанный другим разработчиками под hal, spl, opencm3, легко перенести к себе другому разработчику, который тоже использует hal, spl, opencm3. Это какая-никакая унификация. А если каждый будет колхозить свои библиотеки, тот как обмениваться наработками? Можно но уже сложнее, ибо низкоуровневые вещи нужно переписывать.

А разговоры про избыточность, мне кажется надуманными.
Покажите мне сравнительные тесты, в которых наглядно показывается что по вине hal программа начинает работать в разы медленнее. В моей практике такого не было.
Большее потребление памяти? Сколько раз в жизни у вас было такое, что на cortex процах у вас кончалась память? Если такое и было, то держу пари это точно происходило не по вине hal.
Код громоздкий и непонятный? Это уже чистой воды субъективизм, найдется приличное количество народу, кто не согласится с этим. В добавок ко всему hal достаточно гибкий совсем не обязательно использовать все его конструкции.

Ну вот вообщем такое мое мнение. Извините за оффтоп.

[juvf]

Смысл такой: что spl, что hal, что opencm3 дают очевидные, на мой взгляд, преимущества:

+1. ППКС

но на F0 это просто жесть!

А мне бы SPL для L0

[Эдди]

Когда я заводил 1-wire через таймер с ПДП, был первый раз, когда я столкнулся с невозможностью реализации задуманного по вине библиотеки. Opencm3 оказалась слишком медленной.
Во всех перечисленных библиотеках очень жирный код. Поражающая избыточность приводит к 1) тормозам, 2) увеличению объема прошивки. Оба этих момента в определенный момент могут подставить подлянку.

На мой взгляд единственным правильным вариантом будет нарабатывать сниппеты. А "обмениваться" быдлокодом смысла не вижу. Самый страшный пример — абдурина. Я тут намедни писал обработчик, работающий с термодатчиком TSYS01. Скачал код для абдурины — думал, шустрей будет. А там такое... Какой-то идиот мало того, что флоаты воткнул, так еще и температуру вычислял по формуле из даташита!!!
Я от такого идиотизма вообще в шоке.

Под STM32 тоже полно кода в интернетах можно найти. Мне к девборде заботливые китайцы диск приложили с уймой проектов под калокубы. Я даже пытался было для работы с экранчиком взять готовое, но почитав этот жесточайший быдлокод понял, что так делать ни в коем случае нельзя!
Вот каким надо быть чудаком на букву "М", чтобы использовать ногодрыг на проце, имеющем нужную периферию и DMA?

И да, т.к. сами авторы опенцм3 говорят, что библиотека еще в стадии тестирования, лучше ею не пользоваться. После того, как они поменяли API, я решил от этой дряни отказаться. Пока ваяю под STM32F0, и очень даже хорошо все идет. Надо будет только USB откуда-нибудь выдрать (из той же opencm3, например), т.к. хочу посредника между USB и CAN на STM32F042 замутить. Да и просто на F103 я привык с CDC работать вместо подключения лишнего переходника на USART.

Сообщение отредактировал Эдди - Mar 11 2017, 13:13

[Baser]

... Пока ваяю под STM32F0, и очень даже хорошо все идет. Надо будет только USB откуда-нибудь выдрать (из той же opencm3, например), т.к. хочу посредника между USB и CAN на STM32F042 замутить. ...

Я когда перетаскивал проект с Меги128 на STM32F072 и нужно было в духе времени по-быстрому USB подцепить вдогонку к RS-232.
Так сгенерировал проект на HALе, и первое время, когда с ним разбирался, тоже диву давался тому, как там все понаписано.
Но идеология понятна: разработчики хотели добиться переносимости между ВСЕМИ stm32. Поэтому и эта жуткая многослойность различных макросов друг на друге, когда более сложные низкоуровневые постепенно, в несколько этапов, заменяются на применимые к конкретному процессору. И разделение процедур на несколько уровней для разграничения области видимости переменных и функций - тоже прозрачности не прибавляет. Разбираться в этом - пипец полный, но ведь работает

Но глядя на то, сколько у меня суммарно ушло времени на то, чтобы с нуля начал работать проект с USB и прочей периферией, у меня никакого желания нет погружаться сильно в глубь и переписывать библиотеки. Тем более, что периферия у STM32 не такая и простая, как у предыдущих простеньких ПИКов, АВРок и т.д. Частенько разбираешься с HAL (я обычно верхний уровень, а часто и пониже, правлю, выкидывая уж слишком сложные навороты) и видишь манипуляции с флагами периферии, про которые сразу догадаться, что так нужно делать, при чтении документации невозможно.

Так что можно "все взять под свой контроль" - но с годами лучше начинаешь понимать, что это мало где нужно. Время уплотняется, все нужно быстрее, быстрее. Сидишь так, вылизываешь код, а год-два проходит (а часто и меньше) - и никому это уже не нужно - давай гони что-то новое.
Как то так...

[jcxz]

Тем более, что периферия у STM32 не такая и простая, как у предыдущих простеньких ПИКов, АВРок и т.д.

Из всех прочих ARM, с которыми я имел дело, у STM32 самая простая периферия.
А имел дело я и с NXP (LPC17xx и LPC43xx) и TI (Tiva, Concerto, OMAP) и Infineon.
Видна цель производителя: сделать наиболее простую периферию для снижения порога входа для новичков, пускай даже в ущерб функциональности.
Осваивать периферию STM32 не в пример легче, хотя бы потому что приходится читать описания на гораздо меньшее число регистров периферии чем в других МК.
Сужу по собственному опыту.
Например: в том же USART у STM32F4x всего 7 регистров, в то время как у Infineon например - около полусотни в его USIC. И это не считая связанных регистров.

[Эдди]

Вот если бы STMщики вместо идиотизма с SPL/калокубом сразу написали побольше сниппетов под все серии своих МК, было бы намного лучше!
Ладно, под STM8 не надо — там даташит тоненький и регистров немного, но вот некоторые вещи у STM32 требуют реально много времени. Скажем, с тактированием I2C я часа на три завис, пока разобрался, что к чему. Непонятно, зачем вообще на простецкий и2це столько регистров. Ведь 99.9% устройств никакого "тюнинга" не требуют. Можно было по тактированию один-единственный регистр с предделителем тактовой частоты завести.

[jcxz]

Непонятно, зачем вообще на простецкий и2це столько регистров.

Жалких 10 регистров - это много?????
В LPC17 их 16, в Tiva - 27, в Infineon - полсотни. STM32 - самый простой из всех.
Если самый простейший МК Вам сложен, то что будете делать на более серьёзном?

[Alechek]

Но идеология понятна: разработчики хотели добиться переносимости между ВСЕМИ stm32.

Вот только переносимости ЧЕГО - они, видать, так и не придумали....
"HelloWorld" переносить? Потому как при переносе чего существенного все равно возникают проблемы: то тактирование не то, то DMA не совместимы, и вообще, оказывается, одинаковая периферия на самом деле то разная, возможности не те...
Поэтому в любом случае, придется немного дорабатывать. И коим образом тут поможет кубохал?

[juvf]

наброс говна на вентилятор продолжаем разговор.... ну не нравиться хал где-то в узких местах.... хотя я бы не сказал, что HAL_GPIO_WritePin() прям уж такая тяжелая... в критичных местах можно использовать от туда же LL_GPIO_WriteOutputPort() из набра Low Layer (LL) drivers. LL - это тоже зло от st?

[Эдди]

Для set/clear/toggle функции не нужны, делается это элементарно на макросах!

[Alechek]

LL - это тоже зло от st?

Все в жизни относительно. Для ST - SPL\HAL\LL - это очень большое добро. Привязывает пользователей к продукции ST.
Для остальных - кому как. Если нравится кому быть привязаным к одному производителю - пожалуйста.

У меня свой лунапарк в части интерфейса к GPIO и основой периферии (SPI, I2C, UART). Поэтому не не составляет труда переносить код между используемыми камнями.
Если использовать HAL - то это будет просто лишней прослойкой, которая в конкретном случае ни от чего не спасет.

[jcxz]

У меня свой лунапарк в части интерфейса к GPIO и основой периферии (SPI, I2C, UART). Поэтому не не составляет труда переносить код между используемыми камнями.

Во-во - у меня тоже. С (насколько возможно) одинаковым интерфейсом для разных МК

[Velund]

Во-во - у меня тоже. С (насколько возможно) одинаковым интерфейсом для разных МК

И я тоже со времен ARM7 держу единый "стандарт" вызовов для основой периферии (SPI, USART, I2C и т.д.) на которые "верхом" встают драйвера периферии (EEPROM, ADC/DAC, цифровые потенциометры, синтезаторы частоты и прочие мелочи). Под куб написал "обертку", которая приводит форматы вызовов к привычному мне. "Подрываться" и переписывать свои отлаженные и обкатанные на тысячах серийных изделий наработки под каждый "взбрык" индусов, нанятых писать кубы и подобное им - много чести будет.

[Genadi Zawidowsk...]

Оооо! Я тоже на таком же велосипеде езжу!
Этажом ниже ATMega, ATXMega (кроме USB), Renesas RZ/A1L, AT91SAM9S, ATSAM3/4S, STM32Fxxxx

Код

// +++ dsp
// Интерфейс к НЧ кодеку
void hardware_audiocodec_enable(void);        // Интерфейс к НЧ кодеку
void hardware_audiocodec_initialize(void);    // Интерфейс к НЧ кодеку

// Интерфейс к ПЧ кодеку или FPGA
void hardware_fpgacodec_enable(void);        // Интерфейс к ВЧ кодеку
void hardware_fpgacodec_initialize(void);    // Интерфейс к ВЧ кодеку
void hardware_fpgaspectrum_enable(void);    // Интерфейс к источнику данных о спектре
void hardware_fpgaspectrum_initialize(void);    // Интерфейс к источнику данных о спектре

void hardware_dac_initialize(void);        /* инициализация DAC на STM32F4xx */
void hardware_dac_ch1_setvalue(uint_fast16_t v);    // вывод 12-битного значения на ЦАП - канал 1
void hardware_dac_ch2_setvalue(uint_fast16_t v);    // вывод 12-битного значения на ЦАП - канал 2


void hardware_spi_io_delay(void);

void cat2_parsechar(uint_fast8_t c);                /* вызывается из обработчика прерываний */
void cat2_rxoverflow(void);                            /* вызывается из обработчика прерываний */
void cat2_disconnect(void);                            /* вызывается из обработчика прерываний произошёл разрыв связи при работе по USB CDC */
void cat2_sendchar(void * ctx);                            /* вызывается из обработчика прерываний */

// Функции тестирования работы компорта по прерываниям
void cat3_parsechar(uint_fast8_t c);                /* вызывается из обработчика прерываний */
void cat3_rxoverflow(void);                            /* вызывается из обработчика прерываний */
void cat3_disconnect(void);                            /* вызывается из обработчика прерываний */
void cat3_sendchar(void * ctx);                            /* вызывается из обработчика прерываний */

void modem_parsechar(uint_fast8_t c);                /* вызывается из обработчика прерываний */
void modem_rxoverflow(void);                        /* вызывается из обработчика прерываний */
void modem_disconnect(void);                        /* вызывается из обработчика прерываний */
void modem_sendchar(void * ctx);                            /* вызывается из обработчика прерываний */

void nmea_parsechar(uint_fast8_t c);                /* вызывается из обработчика прерываний */
void nmea_rxoverflow(void);                            /* вызывается из обработчика прерываний */
void nmea_sendchar(void * ctx);                            /* вызывается из обработчика прерываний */

void hardware_uart1_initialize(void);
void hardware_uart1_set_speed(uint_fast32_t baudrate);
void hardware_uart1_tx(void * ctx, uint_fast8_t c);    /* передача символа после прерывания о готовности передатчика */
void hardware_uart1_enabletx(uint_fast8_t state);    /* вызывается из обработчика прерываний */
void hardware_uart1_enablerx(uint_fast8_t state);    /* вызывается из обработчика прерываний */
uint_fast8_t hardware_usart1_putchar(uint_fast8_t c);/* передача символа если готов порт */
uint_fast8_t hardware_usart1_getchar(char * cp); /* приём символа, если готов порт */

void hardware_uart2_initialize(void);
void hardware_uart2_set_speed(uint_fast32_t baudrate);
void hardware_uart2_tx(void * ctx, uint_fast8_t c);    /* передача символа после прерывания о готовности передатчика */
void hardware_uart2_enabletx(uint_fast8_t state);    /* вызывается из обработчика прерываний */
void hardware_uart2_enablerx(uint_fast8_t state);    /* вызывается из обработчика прерываний */
uint_fast8_t hardware_usart2_putchar(uint_fast8_t c);/* передача символа если готов порт */
uint_fast8_t hardware_usart2_getchar(char * cp); /* приём символа, если готов порт */

void usbd_cdc_tx(void * ctx, uint_fast8_t c);            /* передача символа после прерывания о готовности передатчика - вызывается из HARDWARE_CDC_ONTXCHAR */
void usbd_cdc_enabletx(uint_fast8_t state);    /* вызывается из обработчика прерываний */
void usbd_cdc_enablerx(uint_fast8_t state);    /* вызывается из обработчика прерываний */

/* отладочная выдача через USB CDC */
void debugusb_initialize(void);                /* Вызывается из user-mode программы при запрещённых прерываниях. */
uint_fast8_t debugusb_putchar(uint_fast8_t c);/* передача символа если готов порт */
uint_fast8_t debugusb_getchar(char * cp); /* приём символа, если готов порт */
void debugusb_parsechar(uint_fast8_t c);    /* вызывается из обработчика прерываний */
void debugusb_sendchar(void * ctx);            /* вызывается из обработчика прерываний */

И далее в том же духе:

Код

uint_fast8_t board_getadc_filtered_u8(uint_fast8_t i, uint_fast8_t lower, uint_fast8_t upper);    /* получить значение от АЦП в диапазоне lower..upper (включая границы) */
uint_fast16_t board_getadc_filtered_u16(uint_fast8_t i, uint_fast16_t lower, uint_fast16_t upper);    /* получить значение от АЦП в диапазоне lower..upper (включая границы) */
uint_fast8_t board_getadc_smoothed_u8(uint_fast8_t i, uint_fast8_t lower, uint_fast8_t upper);    /* при изменении отфильтрованного значения этого АЦП возвращаемое значение на каждом вызове приближается к нему на 1 */
uint_fast8_t board_getadc_unfiltered_u8(uint_fast8_t i, uint_fast8_t lower, uint_fast8_t upper);    /* получить значение от АЦП в диапазоне lower..upper (включая границы) */
uint_fast16_t board_getadc_unfiltered_u16(uint_fast8_t i, uint_fast16_t lower, uint_fast16_t upper);    /* получить значение от АЦП в диапазоне lower..upper (включая границы) */
uint_fast32_t board_getadc_unfiltered_u32(uint_fast8_t i, uint_fast32_t lower, uint_fast32_t upper);    /* получить значение от АЦП в диапазоне 0..255 */
adcvalholder_t board_getadc_filtered_truevalue(uint_fast8_t i);    /* получить значение от АЦП */
adcvalholder_t board_getadc_unfiltered_truevalue(uint_fast8_t i);    /* получить значение от АЦП */
adcvalholder_t board_getadc_fsval(void);    /* получить максимальное значение значение от АЦП */
void hardware_set_adc_filter(uint_fast8_t i, uint_fast8_t v);    /* установить способ фильтрации данных (в момент выборки их регистра АЦП */

void hardware_set_adc_filterLPF(uint_fast8_t i, uint_fast8_t k);    /* Установить способ фильтрации LPF и частоту среза - параметр 1.0..0.0, умноженное на HARDWARE_ADCFILTER_LPF_DENOM */
#define HARDWARE_ADCFILTER_LPF_DENOM    128        /* положение фиксированной точки при фильтрации HARDWARE_ADCFILTER_LPF */

Сообщение отредактировал Genadi Zawidowski - Mar 14 2017, 22:40

[Эдди]

На русском комментарии делать некультурно, между прочим! Как китайцы читать будут?

[ViKo]

На русском комментарии делать некультурно, между прочим! Как китайцы читать будут?

Намного культурнее, чем на ломаном английском, от которого англичанина наизнанку вывернет.

[Эдди]

По крайней мере, он хотя бы поймет, о чем речь!
Вот я смотрю два кЕтайских исходника. У одного комментарии на кетаглийском, у другого — на китайском. Какой исходник я в /dev/null сразу же отправил?

[Genadi Zawidowsk...]

Между прочим, на pudn кто-то залил архив моего проекта, переведя readme.txt с русского на китайский.
А началось с того, что я не один раз пытался своего друга, который делает гигантские платы на x51 и Atmega с внешней памятью (компилируя с -O0, потому что иначе проект обваливается) на ARM перетащить. И писал для него примеры кода с русскими комментариями... Не удалось, но к русскому привык.

Сообщение отредактировал Genadi Zawidowski - Mar 14 2017, 22:43

Прикрепленные файлы

 readme__32763___35793_.txt ( 2.11 килобайт ) Кол-во скачиваний: 46
 readme.txt ( 1.47 килобайт ) Кол-во скачиваний: 43

 

[Velund]

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

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

[ViKo]

Поделитесь примером с комментариями на английском, который не стыдно показать.

[Velund]

Поделитесь примером с комментариями на английском, который не стыдно показать.

Не знаю, какой в этом смысл, но вот - хватанул с экрана что было в окне редактора...

CODE

  for (;;)         // Task, that caused error, will loop here forever
   {
#ifndef DEBUG
       if (!(SysFlags & SYSF_OSStarted)) VdHitWd(wd);
#endif

     UpdLEDs ();
         t2 = _SET_TIMEOUT(100);         // 100 ms delay
         while (!(_CHK_TIMEOUT(t2))) {}

         if (_CHK_TIMEOUT(t))            // Check if timeout expired
          {
            SysFlags |= SYSF_ResetReq;   // Set restart request flag
            t = _SET_TIMEOUT(3000);      // Allow 3 sec for graceful termination of other tasks
            while (!(_CHK_TIMEOUT(t))) {}
            GSMPower(0);                 // Turn modem off
            if (GenCnf.dat.DSLflags & DSMF_Enable)
            {
              Slv_SleepCmd (SLAVE_ADDR, 3600, 0x01, &err);
              t = _SET_TIMEOUT(3000);    // Delay 3 sec
              while (!(_CHK_TIMEOUT(t))) {}  // (actually, power will be shut down during this delay)
              // If we pass here, something went really wrong. Reboot anyway.  
              reboot();                   // Reset unit, if wasn't done already by other task
            }              
            else
              reboot();                   // Reset unit, if wasn't done already by other task
          }
    }

}

//////////////////////////////////////////////////////////////////////////

[Эдди]

Что-то у вас излишне комментариев. Например, зачем комментировать очевидное — паузы?

[Шаманъ]

Что-то у вас излишне комментариев. Например, зачем комментировать очевидное — паузы?

Комментариев мало не бывает

[jcxz]

Что-то у вас излишне комментариев. Например, зачем комментировать очевидное — паузы?

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

[Obam]

"…зачем комментировать очевидное — паузы?…"

А для чего эта пауза? Очевидно? Не думаю… (;

[Сергей Борщ]

А для чего эта пауза? Очевидно? Не думаю… (;

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

[Эдди]

А для чего эта пауза? Очевидно? Не думаю… (;

Во-во. Правильней было бы объяснить, на кой черт она вообще нужна!

[Baser]

Например, зачем комментировать очевидное — паузы?

У меня такие комментарии частенько бывают. По двум причинам.
1. Частенько лень писать спец. макрос и число в коде не явно описывает реальное время задержки.
2. Как выше в примере - число реальное, а единицы измерений неизвестно какие (мкс, мс, сек ??)
А через год нужно подкрутить код - и ищи концы по проекту. А так - комментарий присутствует

[Эдди]

Ну, я стараюсь только неочевидные вещи комментировать + для себя кой-какие заметки на будущее делать, вроде такого.

[Obam]

2. Как выше в примере - число реальное, а единицы измерений неизвестно какие (мкс, мс, сек ??)
А через год нужно подкрутить код - и ищи концы по проекту. А так - комментарий присутствует

Дарю:
#define _RTTPrsclr_15ms (480u)

#define _RTT_30ms (2)// по _RTT_15ms_Tick
#define _RTT_250ms (17)// по _RTT_15ms_Tick
#define _RTT_300ms (20)// по _RTT_15ms_Tick

PAUSE (_RTT_1500ms);

Как показывает опыт, экономить на топтании клавы не стОит. (:

[juvf]

есть такое...... хороший код в коментариях не нуждается.
у Genadi Zawidowski скорее не комментарии, а референс мануал на его API.

У Velund пустые, не нужные комментарии.... типа таких

Код

int a = 10; //создал переменную а, задал ей значение 10

2. Как выше в примере - число реальное, а единицы измерений неизвестно какие (мкс, мс, сек ??)
А через год нужно подкрутить код - и ищи концы по проекту. А так - комментарий присутствует

Для этого не нужны комментарии, нужны правильные имена.

Код

t2 = _SET_TIMEOUT_MS(100);

GSMPower(0); - такой вызов без комментариев не очевиден
GSMPower(OFF), GsmModemPowerOff() или GsmModemOff() не нуждается в комментариях.

ps чужой код всегда плох. у каждого свой стиль, и только он true. Все остальное говнокод неправильное

[Alechek]

Комментариев мало не бывает

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

Я, бывает, вначале комментариями пишу, что должно делаться, а потом уже эту последовательность последовательно превращааю в код.
Так как когда код уже написан, и в текущий момент времени понят тобой на 120%, то необходимость в комментариях (особенно развернутых) в этот момент вообще никак не очевидна.

GSMPower(0); - такой вызов без комментариев не очевиден
GSMPower(OFF), GsmModemPowerOff() или GsmModemOff() не нуждается в комментариях.

ИМХО, правильнее комментирование целого куска:

/* Выключаем модем правильно, см. ****pdf, 2.3.4 Power Down Cycle */
GSMPowerKey(1);
Delay(2000);
GSMPowerKey(1);
Delay(8000);
GSMPower(0);

[ViKo]

Моё.

CODE

/*!****************************************************************************
@brief Voltage Battery conversion & check
@note Однократное преобразование напряжения литиевой батареи
@note Temp.sensor, VRefint измеряются перед VBat/2
*/
uint32_t Bat_check(void)
{
/* Сначала запустить и дождаться преобразования инжектированных каналов
2 * (480 + 12 cycles) : 32.8 us
Заодно сработает прерывание от ADC3 - проверка уровня заряда аккумулятора
Сбросить бит окончания преобразования инжектированных каналов */
ADC1->CR2 |= ADC_CR2_JSWSTART;
ADC3->CR2 |= ADC_CR2_JSWSTART;

while (!(ADC1->SR & ADC_SR_JEOC)) { }
ADC1->SR &= ~ADC_SR_JEOC;

/* Разрешить делитель напряжения батареи
Задержка для включения не нужна */
ADC->CCR |= ADC_CCR_VBATE;

/* Старт регулярного канала преобразования
Ожидать окончание преобразования, 480 + 12 cycles : 16.4 us */
ADC1->CR2 |= ADC_CR2_SWSTART;
while (!(ADC1->SR & ADC_SR_EOC)) { }

/* Запретить делитель напряжения батареи */
ADC->CCR &= ~ADC_CCR_VBATE;

/* Прочитать температурный датчик и опорное напряжение */
Sensors.Temp = ADC1->JDR1;
Sensors.Ref = ADC1->JDR2;

/* Прочитать напряжение батареи (умножить на 2)
При чтении DR автоматически сбрасывается бит окончания
преобразования регулярных каналов EOC
Для перевода в мВ измеренное значение нужно преобразовать по формуле:
mV = Data * 1210 / VRefData */
uint32_t Bat = (ADC1->DR << 1) * 1210 / Sensors.Ref;

/* Округлить и уменьшить в 10 раз */
if (Bat % 10 < 5) Bat = Bat / 10;
else Bat = Bat / 10 + 1;
// NumStat1_print(Bat);

/* Проверить, укладывается ли напряжение в допустимый диапазон */
return Bat;
}

[Obam]

"Я, бывает, вначале комментариями пишу, что должно делаться, а потом уже эту последовательность последовательно превращааю в код."
Присоединяюсь…

"Так как когда код уже написан, и в текущий момент времени понят тобой на 120%, то необходимость в комментариях (особенно развернутых) в этот момент вообще никак не очевидна."
ОтлОжите его (этот код) не менее чем на пол-годика, займётесь каким-нибудь перпендикулярным проектом и после, вернувшись, похвАлите себя за то, что не зажмотились в "…комментариях (особенно развернутых)…"
Я гарантирую это (;

[jcxz]

У Velund пустые, не нужные комментарии.... типа таких

Код

int a = 10; //создал переменную а, задал ей значение 10

Согласен. Такие комментарии делают обратное - только ухудшают читаемость исходника, загромождая его.

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

А бывает и наоборот.
Очень часто бывает (много раз сталкивался на практике), когда код написали вместе с комментами, а потом начали отлаживать-отлаживать-отлаживать. В результате код сильно изменился (до совершенно другого), а комменты каждый раз при отладке конечно лень менять. В результате получаем комменты не соответствующие коду, и наоборот - только вводящие в заблуждение.
Поэтому я, например, при первоначальном написании, комменты почти не пишу. А пишу их только когда исходник более-менее устаканится и заработает как надо.

[Forger]

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

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

Кто уже плотно сидит на "плюсах" и тем более уже созрел строить полноценный объектный код, используя всю мощь "плюсов", вторую книжка будет очень полезна, по крайней мере мне она очень пригодилась.
Благодаря этой книжке мне удалось составить собственную "конвенцию именования", очень лаконичную и простую, но при этом предельно однозначную, что значительно улучшило читаемость кода:


ps, Картинка не ради разведения очередного холивара, а, просто - вдруг кому-то пригодится ))

[juvf]

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

а мне помогла небольшая шпаргалка

Прикрепленные файлы

 ________________________.pdf ( 534.14 килобайт ) Кол-во скачиваний: 117

 

[Forger]

а мне помогла небольшая шпаргалка

Прям с языка сняли!!!

Правда с некоторыми пунктами я не очень согласен, в частности с теми, которые имеют приписку "Это правило пришло из математики...".
Предпочитаю математику (да и не только математику, но и другие дисциплины) с ее короткими и малоинформативными именами и именами в коде не смешивать, не путать "мух с колетами"
Скажем "скорость" называть не 'v', а как положено - velocity, т. е. в данных случаях сокращения, пришедшие из фундаментальных вековых дисциплин, могут сильно усложнить чтение кода.
Дело в том, что в те далекие времена английский не был, можно сказать, "всемирным" языком, и потому чаще всего использовались лишь сокращения от латинских названий терминов,
К тому же практически все писалось от руки.
Но те времена уже давно прошли, поэтому я лично не вижу никакого смысла цепляться за них в коде.

Например, вместо "i" использую переменную, носящую конкретный смысл для кода, где она используется: index, iterarator, value ..., составные: itemIndex, objectIterator и и т.п.
Но в примитивных случаях (скажем, цикл из одной строки), "классическое i" вполне сгодится, иначе увеличивается сложность чтения кода.

Для отладки полноценные имена (в том числи и счетчики циклов, итераторы и т. п.) тоже очень полезны - в окне watch переменные несут явный и однозначный смысл.
Разумеется, при условии, что переменные и объекты названы правильно

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

[Alechek]

Благодаря этой книжке мне удалось составить собственную "конвенцию именования", очень лаконичную и простую, но при этом предельно однозначную, что значительно улучшило читаемость кода:

Если уж пошла такая пьянка по поводу стилей, то при переходе на C++ я решил придерживаться

https://google.github.io/styleguide/cppguide.html

[Forger]

Если уж пошла такая пьянка по поводу стилей, то при переходе на C++ я решил придерживаться

А почему лишь C++?
Я вот использую единые принципы именования и структурирования не только в С/С++ коде, но и в других языках, средах, CAD-ах и т. п.
Например, очень удобно писать код для МК, если цепи на схеме (AD) названы таким образом, что позволяет в коде использовать точно такие же имена для пинов.

[zltigo]

Очень часто бывает (много раз сталкивался на практике), когда код написали вместе с комментами, а потом начали отлаживать-отлаживать-отлаживать. В результате код сильно изменился (до совершенно другого), а комменты каждый раз при отладке конечно лень менять. В результате получаем комменты не соответствующие коду, и наоборот - только вводящие в заблуждение.

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

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

Именно так. Причем такое комментирование прекрасно совмещается с общей вычиткой и оптимизацией исходника.

[Aaron]

а мне помогла небольшая шпаргалка

Блин, товарищи, поздновато выложили Как раз сейчас разродился наконец оформить требования к стилю кодирования в своём отделе, уже написал почти Но всё равно подглядеть чужие готовые рекомендации незазорно, чтобы ничего не упустить!

[Forger]

Как раз сейчас разродился наконец оформить требования к стилю кодирования в своём отделе, уже написал почти

Я для своего отдела тоже задавался подобной целью, курил интернеты, читал соотв. книжки, но не прижилось в том виде, как я хотел.
Полагаю, что причина в том, что каждый работник тянет свои проекты в одиночку.
Проекты относительно небольшие, команда не требуется.
Поэтому каждый "ваяет" как пожелает.
Главное - положительный результат на выходе )))

[Kabdim]

+1 за гугльстайл. Самый вменяемый стайлгайд на данный момент. Для любителей варианта "от создатаелей..." даже Страуструп написал тяжеловесный толмуд. А вот придумывать своё в 17 году - это жесть, ей богу.

[juvf]

+1 за гугльстайл. Самый вменяемый стайлгайд на данный момент.

string table_name; // OK - uses underscore.
string tablename; // OK - all lowercase.

string tableName; // Bad - mixed case.

где уж самый вменяемый? tableName - читабельно. table_name - читабельно. tablename - не читабельно. tableName - такой стиль часто встречал. Например Qt так написан. Например переменная
bool QGuiApplication::quitOnLastWindowClosed, в гуглсайле будет так quitonlastwindowclosed - это плохо читаемо. имхо.

[Forger]

quitonlastwindowclosed - это плохо читаемо

Поддерживаю! Такой набор букв даже носители языка вряд ли прочтут без труда, остальным остается лишь по-сочувствовать ))

[Kabdim]

tablename - не читабельно

Как по мне так вполне читабельно, особенно если это не просто два слова, а постоянно используемые в такой связке два слова. Рекомендаций называть переменную предложением, а потом записывать её имя без подчеркиваний там нет.

А по поводу вашего примера: bool QGuiApplication::quitOnLastWindowClosed - не переменная, а property. В гугльстайле вы модификаторы property можете называть как переменную, но это не требуется. Т.е. когда имя property - предложение, очевидно её удобней называть Camal case'ом, что стайл вполне позволяет.

[Forger]

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

Полагаю, что если жить только с гуглекодом и изучать/пользовать/читать только гуглепроеты с утра до вечера, то постепенно привыкаешь и подсаживаешься
Однако, если пройдет какое-то время (перерыв), то придется заново вкуривать в этот код, потратив некоторое время на повторное привыкание.

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

[Aaron]

К чему холивар, Kabdim? Главное не инструмент (коих много), а цель - достичь переносимости и поддерживаемости кода в команде. Если тебе инструмент не подходит - ты берёшь другой, или делаешь удобный, под себя.

А вот придумывать своё в 17 году - это жесть, ей богу.

В чём именно жесть? Скомпилировать несколько трудов, взять из них лучшее, вычеркнуть неудачное и лишнее, скомпоновать - это здорово!
Между прочим, разработчики крупных проектов не стесняются внедрять свои собственные правила, поищите JPL C Coding Standard, CERN C++ Coding Standard
ГуглоСтайл как по мне, не совсем торт. Аналогично как и КьютСтайл. Выше уже высказались.

[Kabdim]

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

[Forger]

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

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

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

[Kabdim]

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

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

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

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

[Forger]

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

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

Код

quitonlastwindowclosed

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

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

[Kabdim]

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

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

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

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

[Forger]

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

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

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

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

[juvf]

А по поводу вашего примера: bool QGuiApplication::quitOnLastWindowClosed - не переменная, а property.

А проперти - это не переменная? в с++ вообще нет проперти. проперти - это уже смысловое значение переменной или константы.

Код

Q_PROPERTY([b]bool quitOnLastWindowClosed[/b]  READ quitOnLastWindowClosed WRITE setQuitOnLastWindowClosed)

вижу тип переменной bool, имя переменной quitOnLastWindowClosed. может в с++ появилось что-то новое, появились проперти.... заглянул в ассистант, глянул что такое PROPERTY

Код

Q_PROPERTY(type name.....

ан нет... тип и имя переменной.

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

ps в довершении.... в QtCreator, и позже в Eclipse, есть автодополнение по камел кейсу. назвал переменную quitOnLastWindowClosed, в коде набираешь qol (или qOL) автодополнение предлагает все переменные начинающиеся на q и имеющие в имени большие буквы O и L. в итоге будет предложены все переменные и методы... с вероятностью в 100% будет предложена переменная quitOnLastWindowClosed (или достаточно будет набрать qO). у QString набираешь tss - автодополнение делает toStdString. Набираешь gp - выдает getPoint и getPosition. tn - выскочит tableName Т.е. камел кэйс дает подсказку для автодополнения. Это очень удобно в написании.

[Kabdim]

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

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

А проперти - это не переменная?

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

в с++ вообще нет проперти.

А в QT из которого выдран пример - есть.

без разницы в каком стеле написано.... главное чтобы всем было понятно....

Тут я с вами безусловно согласен.

и не только мне не понравился гугл стайл.
ps в довершении.... в QtCreator, и позже в Eclipse, есть автодополнение по камел кейсу. назвал переменную quitOnLastWindowClosed, в коде набираешь qol (или qOL) автодополнение предлагает все переменные начинающиеся на q и имеющие в имени большие буквы O и L. в итоге будет предложены все переменные и методы... с вероятностью в 100% будет предложена переменная quitOnLastWindowClosed (или достаточно будет набрать qO). у QString набираешь tss - автодополнение делает toStdString. Набираешь gp - выдает getPoint и getPosition. tn - выскочит tableName Т.е. камел кэйс дает подсказку для автодополнения. Это очень удобно в написании.

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

[juvf]

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

а оно работает по подчеркиванию. написал int hello_world; сохранил. в следующей строке написал hW и жамкнул ctrl+Пробел. дополнило до hello_world. я не говорю что подчеркивание не удобно, я говорю что слитно не удобно. а гугл пердлогает и слитно тоже.

[zltigo]

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

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

[Kabdim]

я говорю что слитно не удобно

Кмк эта возможность писать слитно слишком слишком демонизируется. Этот вариант написания один из возможных, т.е. программист может выбрать его там где он будет уместен. Например isalpha, в качестве локальной переменной - почему бы и нет. А в тех местах где это не уместно предлагаются подчеркивания.

[Forger]

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

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

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

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

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

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

[jcxz]

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

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

[Aaron]

очевидно же - у класса есть конструкторы/деструкторы и private/protected области видимости =)

[Forger]

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

А потому что в английском язые нет слова "isalpha", а есть два слова Is или Alpha, поэтому логичнее изменить на "isAlpha", is_alpha или IsAlpha.
Английский Язык Предусматривает Написание Каждого Слова Предложения Заглавными Буквами, а русский - нет.
Поэтому логично предположить, что и все правила английского языка распространяются на код, на котором он написан.

А в тех местах где это не уместно предлагаются подчеркивания.

Я раньше применял такое правил, но отказался - глаз спотыкается об эти подчеркивания, а пользы я не нашел.
К тому же как только переменная меняет области видимости (локальная - глобальная - поле класса), ее ВЕЗДЕ приходится переименовывать.
Какой в этом смысл? Зачем в название переменной вносить область ее видимости?
Мне кажется более логичным создать ее экземпляр непосредственно перед тем местом, где она используется (в стеке).
В С++ такое возмоно, но не в С.
Например:

Код

for (int index = 0; ....)
{
...
}

Если в коде опять будет цикл, можно создать переменную с точно таким же именем, но это будет совсем ДРУГАЯ переменная,
что заставляет узко локализовать область использования временных (локальных) переменных, а не раскидывать их по всему коду функции,
особенно, если она вся не влазит на экран.
Хотя я стараюсь минимизировать число локальных переменных и главное - дробить огромные функции.

очевидно же - у класса есть конструкторы/деструкторы и private/protected области видимости =)

В структуре все поля, если не указано public/private/protected, являются по-умолчанию public, а в классе - private.
Это - единственное отличие между структурой и классом. В остальном они отличаются лишь названием

Это как это?

Структура у меня используется лишь как структурированное хранилище данных (часто упакованы с соотв. атрибутами типа packed), т.е. ТОЛЬКО ПОЛЯ,
а класс - уже что-умеет делать сам, т.е. у его есть еще и МЕТОДЫ.
Я делю их между собой именно так, хотя прекрасно знаю, чем они отличаются на самом деле (см. выше).
Структур (struct) в коде у меня очень мало и почти все они имеют крайне локализованный характер, т. е. обладают очень узкой областью видимости. Насколько это возможно.
На самом деле, я немного слукавил, приведя в пример возможность структуры стать классом )) Обычно, это происходит не так явно - просто, резко сужается область видимости структуры и она попадает лишь внутрь соотв. класса.

Небольшое дополнение насчет макросов и замен "магических" чисел.
Поскольку в коде у меня нигде нет глобальных объектов, ни одного,
то это создает некоторые сложности с отказом от моего правила - макросов и замен "магических" чисел - БОЛЬШИМИ_БУКВАМИ_С_ПОДЧЕРКИВАЕНИЕМ.
Т. е. в моем случае такие "дефайны" имеют исключительно глобальный смысл и каждый объектный модуль при желании может их использовать.
Таким образом получается, что я как бы намекаю (сам себе, разумеется), что речь идет не об объектах, а лишь заменах (дефайнах), которые при компиляции (после препроцессора) станую обычными числами и выражениями.
Поэтому сильно сомневаюсь, что макросы и замены буду именовать иначе, чем так, как сейчас ))

[jcxz]

очевидно же - у класса есть конструкторы/деструкторы и private/protected области видимости =)

К Вашему сведению: у структуры - тоже.
Единственное отличие между ними (насколько я знаю): у структуры права доступа по умолчанию - "public", у класса - "private".

PS: О! Уже опередили....

[Kabdim]

В С++ такое возмоно, но не в С.
Например:

Код

for (int index = 0; ....)
{
...
}

Вы про C99 не слышали?

можно создать переменную с точно таким же именем

Вы уверены что это можно назвать хорошим стилем?

Структура у меня используется лишь как структурированное хранилище данных (часто упакованы с соотв. атрибутами типа packed), т.е. ТОЛЬКО ПОЛЯ,

Это называется plain old data (POD)

[juvf]

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

я тоже не поддерживаю в имени переменной её тип (как например в том же гугл сайл), но переименовать переменную везде... так это вроде в пару кликов. рефакторинг ещё ни кто не отменял.

[scifi]

я тоже не поддерживаю в имени переменной её тип (как например в том же гугл сайл), но переименовать переменную везде... так это вроде в пару кликов. рефакторинг ещё ни кто не отменял.

+1. Современные текстовые редакторы - это благо. Тип переменной встраивали в её название в каменном веке, когда текстовые редакторы ещё недалеко ушли от карандаша и ручки. Сейчас объявление переменной вместе с её типом искать не приходится - оно само находится.