Python-сообщество

Создал одиночный Учебный проект, в котором я собираюсь сделать динамический график, напоминающий тот, что имеется в Диспетчере задач Windows, но с дополнительными возможностями. Например, с паузой, прокруткой (просмотр истории), масштабированием и т.д.

Цель: изучить Python, wxPython, возможно, Tkinter и закрепить знание ООП. Наиболее важным для меня является научиться писать простой для восприятия код; он должен быть минимально зависимым от конкретного GUI, не содержать дублирования. Важным является изучение рефакторинга и юнит-тестирования.

То есть целью является не продукт, а процесс. Я знаю, что есть альтернативные проекты с графиками (например, тот что входит в wxPython) и буду посматривать на них. Пока я создал “резиновый график”, с легендами и сеткой. Начат ввод масштабирования.

Мой проект находится по адресу:
http://code.google.com/p/dynamic-plot/
Код:
http://dynamic-plot.googlecode.com/svn/trunk/
Черновик ТЗ:
http://dynamic-plot.googlecode.com/files/TZ_dynamic_plot.pdf

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

DRY
Методы вроде как положено называть с маленькой буквы. По сути сейчас сказать трудно - мало всего пока.

Ferroman
Методы вроде как положено называть с маленькой буквы. По сути сейчас сказать трудно - мало всего пока.

Почитайте труды великого диктатора, на самом деле соблюдение стиля принято и очень облегчит работу людям, которые будут читать ваш код и, может, совместно с вами разрабатывать проект: http://www.python.org/dev/peps/pep-0008/

Отредактировано (Дек. 11, 2009 15:10:43)

Вообще-то диктатор у нас “великодушный”.

Ferroman

xFin = self.rectLeft + self.rectWidth

Дублирование? Удалю. Но пока не решил как сделать лучше. Наверное сделаю переменной класса, а потом класс порву на части.

Ferroman
Методы вроде как положено называть с маленькой буквы.

Например, в wxPython они начинаются с большой. Понятно, что это связано с тем, что хотели сохранить какую-то совместимость с C++. Но всё же это прецедент. И так как я собираюсь потом все переписать на C++, то не думаю, что сильно грешу. Тут мне главнее соблюдать единообразие в своем стиле.

Ferroman
По сути сейчас сказать трудно - мало всего пока.

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

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

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

Дублирование? Удалю. Но пока не решил как сделать лучше. Наверное сделаю переменной класса, а потом класс порву на части.

В смысле “переменной класса”?
Можно сделать приватным методом класса, или как property (но тогда надо использовать “новые” классы). Зависит от того где это значение будет ещё использоваться, конечно.

Например, в wxPython они начинаются с большой. Понятно, что это связано с тем, что хотели сохранить какую-то совместимость с C++. Но всё же это прецедент.

Эти “прецеденты” описаны отдельно в PEP8. Рекомендую ознакомится.
Ибо читать трудно, в виду отсутствия видимой разницы между названиями методов и классов.

Изменил стиль кода для функций, как сказано в PEP8.