Я должен заставить свой Python кодировать менее надежный для улучшения удобочитаемости?
Я пытаюсь сделать свой код надежным, но я заметил, что требуется много времени для вывода вещей, и требуется больше времени для чтения кода.
Вместо:
class TextServer(object):
def __init__(self, text_values):
self.text_values = text_values
# <more code>
# <more methods>
Я склонен писать это:
class TextServer(object):
def __init__(self, text_values):
for text_value in text_values:
assert isinstance(text_value, basestring), u'All text_values should be str or unicode.'
assert 2 <= len(text_value), u'All text_values should be at least two characters long.'
self.__text_values = frozenset(text_values) # <They shouldn't change.>
# <more code>
@property
def text_values(self):
# <'text_values' shouldn't be replaced.>
return self.__text_values
# <more methods>
Действительно ли мой стиль кодирования Python является слишком параноидальным? Или есть ли способ улучшить удобочитаемость при сохранении этого надежным?
- Примечание 1: я добавил комментарии между
<и>только для разъяснения. - Примечание 2: основной дурак, которого я пытаюсь предотвратить для злоупотребления моим кодом, является моим будущим сам.
7 ответов
Вот несколько полезных советов по идиомам Python с этой страницы :
Вылавливайте ошибки, а не избегайте их, чтобы не загромождать код особыми случаями. Эта идиома называется EAFP («проще просить прощения, чем разрешения»), в отличие от LBYL («посмотрите, прежде чем прыгнуть»). Это часто делает код более читабельным. Например:
Хуже:
#check whether int conversion will raise an error
if not isinstance(s, str) or not s.isdigit:
return None
elif len(s) > 10: #too many digits for int conversion
return None
else:
return int(str)
Лучше:
try:
return int(str)
except (TypeError, ValueError, OverflowError): #int conversion failed
return None
(Обратите внимание, что в этом случае вторая версия намного лучше, так как она правильно обрабатывает ведущие + и -, а также значения от 2 до 10 миллиардов (для 32 -битные машины). Не загромождайте свой код, ожидая всех возможных сбоев: просто попробуйте и используйте соответствующую обработку исключений.)
В Python необычно использовать атрибут частного экземпляра, а затем предоставлять его через свойство, как у вас. Просто используйте self.text_values .
Ваш код слишком параноидальный (особенно когда вы хотите защитить себя только от себя).
В кругах Python LBYL обычно (но не всегда) осуждается . Но есть также (часто неустановленное) предположение, что у человека есть (хорошие) модульные тесты.
Я лично? Я считаю, что удобочитаемость имеет первостепенное значение. Я имею в виду, если вы сами думаете, что это трудно читать, что подумают другие? И менее читаемый код также с большей вероятностью обнаружит ошибки. Не говоря уже о том, что над этим труднее и труднее работать (вам нужно покопаться, чтобы найти, что на самом деле код делает во всем этом LBYLing)
Если вы попытаетесь сделать свой код полностью защищенным от дурака, кто-то придумает дурака получше. Серьезно, хорошее практическое правило - защищаться от вероятных ошибок, но не загромождайте свой код, пытаясь продумать все мыслимые способы, которыми вызывающий абонент может вас сломать.
вместо того, чтобы тратить время на assert и частную переменную, я предпочитаю тратить время на документацию и тестовые примеры. Я предпочитаю читать документацию, а когда мне нужно читать код, я предпочитаю читать тесты. это тем более верно, чем больше кода растет. в то же время тесты дают вам надежный код и полезные варианты использования.
«Мой стиль программирования на Python слишком параноидален? Или есть способ улучшить читаемость, сохранив при этом защиту от дурака?»
От кого ты защищаешься?
]Вы? Вы беспокоитесь, что не помните API, который написали?
Пир? Вы обеспокоены тем, что кто-то из соседнего кабинета будет активно пытаться передать неправильные данные через API? Вы можете поговорить с ними, чтобы решить эту проблему. Если вы предоставите документацию, это сэкономит много кода.
Полный социопат, который загрузит ваш код, откажется читать документацию API, а затем вызовет все методы с неправильными аргументами? Какую возможную помощь вы можете им оказать?
«Защищенное от дурака» кодирование на самом деле не очень полезно, поскольку все эти сценарии легче решить другим способом.
Если вы защищаете себя от дурака, возможно, это не совсем разумно.
Если вы защищаете своего коллегу или коллегу от дурака, вам следует - возможно, - поговорить с ними и убедиться, что они понимают документацию по API.
Если вы защищаете от дурака несколько гипотетических социопатический программист, стремящийся подорвать API, вы ничего не можете сделать. Это Python. У них есть источник. Зачем им прилагать усилия, чтобы злоупотреблять API, если они могут просто отредактировать исходный код, чтобы что-то сломать?
Чтобы подорвать API, вы ничего не можете сделать. Это Python. У них есть источник. Зачем им прилагать усилия, чтобы злоупотреблять API, если они могут просто отредактировать исходный код, чтобы что-то сломать? Чтобы подорвать API, вы ничего не можете сделать. Это Python. У них есть источник. Зачем им прилагать усилия, чтобы злоупотреблять API, если они могут просто отредактировать исходный код, чтобы что-то сломать?Необходимость проверки кода на наличие ошибок я основываю на последствиях тех ошибок, которые он проверяет. Если дерьмовые данные попадут в мою систему, как долго я их обнаружу, как трудно будет определить, что проблема была дерьмовыми данными, и как сложно будет ее исправить? В таких случаях, как тот, который вы разместили, ответы, как правило, "не долго", "не трудно" и "не сложно"
Но данные, которые будут где-то сохраняться, а затем использоваться в качестве входных данных для сложного алгоритма через шесть недель? Я это проверю.