Зачем локальную переменную делать статик? Если мы сохраняем ее в RAM то с тем же успехом ее можно сделать глобальной ну или статик на уровне файла.

Для ограничения области видимости статической переменной внутри функции.
В других местах можно применять переменные с таким же именем и они будут другими для компилятора.

я понял. спасибо. наверное когда нибудь мне пригодиться такое свойство.

При "правильном" программировании все статические переменные, которые применяются только внутри функции, нужно обязательно объявлять внутри этой функции.
Например, переменная step, которая является текущим шагом конечного автомата, описываемого функцией.
Это повышает читабельность кода и снижает возможность ошибок.
Нельзя случайно изменить эту переменную в другой функции и не нужно рыться по всему проекту, выясняя где эта переменная еще используется.

спасибо. наконец то понял для чего это нужно.

Но такой подход убивает чистоту функции, а в некоторых языках программирования чистота функции большой плюс.
Функцию с внутренней переменной step не особенно запихнешь в библиотеку для повторного использования.
С многопоточностью будут проблемы у такой функции.
Совпадение имен глобальной и локальной переменной тоже лучше не практиковать - попутать что где легче простого.

Ну, с глобальной переменной будет ровно то же самое. Что касается полезности, то завит от. У локальных статических функций есть свои плюсы. Например, функции-генераторы. Или тот же синглтон Мейерса. Реализация получается простая и эффективная. Конечно, в любом случае программист должен чётко представлять, что он делает и какие последствия могут возникнуть из-за неправильного использования.


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

А если все необходимые переменные передавать в функцию (в виде списка или сложного объекта)?
Разумеется, что совсем без побочных действий не обойтись, но если данные можно отделить от кода,
то я такой возможностью пользуюсь.
Тут пример для управления шаговым двигателем приводили. Предложенная реализация возможна
для одного двигателя, а если их много больше?
Я бы сделал массив объектов, которые бы хранили все необходимое - и текущий шаг, и скорость, и ускорение,
и целевое значение, обратную связь по энкодеру или потенциометру, адреса пинов, если это необходимо.
А функцию, решающую что делать с полем step, сделал бы универсальной.
Разумеется static переменных в ней не было бы. Оформил бы это в виде библиотеки и таскал из проекта в проект,
где есть хоть один шаговый двигатель.

Все это хорошо, но локальные данные могут быть и константными (скажем, таблица для перевода номера микрошага в коэф. заполнения ШИМ или любые другие константы) и чтобы эти данные не копировались в ОЗУ во время создания переменной при каждом входе в такую функцию, переменная должна быть объявлена статической.

Т.е. эта таблица жестко "вшита" в функцию? Не пойдет ибо ШИМ довольно аппаратно-зависимая вещь.
Хотя идея понятна (может понадобиться таблица синуса, например).

С этим никто не спорит, но нужно решать в каждом конкретном случае, как будет удобней.


А вот тут никто вам не запрещает это делать. Более того, в стандартных библиотеках Си полно функций с таким финтом,
в описаниях отдельно пишут, что они "опасные", не реентерабельные, дописывают новые варианты безопасных, но нестандартных функций. Но стандартные функции то уже никуда не денешь
Вот пример, функция парсинга текстовых строк strtok


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


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


Для таблиц и констант можно применять указатели, которые тоже передаются в функцию. Можно передавать также и переменные свойства таблиц (длину, структуру).

Много чего можно придумать, главное чтобы понятность кода не страдала.
А то сам иногда так накручу код для компактности, потом смотрю на тот ужОс, который получился и понимаю, что написание "тупо в лоб методом copy-paste" было бы лучше

Порой проще и естественней засунуть таблицу в функцию. Например, таблицу перекодировки тетрады в ASCII для вывода чисел в шестнадцатиричном формате. Такая таблица больше нигде не понадобится, какой смысл ее выностить из функции?
Серега, ты созрел для перехода на C++

Увы, все никак...
Даже осилил почти весь учебник Шилдса, но до конца прочуствовал только одну фразу во введении,
где говорится, что смысл применять плюсы есть только начиная с определенного уровня сложности проектов.

У меня проекты сравнительно простые, поэтому я никак не пойму для чего мне все эти фантики (обертки) которые скрывают реальную сущность объектов.
С переходом с асма на си было все понятно, выгоды очевидны, а тут...

Да что этот Шилдс понимает... :-)
Я осваивал плюсы на scmRTOS ("кишки" довольно сложные, но снаружи всё просто и понятно) и на Qt (супер-понятный внешний интерфейс, в "кишки" даже не лазил).
Рекомендую!
После этого свои классы без особых проблем придумываются.

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

Мой первый сиобразный язык был С++, а не С. В незапамятные времена, когда только появился первый (первый, потому, что 1.0 версии не было ) борлондячий Борланд С++ 2.0 я получил персональный компьютер и решил сваять для работы некую приблуду для которой требовалась, то, что я назвал, "оконной библиотекой" - то есть всякие окошки, текстовые естественно, но все же типа "Windows". В КБ у меня уже был уже бывалый сишный программисто, который утверждал, что писать нужно на Си с большими вкраплениями ASM, иначе будет безумно медленно. В обшем-то он был прав, поскольку тогдашний массовый персональный компьютер был восьмибитовым и имел тактовую 4,7MHz . Он даже взялся на спор показать мастеркласс в соревновании на скорость работы оконной библиотеки. В общем вечерами сидели и писали. Я на плюсах, правда с вкрапелениями на ASM, ибо уровень оптимизации тогдашних компиляторов был просто никакой, он на Си. Результат был как бы неожиданный - плюсовая работала быстрее . Причина на самом деле проста - уже больно она красиво и хорошо ложилась она во все эти классы и иже с ними. Выигрыш был за счет лучшей системной оптимизации. На самом деле обе , библиотеки работали медленно . Так что дальше начался этап писания на Си, но опираясь на понимание пришедшее с плюсов. Компиляторы с тех пор сделали громадный скачек так что СЕГОДНЯ откатываться на Си уже не пришлось-бы.
Сегодня надо писать на C++, хотя я так и остался де-факто на Си. Но С++ подход к делу НАВСЕГДА остался со мной.