Найти - Пользователи
Полная версия: Есть рабочий код, нужна критика и дельные советы опытных.
Начало » Центр помощи » Есть рабочий код, нужна критика и дельные советы опытных.
1 2 3 4 5
J.R.
.
py.user.next
J.R.
Mp3CueGen нужны все методы, которые есть в FlacCueGen.
Mp3 - это не разновидность Flac.
Они могут наследоваться от общего абстрактного формата какого-то, но не друг от друга. Потому что если во Flac надо будет что-то добавить, то в Mp3 этого может не оказаться, а может и вообще противоречить Mp3.
Поэтому по такому принципу (что типа методы одинаковые) наследование не делается.

J.R.
К тому же функция получилась лаконичная и самодостаточная
Вообще, надо уметь всё самому писать. И только когда умеешь, тогда и ищешь уже готовое. Иначе однажды просто не сможешь продолжать разработку, когда что-то будет нужно, а готовой реализации нигде не будет или она будет, но с кучей лицензионных условий.

J.R.
Это тоже сделано, дабы избежать длинных if… elif…
Как можно меньше зависимостей должно быть у частей кода друг с другом. По крайней мере, все эти преобразования не ясны, документировать неясное - это плохой стиль. Код должен сам себя документировать.
Shaman
J.R.
Mp3CueGen нужны все методы, которые есть в FlacCueGen. Плюс у MP3CueGen есть дополнительная проверка по версии тега. Там основной методе в FlacCueGen это get_metadata, который собирает теги из всех предложенных файлов одного формата.
Мне кажется, при выбранном подходе лучше разместить функциональность этих двух классов в ChooseType.
J.R.
.
J.R.
.
Shaman
J.R.
Крамола?
И ещё какая.
Shaman
Строка 261
line.maketrans(dict(zip(ru, lat)))
Таблицу перекодирования лучше считать в конструкторе, или определении класса, а не при каждом вызове функции.
py.user.next
J.R.
Посмотри пожалуйста функцию remove_slashes (451 строчка). Крамола? Переделать?
Это map() + re.sub(). Только тут не одна строка, а десять.

Shaman
Таблицу перекодирования лучше считать в конструкторе
Можно вынести, но можно и не выносить. Не такая уж она и большая.

J.R.
А про приём этот со словарем (choose_class, choose_action) выскажись пожалуйста?
Да можно его по разному делать, на первых порах лучше всё понятно писать.
Лучше какой-нибудь длиннющий if … elif … else, но локализованный в одном месте, чем короткие словари, но раскиданные по всей программе и связывающие её.
Если надо будет внести изменения в словарь, там вся программа посыпется из-за того, что разные фрагменты кода привязаны к его формату (названиям ключей).

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

И втягивай коммиты, я там ещё правил некоторые вещи.
[guest@localhost cuetool-concept-my]$ git fetch fork 
Enter passphrase for key '/home/guest/.ssh/id_rsa':
[guest@localhost cuetool-concept-my]$ git logo fork/master..
38393d7 Add the encoding argument to all open() calls with text mode
4319042 Remove redundant letter t in open mode
fffcda8 Refactor translit comprehension to map
441e31b Remove unnecessary .keys() calls from dictionaries
f044201 Add notes about git
8788a9b Add some empty lines between points
e00f7d4 Add a note about assertions
[guest@localhost cuetool-concept-my]$
J.R.
.
py.user.next
J.R.
Я щас с git -ом маленько пособлюсь
Там есть инфа в заметках, у тебя в репозитории нет.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB