Python для си-шника

Я — разработчик микроконтроллерных систем. Я пишу программное обеспечение для МК на языке Си. При работе с проектами я предпочитаю использовать make-подход и командную строку, а не тяжеловесные IDE типа Code::Blocks и Eclipse.

С одной стороны, эти IDE требуют для своей нормальной работы очень мощные компы, а  с другой — я не очень понимаю (и принимаю)  тенденцию к наращиванию «жира».

На минуточку, проснитесь! Ведь чтобы создать программу для МК, размер которой не превышает несколько килобайт, привлекаются мощнейшие компы с гигагерцовыми процессорами и гигабайтами оперативной памяти. И мы ведь искренне гордимся тем, что «гора» нашего железа, стоящего у нас на столе, рожает мышь в каких-то 300-500 байт за полсекунды»? Эй! Алё! Что происходит?

Если на ситуацию посмотреть со стороны, то становится понятно, что мы не замечаем, что крепко сидим на крючке — нам втюкивают не функционал вещей, а ненужные понты. Здравый рассудок подсказывает, чтобы создать программу в один килобайт не нужен инструмент, размер которого превышает 100 килобайт. Вспомните времена DOS! Вспомните «Turbo-C 2.0». Что изменилось с тех пор? Почему мир пошел в этом направлении?

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

Оглянитесь вокруг! Разработчики озабочены не тем, что они делают на своих компах, а тем — какие у них компы. Выпускать посредственную 2-килобайтную гавно-программу на крутом 8-ми ядерном компе с 16 гигабайтами оперативы — ну да, это мега-круто!

Я не понимаю эту философию, поэтому предпочитаю немного другие инструменты.

Это было лирическое отступление. Далее пойдет техническая часть.

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

Например, понадобилось мне включить в проект функциональный модуль для измерения температуры. Пока не важно на основе какого железа будет работать этот модуль, и что он будет делать. Важно только лишь то, что почти вся его функциональность будет находится в отдельном файле — точнее в двух — в temp.c и temp.h.

Что характерно — обычно я создаю сразу пару файлов (.c и .h) с одинаковым именем. В начале каждого файла я прописываю в комментариях его имя. Это нужно для распечатки файла на бумаге — потом сразу будет видно, содержимое какого файла представлено на этой распечатке. Гадать не придётся. Кроме того, в хэдерном файле я обычно создаю секцию для исключения повторного определения, а в си-шном файле обычно вставляю команду препроцессора для подключения хэдерного файла. Мне объяснять, а вам читать — утомительно, нагляднее показать содержимое этих файлов. Точнее заготовку содержимого для этих файлов.

temp.c

// temp.c

#include "temp.h"

temp.h

// temp.h

#ifndef __TEMP_H__
#define __TEMP_H__


#endif

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

(Мечтательно) Да-а, было бы здорово, если бы можно было одним взмахом руки создать заготовку этих файлов.

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

Вот она, перед вами. Я назвал эту утилиту незатейливо — mkch (имя вроде как не занято).

#!/usr/bin/env python

def create_hfile(hname, defname):
  hfile = open(hname, "w")
  hfile.write("// " + hname + '\n')
  hfile.write("\n")
  hfile.write("#ifndef " + defname + '\n')
  hfile.write("#define " + defname + '\n')
  hfile.write("\n\n")
  hfile.write("// Put here all your defines\n")
  hfile.write("\n\n")
  hfile.write("#endif" + '\n')
  hfile.close()

def create_cfile(cname, hname):
  cfile = open(cname, "w")
  cfile.write("// " + cname + '\n')
  cfile.write("\n")
  cfile.write("#include \"" + hname + "\"\n")
  cfile.write("\n\n")
  cfile.write("// Put here your codes\n")
  cfile.close()

def create_couple(modname):
  hname = modname + ".h"
  cname = modname + ".c"
  defname = "__" + modname.upper() + "_H__"
  create_hfile(hname, defname)
  create_cfile(cname, hname)

if __name__ == "__main__":
  import sys
  modname = sys.argv[1]
  #print modname
  create_couple(modname)

Это обычная Питоновская прога, которая размещается в поддиректории bin, в домашнем директории (если кому не понятно, то вот — /home/alex/bin). Путь в этот директорий в Убунте как правило уже прописан. Таким образом даже ничего специально не надо делать, нужно просто создать в этом поддиректории файл mkch и сделать его исполняемым.

Теперь мне не нужно отвлекаться на создание пары файлов, прописывать у них начальную структуру, следить за тем, чтобы они «срослись» по именам и прочее. Я просто набираю команду

$ mkch temp

, а затем вызываю текстовый редактор и начинаю «набивать» созданные файлы содержимым. Таким образом, творческий процесс полета инженерной мысли практически не прерывается.

Я не утверждаю, что утилита mkch — это какой-то шедевр программистской мысли или что это уже функционально-полная прога, — нет! Если вы способны ее изменять в лучшую сторону, то я могу это только приветствовать. Кроме того, я преднамеренно в проге на стал прописывать всякие-там try-except-ловушки, которые, конечно сделают утилиту более робастой, но при этом она потеряет в наглядности (в прозрачности работы). Мне сейчас важно поделиться идеей, а не выкатить на рынок уже готовый (на все случаи) инструмент. Хотя, похоже, я уже начал оправдываться… В общем, берите, пользуйтесь и получайте удовольствие, а жир-сало можно навешать потом, по мере надобности.

Ну и как обычно — если заметите ошибки или неточности, сообщайте, плиз!

 

UPDATE 31.05.2016

Продолжение темы: http://wp.me/p1H7g0-1q3