Действительно ли Стиль программирования важен? Как Важный? [закрытый]
Если вам нужен самый быстрый способ, вы можете комбинировать itertools с operator.add:
In [36]: from operator import add
In [37]: from itertools import starmap, izip
In [38]: timeit "".join([i + j for i, j in uzip(l1, l2)])
1 loops, best of 3: 142 ms per loop
In [39]: timeit "".join(starmap(add, izip(l1,l2)))
1 loops, best of 3: 117 ms per loop
In [40]: timeit "".join(["".join(item) for item in zip(l1, l2)])
1 loops, best of 3: 196 ms per loop
In [41]: "".join(starmap(add, izip(l1,l2))) == "".join([i + j for i, j in izip(l1, l2)]) == "".join(["".join(item) for item in izip(l1, l2)])
Out[42]: True
Но объединение izip и chain.from_iterable выполняется быстрее
In [2]: from itertools import chain, izip
In [3]: timeit "".join(chain.from_iterable(izip(l1, l2)))
10 loops, best of 3: 98.7 ms per loop
Существует также существенное различие между chain(* и chain.from_iterable(....
In [5]: timeit "".join(chain(*izip(l1, l2)))
1 loops, best of 3: 212 ms per loop
Нет такой вещи, как генератор с соединением, проходящий один, всегда будет быть медленнее, поскольку python будет сначала создавать список, используя контент, потому что он выполняет два прохода над данными, один для определения необходимого размера и один для фактического выполнения соединения, который невозможен с помощью генератора:
join.h :
/* Here is the general case. Do a pre-pass to figure out the total
* amount of space we'll need (sz), and see whether all arguments are
* bytes-like.
*/
Также, если у вас разные строки длины, и вы не хотите потерять данные, вы можете использовать izip_longest :
In [22]: from itertools import izip_longest
In [23]: a,b = "hlo","elworld"
In [24]: "".join(chain.from_iterable(izip_longest(a, b,fillvalue="")))
Out[24]: 'helloworld'
Для python 3 он называется zip_longest
. Но для python2 предложение veedrac является самым быстрым:
In [18]: %%timeit
res = bytearray(len(u) * 2)
res[::2] = u
res[1::2] = l
str(res)
....:
100 loops, best of 3: 2.68 ms per loop
45 ответов
Мне трудно полагать, что любой думал бы, что никакое добавление отступа не является хорошей идеей. Это является просто немым, я не позвонил бы ему назад также, если бы он сделал это для меня на интервью.
Комментарии немного более серы, большой код сам документирующий в большой степени. ЕСЛИ Вы пишете, что большой код тогда комментирует, должны только быть места экономно в местах, где то, что продолжается, действительно сложно и твердо следовать.
Я не возражал бы против него, он сразу не вставил комментарии. Но добавление отступа важно. Когда Вы пишете код, он редко выходит линейно в одном припадке ввода безумства.
нет, даже прежде, чем протестировать и возможно отладить код, обычно существует большое редактирование и способность ясно видеть, что структура кода важна.
Это напоминает мне об инциденте, который произошел рано в моей карьере. Я был младшим программистом уровня, и другой младший программист попросил у меня некоторой справки на его коде. Мы использовали Паскаль в то время. Его код был путаницей. Я видел код без добавления отступа прежде, но никогда не видел код со случайным добавлением отступа. Не было никакого способа следовать за ним.
Так, первая вещь, которую я сделал, состояла в том, чтобы зафиксировать добавление отступа. Он самодовольно сказал. "Я не думаю , это попытка зафиксировать его!". Я оглянулся назад на код. Ошибку было теперь легко определить, таким образом, я просто указал на нее и ушел.
Ну, факт - то, что фаза жизненного цикла программного обеспечения, в которой это живет самое длинное, является обслуживанием. В течение того времени это главным образом читается и анализируется Хумань, пытающимся зафиксировать его, снова использовать его, улучшить его, и т.д. Это - лучшая причина сохранить его легко читаемым и понятным. Кто-то заявляющий, что у него нет времени волноваться о стиле, который явно влияет на readibility, показывает только его незрелость как разработчика программного обеспечения. Или возможно просто никакое понимание жизненного цикла программного обеспечения.
Стиль программирования очень важен. Чистый код радует глаз и улучшает пригодность для обслуживания программы. Поэтому это непосредственно связывается с качеством и архитектурой самой программы.
Даже на языке, который вызывает добавление отступа, каждый может действительно, повредил все с плохим стилем. Плохой стиль не может поэтому быть отсутствием добавления отступа или комментариев. На самом деле я редко использую комментарии, я очень скорее предпочитаю docstrings и в целом запись лучшей документации. Я связываю комментарии к маленьким примечаниям, которые Вы распространяете вокруг кода, если Вы действительно видите, что существует что-то, чтобы зафиксировать или задаться вопросом о там.
я рассматривал бы плохой стиль как не разрешение языку программирования сделать часть Вашего материала для Вас. Надлежащий, чисто записанный макрос в месте или два является действительно хорошим стилем, а не плохо.
Существует другая причина, почему стиль кода важен. Это может действовать как прокси для определения профессионализма программиста. Так же, как растушевки хвоста павлина демонстрируют его здоровье, и мужество (нездоровый организм не был бы в состоянии посвятить дефицитные ресурсы в создание шикарного хвоста), стиль программы может показать много относительно человека, который записал его.
, Когда я вижу плохо отформатированный код с непоследовательными соглашениями о присвоении имен и недостаточными комментариями, я держусь далеко от него не только потому, что такой код по сути нечитабелен, но также и потому что код, довольно вероятно, будет питать еще худшие проблемы под этой неприятной поверхностью.
Я хотел бы знать, как любой достойный программист мог записать код без добавления отступа, сделано ли это в IDE, vi, Блокноте, на электронной доске, или на постэтом. Расположение с отступом кода должно произойти естественно. Я не перезвонил бы ему, если бы то, что он возвратил, выглядело примерно так (я просто копирую реализацию прочь Википедии, фокус находится на отсутствии добавления отступа):
struct Node{
data
next
prev
}
struct List{
Node firstNode
Node lastNode
}
function insertAfter(List list, Node node, Node newNode) {
newNode.prev := node
newNode.next := node.next
if node.next = null
list.lastNode := newNode
else
node.next.prev := newNode
node.next := newNode
}
function insertBefore(List list, Node node, Node newNode) {
newNode.prev := node.prev
newNode.next := node
if node.prev is null
list.firstNode := newNode
else
node.prev.next := newNode
node.prev := newNode
}
function remove(List list, Node node){
if node.prev = null
list.firstNode := node.next
else
node.prev.next := node.next
if node.next = null
list.lastNode := node.prev
else
node.next.prev := node.prev
destroy node
}
Если Вы проводите больше времени на делающем отступ коде, чем фактическая запись его, это могла бы быть проблема. Но моделирование исходного кода, соглашения и непротиворечивость через решение важны.
Именно поэтому я полагаюсь на инструмент, чтобы сделать это. Resharper позволяет мне переформатировать весь свой код путем нажатия Ctrl+F, комбинации ключей E.
Ваш друг должен разобраться в своих приоритетах, и по-моему я полагаю, что Microsoft заботилась бы больше тогда, что Вы, кажется, думаете, что они были бы.
Я всегда чувствовал, что одна вещь, на которую можно рассчитывать, состоит в том, что люди, которые смотрят код после того, как Вы ушли, будут думать, что Вы - идиот. Ключевая вещь состоит в том, чтобы максимизировать время между тем, когда код сначала просматривается и когда они делают то определение.
Хорошее форматирование является одним способом увеличить N, полезные комментарии - другой.
Это - весь вопрос того, кто целевая аудитория исходного кода. Корректный ответ является "другими программистами" (специалисты по обслуживанию, и т.д.). Ваш коллега думал, что это не было важно, и я полностью понимаю, почему MS не нанимал его. Я был бы удивлен, наймет ли какая-либо крупная компания его вообще!
я помню старую статью, названную" , Типографский стиль более, чем косметический ", появился на "Связи ACM", который сделал эксперименты на влиянии хорошего отформатированного кода производительности.
Они взяли группу программистов и дали им тест для рейтинга их. Тогда они разделили группу на два, два группируют то же присвоение: измените часть программного обеспечения для добавления некоторой функциональности.
Только, что первая группа заставила приятно отформатированный исходный код продолжать работать и у других была довольно грязная версия того же кода.
Они измерили свой productivty снова, и конечный результат состоял в том что ХУДШИЙ программист первой группы, выигранной лучше, чем ЛУЧШИЙ программист второй группы.
С тех пор, я всегда прикладывал дополнительные усилия к коду makingmy, ясному читать для других людей.
Для заинтересованных темой я предлагаю читать о грамотном программировании, намеренном программировании и других связанных понятиях.
О "стиле" (который я назвал бы "форматированием"): это - в основном вопрос персонального вкуса, но работающий в команде очень важное определение некоторых инструкций, за которыми ВСЕ должны следовать, изгибая его персональные предпочтения в случае необходимости (в Eclipse, мы экспортируем конфигурацию средства форматирования, и с нажатием клавиши мы отформатировали файл). Очень скоро все привыкнут к стандарту, и читающий код будет очень менее утомительным.
О комментариях: Я предпочитаю хорошее именование для своих методов, но комментарий два на самых неясных частях обязателен.
Можно утверждать, что правильно написанному коду не нужны комментарии или по крайней мере очень немного комментариев. Но отсутствие расположения с отступом не приемлемо. Компилятор действительно заботится (в большинстве случаев), но люди, поддерживающие код, делают.
Код читается тремя объектами: компьютер, программист, и в конечном счете специалист по обслуживанию.
Стиль и Форматирование не важны компьютеру, возможно важны для программиста, но это, конечно, важно для специалиста по обслуживанию, который должен попытаться постигать функциональность программы.
Отказ разместить других разработчиков путем создания кода читаемым непочтителен.
Создание организовало код со значимыми именами переменной, и комментарии форма общей любезности кому-либо еще, кто читает его.
Разработчик, который не заботится о стиле, похож на художника, живописца, который не заботится о цвете.
Я склонен думать, что стиль программирования на самом деле больше отражает то, какими программистами мы являемся.
Если мы напишем небрежный код, не обращая внимания на мир, да, тогда я бы подумал, что мы изображаем отношение, которое мы не уважаем других членов команды, но если мы найдем время, чтобы писать в стиле это понятно, и сознательно стараемся убедиться, что наш код разборчив и правильно структурирован, тогда, конечно, мы изображаем, что у нас есть отношение к нашей команде?
Стиль больше говорит о том, кто мы есть, а не о том, что мы знаем.