Как я могу написать код, не “нуждаясь” в комментариях для удобочитаемости? [дубликат]

11
задан Community 23 May 2017 в 12:25
поделиться

7 ответов

Ответ в одной строке:

''.join(random.choice(string.ascii_uppercase + string.digits) for _ in range(N))

или даже короче, начиная с Python 3,6 с помощью random.choices () :

''.join(random.choices(string.ascii_uppercase + string.digits, k=N))

криптографически более защищенная версия; см https://stackoverflow.com/a/23728630/2213647 :

''.join(random.SystemRandom().choice(string.ascii_uppercase + string.digits) for _ in range(N))

Подробно, с чистой функцией для дальнейшего использования:

>>> import string
>>> import random
>>> def id_generator(size=6, chars=string.ascii_uppercase + string.digits):
...    return ''.join(random.choice(chars) for _ in range(size))
...
>>> id_generator()
'G5G74W'
>>> id_generator(3, "6793YUIO")
'Y3U'

Как это работает?

Мы импортируем строку , модуль, который содержит последовательности общих символов ASCII, и случайный , модуль, который занимается случайным порождением.

string.ascii _ uppercase + string.digits только что объединяет список символов, представляющих символы и цифры ASCII верхнего регистра:

>>> string.ascii_uppercase
'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
>>> string.digits
'0123456789'
>>> string.ascii_uppercase + string.digits
'ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'

Затем мы используем понимание списка для создания списка «n» элементов:

>>> range(4) # range create a list of 'n' numbers
[0, 1, 2, 3]
>>> ['elem' for _ in range(4)] # we use range to create 4 times 'elem'
['elem', 'elem', 'elem', 'elem']

В приведенном выше примере мы используем [ для создания списка, но не в функции id _ generator , поэтому Python не создает список в памяти, а генерирует элементы на лету, один за другим (подробнее об этом здесь ).

Вместо запроса на создание «n» раз строки elem , мы попросим Python создать «n» раз случайный символ, выбранный из последовательности символов:

>>> random.choice("abcde")
'a'
>>> random.choice("abcde")
'd'
>>> random.choice("abcde")
'b'

Поэтому random.choice (chars) для _ в диапазоне (size) действительно создает последовательность из символов размера . Символы, которые произвольно выбираются из символов :

>>> [random.choice('abcde') for _ in range(3)]
['a', 'b', 'b']
>>> [random.choice('abcde') for _ in range(3)]
['e', 'b', 'e']
>>> [random.choice('abcde') for _ in range(3)]
['d', 'a', 'c']

Затем мы просто соединяем их с пустой строкой, так что последовательность становится строкой:

>>> ''.join(['a', 'b', 'b'])
'abb'
>>> [random.choice('abcde') for _ in range(3)]
['d', 'c', 'b']
>>> ''.join(random.choice('abcde') for _ in range(3))
'dac'
-121--1754640-

В месте, где я арендую сервер, они сбрили изображения Ubuntu до минимума. Предположительно потому, что им все равно приходилось делать особый образ с как раз правильными водителями и таковыми в нем, но я точно не знаю. Они даже удалили wget и nano. Так что вы получаете все apt-get goodness и не много «cookie-cutter» OS.

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

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

На стороне веб-сервера я бы предложил взглянуть на cherokee, если еще не сделал этого. Это может быть не твоя чашка Джо, но нет никакого вреда, чтобы попробовать это. Я предпочитаю легкую установку как Ubuntu, так и Cherokee. Хотя я играю с большим количеством вещей для удовольствия, я предпочитаю это для своего бизнеса. У меня есть другие задачи, кроме управления серверами, поэтому любое решение, которое поможет мне сделать это быстрее, просто хорошо. Если эти проекты в основном для удовольствия, то это, скорее всего, не будет применяться, так как вы не получите много опыта от этих простых-с-приятно-gui-и-очень-helpfull-мастеров

-121--3366959-

Я не думаю, что вы можете обычно писать код без комментариев.

Вкратце, код документирует как . Документ комментариев почему .

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

25
ответ дан 3 December 2019 в 00:44
поделиться

Рекомендуемая литература: Чистый код Роберта К. Мартина.

Вкратце, вы должны

  • использовать значимые имена переменных / методов / классов,
  • делать ваши функции / методы короткими,
  • пусть каждый класс и метод делают только одно,
  • имеют код в каждый метод находится на одном уровне абстракции.

Не бойтесь извлекать даже умеренно сложные выражения из if операторов; какой из них легче читать, это

if (i >= 0 && (v.size() < u || d == e)) ...

или

if (foundNewLocalMaximum()) ...

(Не пытайтесь найти какой-либо смысл в первом фрагменте кода, я просто придумал его: -)

Комментарии в чистом коде почти никогда не нужны. Единственные исключения, о которых я могу думать, - это если вы используете какую-то неясную языковую функцию (например, метапрограммирование шаблона C ++) или алгоритм, и вы даете ссылку на источник метода / алгоритма и детали его реализации в комментарии.

Основная причина, по которой любые другие виды комментариев не очень полезны в долгосрочной перспективе, заключается в том, что код изменяется, а комментарии, как правило, не обновляются вместе с изменениями в соответствующем коде. Итак, через некоторое время комментарий не просто бесполезен, он вводит в заблуждение: он сообщает вам что-то (примечания по реализации, рассуждения о вариантах дизайна, исправления ошибок и т. Д.), Что относится к версии кода, которая давно ушла, и у вас есть не знаю, актуально ли это больше для текущей версии кода.

Другая причина, по которой я думаю, что «почему я выбрал это решение» чаще всего не стоит документировать в коде, заключается в том, что краткая версия такого комментария почти всегда будет похожа на «либо», потому что я думаю, что это лучший способ "или ссылка, например, на «Язык программирования C ++, глава 5.2.1», а полная версия будет представлять собой трехстраничное эссе. Я думаю, что опытный программист чаще всего видит и понимает, почему код так написан без особых пояснений, а новичок может не понять даже самого объяснения - не стоит пытаться охватить всех.

И последнее, но не менее важное: модульные тесты IMO почти всегда являются лучшим способом документирования, чем комментарии к коду: ваши модульные тесты довольно эффективно документируют ваше понимание, предположения и рассуждения о коде, более того, вам автоматически напоминают, чтобы они синхронизировались. с кодом всякий раз, когда вы их нарушаете (ну, при условии, что вы действительно запускаете их со своей сборкой ...).

25
ответ дан 3 December 2019 в 00:44
поделиться

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

7
ответ дан 3 December 2019 в 00:44
поделиться

Самые важные вещи, которым нужно следовать:

  • дайте вашим переменным, методам, классам ... значимые имена
  • напишите классы / модули с чистая ответственность
  • не путайте разные уровни кода (не выполняйте сдвиг битов и логику высокого уровня внутри одного метода)
4
ответ дан 3 December 2019 в 00:44
поделиться

Я лично считаю, что отсутствие комментариев так же плохо, как и чрезмерное комментирование. Вам просто нужно найти правильный баланс. Об использовании длинных описательных имен для вещей, о которых я говорю: прочтите это Также прочтите Kernighan & Pike о длинных именах.

2
ответ дан 3 December 2019 в 00:44
поделиться

Вам нужно следовать определенным правилам.

  • Дайте сущностям (переменным, классам и т.д.) читаемые и осмысленные имена.
  • Широко используйте паттерны проектирования и называйте их соответственно, например, если это фабрика, назовите ее FooFactory.
  • Правильно форматируйте код и т.д.
1
ответ дан 3 December 2019 в 00:44
поделиться

Я думаю, что полезно писать комментарии для ПОЛЬЗОВАТЕЛЕЙ вашего кода - что делают классы/методы/функции, когда и как их вызывать и т.д.. Другими словами, документировать API.

Если вам нужно прокомментировать, как работает метод, для пользы сопровождающих, тогда я думаю, что код, вероятно, слишком сложен. В таком случае рефакторите его на более простые функции, как уже говорили другие.

2
ответ дан 3 December 2019 в 00:44
поделиться
Другие вопросы по тегам:

Похожие вопросы: