Как Вы пишете код, который легко прочитан другими людьми, у которых не было руки в письменной форме никакая часть его?
Функция отображения списка с возвратом имеет преимущество сохранения набора текста, особенно во время интерактивных сеансов. Вы можете определить функцию lmap (по аналогии с python2's imap), которая возвращает список:
lmap = lambda func, *iterable: list(map(func, *iterable))
Тогда вызов lmap вместо map выполнит задание: lmap(str, x) короче на 5 символов (30% в этом случае), чем list(map(str, x)) и, конечно, короче [str(v) for v in x]. Вы также можете создавать похожие функции для filter.
Был комментарий к исходному вопросу:
Я бы предложил переименовать в Get Map (), чтобы вернуть список в Python 3. *, как это применимо ко всем версиям Python3. Есть ли способ сделать это? - meawoppl 24 января в 17:58
Возможно, это , но это очень плохая идея. Просто для удовольствия, вот как вы можете (но не должны) делать это:
__global_map = map #keep reference to the original map lmap = lambda func, *iterable: list(__global_map(func, *iterable)) # using "map" here will cause infinite recursion map = lmap x = [1, 2, 3] map(str, x) #test map = __global_map #restore the original map and don't do that again map(str, x) #iterator
13 ответов
Лучший способ гарантировать, что другие могут прочитать Ваш код, состоит в том, чтобы удостовериться, что это ясно и кратко. А именно,
- Используйте сам документирующие названия переменных, функций и классов.
- Прокомментируйте сложные алгоритмы так, чтобы читатель не тратил к долгому выяснению, что это делает.
- Удостоверьтесь, что переключение вкладок и разрывы строки является постоянным всюду по коду.
Кроме того Вы начинаете входить к областям, которые могли бы быть немного субъективными, большинство людей должно договориться об этих объектах.
Этот вопрос субъективен, и должен избежаться на StackOverflow согласно FAQ
Какие вопросы разве я не должен задавать здесь?
Постарайтесь не задавать вопросы, которые субъективны, спорны, или требуют расширенного обсуждения. Это - место для вопросов, на которые можно ответить!
Короткий ответ был бы:
Избегайте чрезмерного комментария:
// add one to the count: i++;Используйте хорошие имена переменной и имена методов:
int x = i + j; int runSum = prevSum += newValue;Используйте стенографию кодирования где доступный:
if (x == y) { z = a; } else { z = b; } z = (x == y) ? a : b;
Можно хотеть смотреть на Чистый Код Robert C. Martin. Это предлагает много полезных методов для обеспечения Вашего кода, читаемо.
Кроме того, если Ваш код поддерживается многими модульными тестами, которые полностью тестируют Ваш код, он предлагает способ для Вашего пользователя понять код путем взгляда на то, что делают тесты. Вы также найдете, что, если Вы следуете за процессом Разработки через тестирование и Вами тесты записи на каждый бит функциональности, Ваши функции имеют тенденцию быть небольшими, делать одну вещь только и делать это хорошо и иметь тенденцию течь больше как история, чем просто большая сложная сеть "материала".
Тесты имеют тенденцию оставаться в курсе больше, чем комментарии. Я часто игнорирую комментарии больше из-за очевидного факта, что они становятся устаревшими очень быстро.
Сохраните код хорошим, ясным и простым. Не комментируйте, что Вы делаете, когда это очевидно (например, я знаю то, что foreach или если делает, мне обычно не нужно объяснение).
Приемы кода (такие как автоматические свойства), которые заставляют простые вещи поднять меньше строк, хороши также.
Купите и прочитайте Код Полные 2. Существуют загрузки материала там о записи легкого читать / поддерживают код.
Я не думаю, что это - субъективный вопрос, но это слишком широко! Это примерно не комментирует и дает хорошие имена переменных. Это имеет дело с тем, как люди постигают код. Таким образом, Ваша система должна быть реализована способом, что читатель может легко создать умственную модель ее дизайна двумя способами:
Сверху вниз: принятие пользователя знает системный домен, он склонен делать предположения о том, как это было бы реализовано, таким образом, он просканирует системные пакеты и классы, ища объекты, он может определить. При давании хороших имен к классам и правильно модульном исполнении это помогло бы очень.
Вверх дном: после того как пользователь достигает части кода, он запустит навигацию оттуда, создавая блоки знания. Если Ваша система будет иметь низкое сцепление и много неявных зависимостей, то пользователь будет потерян.
Kent Beck принимает три принципа: Коммуникация, Простота и Гибкость. Конечно, иногда необходимо будет обменять простоту на гибкость, и наоборот.
Это могло продолжиться и на. Ответ на этот вопрос вписывается в большую книгу. Как @rmbarnes предложенный, купите и прочитайте Код Полные 2. Я также предлагаю Шаблоны Реализации Kent Beck - ее очень связанный с Вашим вопросом.
- Зарегистрируйте код относительно того, почему он делает то, что он делает.
- Удостоверьтесь, что все функции переменных и т.д. называют последовательно и описательно
- Используйте пробел для собирания в группу логических частей кода, таким образом, он течет при чтении.
- Поместите функции/методы и т.д. в логический порядок.
- (этот - мое персональное предпочтение), Удостоверяются, что код может легко быть прочитан на экране, не имея необходимость прокручивать горизонтально (некоторые люди говорят вертикально также, но это, кажется, не беспокоит меня).
Так как все остальные сказали в значительной степени, что я думаю, когда я считал этот вопрос, я просто совместно использую две книги, связанные с этим предметом, что Вы могли бы интересоваться чтением. Эти книги используют примеры открытого исходного кода, чтобы объяснить, как прочитать и написать высококачественный код. Кроме того, для Кодирования Завершенный я думаю, что они - ценные ресурсы, когда Вы хотите написать хороший код на любом языке.
Мои правила:
- Дайте всему понятное имя и назовите его, каково это. Избегайте использования "x" и "y" для переменных.
- НИЧЕГО не сокращайте. Я не забочусь, какой длины имя переменной, не сокращайте, даже с комментариями. Интерпретация сокращений субъективна. Cmp означает компьютер? Компьютер? Компания? Комплимент? Сделайте это сильным правилом, никакими исключениями и его легким для следования.
- Не помещайте несколько операторов на ту же строку. Каждая строка выполняет единственное действие.
- Избегайте Венгерской записи как чумы. Или это - ntHungarian?
- Используйте скобки даже для одной строки (если, для) подструктуры. Различия в добавлении отступа слишком легки для потери.
Вероятно, наиболее важный момент должен сохранить Ваш синтаксис последовательным. Я также взглянул бы на руководство по проектированию для языка, в котором Вы пишете.
Я наиболее вероятен в меньшинстве, но я не возражаю против пробела. Я ЛЮБЛЮ ПРОБЕЛ. Так как компилятор вынимает его и пространство HD, являющееся настолько дешевым, мне нравится иметь пробел в моем коде.
Например, мне нравится:
int total = 10;
int sum = 0;
for (int i = 0; i < total; i++)
{
sum += i;
}
// Next coding statement is a space below the bracket
return sum;
Мне не нравится:
int total = 10;int sum = 0;
for (int i = 0; i < total; i++)
{
sum += i;
}
return sum;
Что я также поместил в скобках даже при том, что технически они не нужны. Лучший пример если оператор. Я нахожу, что это значительно помогает удобочитаемости.
if(true)
// some action
if(true)
{
// Some action
}
Лучший код мне, тот что максимально простой. С наименьшим количеством комментариев как возможное, и самое главное работает.
От того, чтобы быть разработчиком с несколькими годами ниже пояса, это раньше было реальным вопросом для меня. Я не мог даже сказать, сколько часов я передал взгляды об этом и попытку разных вещей в моем коде. Вышеупомянутые ответы очень хороши также. Я просто хочу добавить вещь или два.
У каждого из нас есть разные вещи, которые делают наше чтение отличающимся, чем другие. Что-то, что Вы находите легкими читать, могло бы действительно быть трудно для кого-то еще читать.
Чистота Вашего кода является очень важным аспектом. Скоро, поскольку это слишком ограничено, просто забывают об этом.
Самый важный: Вы - Вы, владеют учителем. Независимо от того, что разрабатывает Вас, следуют, Вы захотите изменить вещь или два на основе Вашего опыта. Когда передача месяцев и Вы должны вернуться к Вашему старому для мер или документации, Вы будете иметь, "Я не могу полагать, что написал код, который читает как этот" эффект. Сделайте заметки того, что прослушивало Вас с удобочитаемостью кода, и удостоверьтесь, что не записали как этот снова.
Много хороших ответов здесь, я хотел бы добавить что-то с точки зрения инженера, которому нравится большое изображение. Я часто находил, что, получая обзор высокого уровня, с точки зрения диаграммы классов или обзора уровня пакета (схематически изображают/комментируют и т.д.), heck, если ничто не существует, 10 заголовков строки комментируют в файле для помощи мне много. Мы можем использовать Doxygen/Javadocs, чтобы генерировать их или провести 10-15 минут, чтобы просто кратко записать что-то в разделе комментариев.
Они не должны быть на 100% точными, и я сомневаюсь, что полная структура классов/пакетов изменится без полного, переписывают.
Я лично нашел этот вид большого обзора изображения очень полезным и уверен, что существуют другие, которые чувствуют то же.